Subject: [quicwg/base-drafts] editorial changes in the closing section (#2315)

From: Marten Seemann <[email-masked]>
Date: Mon, 07 Jan 2019 18:46:32 -0800

You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * remove misleading sentence about closing and stateless resets
  * allow closing and draining periods longer than 3 PTO
  * editorial changes in the closing section

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 19:43:12 -0800

ianswett commented on this pull request.

 An endpoint enters a closing period after initiating an immediate close
 ({{immediate-close}}).  While closing, an endpoint MUST NOT send packets unless
 they contain a CONNECTION_CLOSE frame (see {{immediate-close}} for details).  An
 endpoint retains only enough information to generate a packet containing a
 CONNECTION_CLOSE frame and to identify packets as belonging to the connection.
-The connection ID and QUIC version is sufficient information to identify packets
-for a closing connection; an endpoint can discard all other connection state.
-An endpoint MAY retain packet protection keys for incoming packets to allow it
-to read and process a CONNECTION_CLOSE frame.
+The source and the destination connection ID and the QUIC version are sufficient

If it's possible the source CID could change, I'd suggest we only mention the destination CID.

-- 
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/2315#pullrequestreview-190083279

---

From: Marten Seemann <[email-masked]>
Date: Mon, 07 Jan 2019 20:40:08 -0800

marten-seemann commented on this pull request.

It looks like we have different scenarios in mind. I was thinking about an error that occurs during the handshake. In that case, you close the connection, but there might still be Handshake packets arriving, which you would want to ignore then.
You seem to be thinking about the peer switching to a new connection ID. If we want to cover that case, it seems like we need to remember *all* connection IDs that are still active.

-- 
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/2315#discussion_r245875839

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 21:30:53 -0800

martinthomson commented on this pull request.

The intent here was destination connection ID.  That should always be sufficient to identify the connection.  The source connection ID doesn't appear on any packets that are likely to matter and it only matters for the purposes of generating these packets.

Source connection ID might matter for the first Initial packet from the client, where there might be some value in distinguishing between connection attempts with colliding destination connection IDs.  The odds of that are slim enough for this to not matter though.

> @@ -2225,14 +2226,11 @@ 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.
 
-The draining and closing periods do not apply when a stateless reset
-({{stateless-reset}}) is sent.
-

What do you hope to achieve by removing this text?  It's still accurate, right?

>  An endpoint is not expected to handle key updates when it is closing or
 draining.  A key update might prevent the endpoint from moving from the closing
 state to draining, but it otherwise has no impact.
 
-While in the closing period, an endpoint could receive packets from a new source
+While in the closing period, a server could receive packets from a new source
 address, indicating a client connection migration ({{migration}}). An endpoint

We've generally avoided assigning roles, preferring to talk about migration as valid in both directions, so it might be better to say endpoint/peer rather than server/client here.  That doesn't matter though.

-- 
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/2315#pullrequestreview-190096457

---

From: Marten Seemann <[email-masked]>
Date: Mon, 07 Jan 2019 22:54:35 -0800

Closing and draining applies to connection. Stateless reset is sent when there is no connection, so I have no idea how this sentence would apply.

-- 
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/2315#discussion_r245892301

---

From: Marten Seemann <[email-masked]>
Date: Tue, 08 Jan 2019 06:58:10 +0000 (UTC)

We're talking from the view point of a connection here, so the CID that's necessary to assign a packet is one of the *source* CIDs (which will be the *destination* CID of the incoming packet).
You'll need to remember at least one of the *destination* CIDs for the connection ID in order to repeat the CONNECTION_CLOSE frame in the closing 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/2315#discussion_r245892861

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 23:00:08 -0800

That is the whole point of the text.  You could expand it to say that this is because there is no connection, I suppose.

-- 
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/2315#discussion_r245893189

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 23:02:07 -0800

I don't know what people view as source and destination when not talking about packets.  That's not something we have crisp terms for, but using source and destination here makes that problem worse.

-- 
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/2315#discussion_r245893468

---

From: Marten Seemann <[email-masked]>
Date: Mon, 07 Jan 2019 23:05:06 -0800

As it stands, it sounds like instead of going through draining and closing period, I can choose a shortcut and just send a stateless reset to kill a connection. I have no idea how one would even start the closing period if there was no connection in the first place.

-- 
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/2315#discussion_r245893897

---

From: Marten Seemann <[email-masked]>
Date: Mon, 07 Jan 2019 23:08:51 -0800

Just talking about "connection ID" is insufficient though, since I need to remember at least the connection ID I'm receiving packets at (which I would have called my source), and one connection ID I'm sending packets to (which I would have called my destination).
In addition, depending on how frequently the peer switches to new connection IDs, I maybe should also remember the outstanding connection IDs I've issued to my peer.

-- 
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/2315#discussion_r245894473

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 23:10:46 -0800

This text is specifically talking about identifying incoming packets, so the only connection ID that is relevant is the inbound one.  The final sentence of the paragraph is where the outbound connection ID becomes relevant.

-- 
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/2315#discussion_r245894747

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Jan 2019 22:41:40 -0800

Rebased and merged manually, with some tweaks.

-- 
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/2315#issuecomment-458014708

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Jan 2019 22:41:40 -0800

Closed #2315.

-- 
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/2315#event-2099907751