Re: NEW_CONNECTION_ID sequence numbers

Wed, 05 Jan 2022 13:03:26 -0800

When implementing Picoquic, I interpreted the specification as: if sending a CID as part of preferred address extension, use #1, otherwise use #1 for the next CID to be sent in "NEW CONNECTION ID" frame. I did not find the specification ambiguous. But maybe that's just me. 

-- Christian Huitema

On 1/5/2022 10:48 AM, Eric Kinnear wrote:

My recollection is that a CID with sequence number 1 does not have special 
meaning whether or not it was delivered via preferred_address or in a NCID 
frame, it’s just a “regular” CID and can be used just like any other CID.

Given that, at some level the text in question becomes only an illustrative 
example, since sequence numbers must monotonically increase and since 
preferred_address arrives via the transport parameters, it will logically have 
sequence number 1.

I think the text stating that it be the second one was added mostly to avoid 
ambiguity in terms of ordering with the initial CID and whether or not the 
initial CID “counted” (obviously ambiguity was not avoided successfully...).

The CID that arrived via preferred_address also counts against the limit just 
like any other CID. However, the text stays away from associating sequence 
number with the connection ID limit, instead referring only to “the number of 
active connection IDs”. Despite that, since the text is clear that “The 
sequence number on each newly issued connection ID MUST increase by 1”, it 
seems understandable to want to use the sequence number (along with the 
retired-prior-to sequence number) to enforce the active CID limit.

While it seems that these paragraphs are technically accurate, I would agree 
that the wording has several places that are ripe for confusion, which is 
something that we should improve.
It seems totally reasonable to clarify some of this in a future document update 
— would be happy to help wordsmith some text that makes things more clear.

Thanks,
Eric



On Jan 5, 2022, at 6:36 AM, Ted Hardie <[email protected]> wrote:

I agree that a short clarification would be helpful.  I did not implement this, but I 
would have used logic that resulted in a situation similar to Martin's, as it is 
non-intuitive to me that a connection ID of "1" has a special meaning in an 
initial connection and a different one if sent in a NEW_CONNECTION_ID.  Kazuho's text 
makes clear why my intuition is wrong, but it is pretty subtle to expect an implementer 
to catch.

regards,

Ted Hardie

On Wed, Jan 5, 2022 at 2:22 PM Ian Swett <[email protected] 
<mailto:[email protected]>> wrote:
I think a short clarification would be helpful, since I can see this being 
misread by others, but I have no opinion of whether it's an errata or not.

On Wed, Jan 5, 2022 at 8:37 AM Mirja Kuehlewind 
<[email protected] 
<mailto:[email protected]>> wrote:
If we want to keep a record we could also create an errata and ask the AD to 
set it into “held for document update” state…


From: QUIC <[email protected] <mailto:[email protected]>> on behalf of Kazuho Oku 
<[email protected] <mailto:[email protected]>>
Date: Wednesday, 5. January 2022 at 07:21
To: Martin Thomson <[email protected] <mailto:[email protected]>>
Cc: IETF QUIC WG <[email protected] <mailto:[email protected]>>
Subject: Re: NEW_CONNECTION_ID sequence numbers


Martin, thank you for bringing the issue to the list.


2022年1月5日(水) 14:57 Martin Thomson <[email protected] 
<mailto:[email protected]>>:

Hey,

I discovered a problem in my implementation of NEW_CONNECTION_ID that quicly 
didn't like.  I was always skipping sequence number 1, even when there was no 
preferred address, which caused quicly to think that I was exceeding the limits 
it set.

Kazuho, Jana, and I all agree that my code was wrong, but I found it pretty 
hard to clearly identify how this was specified in the spec.  Here's what it 
says:


  The sequence number of the initial connection ID is 0. If the 
preferred_address transport parameter is sent, the sequence number of the 
supplied connection ID is 1.

Additional connection IDs are communicated to the peer using NEW_CONNECTION_ID 
frames (Section 19.15). The sequence number on each newly issued connection ID 
MUST increase by 1.

-- https://quicwg.org/base-drafts/rfc9000.html#name-issuing-connection-ids 
<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2a7ac3727495dfff&q=1&e=2924cc42-2683-482a-9fc8-11e09e03a8df&u=https%3A%2F%2Fquicwg.org%2Fbase-drafts%2Frfc9000.html%23name-issuing-connection-ids>

Is it abundantly clear that I'm wrong based on this?  Did I miss a clearer 
piece of text elsewhere?  Or, should we be looking to open an erratum?


I think that the cited text is the only place that discusses this, and 
regarding the text we have now, it seems to me that it clearly *implies* that 
if preferred_address TP is omitted, then the CID(seqnum=1) should be carried by 
a NEW_CONNECTION_ID frame.


If we were to skip CID(seqnum=1) when preferred_address TP is omitted, then we would have not used 
a clause like "if the preferred_address transport parameter is sent." Instead, we would 
have omitted the if clause or said like "regardless of preferred_address transport parameter 
being sent."


Therefore, my personal view is that an erratum is *not* required. However, I 
agree generally that implications are a source of confusion. If we are to 
revise the spec, this is one place that we can do better.


Anyways. Even if we are to conclude that an erratum is unnecessary, it is 
always good to keep a record of how potentially confusing text should be read 
(or be improved in the next revision). To that respect, I appreciate your 
bringing this issue to the list regardless of how we would conclude.



Cheers,
Martin



--

Kazuho Oku

Reply via email to