Endpoint MAY discard CIDs

[janaiyengar]

An endpoint should not assume that its peer will not drop any received CIDs.

[mikkelfj]

I think this is messy - I know there have been lengthy discussions. But sender also may have to track state. It would be better to have a fixed TP length of say, 5 CID's and only replenish when one is retired.

[marten-seemann]

Issuing too many connection IDs doesn't hurt in the case where the server uses a deterministic routing scheme to associate connection IDs to connections (except for the obviously wasted bandwidth). However, there's a different approach (which I chose in my implementation). I'm keeping a mapping connection ID => connection around for every single connection ID I issue. This allows me to use very short (4 bytes) connection IDs. If an implementation like this issues too many connection IDs, and the peer starts dropping them, it will have to keep state for every dropped connection ID until the end of the connection.

This is trivially solved if each peer declares the number of connection IDs it is willing to store in a transport parameter. Based on @dtikhonov's thread on the mailing list, I was planning to contribute a PR for this.

[mikkelfj]

If I understand @marten-seemann correctly, this is in line with what I propose, and which others have proposed earlier.

[janaiyengar]

@marten-seemann @mikkelfj : Like I said on list, I think it's fine to drive that issue (please do file an issue first), and send a PR along (ASAP). I'm merely clarifying existing text.

[ianswett]

Belated question: when you discard them, it seems you should not send a RETIRE_CONNECTION_ID frame, otherwise you may just get more?

[MikeBishop]

The idea is that you can have an uncoordinated negotiation: I'm willing to issue 64, you only need 8. You take the 8 you want, let the remaining 56 fall on the floor, and then I'll replace the 8 you kept as you RETIRE them. If you RETIREd the 56 you didn't need, I'd replace those, and we'd get into an endless RETIRE/NEW drop for no purpose.