Re: Increasing QUIC connection ID size

[Marten Seemann <[e-mail]>]

I’m corcerned about the overhead. In the p2p use case, there’s no need for
encoding any routing information into the connection ID, and since every
node just handles a small number of connections, even 4 bytes would be more
than enough to distinguish between connections.
I can see the use case for 128 bit connection IDs, but in order to reduce
the overhead for other applications, we should either do some kind of
negotiation or a varlen encoding.

On Sat 13. Jan 2018 at 09:12, Christian Huitema <[e-mail]> wrote:

> On 1/12/2018 3:06 PM, Jana Iyengar wrote:
> > I'm not entirely convinced of the overhead concern. In the common HTTP
> > case, we expect server->client to not carry CIDs, so this is a NOP in
> > the commonly bandwidth-limited case.
>
> Not just the transmission overhead. You are also increasing the memory
> footprint of the connection context, which stores at least 2 CNX-ID, and
> maybe more if we want to support migration.
>
> But I agree that this is not the end of the world.
>
> Also, following Victor's message, I was doing the maths on the size of
> the ID. 64 bits allows for 24 bits of server ID, 32 bits of client
> nonce, and 8 bits of zero -- for checking. 8 bits check will still let
> 0.4% of forged packets through, which is probably OK since the server
> acts as a backstop. 24 bits would work for 16M servers, which should be
> OK, but assumes that servers have a unique serial ID, which is not
> necessarily OK. Then 32 bits look like they allow 4G connections per
> server, but we start seeing collisions after 65K connections per server,
> which seems not good. So, yes, 64 bits probably will be very tight if we
> want the router to be stateless.
>
> > I do think that this makes CID generation at servers substantially
> > simpler -- you can simply add 1 to the current CID to generate a new
> > one, and encryption makes it unlinkable to the previous one. This is a
> > substantial benefit.
>
> Yes, you can do that without relying on a secure random generator, and
> thus without exposing more of the state of the crypto PRNG. Which is
> nice. Another advantage, if the router can reliably map connection-ID to
> servers, then we don't need to have the same reset secret for every server.
>
> Just one request. If we do make a change, please go for a fixed size.
>
> -- Christian Huitema
>
>
>
>
>
>