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

[Mike Bishop <[e-mail]>]

@MikeBishop approved this pull request.

I think this flows a lot better.  Thanks for the time you put into this!

> +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.
+
+
+### Closing Connection State {#closing}
+
+An endpoint enters a closing state after initiating an immediate close.

```suggestion
An endpoint enters the closing state after initiating an immediate close.
```

> @@ -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
+draining, but it otherwise has no impact.

```suggestion
the draining state, but it otherwise has no impact.
```

>  containing a CONNECTION_CLOSE frame before entering the draining state, using a
 CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT

Existing text, but "single packet containing a CONNECTION_CLOSE frame ... using a CONNECTION_CLOSE frame" seems redundant.
```suggestion
containing a CONNECTION_CLOSE frame before entering the draining state, using a
NO_ERROR code if appropriate.  An endpoint MUST NOT
```

> +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 cease retransmission of the closing packet.

```suggestion
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.
```

-- 
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-465183222