Clarify section on negotiating connection IDs #3349

janaiyengar · 2020-01-15T19:02:53Z

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.

Addresses #3348.

nibanks · 2020-01-15T19:09:43Z

draft-ietf-quic-transport.md

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

Gah! That was my mistake. Fixed.

nibanks · 2020-01-15T20:45:07Z

draft-ietf-quic-transport.md

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

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.

martinthomson

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

martinthomson · 2020-02-04T13:44:01Z

draft-ietf-quic-transport.md

+Initial packet from the server, it MUST discard any subsequent packet it
+receives with a different Source Connection ID.
+
+A client MUST change the DCID value it sends in response to only the first


Suggested change

A client MUST change the DCID value it sends in response to only the first

A client MUST change the Destination Connection ID value it uses for sending packets in response to only the first

martinthomson · 2020-02-04T13:44:39Z

draft-ietf-quic-transport.md

+receives with a different Source Connection ID.
+
+A client MUST change the DCID value it sends in response to only the first
+received Initial or Retry packet.  A server MUST set its DCID value based on the


Suggested change

received Initial or Retry packet. A server MUST set its DCID value based on the

received Initial or Retry packet. A server MUST set the Destination Connection ID it uses for sending packets based on the

martinthomson · 2020-02-04T13:46:21Z

draft-ietf-quic-transport.md

+A client MUST change the DCID value it sends in response to only the first
+received Initial or Retry packet.  A server MUST set its DCID value based on the
+first received Initial packet. Any further changes to the DCID are not
+permitted; if subsequent Initial packets include a different SCID, they MUST be


are only permitted if the values are taken from NEW_CONNECTION_ID frames; if subsequent

erickinnear · 2020-02-06T11:30:13Z

draft-ietf-quic-transport.md

-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 0-RTT packets. This means that a client might change the DCID
+twice during connection establishment, once in response to a Retry and once in


Given the resolution of #3348, we should likely update this to not set an expectation that you change twice maximum, technically they can change as many times as you give them CIDs / as many times as they want to switch between all active CIDs.

The reference to {{issue-cid}} later will point people at some clarification about this too, so that looks great.

Perhaps: "This means that a client might have to change the connection ID it puts in the Destination Connection ID field twice during connection establishment, [..]"

These changes are mandatory, so it is appropriate to point to those as being special.

martinthomson · 2020-03-05T00:00:52Z

I would like to merge this PR as the corresponding issue has consensus, but it has outstanding issues. @janaiyengar would you mind?

One thing to add is that #3499 touches some of this text. I'll need to rebase that I guess.

janaiyengar · 2020-03-09T22:17:02Z

I've taken in the comments, and revised this PR based on the resolution to #3348.

ianswett · 2020-03-10T02:17:41Z

draft-ietf-quic-transport.md

-Until a packet is received from the server, the client MUST use the same DCID
-value on all packets in this connection. This DCID is used to determine packet
+Initial or Retry packet from the server, the client populates the Destination
+Connection ID field with an unpredictable value.  This Destination Connection ID


It might be worth clarifying that the 'unpredictable value' is constant for a given connection?

That is below.

martinthomson · 2020-03-10T23:23:00Z

draft-ietf-quic-transport.md

-Until a packet is received from the server, the client MUST use the same DCID
-value on all packets in this connection. This DCID is used to determine packet
+Initial or Retry packet from the server, the client populates the Destination
+Connection ID field with an unpredictable value.  This Destination Connection ID


That is below.

martinthomson · 2020-03-10T23:24:23Z

draft-ietf-quic-transport.md

+in response to only the first received Initial or Retry packet.  A server MUST
+set the Destination Connection ID it uses for sending packets based on the first
+received Initial packet. Any further changes to the Destination Connection ID
+are are only permitted if the values are taken from any received


Suggested change

are are only permitted if the values are taken from any received

are only permitted if the values are taken from any received

you know it is hard for me to type that without typing "area"

nibanks reviewed Jan 15, 2020

View reviewed changes

janaiyengar added -transport editorial An issue that does not affect the design of the protocol; does not require consensus. labels Jan 15, 2020

nibanks reviewed Jan 15, 2020

View reviewed changes

martinthomson reviewed Jan 22, 2020

View reviewed changes

martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. and removed editorial An issue that does not affect the design of the protocol; does not require consensus. labels Feb 4, 2020

martinthomson reviewed Feb 4, 2020

View reviewed changes

erickinnear reviewed Feb 6, 2020

View reviewed changes

janaiyengar added 3 commits March 9, 2020 15:01

Clarify section on negotiating connection IDs

c7dabf0

no hs packets

e225cbb

comments

73bf631

janaiyengar force-pushed the jri/cids branch from 53c3698 to 73bf631 Compare March 9, 2020 22:01

leftover abbrevs

95791fc

janaiyengar mentioned this pull request Mar 9, 2020

Which DCID do Handshake retransmissions use? #3348

Closed

ianswett reviewed Mar 10, 2020

View reviewed changes

martinthomson approved these changes Mar 10, 2020

View reviewed changes

are are

d22c4fe

you know it is hard for me to type that without typing "area"

martinthomson merged commit d3adc44 into master Mar 10, 2020

martinthomson deleted the jri/cids branch March 10, 2020 23:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify section on negotiating connection IDs #3349

Clarify section on negotiating connection IDs #3349

janaiyengar commented Jan 15, 2020 •

edited

nibanks Jan 15, 2020

janaiyengar Jan 15, 2020

nibanks Jan 15, 2020

janaiyengar Jan 15, 2020

martinthomson left a comment

martinthomson Feb 4, 2020

martinthomson Feb 4, 2020

martinthomson Feb 4, 2020

erickinnear Feb 6, 2020

martinthomson Feb 25, 2020

martinthomson commented Mar 5, 2020 •

edited

janaiyengar commented Mar 9, 2020

ianswett Mar 10, 2020

martinthomson Mar 10, 2020

martinthomson Mar 10, 2020

martinthomson Mar 10, 2020

		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

	A client MUST change the DCID value it sends in response to only the first
	A client MUST change the Destination Connection ID value it uses for sending packets in response to only the first

	received Initial or Retry packet. A server MUST set its DCID value based on the
	received Initial or Retry packet. A server MUST set the Destination Connection ID it uses for sending packets based on the

	are are only permitted if the values are taken from any received
	are only permitted if the values are taken from any received

Clarify section on negotiating connection IDs #3349

Clarify section on negotiating connection IDs #3349

Conversation

janaiyengar commented Jan 15, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson commented Mar 5, 2020 • edited

janaiyengar commented Mar 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar commented Jan 15, 2020 •

edited

martinthomson commented Mar 5, 2020 •

edited