Merge branch 'master' into connection_id

draft-ietf-quic-invariants.md

@@ -189,7 +189,7 @@ version-specific semantics are marked with an X.
 +-+-+-+-+-+-+-+-+
 |0|X X X X X X X|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                Destination Connection ID (0..144)           ...
+|                 Destination Connection ID (*)               ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X  ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -198,17 +198,16 @@ version-specific semantics are marked with an X.
 
 A QUIC packet with a short header has the high bit of the first octet set to 0.
 
-A QUIC packet with a short header includes an optional Destination Connection
-ID.  The short header does not include the Connection ID Lengths, Source
-Connection ID, or Version fields.
+A QUIC packet with a short header includes a Destination Connection ID.  The
+short header does not include the Connection ID Lengths, Source Connection ID,
+or Version fields.
 
 The remainder of the packet has version-specific semantics.
 
 
 ## Connection ID
 
-A connection ID is an opaque field.  A connection ID can be 0 octets in length,
-or between 4 and 18 octets (inclusive).
+A connection ID is an opaque field of arbitrary length.
 
 The primary function of a connection ID is to ensure that changes in addressing
 at lower protocol layers (UDP, IP, and below) don't cause packets for a QUIC

draft-ietf-quic-qpack.md

@@ -318,7 +318,7 @@ decoder that permit the encoder to track the decoder's state.  These events are:
 
 Regardless of whether a header block contained blocking references, the
 knowledge that it has been processed permits the encoder to evict
-entries to which no unacknowledged references remain; see {{blocked-eviction}}.
+entries to which no unacknowledged references remain; see {{blocked-insertion}}.
 When a stream is reset or abandoned, the indication that these header blocks
 will never be processed serves a similar function; see {{stream-cancellation}}.
 
@@ -428,7 +428,8 @@ only carry header blocks that do not modify the state of the table.
 ### Prefixed Integers
 
 The prefixed integer from Section 5.1 of [RFC7541] is used heavily throughout
-this document.  The format from [RFC7541] is used unmodified.
+this document.  The format from [RFC7541] is used unmodified.  QPACK
+implementations MUST be able to decode integers up to 62 bits long.
 
 ### String Literals
 
@@ -903,23 +904,41 @@ In order to enable this, the encoder will need to track outstanding
 (unacknowledged) header blocks and table updates using feedback received from
 the decoder.
 
-### Blocked Eviction
-
-The encoder MUST NOT permit an entry to be evicted while a reference to that
-entry remains unacknowledged.  If a new header to be inserted into the dynamic
-table would cause the eviction of such an entry, the encoder MUST NOT emit the
-insert instruction until the reference has been processed by the decoder and
-acknowledged.
-
-The encoder can emit a literal representation for the new header in order to
-avoid encoding delays, and MAY insert the header into the table later if
-desired.
-
-To ensure that the blocked eviction case is rare, references to the oldest
-entries in the dynamic table SHOULD be avoided.  When one of the oldest entries
-in the table is still actively used for references, the encoder SHOULD emit an
-Duplicate representation instead (see {{duplicate}}).
+### Blocked Dynamic Table Insertions {#blocked-insertion}
+
+An encoder MUST NOT insert an entry into the dynamic table (or duplicate an
+existing entry) if doing so would evict an entry with unacknowledged references.
+For header blocks that might rely on the newly added entry, the encoder can use
+a literal representation and maybe insert the entry later.
+
+To ensure that the encoder is not prevented from adding new entries, the encoder
+can avoid referencing entries that will be evicted soonest.  Rather than
+reference such an entry, the encoder SHOULD emit a Duplicate instruction (see
+{{duplicate}}), and reference the duplicate instead.
+
+Determining which entries are too close to eviction to reference is an encoder
+preference.  One heuristic is to target a fixed amount of available space in the
+dynamic table: either unused space or space that can be reclaimed by evicting
+unreferenced entries.  To achieve this, the encoder can maintain a draining
+index, which is the smallest absolute index in the dynamic table that it will
+emit a reference for.  As new entries are inserted, the encoder increases the
+draining index to maintain the section of the table that it will not
+reference.  Draining entries - entries with an absolute index lower than the
+draining index - will not accumulate new references.  The number of
+unacknowledged references to draining entries will eventually become zero,
+making the entry available for eviction.
 
+~~~~~~~~~~  drawing
+   +----------+---------------------------------+--------+
+   | Draining |          Referenceable          | Unused |
+   | Entries  |             Entries             | Space  |
+   +----------+---------------------------------+--------+
+   ^          ^                                 ^
+   |          |                                 |
+ Dropping    Draining Index               Base Index /
+  Point                                   Insertion Point
+~~~~~~~~~~
+{:#fig-draining-index title="Draining Dynamic Table Entries"}
 
 ### Blocked Decoding
 

draft-ietf-quic-recovery.md

@@ -88,14 +88,9 @@ when, and only when, they appear in all capitals, as shown here.
 
 Definitions of terms that are used in this document:
 
-ACK frames:
-
-: ACK frames refer to both ACK and ACK_ECN frames in this
-  document.
-
 ACK-only:
 
-: Any packet containing only an ACK or ACK_ECN frame.
+: Any packet containing only an ACK frame.
 
 In-flight:
 
@@ -105,7 +100,7 @@ In-flight:
 
 Retransmittable Frames:
 
-: All frames besides ACK, ACK_ECN, or PADDING are considered
+: All frames besides ACK or PADDING are considered
   retransmittable.
 
 Retransmittable Packets:
@@ -132,14 +127,14 @@ mechanisms ensure that data and frames that need reliable delivery are
 acknowledged or declared lost and sent in new packets as necessary. The types
 of frames contained in a packet affect recovery and congestion control logic:
 
-* All packets are acknowledged, though packets that contain only ACK,
-  ACK_ECN, and PADDING frames are not acknowledged immediately.
+* All packets are acknowledged, though packets that contain only ACK
+  and PADDING frames are not acknowledged immediately.
 
 * Long header packets that contain CRYPTO frames are critical to the
   performance of the QUIC handshake and use shorter timers for
   acknowledgement and retransmission.
 
-* Packets that contain only ACK and ACK_ECN frames do not count toward
+* Packets that contain only ACK frames do not count toward
   congestion control limits and are not considered in-flight. Note that this
   means PADDING frames cause packets to contribute toward bytes in flight
   without directly causing an acknowledgment to be sent.
@@ -598,9 +593,10 @@ min_rtt:
 : The minimum RTT seen in the connection, ignoring ack delay.
 
 max_ack_delay:
-: The maximum ack delay in an incoming ACK frame for this connection.
-  Excludes ack delays for non-retransmittable packets and those
-  that create an RTT sample less than min_rtt.
+: The maximum amount of time by which the receiver intends to delay
+  acknowledgments, in milliseconds.  The actual ack_delay in a
+  received ACK frame may be larger due to late timers, reordering,
+  or lost ACKs.
 
 reordering_threshold:
 : The largest packet number gap between the largest acknowledged
@@ -645,7 +641,6 @@ follows:
    smoothed_rtt = 0
    rttvar = 0
    min_rtt = infinite
-   max_ack_delay = 0
    largest_sent_before_rto = 0
    time_of_last_sent_retransmittable_packet = 0
    time_of_last_sent_handshake_packet = 0
@@ -726,10 +721,6 @@ Pseudocode for OnAckReceived and UpdateRtt follow:
     // Adjust for ack delay if it's plausible.
     if (latest_rtt - min_rtt > ack_delay):
       latest_rtt -= ack_delay
-      // Only save into max ack delay if it's used
-      // for rtt calculation and is not ack-only.
-      if (!sent_packets[ack.largest_acked].ack_only)
-        max_ack_delay = max(max_ack_delay, ack_delay)
     // Based on {{?RFC6298}}.
     if (smoothed_rtt == 0):
       smoothed_rtt = latest_rtt
@@ -1064,7 +1055,7 @@ Variables required to implement the congestion control mechanisms
 are described in this section.
 
 ecn_ce_counter:
-: The highest value reported for the ECN-CE counter by the peer in an ACK_ECN
+: The highest value reported for the ECN-CE counter by the peer in an ACK
   frame. This variable is used to detect increases in the reported ECN-CE
   counter.
 
@@ -1153,7 +1144,7 @@ detected. Starts a new recovery period and reduces the congestion window.
 
 ### Process ECN Information
 
-Invoked when an ACK_ECN frame is received from the peer.
+Invoked when an ACK frame with an ECN section is received from the peer.
 
 ~~~
    ProcessECN(ack):

draft-ietf-quic-tls.md

@@ -324,8 +324,8 @@ encryption levels
 
 - CRYPTO frames MAY appear in packets of any encryption level.
 
-- CONNECTION_CLOSE MAY appear in packets of any encryption level other than
-  0-RTT.
+- CONNECTION_CLOSE and APPLICATION_CLOSE MAY appear in packets of any encryption
+  level other than 0-RTT.
 
 - PADDING and PING frames MAY appear in packets of any encryption level.
 
@@ -546,7 +546,7 @@ shares, and long lists of supported ciphers, signature algorithms, versions,
 QUIC transport parameters, and other negotiable parameters and extensions could
 cause this message to grow.
 
-For servers, in addition to connection ID and tokens, the size of TLS session
+For servers, in addition to connection IDs and tokens, the size of TLS session
 tickets can have an effect on a client's ability to connect.  Minimizing the
 size of these values increases the probability that they can be successfully
 used by a client.
@@ -967,12 +967,12 @@ anticipation of receiving a ClientHello.
 Once the 1-RTT keys are established and the short header is in use, it is
 possible to update the keys. The KEY_PHASE bit in the short header is used to
 indicate whether key updates have occurred. The KEY_PHASE bit is initially set
-to 0 and then inverted with each key update {{key-update}}.
+to 0 and then inverted with each key update.
 
 The KEY_PHASE bit allows a recipient to detect a change in keying material
 without necessarily needing to receive the first packet that triggered the
 change.  An endpoint that notices a changed KEY_PHASE bit can update keys and
-decrypt the packet that contains the changed bit, see {{key-update}}.
+decrypt the packet that contains the changed bit.
 
 An endpoint MUST NOT initiate more than one key update at a time.  A new key
 cannot be used until the endpoint has received and successfully decrypted a