Client generates CONNECTION_ID_LIMIT_ERROR if ACTIVE_CONNECTION_ID_LIMIT is hit

[martinthomson]

Using the cli, quicly will generate an ACTIVE_CONNECTION_ID_LIMIT transport parameter of 4.

If the server does provide a preferred address, it will only be able to provide sequence numbers 2 and 3 as sequence number 0 (handshake) and 1 (preferred address) are still taken. The client is OK with this.

If a server does not provide a preferred address, but provides NEW_CONNECTION_ID frames with sequence numbers 2, 3, and 4, the client treats this as a connection error of CONNECTION_ID_LIMIT_ERROR. I believe that this is incorrect as the preferred address connection doesn't count toward the limit when it is not provided.

This is probably unique to the client as it has to deal with the odd case of the preferred address transport parameter being absent.

[kazuho]

If a server does not provide a preferred address, but provides NEW_CONNECTION_ID frames with sequence numbers 2, 3, and 4, the client treats this as a connection error of CONNECTION_ID_LIMIT_ERROR. I believe that this is incorrect as the preferred address connection doesn't count toward the limit when it is not provided.

Sounds like we disagree about the interpretation of the spec.

Quoting from RFC 9000 section 5.1.1:

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.

My interpretation of this text is that, unless the server sends preferred_address TP, sequence number of the the first NEW_CONNECTION_ID frame to be sent by the server is 1.

It seems to me that the current text was adopted as part of quicwg/base-drafts#1821, following the discussion at 18-09 Interim. I "think" we adopted quicwg/base-drafts#1484 (comment), but I could well be wrong.

[janaiyengar]

@martinthomson -- my interpretation of the text is the same as @kazuho's. I believe that the text is actually unambiguous on this point, that seq num 1 is only consumed by the SPA if an SPA is sent, and 1 is available otherwise for NEW_CONNECTION_ID frames.

[martinthomson]

OK, that interpretation is easy enough to adopt (I hope), so I'll do that in my implementation.

@kazuho, @janaiyengar, do you think that the text in RFC 9000 is sufficiently clear? I don't think that it is. Should we raise this on the list? An erratum might be necessary.

[kazuho]

I would say that it is more natural to interpret the text that way. There's no point in having that if clause if CID1 was going to be absent when preferred_address TP is omitted.

At the same time, I think it would make sense to consult the list.