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

From: Martin Thomson <[email-masked]>
Date: Wed, 05 Aug 2020 23:57:41 -0700

I took a careful look at the text here and found a few things:

1. There wasn&#39;t much redundancy, but there was a little.

2. The closing and draining states only apply to immediate close.

So I moved things up.  Shortened the top-level immediate close text, and
moved text specific to closing or draining to the corresponding
sections.

There were a few bits that could be cut, and a few that needed to be
better aligned with existing text, but nothing major.  Most of this is
unmodified text.

There are a few bits that I had to rewrite.  I will add comments for
those.

Closes #3907.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3988

-- Commit Summary --

  * Closing and draining tidy

-- File Changes --

    M draft-ietf-quic-transport.md (171)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3988.patch
https://github.com/quicwg/base-drafts/pull/3988.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Aug 2020 00:00:06 -0700

@martinthomson pushed 1 commit.

0c9512f6e81837cd4adba3ed670d3376dd072f73  Remove self-reference

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/45e033da8f481d3d0b85e335a4cf3beda602f1e3..0c9512f6e81837cd4adba3ed670d3376dd072f73

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Aug 2020 00:03:54 -0700

@martinthomson commented on this pull request.

>  After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
-closing state.
+closing state; see {{closing}}. After receiving a CONNECTION_CLOSE frame,
+endpoints enter the draining state; see {{draining}}.

This is a new consolidated introduction.  It's all the functional requirements that are relevant to this section.

> +An endpoint MAY drop packet protection keys when starting the closing period
+and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram

This changes to use MAY instead of "is allowed to".

Otherwise, this changes only to remove the self-reference (and s/entering/starting).

> +While in the closing period, an endpoint could receive packets from a new
+source address, indicating a connection migration; see {{migration}}. New
+packets from unverified addresses could be used to create an amplification
+attack; see {{address-validation}}. To avoid being used for an amplication
+attack, 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.

This required a little better alignment with the other text above.  The sentence "To avoid being used for an amplification attack" is now the same in both places.

> +The draining state is entered once an endpoint receives a CONNECTION_CLOSE
+frame, which indicates that its peer is closing or draining. While otherwise
+identical to the closing state, an endpoint in the draining state MUST NOT send
+any packets. Retaining packet protection keys is unnecessary once a connection
+is in the draining state.

We used to think that you could enter draining as a result of a stateless reset or idle timeout.  That is no longer the case, so this just mentions CONNECTION_CLOSE directly.

>  An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet
 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
 send further packets, which could result in a constant exchange of
 CONNECTION_CLOSE frames until the closing period on either peer ended.
 
-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 period to the draining period if it
+receives a CONNECTION_CLOSE frame or stateless reset, either of which indicate
+that the peer is also closing or draining.  The draining period SHOULD end when
+the closing period would have ended.  In other words, the endpoint can use the
+same end time, but cease retransmission of the closing packet.
+
+
+### Terminal Connection State

This stuff is awkward.  I will move it up into the introductory part instead.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Aug 2020 00:06:17 -0700

d44244caca3fd09297fd467bf89bb3908eb90188  Move general stuff into introductory piece

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/0c9512f6e81837cd4adba3ed670d3376dd072f73..d44244caca3fd09297fd467bf89bb3908eb90188

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Aug 2020 00:20:30 -0700

43176fb5cd31d1c0f26c9be3a774dcb2f32eb6ff  Better factoring of closing state introduction

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/d44244caca3fd09297fd467bf89bb3908eb90188..43176fb5cd31d1c0f26c9be3a774dcb2f32eb6ff

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Aug 2020 00:24:05 -0700

cb1bca7cf8468a98a5153e1931a5c7536c8a824c  Remove mention of stateless reset

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/43176fb5cd31d1c0f26c9be3a774dcb2f32eb6ff..cb1bca7cf8468a98a5153e1931a5c7536c8a824c

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Aug 2020 00:24:54 -0700

> +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
+protection keys for incoming packets to allow it to read and process a
+CONNECTION_CLOSE frame.

This is factored fairly heavily.

> +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.

This is only factored lightly:

use MAY in place of "is allowed to"

use state instead of period

remove self-reference

> +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 the exiting the closing or draining state
+could cause delayed or reordered packets to generate an unnecessary stateless
+reset. Endpoints that have some alternative means to ensure that late-arriving
+packets on the connection 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.  This results in new packets on the connection being handled
+generically.  For instance, an endpoint MAY send a stateless reset in response
+to any further incoming packets.

This stuff is mostly just reordered.  The main change is to  talk about states rather than periods, for consistency reasons.

> +could cause delayed or reordered packets to generate an unnecessary stateless
+reset. Endpoints that have some alternative means to ensure that late-arriving
+packets on the connection 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.  This results in new packets on the connection being handled
+generically.  For instance, 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.

Removed a self-reference here, that's all.

+An endpoint MAY transition from the closing state to the draining state if it

This is wrong.  I'll fix that.

> +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.

This bit used to say that you entered draining after getting a stateless reset, which was just flat wrong.

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

---

From: Nick Banks <[email-masked]>
Date: Thu, 06 Aug 2020 07:14:23 -0700

@nibanks commented on this pull request.

+

`prior to the exiting the closing or draining state` I can't parse this. Is a comma missing or are there added/missing word?

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

---

From: ianswett <[email-masked]>
Date: Mon, 10 Aug 2020 17:45:44 -0700

@ianswett commented on this pull request.

+

```suggestion
Disposing of connection state prior to exiting the closing or draining state
```

-- 
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#discussion_r468262935

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Aug 2020 17:50:28 -0700

a31d8dcdc8e35ff2d62899054aca458c71a31645  s/the//

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/cb1bca7cf8468a98a5153e1931a5c7536c8a824c..a31d8dcdc8e35ff2d62899054aca458c71a31645

---

From: ianswett <[email-masked]>
Date: Mon, 10 Aug 2020 18:00:24 -0700

This is a big change, but seems good.  Some specific suggestions on improving the text.

Given the situation, I believe reordered is correct.
```suggestion
could cause reordered packets to generate an unnecessary stateless
```

```suggestion
packets do not induce a response, such as those that are able
```

This sentence is not very helpful, so I'd remove it unless you have a better suggestion.

This sentence is not very helpful, so I'd remove it unless you have a better suggestion.
```suggestion
connection state.  An endpoint MAY send a stateless reset in response
```

> +While in the closing state, an endpoint could receive packets from a new
+source address, indicating a connection migration; see {{migration}}. An
+endpoint that discards information about validated addresses might be used to
+create an amplification attack; see {{address-validation}}. To avoid being used
+for an amplication attack, 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.

Given other path migration constraints, this text seems odd.  It's possible it could be fully removed.

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

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Aug 2020 18:46:45 -0700

6aef5e42b482cb9a3efeab78fd6f3a92c79cf6b1  Ian's cleanup

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/a31d8dcdc8e35ff2d62899054aca458c71a31645..6aef5e42b482cb9a3efeab78fd6f3a92c79cf6b1

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Aug 2020 18:48:57 -0700

Thanks Ian, I took the suggestions.  Not sure about the reordering thing.

Let's say that you send CONNECTION_CLOSE then drop state immediately.  It's not clear whether packets you subsequently receive are the result of the peer just sending, delays, or reordering.  Maybe we can just say "packets":

> [...] could result in an generating unnecessary stateless reset in response to receiving a 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-464694590

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Aug 2020 18:50:36 -0700

e980fc772bdfff04801b7f8febb1d68385655060  Maybe we don't need to specify reordering/delay at all

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/6aef5e42b482cb9a3efeab78fd6f3a92c79cf6b1..e980fc772bdfff04801b7f8febb1d68385655060

---

From: ianswett <[email-masked]>
Date: Tue, 11 Aug 2020 06:45:57 -0700

Sure, the new text works I think.

-- 
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#discussion_r468590641

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Aug 2020 08:46:16 -0700

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

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

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Aug 2020 17:10:51 -0700

e127ccad5d2285df6f7556b914871f70c4d577f7  Small tweaks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/e980fc772bdfff04801b7f8febb1d68385655060..e127ccad5d2285df6f7556b914871f70c4d577f7

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Aug 2020 17:11:21 -0700

37a2d522f133bf26cd8064d0264d05ce7243bb54  Rewrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/e127ccad5d2285df6f7556b914871f70c4d577f7..37a2d522f133bf26cd8064d0264d05ce7243bb54

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Aug 2020 21:03:48 -0700

@janaiyengar, you can add this to your review load.

-- 
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#issuecomment-674643475

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 26 Aug 2020 22:49:13 -0700

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

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

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

+

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

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

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

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

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

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

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

All frames are in packets.

+

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

+packets.
+

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

+

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

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

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

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

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

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

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

+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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Aug 2020 22:57:20 -0700

6cc520dad75038f046b05e785cecd9869bcf3306  Many little nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/37a2d522f133bf26cd8064d0264d05ce7243bb54..6cc520dad75038f046b05e785cecd9869bcf3306

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Aug 2020 22:59:18 -0700

f6c037d97b3e700569347af0d6c8a596eacd265b  Wrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3988/files/6cc520dad75038f046b05e785cecd9869bcf3306..f6c037d97b3e700569347af0d6c8a596eacd265b

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 26 Aug 2020 23:15:48 -0700

@janaiyengar approved this pull request.

Thanks, Martin!

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

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 26 Aug 2020 23:15:58 -0700

Merged #3988 into master.

-- 
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#event-3697866419