[quicwg/base-drafts] endpoints don't know how many connection IDs the peer is willing to store (#1994)

[Marten Seemann <[e-mail]>]

As discussed on the list and in #1992, the fact that endpoints don't know how many connection IDs the peer is willing to store, leads to some undesirable consequences, which I described in https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561:

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.

I'm preparing a PR to introduce a transport parameter, which will allow an endpoint to declare how many connection IDs it is willing to receive. It's late in Thailand already, so please give me until tomorrow this time to finalize the text for that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1994