Subject: NEW_CONNECTION_ID sequence numbers

From: "Martin Thomson" <[email-masked]>
Date: Wed, 05 Jan 2022 16:56:59 +1100

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

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?

Cheers,
Martin

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 5 Jan 2022 15:20:10 +0900

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

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

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

-- 
Kazuho Oku

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 5 Jan 2022 13:36:44 +0000

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

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

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

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

---

From: Ian Swett <[email-masked]>
Date: Wed, 5 Jan 2022 09:21:19 -0500

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Jan 2022 14:36:40 +0000

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=
[email-masked]> wrote:

>> https://quicwg.org/base-drafts/rfc9000.html#name-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?
>>
>>
>>
>> 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.
>>
>>
>>

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 05 Jan 2022 12:48:54 -0800

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-masked]> 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 <ianswett=[email-masked] <mailto:[email-masked]>> 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=[email-masked] <mailto:[email-masked]>> wrote:
> From: QUIC <[email-masked] <mailto:[email-masked]>> on behalf of Kazuho Oku <[email-masked] <mailto:[email-masked]>>
> To: Martin Thomson <[email-masked] <mailto:[email-masked]>>
> Cc: IETF QUIC WG <[email-masked] <mailto:[email-masked]>>
> 2022年1月5日(水) 14:57 Martin Thomson <[email-masked] <mailto:[email-masked]>>:
> 
> Hey,
> 
> -- 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>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 5 Jan 2022 11:02:49 -1000

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 06 Jan 2022 11:19:23 +1100

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

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 05 Jan 2022 16:34:32 -0800

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 <[email-masked]> wrote:
> 
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 6 Jan 2022 00:50:04 +0000

Erratum sounds good to me. it's an easier aide memoir than a post-it note
pointer to a mailing list thread.

Cheers,
Lucas

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 6 Jan 2022 10:22:45 +0900

> pointer to a mailing list thread.

+1. MT's text looks good to me.

-- 
Kazuho Oku

---

From: Christian Huitema <[email-masked]>
Date: Wed, 5 Jan 2022 15:30:29 -1000

> +1. MT's text looks good to me.

+1.

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 06 Jan 2022 12:52:31 +1100

>> +1. MT's text looks good to me.

https://www.rfc-editor.org/errata/eid6811

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 21 Jan 2022 08:56:39 +0000

I think reporting errata was a good decision. However, looking at this discussion here I am bit confused on whether it should be “Verified” or “Hold for Document Update”. See the IESG statement on processing RFC errata for IETF stream https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ <https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/> . I am only considering guideline 1 and 2 for this errata.

Any suggestion?

//Zahed 

> On 6 Jan 2022, at 02:52, Martin Thomson <[email-masked]> wrote:
> 
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2dab3b36f98e5e89&q=1&e=2c69260a-f7ee-4213-a156-a1211bad8de2&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6811

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 21 Jan 2022 10:53:31 +0000

While this is more a clarification than an errata, having it verified would show it in the errata-inline view and as such might actually help future implementors to get this right. So I’m also not sure anymore; both could be fine.

From: QUIC <[email-masked]> on behalf of Zaheduzzaman Sarker <zaheduzzaman.sarker=[email-masked]>
Date: Friday, 21. January 2022 at 09:57
To: Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: NEW_CONNECTION_ID sequence numbers

I think reporting errata was a good decision. However, looking at this discussion here I am bit confused on whether it should be “Verified” or “Hold for Document Update”. See the IESG statement on processing RFC errata for IETF stream https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ . I am only considering guideline 1 and 2 for this errata.

Any suggestion?

//Zahed 

+1.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Jan 2022 09:42:06 +0200

Hi,

> While this is more a clarification than an errata, having it verified would show it in the errata-inline view and as such might actually help future implementors to get this right. So I’m also not…

if readers would benefit from seeing this now (vs. whenever we rev the doc), that would argue for verifying it now.

Thanks,
Lars

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 26 Jan 2022 10:13:18 +0000

> On 25 Jan 2022, at 08:42, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 

This was my thinking as well. I think we should verify it.

//Zahed