Ben Kaduk's Transport Comment 7

[LPardue]

@kaduk said

Section 5.1.1

An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. Endpoints advertise the number
of active connection IDs they are willing to maintain using the
active_connection_id_limit transport parameter. An endpoint MUST NOT
provide more connection IDs than the peer's limit. [...]

IIUC, the reason that a negotiated limit is needed here is not exactly
for the storage of the connection ID values themselves (though the
requirement to explicitly use RETIRE_CONNECTION_ID makes it not as
simple as it might be), but rather due to the requirement to recognize
the associated stateless reset tokens. Is that correct? If so, perhaps
it could be mentioned as a factor, here.

[martinthomson]

As the recipient of a connection ID, you need to store both. The concern was that tracking these could be onerous. That's all. No need to mention the tokens specially here in my view.

(The original method devised for handling this, which was to throw out any excess without any signaling, could result in starvation.)

Propose no action for this one.

[kaduk]

I don't understand why I, as a recipient of NEW_CONNECTION_ID, need to actually remember the connection ID itself. I am not obligated to ever send packets using that value as a destination connection ID, so what harm comes if I forget it?

[martinthomson]

If you never intend to use another NEW_CONNECTION_ID ever, then sure. But we assume that you might.

[larseggert]

@kaduk is there any further need for clarification?

[MikeBishop]

Remembering is necessary because the peer isn't required to replenish your supply of CIDs. If you forget one without retiring it, the peer might conclude you still have one you could use, you aren't, so clearly you're comfortable continuing to use the CID you've currently got.

It is perfectly legitimate to forget the CID and delay retiring it until you want it replaced, however. That seems like a messy implementation design, however.

[martinthomson]

Another piece that might be missing here is that stateless reset tokens only apply if you use the associated connection ID. Not sure if that helps at all.

Either way, this issue is phrased as a challenge to the design, but I believe the design is OK and this issue does not justify any changes.

[janaiyengar]

I'm not sure how to read this issue. If this is a clarification question, I might be missing it. Either way, I'm not sure there's any action here besides further explanation here.

[kaduk]

Another piece that might be missing here is that stateless reset tokens only apply if you use the associated connection ID. Not sure if that helps at all.

Thanks, that does help me reset my internal model to match reality. I had erroneously expected the reset tokens to be associated with the broader connection and not the specific connection ID (the only thing I can find now to remotely support that misunderstanding is the bit about "associated with the remote address on which the datagram was received", but even that has a matching "datagrams it has recently sent" just a few sentences prior.
I'm sorry that my misunderstanding caused so much effort to be spent, and thanks to everyone for helping me understand.

[janaiyengar]

This can be closed now.

[LPardue]

Closing, thanks all!