idnits 2.17.1 

draft-ietf-ppsp-peer-protocol-12.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 :
  ----------------------------------------------------------------------------

  == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the
     document.

  == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.


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

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

  -- The document date (November 28, 2014) is 3430 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'

  ** Downref: Normative reference to an Experimental RFC: RFC 6817

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

  -- 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: 1 error (**), 0 flaws (~~), 4 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: June 1, 2015                                     V. Grishchenko
6	                                           Technische Universiteit Delft
7	                                                       November 28, 2014

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

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 June 1, 2015.

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  . . . . . . . . . . . . . . . . . . . . . . . .   5
67	     1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   5
68	     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   6
69	     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
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  . . . . . . . . . . . . . . . .  10
74	   3.  Messages  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
75	     3.1.  HANDSHAKE . . . . . . . . . . . . . . . . . . . . . . . .  11
76	       3.1.1.  Handshake Procedure . . . . . . . . . . . . . . . . .  12
77	     3.2.  HAVE  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
78	     3.3.  DATA  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
79	     3.4.  ACK . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
80	     3.5.  INTEGRITY . . . . . . . . . . . . . . . . . . . . . . . .  15
81	     3.6.  SIGNED_INTEGRITY  . . . . . . . . . . . . . . . . . . . .  16
82	     3.7.  REQUEST . . . . . . . . . . . . . . . . . . . . . . . . .  16
83	     3.8.  CANCEL  . . . . . . . . . . . . . . . . . . . . . . . . .  16
84	     3.9.  CHOKE and UNCHOKE . . . . . . . . . . . . . . . . . . . .  17
85	     3.10. Peer Address Exchange . . . . . . . . . . . . . . . . . .  17
86	       3.10.1.  PEX_REQ and PEX_RES Messages . . . . . . . . . . . .  17
87	     3.11. Channels  . . . . . . . . . . . . . . . . . . . . . . . .  18
88	     3.12. Keep Alive Signalling . . . . . . . . . . . . . . . . . .  19
89	   4.  Chunk Addressing Schemes  . . . . . . . . . . . . . . . . . .  20
90	     4.1.  Start-End Ranges  . . . . . . . . . . . . . . . . . . . .  20
91	       4.1.1.  Chunk Ranges  . . . . . . . . . . . . . . . . . . . .  20
92	       4.1.2.  Byte Ranges . . . . . . . . . . . . . . . . . . . . .  21
93	     4.2.  Bin Numbers . . . . . . . . . . . . . . . . . . . . . . .  21
94	     4.3.  In Messages . . . . . . . . . . . . . . . . . . . . . . .  23
95	       4.3.1.  In HAVE Messages  . . . . . . . . . . . . . . . . . .  23
96	       4.3.2.  In ACK Messages . . . . . . . . . . . . . . . . . . .  23

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

206	1.  Introduction

208	1.1.  Purpose

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

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

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

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

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

256	   The protocol defined in this document assumes that a peer has already
257	   discovered a list of (initial) peers using, for example, a
258	   centralized tracker [I-D.ietf-ppsp-base-tracker-protocol].  Once a
259	   peer has this list of peers, PPSPP allows the peer to connect to
260	   other peers, request chunks of content, and discover other peers
261	   disseminating the same content.

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

270	1.2.  Requirements Language

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

276	1.3.  Terminology

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

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

289	   content
290	       Either a live transmission or a pre-recorded multimedia file.

292	   chunk
293	       The basic unit in which the content is divided.  E.g. a block of
294	       N kilobyte.  A chunk may be of variable size.

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

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

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

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

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

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

323	   hash
324	       The result of applying a cryptographic hash function, more
325	       specifically a modification detection code (MDC) [HAC01], such as
326	       SHA-256 [FIPS180-4], to a piece of data.

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

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

338	   munro hash
339	       The hash of a subtree that is the unit of signing in the Unified
340	       Merkle Tree content authentication scheme for live streaming (see
341	       Section 6.1.2.1).

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

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

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

359	   choking
360	       When a peer A is choking peer B it means that A is currently not
361	       willing to accept requests for content from B.

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

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

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

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

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

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

389	2.  Overall Operation

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

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

403	2.1.  Example: Joining a Swarm

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

416	   Peer A now registers with the tracker following the PPSP tracker
417	   protocol [I-D.ietf-ppsp-base-tracker-protocol] and receives the IP
418	   address and port of peers already in the swarm, say B, C, and D.  At
419	   this point the PPSPP peer protocol starts operating.  Peer A now
420	   sends a datagram containing a PPSPP HANDSHAKE message to B, C, and D.
421	   This message conveys protocol options.  In particular, peer A
422	   includes the ID of the swarm (part of the swarm metadata) as a
423	   protocol option, because the destination peers can listen for
424	   multiple swarms on the same transport address.

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

434	2.2.  Example: Exchanging Chunks

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

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

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

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

471	2.3.  Example: Leaving a Swarm

473	   To leave a swarm in a graceful way, peer A sends a specific HANDSHAKE
474	   message to all its peers (see Section 8.4) and deregisters from the
475	   tracker following the (PPSP) tracker protocol.  Peers receiving the
476	   datagram should remove A from their current peer list.  If A crashes
477	   ungracefully, peers should remove A from their peer list when they
478	   detect it no longer sends messages (see Section 3.12).

480	3.  Messages

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

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

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

509	3.1.  HANDSHAKE

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

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

518	   (b)  the chunk size used,

520	   (c)  the chunk addressing method used,

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

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

526	   (f)  If automatic content size detection (see Section 5.6) is not
527	        used, the content length is also part of the metadata (for
528	        static content.)

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

534	   The payload of the HANDSHAKE message contains a sequence of protocol
535	   options.  The protocol options encode the swarm metadata just
536	   described to enable an end-to-end check whether the peers are in the
537	   right swarm, and a number of per-peer configuration parameters.  The
538	   complete set of protocol options are specified in Section 7.  The
539	   HANDSHAKE message also contains a channel ID, for multiplexing
540	   communication and security, see Section 3.11 and Section 13.1.  A
541	   HANDSHAKE message MUST always be the first message in a datagram.

543	3.1.1.  Handshake Procedure

545	   The handshake procedure for a peer P to start communication with
546	   another peer Q in swarm S is now as follows.

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

552	       *  A channel ID, chanP, randomly chosen as specified in
553	          Section 13.1.

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

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

563	       This first datagram MUST be prefixed with the (destination)
564	       channel ID 0, see Section 3.11.  Hence, the datagram contains two
565	       channel IDs: the destination channel ID prefixed to the datagram,
566	       and the channel ID chanP included in the HANDSHAKE message inside
567	       the datagram.  This datagram MAY also contain some minor
568	       additional payload, e.g.  HAVE messages to indicate P's current
569	       progress, but MUST NOT include any heavy payload (defined in
570	       Section 1.3), such as a DATA message Allowing minor payload
571	       minimizes the number of initialization round-trips, thus
572	       improving time-till-playback.  Forbidding heavy payload prevents
573	       an amplification attack (see Section 13.1.)

575	   2.  The receiving peer Q checks the HANDSHAKE message from peer P.
576	       If any check by Q fails, Q MUST NOT send a HANDSHAKE (or any
577	       other) message back, as the message from P may have been spoofed
578	       (see Section 13.1).  Only if P and Q are in the same swarm, and Q
579	       is interested in communicating with P, Q MUST a datagram to P
580	       that starts with a HANDSHAKE message.  This reply HANDSHAKE MUST
581	       contain:

583	       *  A channel ID, chanQ, randomly chosen as specified in
584	          Section 13.1.

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

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

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

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

610	   4.  Next, peer P checks the HANDSHAKE message in the datagram from Q.
611	       If any check by P fails, or P is no longer interested in
612	       communicating with Q, P MAY send a HANDSHAKE message to inform Q
613	       it will cease communication.  This closing HANDSHAKE message MUST
614	       contain an all 0-zeros channel ID and a list of protocol options.
615	       The list MUST be either empty or contain the maximum version
616	       number peer P supports, following the Min/max versioning scheme
617	       defined in [RFC6709], Section 4.1.  The datagram containing this
618	       closing HANDSHAKE message MUST be prefixed with (destination)
619	       channel ID chanQ.  Peer P MAY also simply cease communication.

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

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

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

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

649	3.2.  HAVE

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

658	   In particular, whenever a receiving peer P has successfully checked
659	   the integrity of a chunk, or interval of chunks, it MUST send a HAVE
660	   message to all peers Q1..Qn it wants to allow to download those
661	   chunk(s).  A policy in peer P determines when the HAVE is sent.  P
662	   may sent it directly, or peer P may wait until either it has other
663	   data to sent to Qi, or until it has received and checked multiple
664	   chunks.  The policy will depend on how urgent it is to distribute
665	   this information to the other peers.  This urgency is generally
666	   determined in turn by the chunk picking policy (see Section 9.1).  In
667	   general, the HAVE messages can be piggybacked onto other messages.
668	   Peers that do not receive HAVE messages are effectively prevented
669	   from downloading the newly available chunks, hence the HAVE message
670	   can be used as a method of choking.

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

679	3.3.  DATA

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

690	3.4.  ACK

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

702	3.5.  INTEGRITY

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

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

719	3.6.  SIGNED_INTEGRITY

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

727	3.7.  REQUEST

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

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

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

750	3.8.  CANCEL

752	   When downloading on demand or live streaming content, a peer can
753	   request urgent data from multiple peers to increase the probability
754	   of it being delivered on time.  In particular, when the specific
755	   chunk picking algorithm (see Section 9.1), detects that a request for
756	   urgent data might not be served on time, a request for the same data
757	   can be sent to a different peer.  When a peer P decides to request
758	   urgent data from a peer Q, peer P SHOULD send a CANCEL message to all
759	   the peers to which the data has been previously requested.  The
760	   CANCEL message contains the specification of the chunks P no longer
761	   wants to request.  In addition, when peer Q receives a HAVE message
762	   for the urgent data from peer P, peer Q MUST also cancel the previous
763	   REQUEST(s) from P.  In other words, the HAVE message acts as an
764	   implicit CANCEL.

766	3.9.  CHOKE and UNCHOKE

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

780	3.10.  Peer Address Exchange

782	3.10.1.  PEX_REQ and PEX_RES Messages

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

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

809	   To use PEX in PPSPP on the Internet, two conditions must be met:

811	   1.  Peer transport addresses must be relatively stable.

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

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

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

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

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

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

854	3.11.  Channels

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

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

877	               _________    _________          _________
878	               |       |    |       |          |       |
879	               | Swarm |    | Swarm |          | Swarm |
880	               |  Mgr  |    |   A   |          |   B   |
881	               |_______|    |_______|          |_______|
882	                   |            |                /   \
883	                   |            |               /     \
884	               ____|____    ____|____    ______/__    _\_______
885	               |       |    |       |    |       |    |       |
886	               | Chan  |    | Chan  |    | Chan  |    | Chan  |
887	               |   0   |    |  481  |    |  836  |    |  372  |
888	               |_______|    |_______|    |_______|    |_______|
889	                   |            |            |            |
890	                   |            |            |            |
891	               ____|____________|____________|____________|____
892	               |                                              |
893	               |                      UDP                     |
894	               |                   port 6778                  |
895	               |______________________________________________|

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

902	                                 Figure 1

904	3.12.  Keep Alive Signalling

906	   A peer SHOULD send a "keep alive" message periodically to each peer
907	   it is interested in, but has no other messages to send to them at
908	   present.  The goal of the keep alives is to keep a signaling channel
909	   open to peers that are of interest.  Which peers those are is
910	   determined by a policy that decides which peers are of interest now
911	   and in the near future.  This document does not prescribe a policy,
912	   but examples of interesting peers are: (a) peers that have chunks on
913	   offer that this client needs, or (b) peers that currently do not have
914	   interesting chunks on offer (because they are still downloading
915	   themselves, or in live streaming), but gave good performance in the
916	   past.  When these peers have new chunks to offer, the peer that kept
917	   a signaling channel open can use them again.  Periodically sending
918	   "keep alive" messages prevents other peers declaring the peer dead.
919	   A guideline for declaring a peer dead when using UDP consists of a 3
920	   minute delay since that last packet has been received from that peer,
921	   and at least 3 datagrams were sent to that peer during the same
922	   period.  When a peer is declared dead, the channel to it is closed,
923	   no more messages will be sent to that peer and the local
924	   administration about the peer is discarded.  Busy servers can force
925	   idle clients to disconnect by not sending keep alives.  PPSPP does
926	   not define an explicit message type for "keep alive" messages.  In
927	   the PPSP-over-UDP encapsulation they are implemented as simple
928	   datagrams consisting of a 4-byte channel ID only, see Section 8.3 and
929	   Section 8.4.

931	4.  Chunk Addressing Schemes

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

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

939	4.1.  Start-End Ranges

941	   A chunk specification consists of a single (start specification,end
942	   specification) pair that identifies a range of chunks (end
943	   inclusive).  The start and end specifications can use one of multiple
944	   addressing schemes.  Two schemes are currently defined, chunk ranges
945	   and byte ranges.

947	4.1.1.  Chunk Ranges

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

953	    0                   1                   2                   3
954	    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
955	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
956	   ~                    Start chunk (32 or 64)                     ~
957	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
958	   ~                    End chunk (32 or 64)                       ~
959	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

961	4.1.2.  Byte Ranges

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

966	    0                   1                   2                   3
967	    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
968	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
969	   |                    Start byte offset (64)                     |
970	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
971	   |                                                               |
972	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
973	   |                    End byte offset (64)                       |
974	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
975	   |                                                               |
976	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

978	4.2.  Bin Numbers

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

990	   In bin addressing, the smallest binary interval is a single chunk
991	   (e.g. a block of bytes which may be of variable size), the largest
992	   interval is a complete range of 2**63 chunks.  In a novel addition to
993	   the classical scheme, these intervals are numbered in a way which
994	   lays them out into a vector nicely, which is called bin numbering, as
995	   follows.  Consider an chunk interval of width W.  To derive the bin
996	   numbers of the complete interval and the subintervals, a minimal
997	   balanced binary tree is built that is at least W chunks wide at the
998	   base.  The leaves from left-to-right correspond to the chunks 0..W-1
999	   in the interval, and have bin number I*2 where I is the index of the
1000	   chunk (counting beyond W-1 to balance the tree).  The bin number of
1001	   higher level nodes P in the tree is calculated as follows:

1003	       binP = (binL + binR) / 2

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

1011	                                   7
1012	                                  / \
1013	                                /     \
1014	                              /         \
1015	                            /             \
1016	                           3                11
1017	                          / \              / \
1018	                         /   \            /   \
1019	                        /     \          /     \
1020	                       1       5        9       13
1021	                      / \     / \      / \      / \
1022	                     0   2   4   6    8   10  12   14

1024	                     C0  C1  C2  C3   C4  C5  C6   C7

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

1028	                                 Figure 2

1030	   So bin 7 represents the complete interval, bin 3 represents the
1031	   interval of chunk C0..C3, bin 1 represents the interval of chunks C0
1032	   and C1, and bin 2 represents chunk C1.  The special numbers
1033	   0xFFFFFFFF (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit) stands for an
1034	   empty interval, and 0x7FFF...FFF stands for "everything".

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

1041	    0                   1                   2                   3
1042	    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
1043	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1044	   ~                    Bin number (32 or 64)                      ~
1045	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1047	4.3.  In Messages

1049	4.3.1.  In HAVE Messages

1051	   When a receiving peer has successfully checked the integrity of a
1052	   chunk or interval of chunks it MUST send a HAVE message to all peers
1053	   it wants to allow download of those chunk(s) from.  The ability to
1054	   withhold HAVE messages allows them to be used as a method of choking.
1055	   The HAVE message MUST contain the chunk specification of the biggest
1056	   complete interval of all chunks the receiver has received and checked
1057	   so far that fully includes the interval of chunks just received.  So
1058	   the chunk specification MUST denote at least the interval received,
1059	   but the receiver is supposed to aggregate and acknowledge bigger
1060	   intervals, when possible.

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

1066	   Implementation note:

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

1073	4.3.2.  In ACK Messages

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

1081	5.  Content Integrity Protection

1083	   PPSPP can use different methods for protecting the integrity of the
1084	   content while it is being distributed via the peer-to-peer network.
1085	   More specifically, PPSPP can use different methods for receiving
1086	   peers to detect whether a requested chunk has been maliciously
1087	   modified by the sending peer.  In benign environments, content
1088	   integrity protection can be disabled.

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

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

1105	5.1.  Merkle Hash Tree Scheme

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

1117	   The Merkle hash tree of a content file that is divided into N chunks
1118	   is constructed as follows.  Note the construction does not assume
1119	   chunks of content to be fixed size.  Given a cryptographic hash
1120	   function, more specifically a modification detection code (MDC)
1121	   [HAC01] , such as SHA-256, the hashes of all the chunks of the
1122	   content are calculated.  Next, a binary tree of sufficient height is
1123	   created.  Sufficient height means that the lowest level in the tree
1124	   has enough nodes to hold all chunk hashes in the set, as with bin
1125	   numbering.  The figure below shows the tree for a content file
1126	   consisting of 7 chunks.  As before with the content addressing
1127	   scheme, the leaves of the tree correspond to a chunk and in this case
1128	   are assigned the hash of that chunk, starting at the left-most leaf.
1129	   As the base of the tree may be wider than the number of chunks, any
1130	   remaining leaves in the tree are assigned an empty hash value of all
1131	   zeros.  Finally, the hash values of the higher levels in the tree are
1132	   calculated, by concatenating the hash values of the two children
1133	   (again left to right) and computing the hash of that aggregate.  If
1134	   the two children are empty hashes, the parent is an empty all zeros
1135	   hash as well (to save computation).  This process ends in a hash
1136	   value for the root node, which is called the "root hash".  Note the
1137	   root hash only depends on the content and any modification of the
1138	   content will result in a different root hash.

1140	                               7 = root hash
1141	                              / \
1142	                            /     \
1143	                          /         \
1144	                        /             \
1145	                      3*               11
1146	                     / \              / \
1147	                    /   \            /   \
1148	                   /     \          /     \
1149	                  1       5        9       13* = uncle hash
1150	                 / \     / \      / \      / \
1151	                0   2   4   6    8   10* 12   14

1153	                C0  C1  C2  C3   C4  C5  C6   E
1154	                =chunk index     ^^           = empty hash

1156	          The Merkle hash tree of a content file with N=7 chunks

1158	                                 Figure 3

1160	5.2.  Content Integrity Verification

1162	   Assuming a peer receives the root hash of the content it wants to
1163	   download from a trusted source, it can check the integrity of any
1164	   chunk of that content it receives as follows.  It first calculates
1165	   the hash of the chunk it received, for example chunk C4 in the
1166	   previous figure.  Along with this chunk it MUST receive the hashes
1167	   required to check the integrity of that chunk.  In principle, these
1168	   are the hash of the chunk's sibling (C5) and that of its "uncles".  A
1169	   chunk's uncles are the sibling Y of its parent X, and the uncle of
1170	   that Y, recursively until the root is reached.  For chunk C4 its
1171	   uncles are nodes 13 and 3 and its sibling is 10; all marked with a *
1172	   in the figure.  Using this information the peer recalculates the root
1173	   hash of the tree, and compares it to the root hash it received from
1174	   the trusted source.  If they match the chunk of content has been
1175	   positively verified to be the requested part of the content.
1176	   Otherwise, the sending peer either sent the wrong content or the
1177	   wrong sibling or uncle hashes.  For simplicity, the set of sibling
1178	   and uncles hashes is collectively referred to as the "uncle hashes".

1180	   In the case of live streaming the tree of chunks grows dynamically
1181	   and the root hash is undefined or, more precisely, transient, as long
1182	   as new data is generated by the live source.  Section 6.1.2 defines a
1183	   method for content integrity verification for live streams that works
1184	   with such a dynamic tree.  Although the tree is dynamic, content
1185	   verification works the same for both live and predefined content,
1186	   resulting in a unified method for both types of streaming.

1188	5.3.  The Atomic Datagram Principle

1190	   As explained above, a datagram consists of a sequence of messages.
1191	   Ideally, every datagram sent must be independent of other datagrams,
1192	   so each datagram SHOULD be processed separately and a loss of one
1193	   datagram must not disrupt the flow of datagrams between two peers.
1194	   Thus, as a datagram carries zero or more messages, both messages and
1195	   message interdependencies SHOULD NOT span over multiple datagrams.

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

1205	   The hashes necessary to verify a chunk are in principle its sibling's
1206	   hash and all its uncle hashes, but the set of hashes to send can be
1207	   optimized.  Before sending a packet of data to the receiver, the
1208	   sender inspects the receiver's previous acknowledgments (HAVE or ACK)
1209	   to derive which hashes the receiver already has for sure.  Suppose,
1210	   the receiver had acknowledged chunks C0 and C1 (first two chunks of
1211	   the file), then it must already have uncle hashes 5, 11 and so on.
1212	   That is because those hashes are necessary to check C0 and C1 against
1213	   the root hash.  Then, hashes 3, 7 and so on must be also known as
1214	   they are calculated in the process of checking the uncle hash chain.
1215	   Hence, to send chunk C7, the sender needs to include just the hashes
1216	   for nodes 14 and 9, which let the data be checked against hash 11
1217	   which is already known to the receiver.

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

1228	   In short, the sender MUST put into the datagram the hashes he
1229	   believes are necessary for the receiver to verify the chunk.  The
1230	   receiver MUST remember all the hashes it needs to verify missing
1231	   chunks that it still wants to download.  Note that the latter implies
1232	   that a hardware-limited receiver MAY forget some hashes if it does
1233	   not plan to announce possession of these chunks to others (i.e., does
1234	   not plan to send HAVE messages.)

1236	5.4.  INTEGRITY Messages

1238	   Concretely, a peer that wants to send a chunk of content creates a
1239	   datagram that MUST consist of a list of INTEGRITY messages followed
1240	   by a DATA message.  If the INTEGRITY messages and DATA message cannot
1241	   be put into a single datagram because of a limitation on datagram
1242	   size, the INTEGRITY messages MUST be sent first in one or more
1243	   datagrams.  The list of INTEGRITY messages sent MUST contain a
1244	   INTEGRITY message for each hash the receiver misses for integrity
1245	   checking.  A INTEGRITY message for a hash MUST contain the chunk
1246	   specification corresponding to the node ID of the hash and the hash
1247	   data itself.  The chunk specification corresponding to a node ID is
1248	   defined as the range of chunks formed by the leaves of the subtree
1249	   rooted at the node.  For example, node 3 in Figure 3 denotes chunks
1250	   0,2,4,6, so the chunk specification should denote that interval.  The
1251	   list of INTEGRITY messages MUST be sorted in order of the tree height
1252	   of the nodes, descending (the leaves are at height 0).  The DATA
1253	   message MUST contain the chunk specification of the chunk and chunk
1254	   itself.  A peer MAY send the required messages for multiple chunks in
1255	   the same datagram, depending on the encapsulation.

1257	5.5.  Discussion and Overhead

1259	   The current method for protecting content integrity in BitTorrent
1260	   [BITTORRENT] is not suited for streaming.  It involves providing
1261	   clients with the hashes of the content's chunks before the download
1262	   commences by means of metadata files (called .torrent files in
1263	   BitTorrent.)  However, when chunks are small as in the current UDP
1264	   encapsulation of PPSPP this implies having to download a large number
1265	   of hashes before content download can begin.  This, in turn,
1266	   increases time-till-playback for end users, making this method
1267	   unsuited for streaming.

1269	   The overhead of using Merkle hash trees is limited.  The size of the
1270	   hash tree expressed as the total number of nodes depends on the
1271	   number of chunks the content is divided (and hence the size of
1272	   chunks) following this formula:

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

1276	   In principle, the hash values of all these nodes will have to be sent
1277	   to a peer once for it to verify all chunks.  Hence the maximum on-
1278	   the-wire overhead is hashsize * nnodes.  However, the actual number
1279	   of hashes transmitted can be optimized as described in Section 5.3.

1281	   To see a peer can verify all chunks whilst receiving not all hashes,
1282	   consider the example tree in Section 5.1.  In case of a simple
1283	   progressive download, of chunks 0,2,4,6, etc. the sending peer will
1284	   send the following hashes:

1286	          +-------+---------------------------------------------+
1287	          | Chunk | Node IDs of hashes sent                     |
1288	          +-------+---------------------------------------------+
1289	          |   0   | 2,5,11                                      |
1290	          |   2   | - (receiver already knows all)              |
1291	          |   4   | 6                                           |
1292	          |   6   | -                                           |
1293	          |   8   | 10,13 (hash 3 can be calculated from 0,2,5) |
1294	          |   10  | -                                           |
1295	          |   12  | 14                                          |
1296	          |   14  | -                                           |
1297	          | Total | # hashes        7                           |
1298	          +-------+---------------------------------------------+

1300	                  Table 1: Overhead for the example tree

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

1306	5.6.  Automatic Detection of Content Size

1308	   In PPSPP, the size of a static content file, such as a video file,
1309	   can be reliably and automatically derived from information received
1310	   from the network when fixed sized chunks are used.  As a result, it
1311	   is not necessary to include the size of the content file as the
1312	   metadata of the content, for such files.  Implementations of PPSPP
1313	   MAY use this automatic detection feature.  Note this feature is the
1314	   only feature of PPSPP that requires that a fixed-sized chunk is used.
1315	   This feature builds on the Merkle hash tree and the trusted root hash
1316	   as swarm ID as follows.

1318	5.6.1.  Peak Hashes

1320	   The ability for a newcomer peer to detect the size of the content
1321	   depends heavily on the concept of peak hashes.  The concept of peak
1322	   hashes depends on the concepts of filled and incomplete nodes.
1323	   Recall that when constructing the binary trees for content
1324	   verification and addressing the base of the tree may have more leaves
1325	   than the number of chunks in the content.  In the Merkle hash tree
1326	   these leaves were assigned empty all-zero hashes to be able to
1327	   calculate the higher level hashes.  A filled node is now defined as a
1328	   node that corresponds to an interval of leaves that consists only of
1329	   hashes of content chunks, not empty hashes.  Reversely, an incomplete
1330	   (not filled) node corresponds to an interval that contains also empty
1331	   hashes, typically an interval that extends past the end of the file.
1332	   In the following figure nodes 7, 11, 13 and 14 are incomplete the
1333	   rest is filled.

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

1343	                                  7
1344	                                 / \
1345	                               /     \
1346	                             /         \
1347	                           /             \
1348	                         3*               11
1349	                        / \              / \
1350	                       /   \            /   \
1351	                      /     \          /     \
1352	                     1       5        9*      13
1353	                    / \     / \      / \      / \
1354	                   0   2   4   6    8   10  12*  14

1356	                   C0  C1  C2  C3   C4  C5  C6   E
1357	                                            = 1018 bytes

1359	                    Peak hashes in a Merkle hash tree.

1361	                                 Figure 4

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

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

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

1381	   Proof: (a) Any peak hash is always the left sibling.  Otherwise, be
1382	   it the right sibling, its left neighbor/sibling must also be a filled
1383	   node, because of the way chunks are laid out in the leaves,
1384	   contradiction. (b) For the rightmost peak hash, its right sibling is
1385	   zero. (c) For any peak hash, its right sibling might be calculated
1386	   using peak hashes to the left and zeros for empty nodes. (d) Once the
1387	   right sibling of the leftmost peak hash is calculated, its parent
1388	   might be calculated. (e) Once that parent is calculated, we might
1389	   trivially get to the root hash by concatenating the hash with zeros
1390	   and hashing it repeatedly.

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

1396	   Finally, once peer B has obtained the number of chunks in the content
1397	   it can determine the exact file size as follows.  Given that all
1398	   chunks except the last are fixed size B just needs to know the size
1399	   of the last chunk.  Knowing the number of chunks B can calculate the
1400	   node ID of the last chunk and download it.  As always B verifies the
1401	   integrity of this chunk against the trusted root hash.  As there is
1402	   only one chunk of data that leads to a successful verification the
1403	   size of this chunk must be correct.  B can then determine the exact
1404	   file size as

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

1408	5.6.2.  Procedure

1410	   A PPSPP implementation that wants to use automatic size detection
1411	   MUST operate as follows.  When a peer A sends a DATA message for the
1412	   first time to a peer B, A MUST first send all the peak hashes for the
1413	   content, in INTEGRITY messages, unless B has already signalled
1414	   earlier in the exchange that it knows the peak hashes by having
1415	   acknowledged any chunk.  If they are needed, the peak hashes MUST be
1416	   sent as an extra list of uncle hashes for the chunk, before the list
1417	   of actual uncle hashes of the chunk as described in Section 5.3.  The
1418	   receiver B MUST check the peak hashes against the root hash to
1419	   determine the approximate content size.  To obtain the definite
1420	   content size peer B MUST download the last chunk of the content from
1421	   any peer that offers it.

1423	   As an example, let's consider a 7162 bytes long file, which fits in 7
1424	   chunks of 1 kilobyte, distributed by a peer A.  Figure 4 shows the
1425	   relevant Merkle hash tree.  A peer B which only knows the root hash
1426	   of the file, after successfully connecting to A, requests the first
1427	   chunk of data, C0 in Figure 4.  Peer A replies to B by including in
1428	   the datagram the following messages in this specific order.  First
1429	   the three peak hashes of this particular file, the hashes of nodes 3,
1430	   9 and 12.  Second, the uncle hashes of C0, followed by the DATA
1431	   message containing the actual content of C0.  Upon receiving the peak
1432	   hashes, peer B checks them against the root hash determining that the
1433	   file is 7 chunks long.  To establish the exact size of the file, peer
1434	   B needs to request and retrieve the last chunk containing data, C6 in
1435	   Figure 4.  Once the last chunk has been retrieved and verified, peer
1436	   B concludes that it is 1018 bytes long, hence determining that the
1437	   file is exactly 7162 bytes long.

1439	6.  Live Streaming

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

1448	6.1.  Content Authentication

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

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

1459	   In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
1460	   Tree scheme for static content with signatures to unify the video-on-
1461	   demand and live streaming scenarios.  The use of Merkle hash trees
1462	   reduces the number of signing and verification operations, hence
1463	   providing a similar signature amortization to the approach described
1464	   in [SIGMCAST].  If PPSPP operates over the Internet, the "Unified
1465	   Merkle Tree" method MUST be used.  If the protocol operates in a
1466	   benign environment the "Unified Merkle Tree" method MAY be used.  So
1467	   this method is mandatory-to-implement.

1469	   In both methods the swarm ID consists of a public key encoded as in a
1470	   DNSSEC DNSKEY resource record without BASE-64 encoding [RFC4034].  In
1471	   particular, the swarm ID consists of a 1 byte Algorithm field that
1472	   identifies the public key's cryptographic algorithm and determines
1473	   the format of the Public Key field that follows.  The value of this
1474	   Algorithm field is one of the Domain Name System Security (DNSSEC)
1475	   Algorithm Numbers [IANADNSSECALGNUM].  The RSASHA1 [RFC4034],
1476	   RSASHA256 [RFC5702], and ECDSAP256SHA256 and ECDSAP384SHA384
1477	   [RFC6605] algorithms are MANDATORY to implement.

1479	    0                   1                   2                   3
1480	    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
1481	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1482	   | Algo Number(8)|                                               ~
1483	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1484	   ~                DNSSEC Public Key (variable)                   ~
1485	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1487	6.1.1.  Sign All

1489	   In the "Sign All" method, the live injector signs each chunk of
1490	   content using a private key and peers, upon receiving the chunk,
1491	   check the signature using the corresponding public key obtained from
1492	   a trusted source.  In particular, in PPSPP, the swarm ID of the live
1493	   stream is that public key.

1495	   A peer that wants to send a chunk of content creates a datagram that
1496	   MUST contain a SIGNED_INTEGRITY message with the chunk's signature,
1497	   followed by a DATA message with the actual chunk.  If the
1498	   SIGNED_INTEGRITY message and DATA message cannot be contained into a
1499	   single datagram, because of a limitation on datagram size, the
1500	   SIGNED_INTEGRITY message MUST be sent first in a separate datagram.
1501	   The SIGNED_INTEGRITY message consists of the chunk specification, the
1502	   timestamp, and the digital signature.

1504	   The digital signature algorithm which is used, is determined by the
1505	   Live Signature Algorithm protocol option, see Section 7.7.  The
1506	   signature is computed over a concatenation of the on-the-wire
1507	   representation of the chunk specification, a 64-bit timestamp in NTP
1508	   Timestamp format [RFC5905], and the chunk, in that order.  The
1509	   timestamp is the time signature that was made at the injector in UTC.

1511	6.1.2.  Unified Merkle Tree

1513	   In this method, the chunks of content are used as the basis for a
1514	   Merkle hash tree as for static content.  However, because chunks are
1515	   continuously generated, this tree is not static, but dynamic.  As a
1516	   result, the tree does not have a root hash, or more precisely has a
1517	   transient root hash.  A public key therefore serves as swarm ID of
1518	   the content.  It is used to digitally sign updates to the tree,
1519	   allowing peers to expand it based on trusted information using the
1520	   following process.

1522	6.1.2.1.  Signed Munro Hashes

1524	   The live injector generates a number of chunks, denoted
1525	   NCHUNKS_PER_SIG, corresponding to fixed power of 2
1526	   (NCHUNKS_PER_SIG>=2), which are added as new leaves to the existing
1527	   hash tree.  As a result of this expansion the hash tree contains a
1528	   new subtree, that is NCHUNKS_PER_SIG chunks wide at the base.  The
1529	   root of this new subtree is referred to as the munro of that subtree,
1530	   and its hash as the munro hash of the subtree, illustrated in
1531	   Figure 5.  In this figure, node 5 is the new munro, labeled with a $
1532	   sign.

1534	                                     3
1535	                                    / \
1536	                                   /   \
1537	                                  /     \
1538	                                 1       5$
1539	                                / \     / \
1540	                               0   2   4   6

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

1546	                                 Figure 5

1548	   Informally, the process now proceeds as follows.  The injector now
1549	   signs only the munro hash of the new subtree using its private key.
1550	   Next, the injector announces the existence of the new subtree to its
1551	   peers using HAVE messages.  When a peer, in response to the HAVE
1552	   messages, requests a chunk from the new subtree, the injector first
1553	   sends the signed munro hash corresponding to the requested chunk.
1554	   Afterwards, similar to static content, the injector sends the uncle
1555	   hashes necessary to verify that chunk, as in Section 5.1.  In
1556	   particular, the injector sends the uncle hashes necessary to verify
1557	   the requested chunk against the munro hash.  This differs from static
1558	   content, where the verification takes places against the root hash.
1559	   Finally, the injector sends the actual chunk.

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

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

1578	                                     7
1579	                                    / \
1580	                                  /     \
1581	                                /         \
1582	                              /             \
1583	                            3               11
1584	                           / \              / \
1585	                          /   \            /   \
1586	                         /     \          /     \
1587	                        1       5        9$      13
1588	                       / \     / \      / \      / \
1589	                      0   2   4   6    8   10   E   E

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

1594	                                 Figure 6

1596	   The injector now needs to inform its peers of the updated tree,
1597	   communicating the addition of the new munro hash 9.  Hence, it sends
1598	   a HAVE message with a chunk specification for nodes 8+10 to its
1599	   peers.  As a response, a peer P requests the newly created chunk,
1600	   e.g. chunk 8, from the injector by sending a REQUEST message.  In
1601	   reply, the injector sends the signed munro hash of node 9 as an
1602	   INTEGRITY message with the hash of node 9, and a SIGNED_INTEGRITY
1603	   message with the signature of the hash of node 9.  These messages are
1604	   followed by an INTEGRITY message with the hash of node 10, and a DATA
1605	   message with chunk 8.

1607	   Upon receipt, peer P verifies the signature of the munro and expands
1608	   its view of the tree.  Next, the peer computes the hash of chunk 8
1609	   and combines it with the received hash of node 10, computing the
1610	   expected hash of node 9.  He can then verify the content of chunk 8
1611	   by comparing the computed hash of node 9 with the munro hash of the
1612	   same node he just received, hence P has successfully verified the
1613	   integrity of chunk 8.

1615	   This procedure requires just one signing operation for every
1616	   NCHUNKS_PER_SIG chunks created, and one verification operation for
1617	   every NCHUNKS_PER_SIG received, making it much cheaper than "Sign
1618	   All".  A receiving peer does additionally need to check one or more
1619	   hashes per chunk via the Merkle Tree scheme, but this has less
1620	   hardware requirements than a signature verification for every chunk.
1621	   This approach is similar to signature amortization via Merkle Tree
1622	   Chaining [SIGMCAST].  The downside of scheme is in an increased
1623	   latency.  A peer cannot download the new chunks until the injector
1624	   has computed the signature and announced the subtree.  A peer MUST
1625	   check the signature before forwarding the chunks to other peers
1626	   [POLLIVE].

1628	   The number of chunks per signature NCHUNKS_PER_SIG MUST be a fixed
1629	   power of 2 for simplicity.  NCHUNKS_PER_SIG MUST be larger than 1 for
1630	   performance reasons.  There are two related factors to consider when
1631	   choosing a value for NCHUNKS_PER_SIG.  First, the allowed CPU load on
1632	   clients due to signature verifications, given the expected bitrate of
1633	   the stream.  To achieve a low CPU load in a high bitrate stream,
1634	   NCHUNKS_PER_SIG should be high.  Second, the effect on latency, which
1635	   increases when NCHUNKS_PER_SIG gets higher, as just discussed.  Note
1636	   how the procedure does not preclude the use of variable-sized chunks.

1638	   This method of integrity verification provides an additional benefit.
1639	   If the system includes some peers that saved the complete broadcast,
1640	   as soon as the broadcast ends, the content is available as a video-
1641	   on-demand download using the now stabilized tree and the final root
1642	   hash as swarm identifier.  Peers which saved all the chunks, can now
1643	   announce the root hash to the tracking infrastructure and instantly
1644	   seed the content.

1646	6.1.2.2.  Munro Signature Calculation

1648	   The digital signature algorithm used is determined by the Live
1649	   Signature Algorithm protocol option, see Section 7.7.  The signature
1650	   is computed over a concatenation of the on-the-wire representation of
1651	   the chunk specification of the munro node (see Section 6.1.2.1), a
1652	   timestamp in 64-bit NTP Timestamp format [RFC5905], and the hash
1653	   associated with the munro node, in that order.  The timestamp is the
1654	   time signature that was made at the injector in UTC.

1656	6.1.2.3.  Procedure

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

1662	   When peer B requests a chunk C from peer A (either the injector or
1663	   another peer), and peer A decides to reply, it must do so as follows.
1664	   First, peer A MUST send an INTEGRITY message with the chunk
1665	   specification for the munro of chunk C and the munro's hash, followed
1666	   by a SIGNED_INTEGRITY message with the chunk specification for the
1667	   munro, timestamp and its signature, in a single datagram, unless B
1668	   indicated earlier in the exchange that it already possess a chunk
1669	   with the same corresponding munro (by means of HAVE or ACK messages).
1670	   Following these two messages (if any), peer A MUST send the necessary
1671	   missing uncles hashes needed for verifying the chunk against its
1672	   munro hash, and the chunk itself, as described in Section 5.4,
1673	   sharing datagrams if possible.

1675	6.1.2.4.  Secure Tune In

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

1683	   Recall that in PPSPP, when peer A initiates a channel with peer B,
1684	   peer A sends a first datagram with a HANDSHAKE message, and B
1685	   responds with a second datagram also containing a HANDSHAKE message
1686	   (see Section 3.1).  When A sends a third datagram to B, and it is
1687	   received by B both peers know that the other is listening on its
1688	   stated transport address.  B is then allowed to send heavy payload
1689	   like DATA messages in the fourth datagram.  Peer A can already safely
1690	   do that in the third datagram.

1692	   In the Unified Merkle Tree scheme, peer A MUST send its right-most
1693	   signed munro hash to B in the third datagram, and in any subsequent
1694	   datagrams to B, until B indicates that it possess a chunk with the
1695	   same corresponding munro or a more recent munro (by means of a HAVE
1696	   or ACK message).  B may already have indicated this fact by means of
1697	   HAVE messages in the second datagram.  Conversely, when B sends the
1698	   fourth datagram or any subsequent datagram to A, B MUST send its
1699	   right-most signed munro hash, unless A indicated knowledge of it or
1700	   more recent munros.  The right-most signed munro hash of a peer is
1701	   defined as the munro hash signed by the injector of the right-most
1702	   subtree of width NCHUNKS_PER_SIG chunks in the peer's Merkle hash
1703	   tree.  Peer A and B MUST NOT send the signed munro hash in the first,
1704	   respectively, second datagram as it is considered heavy payload.

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

1712	6.2.  Forgetting Chunks

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

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

1730	   Three factors are important when deciding for an appropriate value
1731	   for this option: the desired amount of playback buffer for peers, the
1732	   bitrate of the stream and the available resources of the peer.
1733	   Consider the case of a fresh peer joining the stream.  The size of
1734	   the discard window of the peers it connects to influences how much
1735	   data it can directly download to establish its prebuffer.  If the
1736	   window is smaller than the desired buffer, the fresh peer has to wait
1737	   until the peers downloaded more of the stream before it can start
1738	   playback.  As media buffers are generally specified in terms of a
1739	   number of seconds, the size of the discard window is also related to
1740	   the (average) bitrate of the stream.  Finally, if a peer has little
1741	   resources to store chunks and metadata it should chose a small
1742	   discard window.

1744	7.  Protocol Options

1746	   The HANDSHAKE message in PPSPP can contain the following protocol
1747	   options.  Unless stated otherwise, a protocol option consists of an
1748	   8-bit code followed by an 8-bit value.  Larger values are all encoded
1749	   big-endian.  Each protocol option is explained in the following
1750	   subsections.  The list of protocol options MUST be sorted on code
1751	   value (ascending) in a HANDSHAKE message.

1753	             +--------+-------------------------------------+
1754	             | Code   | Description                         |
1755	             +--------+-------------------------------------+
1756	             | 0      | Version                             |
1757	             | 1      | Minimum Version                     |
1758	             | 2      | Swarm Identifier                    |
1759	             | 3      | Content Integrity Protection Method |
1760	             | 4      | Merkle Hash Tree Function           |
1761	             | 5      | Live Signature Algorithm            |
1762	             | 6      | Chunk Addressing Method             |
1763	             | 7      | Live Discard Window                 |
1764	             | 8      | Supported Messages                  |
1765	             | 9      | Chunk Size                          |
1766	             | 10-254 | Unassigned                          |
1767	             | 255    | End Option                          |
1768	             +--------+-------------------------------------+

1770	                    Table 2: PPSP Peer Protocol Options

1772	7.1.  End Option

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

1779	    0 1 2 3 4 5 6 7
1780	   +-+-+-+-+-+-+-+-+
1781	   |1 1 1 1 1 1 1 1|
1782	   +-+-+-+-+-+-+-+-+

1784	7.2.  Version

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

1790	           +---------+----------------------------------------+
1791	           | Version | Description                            |
1792	           +---------+----------------------------------------+
1793	           | 0       | Reserved                               |
1794	           | 1       | Protocol as described in this document |
1795	           | 2-255   | Unassigned                             |
1796	           +---------+----------------------------------------+

1798	                Table 3: PPSP Peer Protocol Version Numbers

1800	    0                   1
1801	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1802	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1803	   |0 0 0 0 0 0 0 0|  Version (8)  |
1804	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1806	7.3.  Minimum Version

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

1814	    0                   1
1815	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1816	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1817	   |0 0 0 0 0 0 0 1| Min. Ver. (8) |
1818	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1820	7.4.  Swarm Identifier

1822	   When a peer initiates the handshake it MUST include a single swarm
1823	   identifier option.  If the peer is not the initiator, it MAY include
1824	   a swarm identifier option, as an end-to-end check.  This option has
1825	   the following structure:

1827	    0                   1                   2                   3
1828	    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
1829	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1830	   |0 0 0 0 0 0 1 0|     Swarm ID Length (16)      |               ~
1831	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1832	   ~                       Swarm Identifier (variable)             ~
1833	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

1842	7.5.  Content Integrity Protection Method

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

1847	                   +--------+-------------------------+
1848	                   | Method | Description             |
1849	                   +--------+-------------------------+
1850	                   | 0      | No integrity protection |
1851	                   | 1      | Merkle Hash Tree        |
1852	                   | 2      | Sign All                |
1853	                   | 3      | Unified Merkle Tree     |
1854	                   | 4-255  | Unassigned              |
1855	                   +--------+-------------------------+

1857	          Table 4: PPSP Peer Content Integrity Protection Methods

1859	   The "Merkle Hash Tree" method is the default for static content, see
1860	   Section 5.1.  "Sign All", and "Unified Merkle Tree" are for live
1861	   content, see Section 6.1, with "Unified Merkle Tree" being the
1862	   default.

1864	    0                   1
1865	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1866	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1867	   |0 0 0 0 0 0 1 1|   CIPM (8)    |
1868	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1870	7.6.  Merkle Tree Hash Function

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

1877	                        +----------+-------------+
1878	                        | Function | Description |
1879	                        +----------+-------------+
1880	                        | 0        | SHA-1       |
1881	                        | 1        | SHA-224     |
1882	                        | 2        | SHA-256     |
1883	                        | 3        | SHA-384     |
1884	                        | 4        | SHA-512     |
1885	                        | 5-255    | Unassigned  |
1886	                        +----------+-------------+

1888	             Table 5: PPSP Peer Protocol Merkle Hash Functions

1890	   Implementations MUST support SHA-1 (see Section 13.5) and SHA-256.
1891	   SHA-256 is the default.

1893	    0                   1
1894	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1895	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1896	   |0 0 0 0 0 1 0 0|    MHF (8)    |
1897	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1899	7.7.  Live Signature Algorithm

1901	   When the content integrity protection method is "Sign All" or
1902	   "Unified Merkle Tree" this option MUST be defined.  The code for this
1903	   option is 5.  The 8-bit value of this option is one of the Domain
1904	   Name System Security (DNSSEC) Algorithm Numbers [IANADNSSECALGNUM].
1905	   The RSASHA1 [RFC4034], RSASHA256 [RFC5702], ECDSAP256SHA256 and
1906	   ECDSAP384SHA384 [RFC6605] algorithms are MANDATORY to implement.
1907	   Default is ECDSAP256SHA256.

1909	    0                   1
1910	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1911	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1912	   |0 0 0 0 0 1 0 1|    LSA (8)    |
1913	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1915	7.8.  Chunk Addressing Method

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

1920	                     +--------+---------------------+
1921	                     | Method | Description         |
1922	                     +--------+---------------------+
1923	                     | 0      | 32-bit bins         |
1924	                     | 1      | 64-bit byte ranges  |
1925	                     | 2      | 32-bit chunk ranges |
1926	                     | 3      | 64-bit bins         |
1927	                     | 4      | 64-bit chunk ranges |
1928	                     | 5-255  | Unassigned          |
1929	                     +--------+---------------------+

1931	                Table 6: PPSP Peer Chunk Addressing Methods

1933	   Implementations MUST support "32-bit chunk ranges" and "64-bit chunk
1934	   ranges".  Default is "32-bit chunk ranges".

1936	    0                   1
1937	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1938	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1939	   |0 0 0 0 0 1 1 0|    CAM (8)    |
1940	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1942	7.9.  Live Discard Window

1944	   A peer in a live swarm MUST include the discard window it uses.  The
1945	   code for this option is 7.  The unit of the discard window depends on
1946	   the chunk addressing method used, see Table 6.  For bins and chunk
1947	   ranges it is a number of chunks, for byte ranges it is a number of
1948	   bytes.  Its data type is the same as for a bin, or one value in a
1949	   range specification.  In other words, its value is a 32-bit or 64-bit
1950	   integer in big endian format.  If this option is used, the Chunk
1951	   Addressing Method MUST appear before it in the list.  This option has
1952	   the following structure:

1954	    0                   1                   2                   3
1955	    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
1956	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1957	   |0 0 0 0 0 1 1 1|       Live Discard Window (32 or 64)          ~
1958	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1959	   ~                                                               ~
1960	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1962	   A peer that does not, under normal circumstances, discard chunks MUST
1963	   set this option to the special value 0xFFFFFFFF (32-bit) or
1964	   0xFFFFFFFFFFFFFFFF (64-bit).  For example, peers that record a
1965	   complete broadcast to offer it directly as a static file after the
1966	   broadcast ends use these values (see Section 6.1.2).  Section 6.2
1967	   explains how to determine a value for this option.

1969	7.10.  Supported Messages

1971	   Peers may support just a subset of the PPSPP messages.  For example,
1972	   peers running over TCP may not accept ACK messages, or peers used
1973	   with a centralized tracking infrastructure may not accept PEX
1974	   messages.  For these reasons, peers who support only a proper subset
1975	   of the PPSPP messages MUST signal which subset they support by means
1976	   of this protocol option.  The code for this option is 8.  The value
1977	   of this option is a length octet (SupMsgLen) indicating the length in
1978	   bytes of the compressed bitmap that follows.

1980	   The set of messages supported can be derived from the compressed
1981	   bitmap by padding it with bytes of value 0 until it is 256 bits in
1982	   length.  Then a 1 bit in the resulting bitmap at position X
1983	   (numbering left to right) corresponds to support for message type X,
1984	   see Table 7.  In other words, to construct the compressed bitmap,
1985	   create a bitmap with a 1 for each message type supported and a 0 for
1986	   a message type that is not, store it as an array of bytes and
1987	   truncate it to the last non-zero byte.  An example of the first 16
1988	   bits of the compressed bitmap for a peer supporting every message
1989	   except ACKs and PEXs is: 11011001 11110000.

1991	    0                   1                   2                   3
1992	    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
1993	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1994	   |0 0 0 0 1 0 0 0| SupMsgLen (8) |                               ~
1995	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1996	   ~            Supported Messages Bitmap (variable, max 256)      ~
1997	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1999	7.11.  Chunk Size

2001	   A peer in a swarm MUST include the chunk size the swarm uses.  The
2002	   code for this option is 9.  Its value is a 32-bit integer denoting
2003	   the size of the chunks in bytes in big endian format.  When variable
2004	   chunk sizes are used, this option MUST be set to the special value
2005	   0xFFFFFFFF.  Section 8.1 explains how content publishers can
2006	   determine a value for this option.

2008	    0                   1                   2                   3
2009	    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
2010	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2011	   |0 0 0 0 1 0 0 1|       Chunk Size (32)                         ~
2012	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2013	   ~               |
2014	   +-+-+-+-+-+-+-+-+

2016	8.  UDP Encapsulation

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

2025	8.1.  Chunk Size

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

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

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

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

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

2068	8.2.  Datagrams and Messages

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

2076	                      +----------+------------------+
2077	                      | Msg Type | Description      |
2078	                      +----------+------------------+
2079	                      | 0        | HANDSHAKE        |
2080	                      | 1        | DATA             |
2081	                      | 2        | ACK              |
2082	                      | 3        | HAVE             |
2083	                      | 4        | INTEGRITY        |
2084	                      | 5        | PEX_RESv4        |
2085	                      | 6        | PEX_REQ          |
2086	                      | 7        | SIGNED_INTEGRITY |
2087	                      | 8        | REQUEST          |
2088	                      | 9        | CANCEL           |
2089	                      | 10       | CHOKE            |
2090	                      | 11       | UNCHOKE          |
2091	                      | 12       | PEX_RESv6        |
2092	                      | 13       | PEX_REScert      |
2093	                      | 14-254   | Unassigned       |
2094	                      | 255      | Reserved         |
2095	                      +----------+------------------+

2097	                 Table 7: PPSP Peer Protocol Message Types

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

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

2114	8.3.  Channels

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

2124	8.4.  HANDSHAKE

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

2131	    0                   1                   2                   3
2132	    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
2133	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2134	   |                  Destination Channel ID (32)                  |
2135	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2136	   |0 0 0 0 0 0 0 0|            Source Channel ID (32)             |
2137	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2138	   |               |                                               ~
2139	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2140	   |                                                               |
2141	   ~                     Protocol Options                          ~
2142	   |                                                               |
2143	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2145	   where:

2147	      Destination Channel ID:

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

2152	         If the message sent by the responding peer than it MUST consist
2153	         of the Source Channel ID from the sender's HANDSHAKE message

2155	      The octet 0x00: The HANDSHAKE message: 0x00

2157	      The Source Channel ID: A locally unused channel ID
2158	      Protocol Options: A list of protocol options encoding the swarm's
2159	      metadata, as defined in Section 7.

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

2167	8.5.  HAVE

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

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

2179	    0                   1                   2                   3
2180	    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
2181	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2182	   |0 0 0 0 0 0 1 1|                 Start chunk (32)              |
2183	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2184	   |               |                  End chunk (32)               |
2185	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2186	   |               |
2187	   +-+-+-+-+-+-+-+-+

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

2192	8.6.  DATA

2194	   A DATA message (type 0x01) consists of a chunk specification, a
2195	   timestamp and the actual chunk.  In case a datagram contains one DATA
2196	   message, a sender MUST always put the DATA message in the tail of the
2197	   datagram.  A datagram MAY contain multiple DATA messages when the
2198	   chunk size is fixed and when none of DATA messages carry the last
2199	   chunk if that is smaller than the chunk size.  As the LEDBAT
2200	   congestion control is used, a sender MUST include a timestamp, in
2201	   particular, a 64-bit integer representing the current system time
2202	   with microsecond accuracy.  The timestamp MUST be included between
2203	   chunk specification and the actual chunk.

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

2207	    0                   1                   2                   3
2208	    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
2209	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2210	   |0 0 0 0 0 0 0 1|                 Start chunk (32)              |
2211	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2212	   |               |                  End chunk (32)               |
2213	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2214	   |               |                                               |
2215	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2216	   |                       Timestamp (64)                          |
2217	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2218	   |               |                                               |
2219	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2220	   |                                                               |
2221	   ~                            Data                               ~
2222	   |                                                               |
2223	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2229	8.7.  ACK

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

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

2241	    0                   1                   2                   3
2242	    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
2243	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2244	   |0 0 0 0 0 0 1 0|                 Start chunk (32)              |
2245	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2246	   |               |                  End chunk (32)               |
2247	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2248	   |               |                                               |
2249	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2250	   |                  One-way delay sample (64)                    |
2251	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2252	   |               |
2253	   +-+-+-+-+-+-+-+-+

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

2259	8.8.  INTEGRITY

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

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

2268	    0                   1                   2                   3
2269	    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
2270	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2271	   |0 0 0 0 0 1 0 0|                 Start chunk (32)              |
2272	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2273	   |               |                  End chunk (32)               |
2274	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2275	   |               |                                               |
2276	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2277	   |                                                               |
2278	   ~                            Hash (256)                         ~
2279	   |                                                               |
2280	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2281	   |               |
2282	   +-+-+-+-+-+-+-+-+
2283	   where the first octet is the INTEGRITY message (0x04), followed by
2284	   the start chunk and the end chunk describing the chunk range, and the
2285	   hash.

2287	8.9.  SIGNED_INTEGRITY

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

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

2301	    0                   1                   2                   3
2302	    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
2303	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2304	   |0 0 0 0 0 1 1 1|                 Start chunk (32)              |
2305	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2306	   |               |                  End chunk (32)               |
2307	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2308	   |               |                                               |
2309	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2310	   |                       Timestamp (64)                          |
2311	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2312	   |               |                                               |
2313	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2314	   |                                                               |
2315	   ~                       Signature                               ~
2316	   |                                                               |
2317	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2323	   The length of the digital signature can be derived from the Live
2324	   Signature Algorithm protocol option and the swarm ID as follows.  The
2325	   first MANDATORY algorithms are RSASHA1 and RSASHA256.  For those
2326	   algorithms, the swarm ID consists of a 1-byte Algorithm field
2327	   followed by a RSA public key stored as a tuple (exponent
2328	   length,exponent,modulus) [RFC3110].  Given the exponent length and
2329	   the length of the public key tuple in the swarm ID, the length of the
2330	   modulus in bytes can be calculated.  This yields the length of the
2331	   signature as in RSA this is the length of the modulus [HAC01].  The
2332	   other MANDATORY algorithms are ECDSAP256SHA256 and ECDSAP384SHA384
2333	   [RFC6605].  For these algorithms the length of the digital signature
2334	   is 64 and 96 bytes, respectively.

2336	8.10.  REQUEST

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

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

2344	    0                   1                   2                   3
2345	    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
2346	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2347	   |0 0 0 0 1 0 0 0|                 Start chunk (32)              |
2348	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2349	   |               |                  End chunk (32)               |
2350	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2351	   |               |
2352	   +-+-+-+-+-+-+-+-+

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

2357	8.11.  CANCEL

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

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

2365	    0                   1                   2                   3
2366	    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
2367	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2368	   |0 0 0 0 1 0 0 1|                 Start chunk (32)              |
2369	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2370	   |               |                  End chunk (32)               |
2371	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2372	   |               |
2373	   +-+-+-+-+-+-+-+-+

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

2378	8.12.  CHOKE and UNCHOKE

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

2383	   A CHOKE message:

2385	    0
2386	    0 1 2 3 4 5 6 7
2387	   +-+-+-+-+-+-+-+-+
2388	   |0 0 0 0 1 0 1 0|
2389	   +-+-+-+-+-+-+-+-+

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

2393	   An UNCHOKE message:

2395	    0
2396	    0 1 2 3 4 5 6 7
2397	   +-+-+-+-+-+-+-+-+
2398	   |0 0 0 0 1 0 1 1|
2399	   +-+-+-+-+-+-+-+-+

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

2403	8.13.  PEX_REQ, PEX_RESv4, PEX_RESv6 and PEX_REScert

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

2414	   A PEX_REQ message:

2416	    0
2417	    0 1 2 3 4 5 6 7
2418	   +-+-+-+-+-+-+-+-+
2419	   |0 0 0 0 0 1 1 0|
2420	   +-+-+-+-+-+-+-+-+

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

2424	   A PEX_RESv4 message:

2426	    0                   1                   2                   3
2427	    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
2428	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2429	   |0 0 0 0 0 1 0 1|              IPv4 Address (32)                |
2430	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2431	   |               |             Port (16)         |
2432	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2437	   A PEX_RESv6 message:

2439	    0                   1                   2                   3
2440	    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
2441	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2442	   |0 0 0 0 1 1 0 0|                                               |
2443	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2444	   |                                                               |
2445	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2446	   |                   IPv6 Address (128)                          |
2447	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2448	   |                                                               |
2449	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2450	   |               |             Port (16)         |
2451	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

2465	   A PEX_REScert message:

2467	    0                   1                   2                   3
2468	    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
2469	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2470	   |0 0 0 0 1 1 0 1|   Size of Memb. Cert. (16)    |               |
2471	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2472	   |                                                               |
2473	   ~                    Membership Certificate                     ~
2474	   |                                                               |
2475	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

2493	       file://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3

2495	8.14.  KEEPALIVE

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

2501	   A keepalive datagram:

2503	    0                   1                   2                   3
2504	    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
2505	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2506	   |                       Channel ID (32)                         |
2507	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2509	8.15.  Flow and Congestion Control

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

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

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

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

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

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

2564	8.16.  Example of Operation

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

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

2579	    0                   1                   2                   3
2580	    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
2581	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2582	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2583	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2584	   |   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|
2585	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2586	   |0 0 0 0 0 0 0 1|    Version    |0 0 0 0 0 0 0 1|  Min Version  |
2587	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2588	   |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|
2589	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2590	   |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|
2591	   ~                             .....                             ~
2592	   |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|
2593	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2594	   |   Cont. Int.  |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|
2595	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2596	   |   Chunk Add.  |0 0 0 0 0 0 1 0|   Chunk Size  |0 0 0 0 0 0 0 0~
2597	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2598	   ~0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0|      End      |
2599	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2601	   The protocol options are:

2603	      Version: 1

2605	      Minimum supported Version: 1

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

2610	      Content Integrity Protection Method: Merkle Hash Tree.

2612	      Merkle Tree Hash Function: SHA-256.

2614	      Chunk Addressing Method: 32-bit chunk ranges.

2616	      Chunk Size: 1024.

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

2624	    0                   1                   2                   3
2625	    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
2626	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2627	   |0 0 0 0 0 0 0 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|
2628	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2629	   |   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|
2630	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2631	   |0 0 0 0 1 0 0 0|    Version    |0 0 0 0 0 0 0 1|   Cont. Int.  |
2632	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2633	   |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|   Chunk Add.  |
2634	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2635	   |0 0 0 0 0 0 1 0|  Chunk Size   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
2636	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2637	   ~0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0|      End      |      HAVE     |
2638	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2639	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
2640	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2641	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
2642	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2644	   With the protocol options the receiving peer agrees on speaking
2645	   protocol version 1, on using the Merkle Hash Tree as Content
2646	   Integrity Protection Method, SHA-256 hash as Merkle Tree Hash
2647	   Function, 32-bit chunk ranges as Chunk Addressing Method, and Chunk
2648	   Size 1024.  Furthermore, it sends a HAVE message within the same
2649	   datagram, announcing that it has locally available the first chunk of
2650	   content.

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

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

2666	    0                   1                   2                   3
2667	    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
2668	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2669	   |0 0 0 0 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|
2670	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2671	   |    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|
2672	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2673	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2674	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2675	   |0 0 0 0 0 0 0 0|    PEX_REQ    |
2676	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2683	    0                   1                   2                   3
2684	    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
2685	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2686	   |0 0 0 0 0 0 0 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|
2687	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2688	   |     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|
2689	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2690	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2691	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2692	   |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|
2693	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2694	   |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|
2695	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2696	   |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|
2697	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2698	   ~                           .....                               ~
2699	   |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|
2700	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2702	   The DATA message consists of:

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

2706	      The timestamp value: 0004e94180b7db44

2708	      The Data message: 48656c6c6f20776f726c6421 (the "Hello world!"
2709	      file)

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

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

2722	    0                   1                   2                   3
2723	    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
2724	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2725	   |0 0 0 0 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|
2726	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2727	   |      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|
2728	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2729	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2730	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2731	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2732	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2733	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2734	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2735	   |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|
2736	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2737	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2738	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2739	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2740	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2742	   At this point the initiating peer has successfully retrieved the
2743	   entire file.  It then explicitly closes the connection by sending a
2744	   HANDSHAKE message that contains an all 0-zeros Source Channel ID.

2746	    0                   1                   2                   3
2747	    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
2748	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2749	   |0 0 0 0 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|
2750	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2751	   |   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|
2752	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2753	   |0 0 0 0 0 0 0 0|      End      |
2754	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2756	9.  Extensibility

2758	9.1.  Chunk Picking Algorithms

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

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

2772	9.2.  Reciprocity Algorithms

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

2782	10.  Acknowledgements

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

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

2800	11.  IANA Considerations

2802	   IANA is to create a new top-level registry called "Peer-to-Peer
2803	   Streaming Peer Protocol (PPSPP)", which will host the six new sub-
2804	   registries defined below for the extensibility of the protocol.  For
2805	   all registries, assignments consist of a name and its associated
2806	   value.  Also for all registries, the "Unassigned" ranges designated
2807	   are governed by the policy 'IETF Review' as described in [RFC5226].

2809	11.1.  PPSP Peer Protocol Message Type Registry

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

2815	11.2.  PPSP Peer Protocol Option Registry

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

2821	11.3.  PPSP Peer Protocol Version Number Registry

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

2827	11.4.  PPSP Peer Protocol Content Integrity Protection Method Registry

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

2833	11.5.  PPSP Peer Protocol Merkle Hash Tree Function Registry

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

2839	11.6.  PPSP Peer Protocol Chunk Addressing Method Registry

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

2845	12.  Manageability Considerations

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

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

2855	12.1.  Operations

2857	12.1.1.  Installation and Initial Setup

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

2873	   In addition, a content provider should set up a tracking facility for
2874	   the content by configuring, for example, a PPSP tracker
2875	   [I-D.ietf-ppsp-base-tracker-protocol] or a Distributed Hash Table.
2876	   The output of the latter process is a list of transport addresses for
2877	   the tracking facility.

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

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

2898	12.1.2.  Requirements on Other Protocols and Functional Components

2900	   When using the PPSP tracker protocol, PPSPP requires a specific
2901	   behavior from this protocol for security reasons, as detailed in
2902	   Section 13.2.

2904	12.1.3.  Migration Path

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

2909	12.1.4.  Impact on Network Operation

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

2919	12.1.5.  Verifying Correct Operation

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

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

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

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

2943	12.1.6.  Configuration

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

2950	   +-------------------------+-----------------------+-----------------+
2951	   | Name                    | Default               | Definition      |
2952	   +-------------------------+-----------------------+-----------------+
2953	   | Chunk Size              | var, 1024 bytes       | Section 8.1     |
2954	   |                         | recommended           |                 |
2955	   | Static Content          | 1 (Merkle Hash Tree)  | Section 7.5     |
2956	   | Integrity Protection    |                       |                 |
2957	   | Method                  |                       |                 |
2958	   | Live Content Integrity  | 3 (Unified Merkle     | Section 7.5     |
2959	   | Protection Method       | Tree)                 |                 |
2960	   | Merkle Hash Tree        | 2 (SHA-256)           | Section 7.6     |
2961	   | Function                |                       |                 |
2962	   | Live Signature          | 13 (ECDSAP256SHA256)  | Section 7.7     |
2963	   | Algorithm               |                       |                 |
2964	   | Chunk Addressing Method | 2 (32-bit chunk       | Section 7.8     |
2965	   |                         | ranges)               |                 |
2966	   | Live Discard Window     | var                   | Section 6.2,    |
2967	   |                         |                       | Section 7.9     |
2968	   | NCHUNKS_PER_SIG         | var                   | Section 6.1.2.1 |
2969	   | Dead peer detection     | No reply in 3 minutes | Section 3.12    |
2970	   |                         | + 3 datagrams         |                 |
2971	   +-------------------------+-----------------------+-----------------+

2973	                          Table 8: PPSPP Defaults

2975	12.2.  Management Considerations

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

2988	12.2.1.  Management Interoperability and Information

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

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

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

3008	12.2.2.  Fault Management

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

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

3022	12.2.3.  Configuration Management

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

3034	12.2.4.  Accounting Management

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

3043	12.2.5.  Performance Management

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

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

3053	12.2.6.  Security Management

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

3060	13.  Security Considerations

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

3070	13.1.  Security of the Handshake Procedure

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

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

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

3081	   3.  Disrupt service to an individual peer: attackers send bogus e.g.
3082	       REQUEST and HAVE messages appearing to come from victim peer A to
3083	       the peers B1..Bn serving that peer.  This causes A to receive
3084	       chunks it did not request or to not receive the chunks it
3085	       requested.

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

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

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

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

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

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

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

3120	13.1.1.  Protection Against Attack 1

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

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

3137	13.1.2.  Protection Against Attack 2

3139	   On receiving the first datagram peer B will record some state about
3140	   peer A.  At present this state consists of the chanA channel ID, and
3141	   the results of processing the other messages in the first datagram.
3142	   In particular, if A included some HAVE messages, B may add a chunk
3143	   availability map to A's state.  In addition, B may request some
3144	   chunks from A in the second datagram, and B will maintain state about
3145	   these outgoing requests.

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

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

3160	13.1.3.  Protection Against Attack 3

3162	   In general, channel IDs serve to authenticate a peer.  Hence, to
3163	   attack, a malicious peer T would need to be able to eavesdrop on
3164	   conversations between victim A and a benign peer B to obtain the
3165	   channel ID B assigned to A, chanB.  Furthermore, attacker T would
3166	   need to be able to spoof e.g.  REQUEST and HAVE messages from A to
3167	   cause B to send heavy DATA messages to A, or prevent B from sending
3168	   them, respectively.

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

3174	13.2.  Secure Peer Address Exchange

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

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

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

3197	      E1.  Malicious peers try to eclipse the single injector in live
3198	      streaming.

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

3202	   Attack E1 has the most impact on the system as it would disrupt all
3203	   peers.

3205	13.2.1.  Protection against the Amplification Attack

3207	   If peer addresses are relatively stable, strong protection against
3208	   the attack can be provided by using public key cryptography and
3209	   certification.  In particular, a PEX_REScert message will carry
3210	   swarm-membership certificates rather than IP address and port.  A
3211	   membership certificate for peer B states that peer B at address
3212	   (ipB,portB) is part of swarm S at time T and is cryptographically
3213	   signed.  The receiver A can check the certificate for a valid
3214	   signature, the right swarm and liveliness and only then consider
3215	   contacting B.  These swarm-membership certificates correspond to
3216	   signed node descriptors in secure decentralized peer sampling
3217	   services [SPS].

3219	   Several designs are possible for the security environment for these
3220	   membership certificates.  That is, there are different designs
3221	   possible for who signs the membership certificates and how public
3222	   keys are distributed.  As an example, we describe a design where the
3223	   PPSP tracker acts as certification authority.

3225	13.2.2.  Example: Tracker as Certification Authority

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

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

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

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

3249	   The load generated on the tracker depends on churn and the lifetime
3250	   of a certificate.  Certificates can be fairly long lived, given that
3251	   the main goal of the membership certificates is to prevent that
3252	   malicious peer T can cause good peer A to contact *random* hosts.
3253	   The freshness of the timestamp just adds extra protection in addition
3254	   to achieving that goal.  It protects against malicious hosts causing
3255	   a good peer A to contact hosts that previously participated in the
3256	   swarm.

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

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

3268	   Note that this scheme does not work for peers behind a symmetric
3269	   Network Address Translator, but neither does normal tracker
3270	   registration.

3272	13.2.3.  Protection Against Eclipse Attacks

3274	   Before we can discuss Eclipse attacks we first need to establish the
3275	   security properties of the central tracker.  A tracker is vulnerable
3276	   to Amplification attacks too.  A malicious peer T could register a
3277	   victim B with the tracker, and many peers joining the swarm will
3278	   contact B.  Trackers can also be used in Eclipse attacks.  If many
3279	   malicious peers register themselves at the tracker, the percentage of
3280	   bad peers in the returned address list may become high.  Leaving the
3281	   protection of the tracker to the PPSP tracker protocol specification,
3282	   we assume for the following discussion that it returns a true random
3283	   sample of the actual swarm membership (achieved via Sybil attack
3284	   protection).  This means that if 50% of the peers is bad, you'll
3285	   still get 50% good addresses from the tracker.

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

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

3297	13.3.  Support for Closed Swarms ([RFC6972] PPSP.SEC.REQ-1)

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

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

3309	13.4.  Confidentiality of Streamed Content ([RFC6972] PPSP.SEC.REQ-1)

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

3319	   When transmitting over DTLS, PPSPP can obtain the PMTU estimate
3320	   maintained by the IP layer to determine how much payload can be put
3321	   in a single datagram without fragmentation ([RFC6347], Sec. 4.1.1.1).
3322	   If PMTU changes and the chunk size becomes too large to fit into a
3323	   single datagram, PPSPP can choose to allow fragmentation by clearing
3324	   the DF-bit.  Alternatively, the content publisher can decide to use
3325	   smaller chunks and transmit multiple in the same datagram when the
3326	   MTU allows.

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

3330	   Implementations MUST support SHA-1 as the hash function for content
3331	   integrity protection via Merkle Hash trees.  SHA-1 may be preferred
3332	   over stronger hash functions by content providers because it reduces
3333	   on-the-wire overhead.  As such it presents a trade-off between
3334	   performance and security.  The security considerations for SHA-1 are
3335	   discussed in [RFC6194].

3337	   In general, note that the hash function is used in a hash tree, which
3338	   makes it more complex to create collisions.  In particular, if
3339	   attackers manage to find a collision for a hash it can replace just
3340	   one chunk, so the impact is limited.  If fixed sized chunks are used,
3341	   the collision even has to be of the same size as the original chunk.
3342	   For hashes higher up in the hash tree, a collision must be a
3343	   concatenation of two hashes.  In sum, finding collisions that fit
3344	   with the hash tree are generally harder to find than regular
3345	   collisions.

3347	13.6.  Limit Potential Damage and Resource Exhaustion by Bad or Broken
3348	       Peers ([RFC6972] PPSP.SEC.REQ-2)

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

3354	13.6.1.  HANDSHAKE

3356	   o  Secured against DoS amplification attacks as described in
3357	      Section 13.1.

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

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

3366	13.6.2.  HAVE

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

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

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

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

3380	13.6.3.  DATA

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

3384	      Solution: The content integrity protection schemes defend against
3385	      this.

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

3389	      To protect against this threat we need network-level DoS
3390	      prevention.

3392	13.6.4.  ACK

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

3396	      Solution: peer A will detect inconsistencies with the data it sent
3397	      to T.

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

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

3409	13.6.5.  INTEGRITY and SIGNED_INTEGRITY

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

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

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

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

3427	13.6.6.  REQUEST

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

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

3438	13.6.7.  CANCEL

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

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

3448	13.6.8.  CHOKE

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

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

3456	13.6.9.  UNCHOKE

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

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

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

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

3471	13.6.10.  PEX_RES

3473	   o  Secured against amplification and Eclipse attacks as described in
3474	      Section 13.2.

3476	13.6.11.  Unsolicited Messages in General

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

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

3485	13.7.  Exclude Bad or Broken Peers ([RFC6972] PPSP.SEC.REQ-2)

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

3496	14.  References

3498	14.1.  Normative References

3500	   [CCITT.X208.1988]
3501	              International International Telephone and Telegraph
3502	              Consultative Committee, "Specification of Abstract Syntax
3503	              Notation One (ASN.1)", CCITT Recommendation X.208,
3504	              November 1988.

3506	   [FIPS180-4]
3507	              Information Technology Laboratory, National Institute of
3508	              Standards and Technology, "Federal Information Processing
3509	              Standards: Secure Hash Standard (SHS)", Publication 180-4,
3510	              Mar 2012.

3512	   [IANADNSSECALGNUM]
3513	              IANA, "Domain Name System Security (DNSSEC) Algorithm
3514	              Numbers", Mar 2014,
3515	              <http://www.iana.org/assignments/dns-sec-alg-numbers>.

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

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

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

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

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

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

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

3543	   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
3544	              and RRSIG Resource Records for DNSSEC", RFC 5702, October
3545	              2009.

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

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

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

3559	14.2.  Informative References

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

3565	   [BINMAP]   Grishchenko, V. and J. Pouwelse, "Binmaps: hybridizing
3566	              bitmaps and binary trees", Technical Report PDS-2011-005,
3567	              Parallel and Distributed Systems Group, Fac. of Electrical
3568	              Engineering, Mathematics, and Computer Science, Delft
3569	              University of Technology, The Netherlands, Apr 2009.

3571	   [BITOS]    Vlavianos, A., Iliofotou, M., Mathieu, F., and M.
3572	              Faloutsos, "BiToS: Enhancing BitTorrent for Supporting
3573	              Streaming Applications", IEEE INFOCOM Global Internet
3574	              Symposium Barcelona, Spain, Apr 2006.

3576	   [BITTORRENT]
3577	              Cohen, B., "The BitTorrent Protocol Specification",
3578	              BitTorrent Enhancement Proposal 3, Feb 2008,
3579	              <http://bittorrent.org/beps/bep_0003.html>.

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

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

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

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

3604	   [EPLIVEPERF]
3605	              Bonald, T., Massoulie, L., Mathieu, F., Perino, D., and A.
3606	              Twigg, "Epidemic Live Streaming: Optimal Performance
3607	              Trade-offs", Proceedings of the 2008 ACM SIGMETRICS
3608	              International Conference on Measurement and Modeling of
3609	              Computer Systems Annapolis, MD, USA, Jun 2008.

3611	   [GIVE2GET]
3612	              Mol, J., Pouwelse, J., Meulpolder, M., Epema, D., and H.
3613	              Sips, "Give-to-Get: Free-riding Resilient Video-on-demand
3614	              in P2P Systems", Proceedings Multimedia Computing and
3615	              Networking conference (Proceedings of SPIE Vol. 6818) San
3616	              Jose, California, USA, Jan 2008.

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

3622	   [I-D.gabrijelcic-ppsp-ecs]
3623	              Gabrijelcic, D., "Enhanced Closed Swarm protocol", draft-
3624	              ppsp-gabrijelcic-ecs (work in progress), November 2012.

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

3630	   [I-D.ietf-ppsp-base-tracker-protocol]
3631	              Cruz, R., Nunes, M., Yingjie, G., Xia, J., Taveira, J.,
3632	              and D. Lingli, "PPSP Tracker Protocol-Base Protocol (PPSP-
3633	              TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-06 (work
3634	              in progress), October 2014.

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

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

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

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

3655	   [P2PWIKI]  Bakker, A., Petrocco, R., Dale, M., Gerber, J.,
3656	              Grishchenko, V., Rabaioli, D., and J. Pouwelse, "Online
3657	              video using BitTorrent and HTML5 applied to Wikipedia",
3658	              IEEE International Conference on Peer-to-Peer Computing
3659	              (P2P'10), Delft, The Netherlands, Aug 2010.

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

3666	   [PPSPPERF]
3667	              Petrocco, R., Pouwelse, J., and D. Epema, "Performance
3668	              analysis of the Libswift P2P streaming protocol", IEEE
3669	              International Conference on Peer-to-Peer Computing
3670	              (P2P'12), Tarragona, Spain, Sep 2012.

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

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

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

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

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

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

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

3694	   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
3695	              Addresses", RFC 4193, October 2005.

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

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

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

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

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

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

3716	   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
3717	              Management of New Protocols and Protocol Extensions", RFC
3718	              5706, November 2009.

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

3723	   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
3724	              Considerations for the SHA-0 and SHA-1 Message-Digest
3725	              Algorithms", RFC 6194, March 2011.

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

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

3734	   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
3735	              Considerations for Protocol Extensions", RFC 6709,
3736	              September 2012.

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

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

3746	   [SIGMCAST]
3747	              Wong, C. and S. Lam, "Digital Signatures for Flows and
3748	              Multicasts", IEEE/ACM Transactions on Networking 7(4), pp.
3749	              502-513, 1999.

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

3755	   [SWIFTIMPL]
3756	              Grishchenko, V., Paananen, J., Pronchenkov, A., Bakker,
3757	              A., and R. Petrocco, "Swift reference implementation",
3758	              2014, <https://github.com/libswift/libswift>.

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

3764	Appendix A.  Revision History

3766	   -00        2011-12-19 Initial version.

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

3770	       *  Changed heading to "A.  Bakker"

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

3774	       *  Replaced swift with PPSPP.

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

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

3780	       *  Resolved Ticket #3: Removed sentence about random set of
3781	          peers.

3783	       *  Resolved Ticket #6: Added clarification to "Chunk Picking
3784	          Algorithms" section.

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

3788	       *  Resolved Ticket #14: Added clarification to "Automatic Size
3789	          Detection" section.

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

3794	       *  Resolved Ticket #30: Explained why multiple REQUESTs in one
3795	          datagram.

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

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

3802	       *  Resolved Ticket #33: Explained NAT hole punching via only
3803	          PPSPP messages.

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

3808	   -02        2012-04-17 Major revision

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

3813	       *  Added chunk ID, chunk specification, chunk addressing scheme,
3814	          etc. to terminology.

3816	       *  Created new Sections 4 and 5 discussing chunk addressing and
3817	          content integrity protection schemes, respectively and moved
3818	          relevant sections on bin numbering and Merkle hash trees
3819	          there.

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

3824	       *  Reformulated automatic size detection in terms of nodes, not
3825	          bins.

3827	       *  Extended HANDSHAKE message to carry protocol options and
3828	          created Section 8 on Protocol options.  VERSION and
3829	          MSGTYPE_RCVD messages replaced with protocol options.

3831	       *  Renamed HASH message to INTEGRITY.

3833	       *  Renamed HINT to REQUEST.

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

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

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

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

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

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

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

3857	       *  Moved Rationale to Appendix.

3859	       *  Resolved Ticket #43: Updated Live Streaming section to include
3860	          "Sign All" content authentication, and reference to [SIGMCAST]
3861	          following discussion with Fabio Picconi.

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

3867	   -03        2012-10-22 Major revision

3869	       *  Updated Abstract and Introduction, removing download case.

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

3873	       *  Removed directory lists unused in streaming.

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

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

3881	       *  Added a section on compatibility between chunk addressing
3882	          schemes.

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

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

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

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

3894	       *  Added content integrity protection methods for live streaming
3895	          to the relevant protocol option.

3897	       *  Added a Live Signature Algorithm protocol option.

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

3903	       *  Superfluous parts of Section 10 on extensibility have been
3904	          removed.

3906	       *  Removed appendix with Rationale.

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

3913	   -04        2012-11-07 Minor revision

3915	       *  Corrected typos.

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

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

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

3927	       *  Added PEX_REScert message to carry a membership certificate.
3928	          Renamed PEX_RES to PEX_RESv4.

3930	       *  Added a guideline about private and link-local addresses in
3931	          PEX_RES messages.

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

3936	       *  Clarified that a HANDSHAKE message must be the first message
3937	          in a datagram.

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

3944	       *  Clarified rare case of sending multiple DATA messages in one
3945	          datagram.

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

3950	       *  Defined value for version protocol option.

3952	       *  Added small clarifications and corrected typos.

3954	       *  Extended versioning scheme to Min/max versioning scheme
3955	          defined in [RFC6709], Section 4.1, following Riccardo
3956	          Bernardini's suggestion.

3958	       *  Processed comments on unclear phrasing from Riccardo
3959	          Bernardini.

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

3963	       *  Made sure all essential references are listed as Normative
3964	          references following RFC3967.

3966	   -05        2013-01-23 Minor revision

3968	       *  Corrected category to Standards Track.

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

3973	       *  Added IANA considerations and tablised name spaces for
3974	          registry definition.

3976	   -06        2013-02-11 Minor revision

3978	       *  Updated "Overall Operation" to have more context (HTML5
3979	          video).

3981	       *  Clarified wording on PEX_REQ.

3983	       *  Clarified wording on SIGNED_INTEGRITY.

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

3987	       *  Added Manageability Consideration section following RFC5706.

3989	       *  Clarified that implementations SHOULD implement the "Unified
3990	          Merkle Tree" content integrity protection method for live, and
3991	          MAY implement "Sign All".

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

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

3999	       *  Clarified that implementations MUST implement addressing via
4000	          32-bit chunk ranges.

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

4005	       *  Updated reference to PPSP problem statement and requirements
4006	          document.

4008	       *  Used kibibyte unit in formal sections.

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

4012	          Quoting the AD review by Martin Stiemerling: ***High-level
4013	          issues:

4015	          1) Merkle Hash Trees I have found the document very confusing
4016	          on whether Merkle Hash Trees (MHTs) and the for the MHT
4017	          required bin numbering scheme are now optional or mandatory.
4018	          Parts of the draft make the impression that either of them or
4019	          both or optional (mainly in the beginning of the document),
4020	          while Section 5 and later Sections are relying heavily on
4021	          MHTs.  My naive reading of the current draft is that you could
4022	          rely on start-end ranges for chunk addressing and MHTs for
4023	          content protection.  However, I do know that this combination
4024	          is not working.  If MHTs are really optional, including the
4025	          bin numbering, the document should really state this and make
4026	          clear what the operations of the protocol are with the
4027	          mandatory to implement (MTI) mechanisms.  The MHT, bins, and
4028	          all the protocol handling should go in an appendix.  There is
4029	          a call to make for the WG: I do know that MHTs were considered
4030	          by some as burden and they have called for a leaner way, i.e.,
4031	          the start-end ranges.  The call for the leaner way has been
4032	          implemented in the document but not fully.

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

4039	          2) LEDBAT as congestion control vs. PPSPP The PPSP peer
4040	          protocol is intended for the Standards Track and relies in a
4041	          normative manner on LEDBAT (RFC 6817).  LEDBAT as such is an
4042	          **experimental** delay-based congestion control algorithm.  A
4043	          Standards Track protocol cannot normatively rely on an
4044	          Experimental congestion control mechanism (or RFC in general).
4045	          There are ways out of this situation: i) Do not use ledbat:
4046	          this would call for another congestion control mechanism to be
4047	          described in the PPSPP draft.  ii) Work on an 'upgrade' of the
4048	          LEDBAT specification to Standards Track: Possible, but a very
4049	          long way.  iii) Agree on having PPSPP also as Experimental
4050	          protocol.  I'm currently leaning towards option iii), but this
4051	          is my pure personal opinion as an individual in the IETF.

4053	          +  A new paragraph has been added to Section 8.15 describing
4054	             the widespread use of LEDBAT in current P2P systems.
4055	             Hence, aim is a DOWNREF procedure.

4057	          3) No formal protocol message definition Section 7 and more
4058	          specific Section 8 describe the protocol syntax of the
4059	          protocol options and the messages, though Section 8 is talking
4060	          about UDP encapsulation.  Section 7 is hard to digest if
4061	          someone should implement the options, see also later, but
4062	          Section 8 is almost impossible to understand by somebody who
4063	          has not been involved in the PPSP working group.  See also
4064	          further down for a more detailed review of the sections.  To
4065	          give an example out of Section 8.4: This section describes the
4066	          HANDSHAKE message and gives examples how such a HANDSHAKE
4067	          message could look like.  But no formal definition of the
4068	          message is given leaving a number of thins unclear, such as
4069	          what the local channel number and what's the remote channel
4070	          number is.  This is implicitly defined, but that is not a good
4071	          way of writing Standards Track drafts.

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

4075	          4) Implicit use of default values There are a number of places
4076	          all over the draft where default values are defined.  Many of
4077	          those default values are used when there are no values
4078	          explicitly signaled, e.g., the default chunk size of 1 Kbyte
4079	          in Section 8.4 or Section Section 7.5. with the default for
4080	          the Content Integrity Protection Method.  I have the feeling
4081	          that the protocol and the surroundings (e.g., what comes in
4082	          via the 'tracker') are over-optimized, e.g., always providing
4083	          the Content Integrity Protection Method as part of the
4084	          Protocol options will not waste more than 2 bytes in a
4085	          HANDSHAKE message.  Further, I do not see the need to define a
4086	          default chunk size in the base protocol specification, as this
4087	          default can look very different, depending on who is deploying
4088	          the protocol and in what context.  This calls for a more
4089	          dynamic way of handling the system chunk size, either as part
4090	          of an external mechanisms (e.g. via the tracker) or in the
4091	          HANDSHAKE message.

4093	          +  Removed implicit defaults from protocol options.  Chunk
4094	             size is part of the content's metadata and thus
4095	             configurable.  The default 1KiB has been turned into a
4096	             recommendation.

4098	          5) Concept of channels The concept of channels is good but it
4099	          is introduced too late in the draft, namely in Section 8.3,
4100	          and it is introduced with very few words.  Why isn't this
4101	          introduced as part of Section 2 or Section 3, also in the
4102	          relationship to the used transport protocol?  I.e., the
4103	          intention is to keep only one transport 'connection' between
4104	          two distinct peers and to allow to run multiple swarm
4105	          instances at the same time over the same transport.  And how
4106	          do swarms and channels correlate?

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

4110	          ***Technicals:

4112	          - Section 2.1, 2nd paragraph, about the tracker: I haven't
4113	          seen a single place where the interaction with a tracker is
4114	          discussed or where the tracker less operation is discussed in
4115	          contrast.  It is further unclear what type of information is
4116	          really required from a tracker.  A tracker (or a resource
4117	          directory) would need to provide more then IP address & port,
4118	          e.g., the used transport protocol for the protocol exchange
4119	          (given that other transports are allowed), used chunk size,
4120	          chunk addressing scheme, etc
4121	          +  Interaction with tracking facilities in general is
4122	             discussed in the Operations and Management section,
4123	             Section 12.1.1.  This also discusses swarm metadata and
4124	             information required from tracking facility.  Decentralized
4125	             tracking in PPSPP is discussed in Section 3.10.1.

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

4131	          +  Rephrased.

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

4139	          +  Phrase added.

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

4145	          +  Phrase removed.

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

4153	          +  Added.

4155	          - Section 3.2, 2nd paragraph: "In particular, whenever a
4156	          receiving peer has successfully checked the integrity of a
4157	          chunk or interval of chunks it MUST send a HAVE message to all
4158	          peers it wants to interact with in the near future."  This
4159	          looks like a place where a lot of traffic can be send out of a
4160	          peer, i.e., whenever a chunk arrives a HAVE message must be
4161	          sent.  I don't believe that this should be mandated by the
4162	          protocol specification, but there should guidance on when to
4163	          send this, e.g., peers might be also able to wait for a short
4164	          period of time to gather more chunks to be reported in HAVE.
4165	          Or should in this case a single UDP datagram contain multiple
4166	          HAVEs?
4167	          +  Clarified that this is indeed controlled by a policy
4168	             outside the peer protocol that can decide to piggyback onto
4169	             other traffic or wait till multiple chunks are verified.

4171	          - Section 3.4 on ACKs This section looks pretty weak, as ACKs
4172	          may be sent but on the other hand MUST be sent if ledbat is
4173	          used.  I would simply say: - ACK MUST be sent if an unreliable
4174	          transport protocol is used - ACK MAY be sent if a reliable
4175	          transport protocol is used - keep clarification about ledbat.

4177	          +  DONE.

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

4182	          +  DONE.

4184	          - Section 3.7, 2nd paragraph - all 'MAY' are actually not
4185	          right here.  Please remove or replace them with lower letters
4186	          if appropriate.  - It is not clear what the 'sequentially'
4187	          means exactly.  Is it in the received order?

4189	          +  Rephrased MAYs.  "Sequentially" replaced with "received
4190	             order".

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

4196	          +  DONE.

4198	          - Section 3.9 Same comment as for the Section 3.8 just above
4199	          this comment.

4201	          +  DONE.

4203	          - Section 3.9 waiting for responses OLD " When peer B receives
4204	          a CHOKE message from A it MUST NOT send new REQUEST messages
4205	          and SHOULD NOT expect answers to any outstanding ones."  NEW "
4206	          When peer B receives a CHOKE message from A it MUST NOT send
4207	          new REQUEST messages and it cannot expect answers to any
4208	          outstanding ones, as the transfer of chunks is choked."

4210	          +  DONE.

4212	          - Section 3.10.2 This whole section about PEX hole punching
4213	          reads very, very experimental.  The STUN method is ok, but PEX
4214	          isn't.  First of all, the safe behavior for a peer when it
4215	          receives unsolicited PEX messages, is to discard those
4216	          messages.  Second, this unsolicited PEX messages trigger some
4217	          behavior which may open an attack vector.  The best way, but
4218	          this needs more discussion, is to include to some token in the
4219	          messages that are exchanged in order to make avoid any blind
4220	          attacks here.  However, this will need more and detailed
4221	          discussions of the purpose of this.

4223	          +  We moved parts of the security analysis of PEX up, such
4224	             that all mechanisms are explained in the main text, and the
4225	             analysis of what attacks there are and how these mechanisms
4226	             prevent them is in the Sec. Considerations section.

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

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

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

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

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

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

4250	          +  DONE.

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

4258	          +  Yes, the reference implementation translates from chunk
4259	             ranges on the wire to bins internally.  However, for
4260	             simplicity we now state that all peers in a swarm MUST use
4261	             the same method and the compatibility section has been
4262	             removed.

4264	          - Section 5 This reads that MHTs are mandatory to implement
4265	          while the document makes the impression that MHTs are
4266	          optional.

4268	          +  Rephrased, see High-level issues.

4270	          - Section 5.3 " so each datagram SHOULD be processed
4271	          separately and a loss of one datagram MUST NOT disrupt the
4272	          flow" The MUST NOT is not a protocol specification
4273	          requirement, but more an informative part saying that a lost
4274	          message shouldn't impact the protocol machinery, but it can
4275	          impact the overall operation.  What is the flow here in that
4276	          sentence?

4278	          +  Rephrased.

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

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

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

4291	          +  Expanded.  Added a formal definition.

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

4297	          +  Actually, it does not.  There is a single unstructured
4298	             version number.

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

4305	          +  Clarified.

4307	          - Section 7.6 MHTs are mandatory to support though MHTs are
4308	          optional?

4310	          +  Clarified.

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

4318	          +  Key size derivation procedure added to description of
4319	             SIGNED_INTEGRITY in UDP encapsulation.

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

4325	          +  Corrected, see High-level issues 4.)

4327	          - Section 7.10 I have not understood how the 'Lenght' field
4328	          relates to the message bitmap and how long the message bitmap
4329	          can grow.  The figure looks like a maximum of 16 bits?

4331	          +  Clarified.

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

4339	          +  Adjusted.

4341	          - Section 8.1 about Maximum Transfer Unit (MTU) The text is
4342	          discussing that a Ethernet can carry 1500 bytes.  This is
4343	          true, but the Ethernet payload is not the normative MTU across
4344	          all of the Internet.  For IPv6 the min MTU is 1280 bytes and
4345	          for IPv4 it is 576 bytes, though for IPv4 it can be
4346	          theoretically much lower at 64 bytes.  It would move the
4347	          definition of the default chunk size to a recommendation with
4348	          text saying that this size has a high likelihood to travel
4349	          end-to-end in the Internet without any fragmentation.
4350	          Fragmentation might increase the loss of complete chunks, as
4351	          one lost fragment will cause the loss of a complete chunk.
4352	          One way of getting an informed decision on whether chunks can
4353	          travel in their size is to use the Don't Fragment (DF) bit in
4354	          IPv4 and also to watch for ICMP error messages.  However, ICMP
4355	          error messages are not a reliable indication, but they can be
4356	          some indication.

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

4360	          +  Added a small paragraph discussing the optional integration
4361	             of MTU path discovery.

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

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

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

4376	          +  Concept now introduced in Section 3.11.

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

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

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

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

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

4395	          +  Clarified.

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

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

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

4405	          +  Implementors will unfortunately need to read the full
4406	             LEDBAT specification.

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

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

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

4417	          +  We moved parts of the security analysis of PEX up into
4418	             3.10, such that all mechanisms are explained in the main
4419	             text, and the analysis of what attacks there are and how
4420	             these mechanisms prevent them is in the Sec. Considerations
4421	             section.

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

4427	          +  Policy changed to "IETF Review" and the section was
4428	             extended with information about data types and required
4429	             information.

4431	          ***Editorials:

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

4436	          +  DONE.

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

4442	          +  DONE.

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

4447	          +  DONE.

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

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

4454	          - Section 2.1: What is the PPSP Url?
4455	          +  Reformulated in terms of "Imagine there is a PPSP URL".

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

4461	          +  DONE.  Dead peer detection is now a separate section and
4462	             referenced here.

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

4468	          +  DONE.

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

4473	          +  Rephrased.

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

4478	          +  Rephrased.

4480	          - Section 3.10.1 about PEX messages The text says 'PPSPP
4481	          optionally features...'.  I have not understood if this
4482	          optionally refers to mandatory to implement but optionally to
4483	          use, or if the PEX messages are optionally to implement.

4485	          +  Made it clear that is OPTIONAL and not mandatory-to-
4486	             implement.

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

4493	          +  Yes. Removed.

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

4498	          +  DONE, for byte ranges as well.

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

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

4507	          +  Removed, just similarity in format.

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

4516	          - Section 8.1 1 kibibyte is 1 kbyte?

4518	          +  Mentioned base 1024 in Terminology.  Changed to 1024 bytes
4519	             where appropriate.

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

4525	          +  Idempotent means that processing a message twice does not
4526	             lead to a different state than processing them once.
4527	             Resent handshakes can be recognized as duplicates because a
4528	             peer already recorded the first connection attempt in its
4529	             state.  Updated text.

4531	          - Section 8.5, last sentence in brackets: What is this last
4532	          sentence about?

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

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

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

4545	          - Section 8.14 There is no single place where all the
4546	          constants are collected and also documented what the default
4547	          values or the recommended values.  For instance in this
4548	          Section 8.14 where the dead peer time out is set to 3 minutes
4549	          and also the number of datagrams that should have sent.  I
4550	          would make a section or subsection to discuss dead peers and
4551	          how they are detected and just link to the keep-alive
4552	          mechanism in Section 8.14.

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

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

4561	          +  The section was extended with information about data types
4562	             and required information.

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

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

4568	          Added ECDSAP256SHA256 and ECDSAP384SHA384 as mandatory-to-
4569	          implement live signature algorithms, as they provide small
4570	          swarm IDs.

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

4576	          In response to a remark at WG meeting at IETF 87 we added a
4577	          paragraph on OPTIONAL MTU discovery using PPSPP messages to
4578	          Section 8.1.

4580	   -09        2014-04-4 Nits fixed

4582	          Nits about e.g. newer references fixed.

4584	   -10        2014-06-17 DOWNREF restored

4586	          Reference to LEDBAT was not in Normative references as it
4587	          should have been.

4589	   -11        2014-06-18 IANA not OK

4591	          In the 2nd Last Call IANA posed two questions:

4593	          " QUESTION: Are the authors intended to have one single top-
4594	          level registry to host these six new registries defined in
4595	          this draft?  Please see http://www.iana.org/assignments/ancp
4596	          as an example, that the ANCP registry hosts multiple sub-
4597	          registries."
4598	          +  Yes. We updated the IANA Considerations section with IANA's
4599	             Pearl Liang proposed text to request this.

4601	          "QUESTION: Section 11.3 specifies that the values are integers
4602	          in the range 0-255.  However value 0 is not included in the
4603	          above table.  Section 7.2 (Version) does not clearly explain
4604	          value 0."

4606	          +  0 defined as reserved.

4608	          Text cleanup

4610	          +  Terminology: states chunks may be variable size explicitly
4611	             also here.

4613	          +  Figure 3 label improved.

4615	          +  5.4 Explicitly state that leaves have tree height 0.

4617	          +  5.5 Repaired split paragraph.

4619	          +  5.6 Rephrased start to be consistent with minimally
4620	             required metadata.

4622	          +  5.6.1 Removed remark about peak hashes role in static/live
4623	             download unification as that is no longer the case.

4625	          +  5.6.2 Explicitly stated that peak hashes are transported in
4626	             INTEGRITY messages.

4628	          +  6.1.2.1 Changed "computing the computed" to "comparing the
4629	             computed"

4631	          +  6.2 Changed sentence to "*is* related to bitrate"

4633	          +  8.4 Explicitly stated that the *Source* Channel ID is all
4634	             0-zeros in closing HANDSHAKE.

4636	          +  8.5 Removed spurious line.

4638	          +  8.6 Explicitly stated that the chunk specification in a
4639	             DATA message denotes a single chunk.

4641	          +  8.8 Changed copy+paste from ACK to INTEGRITY message.

4643	          +  8.12 Renamed PEX_RES to PEX_RESv4 where needed.

4645	          +  8.17 Explicitly stated that the *Source* Channel ID is all
4646	             0-zeros in closing HANDSHAKE.

4648	          +  12.1.5 Changed to read that a swarm's operation can easily
4649	             verified when swarm metadata and tracker info is available.

4651	          +  13.2.1 "cert" -> "certificate"

4653	          +  Added refs to RFC6972 where required.

4655	          ==============================================================
4656	          =========== IESG telechat DISCUSSES ==========================
4657	          ===============================================

4659	          **Alissa Cooper:**

4661	          "I'm a little surprised about the choice of LEDBAT for
4662	          congestion control of live streams.  It seems like LEDBAT is
4663	          not what the receiver would want the sender to use for live-
4664	          streamed content, because if a bottleneck is encountered on
4665	          the path, the live stream will yield early, and the
4666	          recipient's perception of quality will degrade.  If the
4667	          bottleneck is near the recipient, then every sender sending
4668	          chunks will yield early, and there may be no senders available
4669	          to stream at an acceptable level of quality.  I'm assuming the
4670	          WG discussed this -- it would be helpful to understand why a
4671	          more aggressive congestion control was not selected for live
4672	          streaming."

4674	          +  Updated 8.16 to discuss why LEDBAT is good in a peer-to-
4675	             peer context (can be friendly to network as a whole and has
4676	             configurable aggressiveness)

4678	          --------------------------------------------------------------

4680	          **Stephen Farrell:**

4682	          "(1) 3.10: What is a "benign" environment?  I actually do
4683	          understand what is meant, but how could a program evaluate
4684	          that in order to decicde whether or not to send a PES_RESv4?
4685	          You then refer to a "potentially hostile environment" which
4686	          could presumably be anywhere, so are you really saying that
4687	          PES_REScert is the "right thing" to do, but you know it won't
4688	          be done so these are weasel words around that awkward fact?
4689	          (Apologies if I'm wrong on that, but that's the impression I
4690	          got when reading this, but maybe that's just my paranoia:-)"
4691	          +  Rephrased to show PEX_REScert is the only option on the
4692	             Internet.

4694	          "(2) 6.1.2.2: What exactly are the "munro" bytes that are the
4695	          first input to the signature?  Where are those defined?
4696	          (Sorry if I missed/skipped over that;-)"

4698	          +  Added to Terminology and added an explicit reference in
4699	             this section.

4701	          "(3) 7.6 and 13.5: SHA1 as the MTI is wrong.  Why is that ok,
4702	          given the collision resistance is less that designed for? 7.7
4703	          also calls for SHA256 being implemented in any case.  The run-
4704	          time argument in 13.5 does not convince me.  Attacks only ever
4705	          get worse, so the collision resistance property which this
4706	          protocol needs ought lead to selection of an as-far-as-known
4707	          good hash function.  Today that means SHA256 and not SHA1."

4709	          +  SHA-256 is now the default.  SHA-1 is still MTI to give
4710	             content providers a trade-off between performance and
4711	             security, as the on-the-wire overhead is 37.5% smaller.

4713	          "(4) 7.7: Why RSASHA1 and not RSA with SHA256?"

4715	          +  RSA256 is now also MTI, but RSASHA1 is also required, as
4716	             argued in the previous point.

4718	          "(5) 7.10: The message number is wrong in the figure."

4720	          +  Fixed.

4722	          "(6) 8.4: I don't see the swarm's metadata record in the ascii
4723	          art diagram and you just say "look at section 7" so two
4724	          questions: a) where is the "chunk size used" option in section
4725	          7? and b) do all the swarm metadata options have to be sent
4726	          each time with no limit on ordering except as given in section
4727	          7 (which had one such order sensitive limit I think)?"

4729	          +  (a) We once envisioned that a peer could start with just a
4730	             swarm ID+chunk size as metadata and obtain all protocol
4731	             options (chunk addressing, integrity protection, etc.) from
4732	             a peer.  As this turned out to be too complex to secure
4733	             (peers may lie about the options), we decided to make the
4734	             options all part of the swarm metadata after the AD review.
4735	             This renders the protocol options in the HANDSHAKE to an
4736	             end-to-end test really.  Chunk size was never part of that
4737	             negotiation because writing code that would handle bad
4738	             input on that parameter was definitely too complicated.
4739	             Chunk size has now been added as a protocol option.

4741	          +  (b) The HANDSHAKE message and hence protocol options are
4742	             sent only in the first datagram.  After that this
4743	             information is part of the context of the channel that has
4744	             been established.  We added a limit on ordering (sort on
4745	             code value, ascending) as a simplification.

4747	          "(7) 8.13: Don't you need to register the ppsp URI scheme?  In
4748	          case its useful, which I doubt, if you have code: RFC6920 URIs
4749	          could be used for this if you wanted and would save you adding
4750	          ppsp to the IANA URI scheme registry (and having to deal with
4751	          the URI police:-)"

4753	          +  Not sure.  The problem is we need to denote a peer in a
4754	             swarm here.  This means we need to encode the swarm ID and
4755	             the peer address.  IMHO, this means we cannot use the ni:
4756	             RFC6920 scheme here, because only the hash determines
4757	             identity.  If we would encode the swarm ID there (SHA-256
4758	             hash of the swarm ID), we need a place for the peer address
4759	             and the authority part does not make the URL unique.  The
4760	             ni: URL will still only identify the swarm.  Encoding the
4761	             peer address in OtherNames instead of
4762	             uniformResourceIdentifier is troublesome too.  We could
4763	             find no single object type to denote a transport address
4764	             (IP+port) that supports both IPv4 and IPv6 (udpDomain is
4765	             IPv4 only).  Using SAN ipAddress for the address and a
4766	             separate OtherName for the port number (e.g.
4767	             udpEndpointLocalPort from [RFC4113]) is not ideal, as the
4768	             port number by itself is not a name for the subject.
4769	             Hence, we replaced the ppsp: scheme with the file: scheme,
4770	             which has an authority part where we can naturally encode
4771	             the peer address in.

4773	          "(8) 13.4: Wouldn't DTLS change the chunk size considerations
4774	          and also influence how messages map to datagrams?  Isn't more
4775	          specification needed to say how to really use DTLS here?  Just
4776	          saying "use DTLS or IPsec or higher layer crypto" doesn't
4777	          really seem sufficient.  And doing the DTLS bits right
4778	          shouldn't be very hard either."

4780	          +  According to RFC6347, for "DTLS over UDP, the upper layer
4781	             protocol SHOULD be allowed to obtain the PMTU estimate
4782	             maintained in the IP layer" (Sec. 4.1.1.1).  So we know
4783	             beforehand how much payload we can send in a datagram
4784	             without fragmentation.  If PMTU changes and the chunk size
4785	             becomes too large, we can choose to allow fragmentation
4786	             ("the upper layer protocol SHOULD be allowed to set the
4787	             state of the DF bit (in IPv4) or prohibit local
4788	             fragmentation (in IPv6).").  Alternatively, the content
4789	             publisher can decide to use smaller chunks and transmit
4790	             multiple in the same datagram when the MTU allows.  We
4791	             added an explanatory paragraph to Section 13.4.

4793	          **Other DISCUSSes: TODO.**

4795	   -12        2014-11-16 Other DISCUSSes and reviews

4797	          ==============================================================
4798	          =========== IESG telechat DISCUSSES (continued) ==============
4799	          ===========================================================

4801	          **Richard Barnes:**

4803	          "My DISCUSS here is based mainly on the readability of the
4804	          document, which seems bad enough to be an impediment to
4805	          interoperability.  As far as I can tell, this document does
4806	          not define a protocol, in the sense of a set of actions
4807	          required to achieve a given objective.  Instead, it presents a
4808	          pile of piece parts with a couple of combinations, and notes
4809	          that these combinations could be used to achieve, e.g., live
4810	          streaming.  (In the language of patents, it has not been
4811	          "reduced to practice".)  What are the steps an implementation
4812	          follows to join a swarm?  To connect to a new peer and request
4813	          chunks?  The pieces seem to be here, but the big picture is
4814	          completely absent."

4816	          +  Clarified the DISCUSS via email.  In response, we made the
4817	             distinction between tracker protocol and peer protocol more
4818	             clear in the Introduction and Section 2.

4820	          +  We also rewrote the section on the HANDSHAKE message to
4821	             include an explicit handshake procedure in the format
4822	             suggested.

4824	          --------------------------------------------------------------

4826	          **Kathleen Moriarty:**

4828	          "I am still reading this draft, but don't see any response to
4829	          the SecDir review that raised some very important points for
4830	          discussion: http://www.ietf.org/mail-
4831	          archive/web/secdir/current/msg04879.html I'll amend this when
4832	          I get further into my review and would appreciate a response
4833	          to the SecDir review."
4834	          +  Please see our responses to the SecDir review via email:
4835	             http://www.ietf.org/mail-archive/web/secdir/current/
4836	             msg04914.html and below.

4838	          --------------------------------------------------------------

4840	          **OpsDir review** by Tina TSOU (replied to by email, July 9th,
4841	          2014):

4843	          "You probably want to mention SHA-256 rater than SHA-1 [...]"

4845	          +  SHA-256 made default.  See reply to Farrell.

4847	          "Section 8.13: You should also include ULAs"

4849	          +  Added.

4851	          "Section 8.16: This doesn't seem like a good justification for
4852	          not having flow control.  Could you please elaborate on why
4853	          flow control is not needed for this case?"

4855	          +  Explained in email reply.

4857	          "Section 8.17, page 53: The channel ID values employed might
4858	          give the reader the impression that they are non-random."

4860	          +  Stated explicitly they must be random with a reference to
4861	             why.

4863	          Nits

4865	          +  Processed

4867	          --------------------------------------------------------------

4869	          **GenArt review** by Christer Holmberg (replied to by email,
4870	          July 9th, 2014)

4872	          "Q1: The sending of keep alives is a SHOULD, and there are no
4873	          procedures on how to act if keep alives are not received.
4874	          There isn't even a mechanism to negotiate the sending of keep
4875	          alives.

4877	          +  Rewrote Section 3.12 to explain what happens when no keep
4878	             alives are received.  In particular, given certain
4879	             conditions the peer is declared dead and no more messages
4880	             are sent to it, and the local administration about that
4881	             peer is discarded.  The exact conditions were specified in
4882	             Sec. 8.15 but are now defined in 3.12 at Christer's
4883	             suggestion in his follow-up to our reply.  Section 8.15
4884	             removed.

4886	          "Q2: As the sending of keep alives is a SHOULD, are there
4887	          example cases when keep alives would NOT be sent?"

4889	          +  Added example of busy server garbage collecting idle
4890	             clients by not sending keep alives.

4892	          "Q3: The text saying "to each peer it wants to interact with
4893	          in the future" sounds a little strange to me.  How does a peer
4894	          know with whom it wants to interact in the future?  Perhaps
4895	          the text instead should talk about peers with whom one wants
4896	          to maintain a signaling channel, or something like that?"

4898	          +  Rephrased in Sec. 3.12 to "interesting peers" and explain
4899	             there is a policy that determines which peers are of
4900	             interest.  E.g. peers that have chunks that the downloader
4901	             is still missing.

4903	          --------------------------------------------------------------

4905	          **SecDir review** by David Harrington (replied to by email,
4906	          July 10th, 2014)

4908	          Editorials:

4910	          +  Incorporated.

4912	          "6) tech: I feel uncomfortable with section 2 containing
4913	          examples that describe the overall flow.  Examples are non-
4914	          normative text, usually contained in a non-normative appendix.
4915	          These examples describe the order of messages, and it is "

4917	          +  Please see our actions taken on Richard Barnes' DISCUSS.

4919	          "7) in example 2.2, the integrity hash is provided by the peer
4920	          that is providing the (potentially maliciously modified)
4921	          content.  Isn't that like asking the fox to verify that the
4922	          henhouse is safe?"

4924	          +  Added that the hashes can be verified against the trusted
4925	             swarm ID using the Merkle tree content integrity protection
4926	             scheme, defined later in the document.

4928	          "9) in 3, paragraph 1, it says "this behavior", but I'm not
4929	          sure which behavior it is referencing.  It is unclear whether
4930	          not sending error messages, or discarding messages, or
4931	          stopping communication, or classifying peers is the behavior
4932	          that allows a peer to deal with slow, crashed, or silent
4933	          peers.  I don't understand HOW any of the behaviors mentioned
4934	          would allow a peer to deal with slow, crashed, or silent
4935	          peers.  I do not understand on what basis peers are judged
4936	          "good" or "bad"."

4938	          +  Added explanation how in a peer-to-peer system with
4939	             multiple sources to obtain the content from, the
4940	             classification in good and bad can be used to deal with
4941	             malfunctioning peers.

4943	          "11) in 3, paragraph 3, the second sentence seems to
4944	          contradict the first sentence, and since neither is written
4945	          using RFC2119 keywords, it seems to really leave the whole
4946	          question open to implementer interpretation."

4948	          +  Added that the video container format used is outside the
4949	             scope of this document.

4951	          ``"A SIGNED_INTEGRITY message (type 0x07) consists of a chunk
4952	          specification, a 64-bit NTP timestamp [RFC5905] and a digital
4953	          signature encoded as a Signature field in a RRSIG record in
4954	          DNSSEC without the BASE-64 encoding [RFC4034]."  Can this work
4955	          in an implementation with no NTP support?''

4957	          +  Yes. It is sufficient for the injector's and receivers'
4958	             clocks to be roughly synchronized.  Rephrased to "64-bit
4959	             timestamp in NTP Timestamp format".

4961	          "8.14 describes a keep alive message format, but no processing
4962	          instructions."

4964	          +  Please see our actions following the GenArt review.

4966	          "Multiple messages are multiplexed in a datagram.  How are the
4967	          messages delimited?  If there is any corruption in one
4968	          message, how does the receiver find the end of the message and
4969	          the start of the next message?  If I understand correctly,
4970	          invalid messages are discarded and no error code is sent.  If
4971	          one of the messages are found to be invalid, are all messages
4972	          in that datagram discarded? or are all subsequent messages in
4973	          that datagram discarded? or is it valid to process the
4974	          remaining messages in the datagram after an invalid message is
4975	          detected?  If so, would that conflict with the rule that all
4976	          messages must be processed in order?"
4977	          +  Messages are fixed size, or contain size fields.  Made it
4978	             more clear in Section 3 that when an invalid message is
4979	             encountered in a datagram, the remaining messages MUST be
4980	             discarded.

4982	          --------------------------------------------------------------

4984	          ** COMMENTS by Spencer Dawkins, July 8th 2014**

4986	          "3.  Messages In general, no error codes or responses are used
4987	          in the protocol; absence of any response indicates an error.
4988	          Is there accurate qualifier more narrow than "in general" that
4989	          you could substitute?"

4991	          +  Qualifier removed.

4993	          "3.1.  HANDSHAKE [heavy/minor confusing]"

4995	          +  Heavy payload has been explicitly defined in Terminology.
4996	             Please see our response to Richard Barnes' DISCUSS for a
4997	             rephrased definition of the handshake procedure.

4999	          "3.2.  HAVE In particular, whenever a receiving peer P has
5000	          successfully checked the integrity of a chunk, or interval of
5001	          chunks, it SHOULD send a ^^^^^^ HAVE message to all peers
5002	          Q1..Qn it wants to interact with in the near future.  A policy
5003	          in peer P determines when the HAVE is sent.  P may sent it
5004	          directly, or peer P may wait until either it has other data to
5005	          sent to Qi, or until it has received and checked multiple
5006	          chunks.  This wasn't clear to me.  I'm not understanding why a
5007	          SHOULD is appropriate, but I suspect I shouldn't be askig a
5008	          2119 question, because this is tangled between "send a HAVE to
5009	          the peers you want to interact with in the near future" and
5010	          "if you don't want to interact with a specific peer in the
5011	          near future, you can wait to send a HAVE".  Is that even
5012	          close? "

5014	          +  Yes. Changed to a MUST and rephrased that the HAVE is sent
5015	             only to the peers the sender wants to allow download of
5016	             those chunks from.

5018	          "3.4.  ACK [unreliable/reliable discussion in WG]"

5020	          +  The swift protocol on which this draft is based had been
5021	             designed from the start to be transport-agnostic.  We tried
5022	             to preserve that as much as possible.

5024	          "5.3.  The Atomic Datagram Principle [...] With that many
5025	          SHOULDs, I'd be worried that implementations using PPSPP can't
5026	          count on much.  If I receive a message that spans multiple
5027	          datagrams (even though it shouldn't), that don't include the
5028	          necessary hashes (even though it should), and I don't drop a
5029	          message with missing data (even though I should), is that all
5030	          fine?"

5032	          +  Yes. Unfortunately, there are some exceptional cases that
5033	             have to be dealt with.  E.g. because of reordering you may
5034	             want to hang on to a datagram with a DATA message that
5035	             cannot yet be verified because the datagram with the
5036	             required hashes was delayed.  In general, there will be
5037	             multiple sources to obtain the content from, so a peer/
5038	             implementor may choose to get the chunks from a different
5039	             source with a better path.

5041	          "5.4.  INTEGRITY Messages Concretely, a peer that wants to
5042	          send a chunk of content creates a datagram that MUST consist
5043	          of a list of INTEGRITY messages followed by a DATA message.
5044	          If the INTEGRITY messages and DATA message cannot be put into
5045	          a single datagram because of a limitation on datagram size,
5046	          the INTEGRITY messages MUST be sent first in one or more
5047	          datagrams.  Is this assuming that the path between peers will
5048	          never reorder packets?"

5050	          +  No.  Hence, the many SHOULDs in the previous Section.  This
5051	             facilitates processing in the normal case.

5053	          --------------------------------------------------------------

5055	          **COMMENT by Jari Arkko, July 8th 2014**

5057	          +  Please see responses to GenArt review.

5059	          --------------------------------------------------------------

5061	          **COMMENTs by Barry Leiba, July 9th 2014**

5063	          "General question on the chunking: Is it the case that a given
5064	          piece of content is chunked in a specific way, with known
5065	          chunk IDs, such that every peer that's serving that content up
5066	          (at least in the same swarm) uses the same chunks with the
5067	          same chunk IDs?  One can guess that from the way things work,
5068	          but shouldn't the document say that?  Or does it, and I missed
5069	          it?"

5071	          +  Explicitly stated this in Section 3.

5073	          "-- Section 3.7 -- When peer Q receives multiple REQUESTs from
5074	          the same peer P, peer Q SHOULD process the REQUESTs in the
5075	          order received.  What happens if it doesn't?  Is there an
5076	          interoperability issue here?  A performance issue?  Or what?
5077	          (That is, why is this a 2119 SHOULD?)"

5079	          +  Consider the case where peer P is operating near the
5080	             playback deadline, i.e., the last chunk it has needs to be
5081	             given to the video player very soon or it will stall (i.e.,
5082	             P has nearly run out of buffer).  In that case it is
5083	             important that the chunks P requests arrive in order (and
5084	             it will be requesting a range of chunks at a time to get a
5085	             pipeline going).  So the SHOULD is there to help prevent a
5086	             performance problem.

5088	          "-- Section 5.3 -- Thus, as a datagram carries zero or more
5089	          messages, neither messages nor message interdependencies
5090	          SHOULD span over multiple datagrams.  The negatives in this
5091	          sentence really make the SHOULD a hidden SHOULD NOT, and its
5092	          meaning is unclear.  I think it would be clearer if it were
5093	          worded that way:"

5095	          +  Replaced with suggested wording.

5097	          --------------------------------------------------------------

5099	          **COMMENTs by Alia Atlas, July 9th 2014**

5101	          +  Requested modifications made.

5103	          "Sec 8.1: The paragraph on PLPMTUD is a bit confusing.
5104	          Presumably this is between two peers - but the chunk sizes
5105	          used by the swarm would be specified by the initial seeder.
5106	          Thus I can see the PLPMTUD variant being useful to decide upon
5107	          the PPSPP datagram size, but not the chunk size.  Could you
5108	          please clarify either what I'm missing?"

5110	          +  This section discussed considerations for choosing a chunk
5111	             size.  Deployments can use PLPMTUD, but in that case they
5112	             should partition the content using a small chunk size, such
5113	             that the datagram can be scaled up or down depending on the
5114	             actual network properties.

5116	          --------------------------------------------------------------

5118	          **COMMENTs by Stephen Farrell, July 10th 2014**.

5120	          For DISCUSSes, please see above at revision -11.

5122	          "- The elephant is in the room, but not the intro:-) Surely
5123	          some comparison with BT is needed in the intro?"

5125	          +  Paragraph added.

5127	          "- 1.1: I really dislike the term self-certification as its
5128	          quite misleading."

5130	          +  AFAIK the term was quite common for this type of mechanism,
5131	             see e.g.  http://en.wikipedia.org/wiki/Self-
5132	             certifying_File_System

5134	          "- 1.3, 'content': s/asset/file/ would be better I think and
5135	          less capitalist;-)"

5137	          +  Done.  We had commercial partners in our research project
5138	             ;-)

5140	          "- 3: I don't get what is meant by this "an external storage
5141	          mapping from the linear byte space of a single swarm to
5142	          different files" I can sorta see what's meant, but am not
5143	          sure.  Maybe try clarify?"

5145	          +  In other words, we do not prescribe the video container
5146	             format.  Added to the paragraph.

5148	          "- 5.3, last para: Is the 1st MUST there really implementable
5149	          in general?  I think the MUST might be to include those hashes
5150	          that the sender thinks the receiver needs."

5152	          +  Clarified

5154	          "- 6.1 - this defines two methods yet says "If the protocol
5155	          operates in a benign environment the method MAY be used."
5156	          Which is meant here?"

5158	          +  Clarified.

5160	          "- 6.1.2.1: what if different folks think NCHUNKS_PER_SIG has
5161	          different values?  How do we all agree on a value?  (BTW, the
5162	          last sentence of this section is a cool thing.)"

5164	          +  This value is set by the content publisher, and is then
5165	             derived from the chunk specification of the signed munro
5166	             hash by all peers.

5168	          "- 7.4: "In other cases a peer MAY include a swarm identifier
5169	          option, as an end-to-end check."  That's not clear to me, what
5170	          other cases?"

5172	          +  Rephrased.

5174	          "- 7.8: The width of the figure seems wrong."

5176	          +  Corrected.

5178	          "- 7.10: An example compressed encoding would be useful."

5180	          +  Added a small example.

5182	          "- 8.16: "perfectly detected" - huh? what does that mean?"

5184	          +  Rephrased in revision -11.

5186	          --------------------------------------------------------------

5188	Authors' Addresses

5190	   Arno Bakker
5191	   Vrije Universiteit Amsterdam
5192	   De Boelelaan 1081
5193	   Amsterdam  1081HV
5194	   The Netherlands

5196	   Email: arno@cs.vu.nl

5198	   Riccardo Petrocco
5199	   Technische Universiteit Delft
5200	   Mekelweg 4
5201	   Delft  2628CD
5202	   The Netherlands

5204	   Email: r.petrocco@gmail.com

5206	   Victor Grishchenko
5207	   Technische Universiteit Delft
5208	   Mekelweg 4
5209	   Delft  2628CD
5210	   The Netherlands

5212	   Email: victor.grishchenko@gmail.com