Subject: [quicwg/base-drafts] Clarify server CONNECTION_CLOSE with Handshake (#2688)

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 04:01:52 -0700

No new normative text, but clarifies that if the server wants the client to process a connection close, it may have to send one in Initial and Handshake.

Came up in discussion on #2541
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Clarify server CONNECTION_CLOSE with Handshake

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2688.patch
https://github.com/quicwg/base-drafts/pull/2688.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/2688

---

From: Nick Banks <[email-masked]>
Date: Fri, 10 May 2019 06:59:19 -0700

nibanks approved this pull request.

LGTM for the most part. A few minor suggestions.

> @@ -2307,10 +2307,14 @@ signal closure.
 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.If the endpoint does not have Handshake keys, it MAY

```suggestion
in a Handshake packet.  If the endpoint does not have Handshake keys, it MAY
```

> @@ -2307,10 +2307,14 @@ signal closure.
 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.If the endpoint does not have Handshake keys, it MAY
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server can have Handshake keys but not know that the client has Handshake
+keys.  In order to guarantee a CONNECTION_CLOSE is processed, it has to send
+a CONNECTION_CLOSE in both Handshake and Initial, because the client discards
+Initial keys as soon as it has Handshake keys. If multiple packets are sent,
+they can be coalesced (see {{packet-coalesce}}) to facilitate retransmission.

```suggestion
they can be coalesced (see {{packet-coalesce}}).
```

> @@ -2307,10 +2307,14 @@ signal closure.
 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.If the endpoint does not have Handshake keys, it MAY
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server can have Handshake keys but not know that the client has Handshake
+keys.  In order to guarantee a CONNECTION_CLOSE is processed, it has to send
+a CONNECTION_CLOSE in both Handshake and Initial, because the client discards
+Initial keys as soon as it has Handshake keys. If multiple packets are sent,

```suggestion
Initial keys as soon as it has Handshake keys.  If multiple packets are sent,
```

> @@ -2307,10 +2307,14 @@ signal closure.
 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.If the endpoint does not have Handshake keys, it MAY
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server can have Handshake keys but not know that the client has Handshake
+keys.  In order to guarantee a CONNECTION_CLOSE is processed, it has to send

Should `has`  be `SHOULD`? If you're going to send a CONNECTION_CLOSE then you want it to be received. If the server isn't certain the client has the handshake keys, it really should send both, IMO.

> @@ -2307,10 +2307,14 @@ signal closure.
 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.If the endpoint does not have Handshake keys, it MAY
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server can have Handshake keys but not know that the client has Handshake

The `but not know` reads a little weird to me for some reason. Perhaps something along the lines of `but not be certain the client does.`?

-- 
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/2688#pullrequestreview-236111152

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 07:59:47 -0700

@ianswett pushed 1 commit.

9bcc7fa068fdd7100c1f3bb5eff18184a3f09518  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2688/files/95827872f54e34d9ba9d5dfe5c611efe92666bb8..9bcc7fa068fdd7100c1f3bb5eff18184a3f09518

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 08:00:56 -0700

ianswett commented on this pull request.

Well, it both minimizes the number of datagrams and makes retransmission easier.  I'll update it with more verbose text about why this can facilitate retransmission.

-- 
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/2688#discussion_r282921414

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 15:01:30 +0000 (UTC)

I believe we've been using one space in this doc?

-- 
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/2688#discussion_r282921618

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 08:02:38 -0700

I tend to agree, but I was attempting to write non-normative text.  I'll change that and see how it reads.

-- 
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/2688#discussion_r282922096

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 08:05:10 -0700

Rewritten

-- 
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/2688#discussion_r282923067

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 08:06:00 -0700

ead6736c0daf7d2d90058a7eee0029f9a2f511f3  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2688/files/9bcc7fa068fdd7100c1f3bb5eff18184a3f09518..ead6736c0daf7d2d90058a7eee0029f9a2f511f3

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 18:56:46 -0700

janaiyengar commented on this pull request.

+in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD

This needs to be only a statement of fact that describes the exception to the preceding SHOULD. "If the endpoint does not have Handshake keys, it sends CONNECTION_CLOSE frames in an Initial packet"

+in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD
+The server may not know whether the client has Handshake keys.  In order to

```suggestion
It is possible that an endpoint does not know whether the peer has Handshake keys.  In order to
```

 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server may not know whether the client has Handshake keys.  In order to
+guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE

The server can't guarantee this. (see proposed text below)

 If the connection has been successfully established, endpoints MUST send any
 CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
 peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server may not know whether the client has Handshake keys.  In order to
+guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE
+in both Handshake and Initial, because the client discards Initial keys as soon
+as it has Handshake keys. If multiple packets are sent, they can be coalesced
+(see {{packet-coalesce}}).

Suggested rewording of text after the first sentence:
"Under these circumstances, an endpoint SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets to increase the likelihood of a CONNECTION_CLOSE frame being processed by the peer.  These packets can be coalesced into a single UDP datagram (see {{packet-coalesce}})."

-- 
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/2688#pullrequestreview-236357458

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 12:03:14 -0700

I'm fairly sure server to client is the only case two connection closes may need to be sent, which is why it's written with server an client.

-- 
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/2688#discussion_r283149566

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 12:05:11 -0700

A server can't guarantee the packet arrives, but I think sending both guarantees that if it does arrive at the client, the client can be decrypted.  Am I missing something?

-- 
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/2688#discussion_r283149645

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 17:01:53 -0700

I'm confused why we have a MUST and a SHOULD for the other two cases, but you're advising no normative text for the Initial case?  Am I missing something?

-- 
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/2688#discussion_r283161366

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 May 2019 17:02:27 -0700

martinthomson commented on this pull request.

We should also try to kill #2151 with this change:

```suggestion
When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
the frame.  Generally, this means sending the frame in a packet with the highest
level of packet protection to avoid the packet being discarded.  However, during
the handshake, it is possible that more advanced packet protection keys are not
available to a peer, so the frame MAY be replicated in a packet that uses a
lower packet protection level.

That assumes a lot about the shape of the handshake though.  If you are going to make that call, cite QUIC-TLS.

A bigger point here is that the server also isn't sure when the client gets 1-RTT keys.  We should say the same about that transition.  I believe that we can rely on handshake confirmation for this transition.  Endpoints might choose to send CONNECTION_CLOSE in Handshake packets prior to the handshake being confirmed.

-- 
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/2688#pullrequestreview-236443175

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 17:11:37 -0700

I have in mind 17.2.2.1 in Transport: https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-17.2.2.1

"A client stops both sending and processing Initial packets when it sends its first Handshake packet."

This clearly indicates that a client will almost never be processing Initial and Handshake packets at once, so if you only send one connection close, some clients will drop it.  In all other cases with #2673 landed, the client and server should both still have Handshake keys even if they also have 1-RTT keys?

Is there something about TLS I'm implicitly assuming as well?  I can imagine I am, but I don't know what it is.

-- 
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/2688#discussion_r283161871

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 17:12:31 -0700

Agreed, another spot we're relying on #2673?

-- 
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/2688#discussion_r283161917

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 17:16:13 -0700

96c89135a1889e5209bc38e64026735d187b50c0  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2688/files/ead6736c0daf7d2d90058a7eee0029f9a2f511f3..96c89135a1889e5209bc38e64026735d187b50c0

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 17:19:16 -0700

e70eff7103fa457e16158dbf03f21d44672e1d76  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2688/files/96c89135a1889e5209bc38e64026735d187b50c0..e70eff7103fa457e16158dbf03f21d44672e1d76

---

From: ianswett <[email-masked]>
Date: Sun, 12 May 2019 17:21:08 -0700

I updated the text about sending 1-RTT connection closes to use Handshake confirmed, which lines up with #2673.  I think that's a good fix?

-- 
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/2688#discussion_r283162416

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 May 2019 17:29:40 -0700

Ahh, the two docs blur together in my mind.  This is OK.  I would suggest that you need to address both transitions here though.  The transition to Handshake and the transition to 1-RTT have the same sort of uncertainty.

Don't sound so uncertain :)  I think that the fix is good.

And we'd (collectively) be crazy if we didn't take #2673.

-- 
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/2688#discussion_r283162838

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 May 2019 11:24:32 -0700

MikeBishop commented on this pull request.

We'd also individually go crazy if we don't take it.  😉

-- 
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/2688#discussion_r283475603

---

From: ianswett <[email-masked]>
Date: Mon, 13 May 2019 18:21:55 -0700

The handshake to 1-RTT transition has an overlap where the peer has both sets of keys, unlike Initial to Handshake, so I think using handshake confirmed as the signal here provides what we want?

-- 
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/2688#discussion_r283594362

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 May 2019 16:16:07 -0700

-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.
+
+If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames
+in a 1-RTT packet.  Prior to handshake confirmation, a peer might not have
+1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake
+packet.  If the endpoint does not have Handshake keys, it SHOULD send
+CONNECTION_CLOSE frames in an Initial packet.
+
+The server may not know whether the client has Handshake keys.  In order to

```suggestion
A client will always know whether the server has Handshake keys (see {{discard-initial}}), but it is possible that a server does not know whether the client has Handshake keys.
```

"Under these circumstances, a server SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at least one of them is processable by the client. These packets can be coalesced into a single UDP datagram (see {{packet-coalesce}})."

-- 
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/2688#pullrequestreview-237541936

---

From: ianswett <[email-masked]>
Date: Tue, 14 May 2019 16:18:04 -0700

cfa8de6f77ce88c84136eac6dc91398ec1445680  Update draft-ietf-quic-transport.md

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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 May 2019 16:19:58 -0700

janaiyengar approved this pull request.

-- 
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/2688#pullrequestreview-237546857

---

From: ianswett <[email-masked]>
Date: Tue, 14 May 2019 16:20:09 -0700

ab282cd9ed385732ecdef405f92e4840bfeee724  Update draft-ietf-quic-transport.md

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

---

From: ianswett <[email-masked]>
Date: Tue, 14 May 2019 17:48:11 -0700

1bb9ef09352cce9ed56c14058105a2029f111715  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2688/files/ab282cd9ed385732ecdef405f92e4840bfeee724..1bb9ef09352cce9ed56c14058105a2029f111715

---

From: MikkelFJ <[email-masked]>
Date: Wed, 15 May 2019 05:42:58 +0000 (UTC)

mikkelfj commented on this pull request.

> @@ -2304,13 +2304,25 @@ the application requests that the connection be closed.  The application
 protocol can use an CONNECTION_CLOSE frame with an appropriate error code to
 signal closure.
 
-If the connection has been successfully established, endpoints MUST send any
-CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.

This paragraph doesn't really say anything that the next paragraph doesn't cover. Also, `a peer` sounds like an endpoint can have multiple peers.

> @@ -2304,13 +2304,25 @@ the application requests that the connection be closed.  The application
 protocol can use an CONNECTION_CLOSE frame with an appropriate error code to
 signal closure.
 
-If the connection has been successfully established, endpoints MUST send any
-CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
-in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
-not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
-frames in an Initial packet.  If multiple packets are sent, they can be
-coalesced (see {{packet-coalesce}}) to facilitate retransmission.
+When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
+the frame.  Generally, this means sending the frame in a packet with the highest
+level of packet protection to avoid the packet being discarded.  However, during
+the handshake, it is possible that more advanced packet protection keys are not
+available to a peer, so the frame MAY be replicated in a packet that uses a
+lower packet protection level.
+
+If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames

```suggestion
When the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE frames
```

> -CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames

```suggestion
1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a Handshake
```

> -If the connection has been successfully established, endpoints MUST send any
-CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
-peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames

```suggestion
in a 1-RTT packet.  Prior to handshake confirmation, the peer might not have
```

-- 
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/2688#pullrequestreview-237616302

---

From: ianswett <[email-masked]>
Date: Wed, 15 May 2019 08:26:57 -0700

That makes it sound a bit too much like one should close the connection upon completing the handshake.  I think If works better, though "After" could also work.

-- 
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/2688#discussion_r284315652

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 May 2019 18:16:37 -0700

```suggestion
When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process
```

```suggestion
available to the peer, so the frame MAY be replicated in a packet that uses a
```

I missed this earlier, but I agree. I'm fine with dropping this paragraph entirely. It seems like it's simply repeating what's in the next para, but in more general terms.

-- 
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/2688#pullrequestreview-238139910