Re: [quicwg/base-drafts] Closing and draining tidy (#3988)

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.

LGTM, just a large number of small nits.

> -amount of time before responding to a received packet.
-
-An endpoint is allowed to drop the packet protection keys when entering the
-closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
-response to any UDP datagram that is received.  However, an endpoint without the
-packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.
+
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a

```suggestion
close a connection.  This might be after the application protocol negotiates a
```

> -
-An endpoint is allowed to drop the packet protection keys when entering the
-closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
-response to any UDP datagram that is received.  However, an endpoint without the
-packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.
+
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that

```suggestion
graceful shutdown.  The application protocol can exchange messages that
```

> -An endpoint is allowed to drop the packet protection keys when entering the
-closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
-response to any UDP datagram that is received.  However, an endpoint without the
-packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.
+
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which

```suggestion
are needed for both application endpoints to agree that the connection can be closed, after which
```

> -closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
-response to any UDP datagram that is received.  However, an endpoint without the
-packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.
+
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the application requests that the connection be closed.  When the application

```suggestion
the application requests that QUIC close the connection.  When QUIC consequently
```

> -response to any UDP datagram that is received.  However, an endpoint without the
-packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.
+
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the application requests that the connection be closed.  When the application
+closes the connection, a CONNECTION_CLOSE frame with an appropriate error code

```suggestion
closes the connection, a CONNECTION_CLOSE frame with an application-supplied error code
```

> -packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST limit the
-cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
-cumulative size of the packets that cause those packets to be sent.  To minimize
-the state that an endpoint maintains for a closing connection, endpoints MAY
-send the exact same packet.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.
+
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the application requests that the connection be closed.  When the application
+closes the connection, a CONNECTION_CLOSE frame with an appropriate error code
+will be used to signal closure.

```suggestion
will be used to signal closure to the peer.
```

> +
+An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the application requests that the connection be closed.  When the application
+closes the connection, a CONNECTION_CLOSE frame with an appropriate error code
+will be used to signal closure.
+
+The closing and draining connection states exist to ensure that connections
+close cleanly and that delayed or reordered packets are properly discarded.
+These states SHOULD persist for at least three times the current Probe Timeout
+(PTO) interval as defined in {{QUIC-RECOVERY}}.
+
+Disposing of connection state prior to exiting the closing or draining state
+could cause could result in an generating unnecessary stateless reset in

```suggestion
could cause could result in an endpoint generating a stateless reset unnecessarily when
```

> +An immediate close can be used after an application protocol has arranged to
+close a connection.  This might be after the application protocols negotiates a
+graceful shutdown.  The application protocol exchanges whatever messages that
+are needed to cause both endpoints to agree to close the connection, after which
+the application requests that the connection be closed.  When the application
+closes the connection, a CONNECTION_CLOSE frame with an appropriate error code
+will be used to signal closure.
+
+The closing and draining connection states exist to ensure that connections
+close cleanly and that delayed or reordered packets are properly discarded.
+These states SHOULD persist for at least three times the current Probe Timeout
+(PTO) interval as defined in {{QUIC-RECOVERY}}.
+
+Disposing of connection state prior to exiting the closing or draining state
+could cause could result in an generating unnecessary stateless reset in
+response to receiving a packet.  Endpoints that have some alternative means to

```suggestion
it receives a late-arriving packet.  Endpoints that have some alternative means to
```

> +will be used to signal closure.
+
+The closing and draining connection states exist to ensure that connections
+close cleanly and that delayed or reordered packets are properly discarded.
+These states SHOULD persist for at least three times the current Probe Timeout
+(PTO) interval as defined in {{QUIC-RECOVERY}}.
+
+Disposing of connection state prior to exiting the closing or draining state
+could cause could result in an generating unnecessary stateless reset in
+response to receiving a packet.  Endpoints that have some alternative means to
+ensure that late-arriving packets do not induce a response, such as those that
+are able to close the UDP socket, MAY end these states earlier to allow for
+faster resource recovery.  Servers that retain an open socket for accepting new
+connections SHOULD NOT end the closing or draining states early.
+
+Once the closing or draining state ends, an endpoint SHOULD discard all

```suggestion
Once its closing or draining state ends, an endpoint SHOULD discard all
```

> +
+The closing and draining connection states exist to ensure that connections
+close cleanly and that delayed or reordered packets are properly discarded.
+These states SHOULD persist for at least three times the current Probe Timeout
+(PTO) interval as defined in {{QUIC-RECOVERY}}.
+
+Disposing of connection state prior to exiting the closing or draining state
+could cause could result in an generating unnecessary stateless reset in
+response to receiving a packet.  Endpoints that have some alternative means to
+ensure that late-arriving packets do not induce a response, such as those that
+are able to close the UDP socket, MAY end these states earlier to allow for
+faster resource recovery.  Servers that retain an open socket for accepting new
+connections SHOULD NOT end the closing or draining states early.
+
+Once the closing or draining state ends, an endpoint SHOULD discard all
+connection state.  An endpoint MAY send a stateless reset in response

```suggestion
connection state.  The endpoint MAY send a stateless reset in response
```

> +The closing and draining connection states exist to ensure that connections
+close cleanly and that delayed or reordered packets are properly discarded.
+These states SHOULD persist for at least three times the current Probe Timeout
+(PTO) interval as defined in {{QUIC-RECOVERY}}.
+
+Disposing of connection state prior to exiting the closing or draining state
+could cause could result in an generating unnecessary stateless reset in
+response to receiving a packet.  Endpoints that have some alternative means to
+ensure that late-arriving packets do not induce a response, such as those that
+are able to close the UDP socket, MAY end these states earlier to allow for
+faster resource recovery.  Servers that retain an open socket for accepting new
+connections SHOULD NOT end the closing or draining states early.
+
+Once the closing or draining state ends, an endpoint SHOULD discard all
+connection state.  An endpoint MAY send a stateless reset in response
+to any further incoming packets.

```suggestion
to any further incoming packets belonging to this connection.
```

> +### Closing Connection State {#closing}
+
+An endpoint enters the closing state after initiating an immediate close.
+
+In the closing state, an endpoint retains only enough information to generate a
+packet containing a CONNECTION_CLOSE frame and to identify packets as belonging
+to the connection. An endpoint in the closing state sends a packet containing a
+CONNECTION_CLOSE frame in response to any incoming packet that it attributes to
+the connection.
+
+An endpoint SHOULD limit the rate at which it generates packets in the closing
+state. For instance, an endpoint could wait for a progressively increasing
+number of received packets or amount of time before responding to received
+packets.
+
+The endpoint's selected connection ID and the QUIC version are sufficient

```suggestion
An endpoint's selected connection ID and the QUIC version are sufficient
```

> +
+An endpoint enters the closing state after initiating an immediate close.
+
+In the closing state, an endpoint retains only enough information to generate a
+packet containing a CONNECTION_CLOSE frame and to identify packets as belonging
+to the connection. An endpoint in the closing state sends a packet containing a
+CONNECTION_CLOSE frame in response to any incoming packet that it attributes to
+the connection.
+
+An endpoint SHOULD limit the rate at which it generates packets in the closing
+state. For instance, an endpoint could wait for a progressively increasing
+number of received packets or amount of time before responding to received
+packets.
+
+The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint MAY

```suggestion
information to identify packets for a closing connection; the endpoint MAY
```

> +
+In the closing state, an endpoint retains only enough information to generate a
+packet containing a CONNECTION_CLOSE frame and to identify packets as belonging
+to the connection. An endpoint in the closing state sends a packet containing a
+CONNECTION_CLOSE frame in response to any incoming packet that it attributes to
+the connection.
+
+An endpoint SHOULD limit the rate at which it generates packets in the closing
+state. For instance, an endpoint could wait for a progressively increasing
+number of received packets or amount of time before responding to received
+packets.
+
+The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint MAY
+discard all other connection state. An endpoint that is closing is not required
+to process the frames contained in packets. An endpoint MAY retain packet

```suggestion
to process any received frame. An endpoint MAY retain packet
```

All frames are in packets.

> +the connection.
+
+An endpoint SHOULD limit the rate at which it generates packets in the closing
+state. For instance, an endpoint could wait for a progressively increasing
+number of received packets or amount of time before responding to received
+packets.
+
+The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint MAY
+discard all other connection state. An endpoint that is closing is not required
+to process the frames contained in packets. An endpoint MAY retain packet
+protection keys for incoming packets to allow it to read and process a
+CONNECTION_CLOSE frame.
+
+An endpoint MAY drop packet protection keys when entering the closing state
+and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram

```suggestion
and send a packet containing a CONNECTION_CLOSE frame in response to any UDP datagram
```

> +number of received packets or amount of time before responding to received
+packets.
+
+The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint MAY
+discard all other connection state. An endpoint that is closing is not required
+to process the frames contained in packets. An endpoint MAY retain packet
+protection keys for incoming packets to allow it to read and process a
+CONNECTION_CLOSE frame.
+
+An endpoint MAY drop packet protection keys when entering the closing state
+and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram
+that is received. However, an endpoint that discards packet protection keys
+cannot identify and discard invalid packets. To avoid being used for an
+amplication attack, such endpoints MUST limit the cumulative size of packets
+containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the

```suggestion
it sends to three times the cumulative size of the
```

> +packets.
+
+The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint MAY
+discard all other connection state. An endpoint that is closing is not required
+to process the frames contained in packets. An endpoint MAY retain packet
+protection keys for incoming packets to allow it to read and process a
+CONNECTION_CLOSE frame.
+
+An endpoint MAY drop packet protection keys when entering the closing state
+and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram
+that is received. However, an endpoint that discards packet protection keys
+cannot identify and discard invalid packets. To avoid being used for an
+amplication attack, such endpoints MUST limit the cumulative size of packets
+containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the
+packets that cause those packets to be sent. To minimize the state that an

```suggestion
packets that are received and attributed to the connection. To minimize the state that an
```

> +The endpoint's selected connection ID and the QUIC version are sufficient
+information to identify packets for a closing connection; an endpoint MAY
+discard all other connection state. An endpoint that is closing is not required
+to process the frames contained in packets. An endpoint MAY retain packet
+protection keys for incoming packets to allow it to read and process a
+CONNECTION_CLOSE frame.
+
+An endpoint MAY drop packet protection keys when entering the closing state
+and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram
+that is received. However, an endpoint that discards packet protection keys
+cannot identify and discard invalid packets. To avoid being used for an
+amplication attack, such endpoints MUST limit the cumulative size of packets
+containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the
+packets that cause those packets to be sent. To minimize the state that an
+endpoint maintains for a closing connection, endpoints MAY send the exact same
+packet.

```suggestion
packet in response to any received packet.
```

> @@ -2763,26 +2805,37 @@ Note:
   congestion control, which are not expected to be relevant for a closed
   connection. Retransmitting the final packet requires less state.
 
-New packets from unverified addresses could be used to create an amplification
-attack; see {{address-validation}}.  To avoid this, endpoints MUST either limit
-transmission of CONNECTION_CLOSE frames to validated addresses or drop packets
-without response if the response would be more than three times larger than the
-received packet.
+While in the closing state, an endpoint could receive packets from a new source
+address, possibly indicating a connection migration; see {{migration}}.  An
+endpoint in the closing state MUST either discard packets received from
+unvalidated addresses or limit the cumulative size of packets it sends to
+unvalidated addresses to 3 times the size of packets it receives from the

```suggestion
an unvalidated address to three times the size of packets it receives from that
```

> @@ -2763,26 +2805,37 @@ Note:
   congestion control, which are not expected to be relevant for a closed
   connection. Retransmitting the final packet requires less state.
 
-New packets from unverified addresses could be used to create an amplification
-attack; see {{address-validation}}.  To avoid this, endpoints MUST either limit
-transmission of CONNECTION_CLOSE frames to validated addresses or drop packets
-without response if the response would be more than three times larger than the
-received packet.
+While in the closing state, an endpoint could receive packets from a new source
+address, possibly indicating a connection migration; see {{migration}}.  An
+endpoint in the closing state MUST either discard packets received from
+unvalidated addresses or limit the cumulative size of packets it sends to

```suggestion
an unvalidated address or limit the cumulative size of packets it sends to
```

> @@ -2763,26 +2805,37 @@ Note:
   congestion control, which are not expected to be relevant for a closed
   connection. Retransmitting the final packet requires less state.
 
-New packets from unverified addresses could be used to create an amplification
-attack; see {{address-validation}}.  To avoid this, endpoints MUST either limit
-transmission of CONNECTION_CLOSE frames to validated addresses or drop packets
-without response if the response would be more than three times larger than the
-received packet.
+While in the closing state, an endpoint could receive packets from a new source
+address, possibly indicating a connection migration; see {{migration}}.  An
+endpoint in the closing state MUST either discard packets received from
+unvalidated addresses or limit the cumulative size of packets it sends to
+unvalidated addresses to 3 times the size of packets it receives from the
+address.
+
+An endpoint is not expected to handle key updates when it is closing. A key

```suggestion
An endpoint is not expected to handle key updates when it is closing (Section 6 of {{QUIC-TLS}}). A key
```

> @@ -2763,26 +2805,37 @@ Note:
   congestion control, which are not expected to be relevant for a closed
   connection. Retransmitting the final packet requires less state.
 
-New packets from unverified addresses could be used to create an amplification
-attack; see {{address-validation}}.  To avoid this, endpoints MUST either limit
-transmission of CONNECTION_CLOSE frames to validated addresses or drop packets
-without response if the response would be more than three times larger than the
-received packet.
+While in the closing state, an endpoint could receive packets from a new source
+address, possibly indicating a connection migration; see {{migration}}.  An
+endpoint in the closing state MUST either discard packets received from
+unvalidated addresses or limit the cumulative size of packets it sends to
+unvalidated addresses to 3 times the size of packets it receives from the
+address.
+
+An endpoint is not expected to handle key updates when it is closing. A key
+update might prevent the endpoint from moving from the closing state to
+the draining state, but it otherwise has no impact.

```suggestion
the draining state, since the endpoint will not be able to process subsequently received packets, but it otherwise has no impact.
```

> +NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets, which
+could result in a constant exchange of CONNECTION_CLOSE frames until either
+endpoint exits the closing state.

```suggestion
NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets. Doing so
could result in a constant exchange of CONNECTION_CLOSE frames until one of the
endpoints exits the closing state.
```

> +An endpoint MAY transition from the closing state to the draining state if it
+receives a CONNECTION_CLOSE frame, which indicates that the peer is also

```suggestion
An endpoint MAY enter the draining state from the closing state if it
receives a CONNECTION_CLOSE frame, which indicates that the peer is also
```

>  
-An immediate close can be used after an application protocol has arranged to
-close a connection.  This might be after the application protocols negotiates a
-graceful shutdown.  The application protocol exchanges whatever messages that
-are needed to cause both endpoints to agree to close the connection, after which
-the application requests that the connection be closed.  When the application
-closes the connection, a CONNECTION_CLOSE frame with an appropriate error code
-will be used to signal closure.
+An endpoint MAY transition from the closing state to the draining state if it
+receives a CONNECTION_CLOSE frame, which indicates that the peer is also
+closing or draining. In this case, the draining state SHOULD end when the
+closing state would have ended. In other words, the endpoint uses the same end
+time, but ceases retransmission of the closing packet.

```suggestion
time, but ceases transmission of any packets on this connection.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988#pullrequestreview-476392482