Re: [quicwg/base-drafts] The number of Connection ID is unbounded to NEW_CONNECTION_ID sender (#2403)

[Kazuho Oku <[e-mail]>]

@tatsuhiro-t 
> The problem of current wording is that server MUST send NEW_CONNECTION_ID when it sees unused connection ID.

Isn't it a SHOULD?

I ask this, because I see the following text in [section 5.1.1 of the transport draft](
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.1.1): _An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs. While each endpoint independently chooses how many connection IDs to issue, endpoints SHOULD provide and maintain at least eight connection IDs._

Having that said, I think I agree that we have an issue.

The minimum length of CID is 32 bits, based on the assumption that the space is capable of supporting multiple connections across certain time-space (remember the fact that CID cannot be reused more frequently than updating the secret used to calculate stateless reset tokens). OTOH, we do not prohibit (or discourage) endpoints from updating the CID aggressively.

For example, an endpoint might try to use a new CID whenever one is available in order to achieve "maximum privacy." That would mean that it would consume ~8 CIDs per round-trip, and in case the RTT is 10ms, it would be consuming around 2<sup>16</sup> CIDs every minute.

I do not think we would like to see clients being such aggressive against a server that tries to use minimally-size CIDs.

Therefore, I think we should discourage endpoints from changing CIDs when it is likely that it's tuple is stable.

-- 
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/2403#issuecomment-460255684