Re: NEW_CONNECTION_ID sequence numbers

[Ted Hardie <[e-mail]>]

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 <ianswett=
[e-mail]> 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 <mirja.kuehlewind=
> [e-mail]> 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 <[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]>:
>>
>> 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
>>
>