Re: NEW_CONNECTION_ID sequence numbers

[Eric Kinnear <[e-mail]>]

That seems like a reasonable proposal to me! 


In terms of clarity on the other points that have come up in this thread, I double checked and it looks like we’ve got good text stating that: 
1. The preferred_address CID is interchangeable with any other CID acquired via NCID frames
2. The active_connection_id_limit (and the set of “active” CIDs) includes the preferred_address and initial CID

So that covers everything I think we’ve seen so far.

Thanks,
Eric

=========

5.1.1 Issuing Connection IDs
…
Connection IDs that are issued and not retired are considered active; any active connection ID is valid for use with the current connection at any time, in any packet type. This includes the connection ID issued by the server via the preferred_address transport parameter.

https://quicwg.org/base-drafts/rfc9000.html#section-5.1.1-3 



9.6.1. Communicating a Preferred Address
...
Once the handshake is confirmed, the client SHOULD select one of the two addresses provided by the server and initiate path validation (see Section 8.2). A client constructs packets using any previously unused active connection ID, taken from either the preferred_address transport parameter or a NEW_CONNECTION_ID frame.

https://quicwg.org/base-drafts/rfc9000.html#section-9.6.1-3



9.6.3. Interaction of Client Migration and Preferred Address
...
The connection ID provided in the preferred_address transport parameter is not specific to the addresses that are provided. This connection ID is provided to ensure that the client has a connection ID available for migration, but the client MAY use this connection ID on any path.

https://quicwg.org/base-drafts/rfc9000.html#section-9.6.3-6



18.2. Transport Parameter Definitions
…
active_connection_id_limit (0x0e):
...
This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.

https://quicwg.org/base-drafts/rfc9000.html#section-18.2-6.2.1


> On Jan 5, 2022, at 4:19 PM, Martin Thomson <[e-mail]> wrote:
> 
> 
> On Thu, Jan 6, 2022, at 08:02, Christian Huitema wrote:
>> 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.
> 
> It's good that I'm the only one who implemented it incorrectly.  I'll get on to fixing it promptly.
> 
> In terms of clarifications, what do people think about this:
> 
> 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.
> +The sequence number for NEW_CONNECTION_ID frames starts at 2 when the preferred_address transport parameter is sent and 1 otherwise.
> 
> I can open an erratum with that as Mirja suggests.
> 
>