Merge branch 'master' into ianswett-gorry

draft-ietf-quic-http.md

@@ -2493,6 +2493,13 @@ what might be a temporary or intermittent error.
 > **RFC Editor's Note:**  Please remove this section prior to publication of a
 > final version of this document.
 
+## Since draft-ietf-quic-http-29
+
+- Require a connection error if a reserved frame type that corresponds to a
+  frame in HTTP/2 is received (#3991, #3993)
+- Require a connection error if a reserved setting that corresponds to a
+  setting in HTTP/2 is received (#3954, #3955)
+
 ## Since draft-ietf-quic-http-28
 
 - CANCEL_PUSH is recommended even when the stream is reset (#3698, #3700)

draft-ietf-quic-qpack.md

@@ -1619,6 +1619,10 @@ return encoderBuffer, prefixBuffer + streamBuffer
 > **RFC Editor's Note:** Please remove this section prior to publication of a
 > final version of this document.
 
+## Since draft-ietf-quic-qpack-16
+
+Editorial changes only
+
 ## Since draft-ietf-quic-qpack-15
 
 No changes

draft-ietf-quic-recovery.md

@@ -481,10 +481,10 @@ implementations SHOULD NOT use a packet threshold less than 3; see {{?RFC5681}}.
 Some networks may exhibit higher degrees of packet reordering, causing a sender
 to detect spurious losses. Additionally, packet reordering could be more common
 with QUIC than TCP, because network elements that could observe and reorder
-TCP packets cannot do that for QUIC, because packet numbers
-are encrypted. Algorithms that increase the reordering threshold after
-spuriously detecting losses, such as RACK {{?RACK}}, have proven to be useful
-in TCP and are expected to be at least as useful in QUIC.
+TCP packets cannot do that for QUIC, because QUIC packet numbers are encrypted.
+Algorithms that increase the reordering threshold after spuriously detecting
+losses, such as RACK {{?RACK}}, have proven to be useful in TCP and are
+expected to be at least as useful in QUIC.
 
 ### Time Threshold {#time-threshold}
 
@@ -1795,6 +1795,20 @@ OnPacketNumberSpaceDiscarded(pn_space):
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-recovery-29
+
+- Allow caching of packets that can't be decrypted, by allowing the reported
+  acknowledgment delay to exceed max_ack_delay prior to confirming the
+  handshake (#3821, #3980, #4035, #3874)
+- Persistent congestion cannot include packets sent before the first RTT
+  sample for the path (#3875, #3889)
+- Recommend reset of min_rtt in persistent congestion (#3927, #3975)
+- Persistent congestion is independent of packet number space (#3939, #3961)
+- Only limit bursts to the initial window without information about the path
+  (#3892, #3936)
+- Add normative requirements for increasing and reducing the congestion
+  window (#3944, #3978, #3997, #3998)
+
 ## Since draft-ietf-quic-recovery-28
 
 - Refactored pseudocode to correct PTO calculation (#3564, #3674, #3681)

draft-ietf-quic-tls.md

@@ -1506,10 +1506,11 @@ The endpoint that initiates a key update also updates the keys that it uses for
 receiving packets.  These keys will be needed to process packets the peer sends
 after updating.
 
-An endpoint SHOULD retain old keys so that packets sent by its peer prior to
-receiving the key update can be processed.  Discarding old keys too early can
-cause delayed packets to be discarded.  Discarding packets will be interpreted
-as packet loss by the peer and could adversely affect performance.
+An endpoint MUST retain old keys until it has successfully unprotected a packet
+sent using the new keys.  An endpoint SHOULD retain old keys for some time
+after unprotecting a packet sent using the new keys.  Discarding old keys too
+early can cause delayed packets to be discarded.  Discarding packets will be
+interpreted as packet loss by the peer and could adversely affect performance.
 
 
 ## Responding to a Key Update
@@ -1613,12 +1614,13 @@ in the network.  In this case, the Key Phase bit alone can be used to select
 keys.
 
 An endpoint MAY allow a period of approximately the Probe Timeout (PTO; see
-{{QUIC-RECOVERY}}) after a key update before it creates the next set of packet
-protection keys.  These updated keys MAY replace the previous keys at that time.
-With the caveat that PTO is a subjective measure - that is, a peer could have a
-different view of the RTT - this time is expected to be long enough that any
-reordered packets would be declared lost by a peer even if they were
-acknowledged and short enough to allow for subsequent key updates.
+{{QUIC-RECOVERY}}) after receiving a packet that uses the new key generation
+before it creates the next set of packet protection keys.  These updated keys
+MAY replace the previous keys at that time.  With the caveat that PTO is a
+subjective measure - that is, a peer could have a different view of the RTT -
+this time is expected to be long enough that any reordered packets would be
+declared lost by a peer even if they were acknowledged and short enough to
+allow for subsequent key updates.
 
 Endpoints need to allow for the possibility that a peer might not be able to
 decrypt packets that initiate a key update during the period when it retains old
@@ -1627,9 +1629,9 @@ after receiving an acknowledgment that confirms that the previous key update was
 received.  Failing to allow sufficient time could lead to packets being
 discarded.
 
-An endpoint SHOULD retain old read keys for no more than three times the PTO.
-After this period, old read keys and their corresponding secrets SHOULD be
-discarded.
+An endpoint SHOULD retain old read keys for no more than three times the PTO
+after having received a packet protected using the new keys. After this period,
+old read keys and their corresponding secrets SHOULD be discarded.
 
 
 ## Limits on AEAD Usage {#aead-limits}
@@ -2467,6 +2469,12 @@ larger advantage in forging packets than the target of 2^-57.
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-tls-29
+
+- Updated limits on packet protection (#3788, #3789)
+- Allow for packet processing to continue while waiting for TLS to provide
+  keys (#3821, #3874)
+
 ## Since draft-ietf-quic-tls-28
 
 - Defined limits on the number of packets that can be protected with a single

draft-ietf-quic-transport.md

@@ -2221,6 +2221,10 @@ defined in {{QUIC-RECOVERY}} is RECOMMENDED.  That is:
    validation_timeout = max(3*PTO, 6*kInitialRtt)
 ~~~
 
+This timeout allows for multiple PTOs to expire prior to failing path
+validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE frame
+does not cause path validation failure.
+
 Note that the endpoint might receive packets containing other frames on the new
 path, but a PATH_RESPONSE frame with appropriate data is required for path
 validation to succeed.
@@ -2703,6 +2707,8 @@ ensures that connections are not closed after new activity is initiated.
 
 To avoid excessively small idle timeout periods, endpoints MUST increase the
 idle timeout period to be at least three times the current Probe Timeout (PTO).
+This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle
+timeout does not expire as a result of a single packet loss.
 
 
 ### Liveness Testing
@@ -7414,6 +7420,27 @@ incurred.
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-transport-29
+
+- Require the same connection ID on coalesced packets (#3800, #3930)
+- Allow caching of packets that can't be decrypted, by allowing the reported
+  acknowledgment delay to exceed max_ack_delay prior to confirming the
+  handshake (#3821, #3980, #4035, #3874)
+- Allow connection ID to be used for address validation (#3834, #3924)
+- Required protocol operations are no longer directed at implementations, but
+  are features provided to application protocols (#3838, #3935)
+- Narrow requirements for reset of congestion state on path change (#3842,
+  #3945)
+- Add a three times amplification limit for sending of CONNECTION_CLOSE with
+  reduced state (#3845, #3864)
+- Change error code for invalid RETIRE_CONNECTION_ID frames (#3860, #3861)
+- Recommend retention of state for lost packets to allow for late arrival and
+  avoid unnecessary retransmission (#3956, #3957)
+- Allow a server to reject connections if a client reuses packet numbers after
+  Retry (#3989, #3990)
+- Limit recommendation for immediate acknowledgment to when ack-eliciting
+  packets are reordered (#4001, #4000)
+
 ## Since draft-ietf-quic-transport-28
 
 - Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED (#3709,