Merge branch 'master' into ianswett-patch-3

Author: martinthomson

Makefile

@@ -10,6 +10,13 @@ endif
 
 latest::
 	@if grep -l ' $$' *.md; then ! echo "Trailing whitespace found"; fi
-	@wc -L draft-*.md | head -n -1 | while read l f; do \
-	  [ "$$l" -le 80 ] || ! echo "$$f is contains a line with $$l characters"; \
-	done
+	@err=0; for f in draft-*.md ; do \
+	  line=$$(cat "$$f" | wc -L); \
+	  if [ "$$line" -gt 80 ]; then \
+	    echo "$$f contains a line with >80 ($$line) characters"; err=1; \
+	  fi; \
+	  figure=$$(sed -e '/^~~~/,/^~~~/p;d' "$$f" | wc -L); \
+	  if [ "$$figure" -gt 69 ]; then \
+	    echo "$$f contains a figure with >69 ($$figure) characters"; err=1; \
+	  fi; \
+	done; [ "$$err" -eq 0 ]

draft-ietf-quic-http.md

@@ -31,7 +31,7 @@ normative:
         org: Mozilla
         role: editor
       -
-        ins: S. Turner, Ed.
+        ins: S. Turner
         name: Sean Turner
         org: sn3rd
         role: editor

draft-ietf-quic-recovery.md

@@ -37,7 +37,7 @@ normative:
         org: Mozilla
         role: editor
       -
-        ins: S. Turner, Ed.
+        ins: S. Turner
         name: Sean Turner
         org: sn3rd
         role: editor
@@ -483,7 +483,7 @@ Pseudocode for OnAlarm follows:
 ~~~
    OnAlarm(acked_packet):
      lost_packets = DetectLostPackets(acked_packet);
-     MaybeRetransmitLostPackets();
+     MaybeRetransmit(lost_packets);
      SetLossDetectionAlarm();
 ~~~
 
@@ -503,22 +503,21 @@ identical to other packets.
 
 ### Psuedocode
 
-DetectLostPackets takes one parameter, acked_packet, which is the packet number
-of the largest acked packet, and returns a list of packet numbers detected as
-lost.
+DetectLostPackets takes one parameter, acked, which is the largest acked packet,
+and returns a list of packets detected as lost.
 
 Pseudocode for DetectLostPackets follows:
 
 ~~~
-   DetectLostPackets(acked_packet):
+   DetectLostPackets(acked):
      lost_packets = {};
-     foreach (unacked_packet less than acked_packet):
-       if (unacked_packet.time_sent <
-           acked_packet.time_sent - kTimeReorderThreshold * smoothed_rtt):
-         lost_packets.insert(unacked_packet.packet_number);
-       else if (unacked_packet.packet_number <
-                acked_packet.packet_number - reordering_threshold)
-         lost_packets.insert(unacked_packet.packet_number);
+     foreach (unacked less than acked):
+       time_delta = acked.time_sent - unacked.time_sent
+       packet_delta = acked.packet_number - unacked.packet_number
+       if (time_delta > kTimeReorderThreshold * smoothed_rtt):
+         lost_packets.insert(unacked);
+       else if (packet_delta > reordering_threshold)
+         lost_packets.insert(unacked);
      return lost_packets;
 ~~~
 

draft-ietf-quic-transport.md

@@ -52,7 +52,7 @@ normative:
         org: Mozilla
         role: editor
       -
-        ins: S. Turner, Ed.
+        ins: S. Turner
         name: Sean Turner
         org: sn3rd
         role: editor
@@ -475,8 +475,8 @@ The fields in a Regular packet past the Common Header are the following:
 
 * Packet Number: The lower 8, 16, 32, or 48 bits of the packet number, based on
   the PACKET_NUMBER_SIZE flag.  Each Regular packet is assigned a packet number
-  by the sender.  The first packet sent by an endpoint MUST have a packet number
-  of 1.
+  by the sender.  The first packet number is randomized (see
+  {{initial-packet-number}}.
 
 * Encrypted Payload: The remainder of a Regular packet is both authenticated and
   encrypted once packet protection keys are available.  {{QUIC-TLS}} describes
@@ -535,6 +535,17 @@ at any point in the connection.  In other words,
 
 (TODO: Clarify how packet number size can change mid-connection.)
 
+
+### Initial Packet Number
+
+The initial value for packet number MUST be a 31-bit random number.  That is,
+the value is selected from an uniform random distribution between 0 and 2^31-1.
+
+The first set of packets sent by an endpoint MUST include the low 32-bits of the
+packet number.  Once any packet has been acknowledged, subsequent packets can
+use a shorter packet number encoding.
+
+
 ### Frames and Frame Types {#frames}
 
 A Regular packet MUST contain at least one frame, and MAY contain multiple
@@ -920,28 +931,29 @@ A STREAM frame is shown below.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|       [Data Length (16)]      |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Stream ID (8/16/24/32)                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Offset (0/16/24/32/40/48/56/64)              ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                      [Data Length (16)]                       |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Stream Data (*)                      ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 {: #stream-format title="STREAM Frame Format"}
 
 The STREAM frame contains the following fields:
 
+* Data Length: An optional 16-bit unsigned number specifying the length of the
+  Stream Data field in this STREAM frame.  This field is present when the `D`
+  bit is set to 1.
+
 * Stream ID: A variable-sized unsigned ID unique to this stream.
 
 * Offset: A variable-sized unsigned number specifying the byte offset in the
   stream for the data in this STREAM frame.  The first byte in the stream has an
   offset of 0.
 
-* Data Length: An optional 16-bit unsigned number specifying the length of the
-  Stream Data field in this STREAM frame.
-
 * Stream Data: The bytes from the designated stream to be delivered.
 
 A STREAM frame MUST have either non-zero data length or the FIN bit set.
@@ -1007,36 +1019,36 @@ An ACK frame is shown below.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                  Largest Acked (8/16/32/48)                 ...
+|[Num Blocks(8)]|   NumTS (8)   |  Largest Acked (8/16/32/48) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Ack Delay (16)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|[Num Blocks(8)]|             Ack Block Section (*)           ...
+|                     Ack Block Section (*)                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|   NumTS (8)   |             Timestamp Section (*)           ...
+|                     Timestamp Section (*)                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 {: #ack-format title="ACK Frame Format"}
 
 The fields in the ACK frame are as follows:
 
+* Num Blocks (opt): An optional 8-bit unsigned value specifying the number of
+  additional ack blocks (besides the required First Ack Block) in this ACK
+  frame.  Only present if the 'N' flag bit is 1.
+
+* Num Timestamps: An unsigned 8-bit number specifying the total number of
+  <packet number, timestamp> pairs in the Timestamp Section.
+
 * Largest Acked: A variable-sized unsigned value representing the largest packet
   number the peer is acking in this packet (typically the largest that the peer
   has seen thus far.)
 
 * Ack Delay: Time from when the largest acked packet, as indicated in the
   Largest Acked field, was received by this peer to when this ack was sent.
 
-* Num Blocks (opt): An optional 8-bit unsigned value specifying the number of
-  additional ack blocks (besides the required First Ack Block) in this ACK
-  frame.  Only present if the 'N' flag bit is 1.
-
 * Ack Block Section: Contains one or more blocks of packet numbers which have
   been successfully received.  See {{ack-block-section}}.
 
-* Num Timestamps: An unsigned 8-bit number specifying the total number of
-  <packet number, timestamp> pairs in the Timestamp Section.
-
 * Timestamp Section: Contains zero or more timestamps reporting transit delay of
   received packets.  See {{timestamp-section}}.
 
@@ -1387,9 +1399,7 @@ bundle any set of frames in a packet.  All QUIC packets MUST contain a packet
 number and MAY contain one or more frames ({{frames}}).  Packet numbers MUST be
 unique within a connection and MUST NOT be reused within the same connection.
 Packet numbers MUST be assigned to packets in a strictly monotonically
-increasing order.  The initial packet number used, at both the client and the
-server, MUST be 0.  That is, the first packet in both directions of the
-connection MUST have a packet number of 0.
+increasing order.
 
 A sender SHOULD minimize per-packet bandwidth and computational costs by
 bundling as many frames as possible within a QUIC packet.  A sender MAY wait for
@@ -1532,8 +1542,8 @@ shown in the following figure and described below.
 
        app: application API signals to QUIC
        reserve_stream: causes a StreamID to be reserved for later use
-       read_close: causes stream to be half-closed without receiving a FIN
-       write_close: causes stream to be half-closed without sending a FIN
+       read_close: causes stream to be half-closed without a FIN
+       write_close: causes stream to be half-closed without a FIN
 ~~~
 {: #stream-lifecycle title="Lifecycle of a stream"}
 
@@ -1708,6 +1718,15 @@ receives a STREAM frame that causes its advertised concurrent stream limit to be
 exceeded MUST treat this as a stream error of type QUIC_TOO_MANY_OPEN_STREAMS
 ({{error-handling}}).
 
+All streams, including stream 1, count toward this limit.  Thus, a concurrent
+stream limit of 0 will cause a connection to be unusable.  Application protocols
+that use QUIC might require a certain minimum number of streams to function
+correctly.  If a peer advertises an MSPC value that is too small for the
+selected application protocol to function, an endpoint MUST terminate the
+connection with an error of type QUIC_TOO_MANY_OPEN_STREAMS
+({{error-handling}}).
+
+
 ## Sending and Receiving Data
 
 Once a stream is created, endpoints may use the stream to send and receive data.