Subject: [quicwg/base-drafts] Clarify section on negotiating connection IDs (#3349)

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 11:03:05 -0800

In thinking about #3348, I started this editorial PR to clarify language in the section on negotiating connection IDs. I suspect much of it was left over from before we had the DCID / SCID split, and also before the new handshake was established.

This is deliberately only editorial, and it exposes issues. Notably, there is no mention of Handshake packets, but that is just as it was. Where that should fit needs more discussion, and I am proposing to do that separately.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Clarify section on negotiating connection IDs

-- File Changes --

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

-- Patch Links --

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

---

From: Nick Banks <[email-masked]>
Date: Wed, 15 Jan 2020 11:09:54 -0800

nibanks commented on this pull request.

> -Initial packet from the server. Once a client has received an Initial packet
-from the server, it MUST discard any packet it receives with a different Source
-Connection ID.
-
-A client MUST only change the value it sends in the Destination Connection ID in
-response to the first packet of each type it receives from the server (Retry or
-Initial); a server MUST set its value based on the Initial packet.  Any
-additional changes are not permitted; if subsequent packets of those types
-include a different Source Connection ID, they MUST be discarded.  This avoids
-problems that might arise from stateless processing of multiple Initial packets
-producing different connection IDs.
-
-The connection ID can change over the lifetime of a connection, especially in
-response to connection migration ({{migration}}); see {{issue-cid}} for details.
+the SCID supplied by the server as the DCID for subsequent packets, including
+all subsequent Handshake and 0-RTT packets. This means that a client might

Why require that all subsequent Handshake packets use the same CID? It's definitely requires for Initial and 0-RTT to have consistent routing through the LB, but I haven't heard any reason to require it for handshake (taking into account possible new CIDs being received, i.e. #3348). IMO, adding extra restrictions here just complicates NEW_CONNECTION_ID handling.

-- 
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/3349#pullrequestreview-343453704

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 12:32:04 -0800

@janaiyengar pushed 1 commit.

8900cc103b376a80266150a907e7d1004dd15690  no hs packets

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3349/files/9df4a03454c43c2b63413c5689c9c36a4fea1826..8900cc103b376a80266150a907e7d1004dd15690

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 12:33:01 -0800

janaiyengar commented on this pull request.

Gah! That was my mistake. Fixed.

-- 
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/3349#discussion_r367092593

---

From: Nick Banks <[email-masked]>
Date: Wed, 15 Jan 2020 12:45:17 -0800

> +the SCID supplied by the server as the DCID for subsequent packets, including
+all subsequent 0-RTT packets. This means that a client might change the DCID

I think it might just be best to explicitly state which packet types require use of the new DCID. Not mentioning handshake packets here just leaves it unclear IMO.

-- 
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/3349#pullrequestreview-343509112

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jan 2020 12:54:52 -0800

I agree, and as I noted in the description, this PR exposes this issue.

Ok, I'm going to give it a shot based on what I understand our intent was; I'll see how it goes.

-- 
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/3349#discussion_r367101833

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jan 2020 17:06:48 -0800

martinthomson commented on this pull request.

I have an editorial disagreement with this separate from the more substantive changes: I don't like acronyms for field names.  Can we separate that out (or not do it, ideally)?

-- 
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/3349#pullrequestreview-346293094