Re: NEW_CONNECTION_ID sequence numbers

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> on behalf of Kazuho Oku <[e-mail]>
Date: Wednesday, 5. January 2022 at 07:21
To: Martin Thomson <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: NEW_CONNECTION_ID sequence numbers

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

2022年1月5日(水) 14:57 Martin Thomson <[e-mail]<mailto:[e-mail]>>:
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