Merge branch 'master' into ianswett-app-limited

.github/release-drafter.yml

@@ -0,0 +1,14 @@
+categories:
+  - title: Transport
+    label: -transport
+  - title: Recovery
+    label: -recovery
+  - title: TLS
+    label: -tls
+  - title: HTTP/3
+    label: -http
+change-template: - $TITLE (#$NUMBER)
+template: |
+  ## What’s Changed
+
+  $CHANGES

draft-ietf-quic-http.md

@@ -334,6 +334,10 @@ them.  However, stream types which could modify the state or semantics of
 existing protocol components, including QPACK or other extensions, MUST NOT be
 sent until the peer is known to support them.
 
+A sender can close or reset a unidirectional stream unless otherwise specified.
+A receiver MUST tolerate unidirectional streams being closed or reset prior to
+the reception of the unidirectional stream header.
+
 ###  Control Streams
 
 A control stream is indicated by a stream type of `0x43` (ASCII 'C').  Data on
@@ -345,8 +349,9 @@ the first frame of the control stream is any other frame type, this MUST be
 treated as a connection error of type HTTP_MISSING_SETTINGS. Only one control
 stream per peer is permitted; receipt of a second stream which claims to be a
 control stream MUST be treated as a connection error of type
-HTTP_WRONG_STREAM_COUNT.  If the control stream is closed at any point, this
-MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.
+HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control stream.  If the
+control stream is closed at any point, this MUST be treated as a connection
+error of type HTTP_CLOSED_CRITICAL_STREAM.
 
 A pair of unidirectional streams is used rather than a single bidirectional
 stream.  This allows either peer to send data as soon they are able.  Depending
@@ -717,7 +722,7 @@ with its 0-RTT data.
 ### PUSH_PROMISE {#frame-push-promise}
 
 The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header
-set from server to client, as in HTTP/2.
+set from server to client on a request stream, as in HTTP/2.
 
 ~~~~~~~~~~  drawing
  0                   1                   2                   3
@@ -748,6 +753,9 @@ multiple PUSH_PROMISE frames.  A client MUST treat receipt of a PUSH_PROMISE
 that contains a larger Push ID than the client has advertised or a Push ID which
 has already been promised as a connection error of type HTTP_MALFORMED_FRAME.
 
+If a PUSH_PROMISE frame is received on either control stream, the recipient MUST
+respond with a connection error ({{errors}}) of type HTTP_WRONG_STREAM.
+
 See {{server-push}} for a description of the overall server push mechanism.
 
 ### GOAWAY {#frame-goaway}
@@ -770,7 +778,7 @@ close a connection.
 The GOAWAY frame is always sent on the control stream. It carries a QUIC Stream
 ID for a client-initiated bidirectional stream encoded as a variable-length
 integer.  A client MUST treat receipt of a GOAWAY frame containing a Stream ID
-of any other type as a connection error of type HTTP_MALFORMED_FRAME.
+of any other type as a connection error of type HTTP_WRONG_STREAM.
 
 Clients do not need to send GOAWAY to initiate a graceful shutdown; they simply
 stop making new requests.  A server MUST treat receipt of a GOAWAY frame on any
@@ -965,22 +973,26 @@ header list is calculated based on the uncompressed size of header fields,
 including the length of the name and value in bytes plus an overhead of 32 bytes
 for each header field.
 
-### Request Cancellation
+### Request Cancellation and Rejection {#request-cancellation}
 
-Either client or server can cancel requests by aborting the stream (QUIC
-RESET_STREAM and/or STOP_SENDING frames, as appropriate) with an error code of
+Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or
+STOP_SENDING frames, as appropriate) with an error code of
 HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client cancels a
 response, it indicates that this response is no longer of interest.
 Implementations SHOULD cancel requests by aborting both directions of a stream.
 
-When the server aborts its response stream using HTTP_REQUEST_CANCELLED, it
-indicates that no application processing was performed.  In this context,
-"processed" means that some data from the stream was passed to some higher layer
-of software that might have taken some action as a result.  The client can treat
-requests cancelled by the server as though they had never been sent at all,
-thereby allowing them to be retried later on a new connection.  Servers MUST NOT
-use the HTTP_REQUEST_CANCELLED status for requests which were partially or fully
-processed.
+When the server rejects a request without performing any application processing,
+it SHOULD abort its response stream with the error code HTTP_REQUEST_REJECTED.
+In this context, "processed" means that some data from the stream was passed to
+some higher layer of software that might have taken some action as a result. The
+client can treat requests rejected by the server as though they had never been
+sent at all, thereby allowing them to be retried later on a new connection.
+Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for requests which
+were partially or fully processed.  When a client sends a STOP_SENDING with
+HTTP_REQUEST_CANCELLED, a server MAY indicate the error code
+HTTP_REQUEST_REJECTED in the corresponding RESET_STREAM if no processing was
+performed.  Clients MUST NOT reset streams with the HTTP_REQUEST_REJECTED error
+code except in response to a QUIC STOP_SENDING frame.
 
 If a stream is cancelled after receiving a complete response, the client MAY
 ignore the cancellation and use the response.  However, if a stream is cancelled
@@ -1210,31 +1222,32 @@ function by communicating with clients.
 Servers initiate the shutdown of a connection by sending a GOAWAY frame
 ({{frame-goaway}}).  The GOAWAY frame indicates that client-initiated requests
 on lower stream IDs were or might be processed in this connection, while
-requests on the indicated stream ID and greater were not accepted. This enables
+requests on the indicated stream ID and greater were rejected. This enables
 client and server to agree on which requests were accepted prior to the
 connection shutdown.  This identifier MAY be lower than the stream limit
 identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were
 processed.  Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after
 sending a GOAWAY frame.
 
-Once GOAWAY is sent, the server MUST cancel requests sent on streams with an
-identifier higher than the indicated last Stream ID.  Clients MUST NOT send new
-requests on the connection after receiving GOAWAY, although requests might
-already be in transit. A new connection can be established for new requests.
+Once GOAWAY is sent, the server MUST reject requests sent on streams with an
+identifier greater than or equal to the indicated last Stream ID.  Clients MUST
+NOT send new requests on the connection after receiving GOAWAY, although
+requests might already be in transit. A new connection can be established for
+new requests.
 
-If the client has sent requests on streams with a higher Stream ID than
-indicated in the GOAWAY frame, those requests are considered cancelled
-({{request-cancellation}}).  Clients SHOULD reset any streams above this ID with
-the error code HTTP_REQUEST_CANCELLED.  Servers MAY also cancel requests on
-streams below the indicated ID if these requests were not processed.
+If the client has sent requests on streams with a Stream ID greater than or
+equal to that indicated in the GOAWAY frame, those requests are considered
+rejected ({{request-cancellation}}).  Clients SHOULD cancel any requests on
+streams above this ID.  Servers MAY also reject requests on streams below the
+indicated ID if these requests were not processed.
 
 Requests on Stream IDs less than the Stream ID in the GOAWAY frame might have
 been processed; their status cannot be known until they are completed
 successfully, reset individually, or the connection terminates.
 
 Servers SHOULD send a GOAWAY frame when the closing of a connection is known
 in advance, even if the advance notice is small, so that the remote peer can
-know whether a stream has been partially processed or not.  For example, if an
+know whether a request has been partially processed or not.  For example, if an
 HTTP client sends a POST at the same time that a server closes a QUIC
 connection, the client cannot know if the server started to process that POST
 request if the server does not send a GOAWAY frame to indicate what streams it
@@ -1404,6 +1417,9 @@ HTTP_MISSING_SETTINGS (0x0012):
 HTTP_UNEXPECTED_FRAME (0x0013):
 : A frame was received which was not permitted in the current state.
 
+HTTP_REQUEST_REJECTED (0x0014):
+: A server rejected a request without performing any application processing.
+
 HTTP_GENERAL_PROTOCOL_ERROR (0x00FF):
 : Peer violated protocol requirements in a way which doesn't match a more
   specific error code, or endpoint declines to use the more specific error code.
@@ -1618,6 +1634,7 @@ The entries in the following table are registered by this document.
 | HTTP_EARLY_RESPONSE                 | 0x0011     | Remainder of request not needed          | {{http-error-codes}}   |
 | HTTP_MISSING_SETTINGS               | 0x0012     | No SETTINGS frame received               | {{http-error-codes}}   |
 | HTTP_UNEXPECTED_FRAME               | 0x0013     | Frame not permitted in the current state | {{http-error-codes}}   |
+| HTTP_REQUEST_REJECTED               | 0x0014     | Request not processed                    | {{http-error-codes}}   |
 | HTTP_MALFORMED_FRAME                | 0x01XX     | Error in frame formatting                | {{http-error-codes}}   |
 | ----------------------------------- | ---------- | ---------------------------------------- | ---------------------- |
 
@@ -1872,8 +1889,10 @@ FRAME_SIZE_ERROR (0x6):
 : HTTP_MALFORMED_FRAME error codes defined in {{http-error-codes}}.
 
 REFUSED_STREAM (0x7):
-: Not applicable, since QUIC handles stream management.  Would provoke a
-  STREAM_ID_ERROR from the QUIC layer.
+: HTTP_REQUEST_REJECTED (in {{http-error-codes}}) is used to indicate that a
+  request was not processed. Otherwise, not applicable because QUIC handles
+  stream management.  A STREAM_ID_ERROR at the QUIC layer is used for streams
+  that are improperly opened.
 
 CANCEL (0x8):
 : HTTP_REQUEST_CANCELLED in {{http-error-codes}}.
@@ -1902,6 +1921,13 @@ Error codes need to be defined for HTTP/2 and HTTP/3 separately.  See
 > **RFC Editor's Note:**  Please remove this section prior to publication of a
 > final version of this document.
 
+## Since draft-ietf-quic-http-17
+
+- HTTP_REQUEST_REJECTED is used to indicate a request can be retried (#2106,
+  #2325)
+- Changed error code for GOAWAY on the wrong stream (#2231, #2343)
+
+
 ## Since draft-ietf-quic-http-16
 
 - Rename "HTTP/QUIC" to "HTTP/3" (#1973)

draft-ietf-quic-invariants.md

@@ -16,7 +16,7 @@ author:
     ins: M. Thomson
     name: Martin Thomson
     org: Mozilla
-    email: martin.thomson@gmail.com
+    email: mt@lowentropy.net
 
 normative:
 

draft-ietf-quic-qpack.md

@@ -588,9 +588,9 @@ instruction space:
 <!-- s/exactly/no more than/  ? -->
 There MUST be exactly one of each unidirectional stream type in each direction.
 Receipt of a second instance of either stream type MUST be treated as a
-connection error of HTTP_WRONG_STREAM_COUNT.  Closure of either unidirectional
-stream MUST be treated as a connection error of type
-HTTP_CLOSED_CRITICAL_STREAM.
+connection error of HTTP_WRONG_STREAM_COUNT.  These streams MUST NOT be closed.
+Closure of either unidirectional stream MUST be treated as a connection error of
+type HTTP_CLOSED_CRITICAL_STREAM.
 
 This section describes the instructions which are possible on each stream type.
 

draft-ietf-quic-recovery.md

@@ -44,6 +44,23 @@ normative:
         org: Mozilla
         role: editor
 
+  QUIC-TLS:
+    title: "Using TLS to Secure QUIC"
+    date: {DATE}
+    seriesinfo:
+      Internet-Draft: draft-ietf-quic-tls-latest
+    author:
+      -
+        ins: M. Thomson
+        name: Martin Thomson
+        org: Mozilla
+        role: editor
+      -
+        ins: S. Turner
+        name: Sean Turner
+        org: sn3rd
+        role: editor
+
 informative:
 
   FACK:
@@ -289,8 +306,15 @@ be subtracted from the RTT as long as the result is larger than the min_rtt.
 If the result is smaller than the min_rtt, the RTT should be used, but the
 ack delay field should be ignored.
 
-Like TCP, QUIC calculates both smoothed RTT and RTT variance similar to those
-specified in {{?RFC6298}}.
+A sender calculates both smoothed RTT and RTT variance similar to those
+specified in {{?RFC6298}}, see {{on-ack-received}}.
+
+A sender takes an RTT sample when an ACK frame is received that acknowledges a
+larger packet number than before (see {{on-ack-received}}).  A sender will take
+multiple RTT samples per RTT when multiple such ACK frames are received within
+an RTT.  When multiple samples are generated within an RTT, the smoothed RTT and
+RTT variance could retain inadequate history, as suggested in {{?RFC6298}}.
+Changing these computations is currently an open research question.
 
 min_rtt is the minimum RTT measured over the connection, prior to adjusting by
 ack delay.  Ignoring ack delay for min RTT prevents intentional or unintentional
@@ -427,14 +451,30 @@ packet is received.  The client MAY use this value to seed the RTT estimator for
 a subsequent connection attempt to the server.
 
 
-#### Discarding Initial State {#discard-initial}
+#### Discarding Keys and Packet State {#discarding-packets}
+
+When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}), all
+packets that were sent with those keys can no longer be acknowledged because
+their acknowledgements cannot be processed anymore. The sender considers them no
+longer in flight. That is, the sender SHOULD discard all recovery state
+associated with those packets and MUST remove them from the count of bytes in
+flight.
+
+Endpoints stop sending and receiving Initial packets once they start exchanging
+Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). At this point,
+recovery state for all in-flight Initial packets is discarded.
+
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
 
-As described in Section 17.5.1 of {{QUIC-TRANSPORT}}, endpoints stop sending and
-receiving Initial packets once they start exchanging Handshake packets.  At this
-point, all loss recovery state for the Initial packet number space is also
-discarded. Packets that are in flight for the packet number space are not
-declared as either acknowledged or lost.  After discarding state, new Initial
-packets will not be sent.
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+It is expected that keys are discarded after packets encrypted with them would
+be acknowledged or declared lost.  Initial secrets however might be destroyed
+sooner, as soon as handshake keys are available (see Section 4.10 of
+{{QUIC-TLS}}).
 
 
 ### Probe Timeout {#pto}
@@ -688,7 +728,7 @@ Pseudocode for OnPacketSent follows:
      SetLossDetectionTimer()
 ~~~
 
-### On Receiving an Acknowledgment
+### On Receiving an Acknowledgment {#on-ack-received}
 
 When an ACK frame is received, it may newly acknowledge any number of packets.
 
@@ -944,6 +984,15 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Ignoring Loss of Undecryptable Packets
+
+During the handshake, some packet protection keys might not be
+available when a packet arrives. In particular, Handshake and 0-RTT packets
+cannot be processed until the Initial packets arrive, and 1-RTT packets
+cannot be processed until the handshake completes.  Endpoints MAY
+ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before
+the peer has packet protection keys to process those packets.
+
 ## Probe Timeout
 
 Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST
@@ -1009,23 +1058,6 @@ acknowledgements, due to pacing.  In this case, the sender should not consider
 themselves application limited and should allow the congestion window to
 increase.
 
-## Discarding Packet Number Space State
-
-When keys for a packet number space are discarded, any in-flight packets
-sent with those keys are removed from the count of bytes in flight.  Loss
-recovery state is also discarded, so no loss events will occur for any
-in-flight packets from that space (see {{discard-initial}}).  Note that it is
-expected that keys are discarded after those packets would be declared lost,
-but Initial secrets are destroyed earlier.
-
-When 0-RTT is rejected, all in-flight 0-RTT packets are removed from
-the count of bytes in flight.  Loss recovery state is also discarded, so no
-loss events will occur for any in-flight 0-RTT packets.
-
-If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
-before Initial packets, early 0-RTT packets will be declared lost, but that
-is expected to be infrequent.
-
 ## Pseudocode
 
 ### Constants of interest {#cc-consts-of-interest}
@@ -1248,6 +1280,23 @@ This document has no IANA actions.  Yet.
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-recovery-17
+
+- After Probe Timeout discard in-flight packets or send another (#2212, #1965)
+- Endpoints discard initial keys as soon as handshake keys are available (#1951,
+  #2045)
+- 0-RTT state is discarded when 0-RTT is rejected (#2300)
+- Loss detection timer is cancelled when ack-eliciting frames are in flight
+  (#2117, #2093)
+- Packets are declared lost if they are in flight (#2104)
+- After becoming idle, either pace packets or reset the congestion controller
+  (#2138, 2187)
+- Process ECN counts before marking packets lost (#2142)
+- Mark packets lost before resetting crypto_count and pto_count (#2208, #2209)
+- Congestion and loss recovery state are discarded when keys are discarded
+  (#2237)
+
+
 ## Since draft-ietf-quic-recovery-16
 
 - Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP and min crypto

draft-ietf-quic-tls.md

@@ -16,7 +16,7 @@ author:
     ins: M. Thomson
     name: Martin Thomson
     org: Mozilla
-    email: martin.thomson@gmail.com
+    email: mt@lowentropy.net
     role: editor
   -
     ins: S. Turner
@@ -1601,6 +1601,13 @@ cb54df7884
 Issue and pull request numbers are listed with a leading octothorp.
 
 
+## Since draft-ietf-quic-tls-17
+
+- Endpoints discard initial keys as soon as handshake keys are available (#1951,
+  #2045)
+- Use of ALPN or equivalent is mandatory (#2263, #2284)
+
+
 ## Since draft-ietf-quic-tls-14
 
 - Update the salt used for Initial secrets (#1970)