Re: Increasing QUIC connection ID size

[Mikkel Fahnøe Jørgensen <[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.

This is true. In some cases you might want a long routing ID in p2p, but
messages are routed inside established connections where each node has only
a few “physical” connections and each message has a large number of
possible targets. Having both a connection ID and a long internal routing
ID, and the auth tag would be a lot to carry for short status messages.

I earlier suggested a possible varlen extension to 64 bits. An alternative
is to have the client always connect with 128-bits and have the server
respond with a connection id of chosen size.

Having a 128-bit client ID that only exists during handshake ought to be
always enough. It could also be used for fast rejection of invalid
connection attempts by placing some hashed knowledge in the ID, which is
deployment specific. Or it could provide priority access during a DoS
scenario.

The server can choose an established connection ID length that is agreeable
with the infrastructure, which could be down to a single byte - which still
allows for single port client usage with little overhead. This is
especially useful on micro-controller deployments where a UDP header might
be skipped. Routers can assume a fixed size connection ID because the
servers will use something the routers can understand.

I am a bit concerned about connection migration because a new path might
need a different kind of connection ID both in size and in encoding. Simply
using the next NEW_CONNECTION_ID might not be optimal because the routers
on the new path might be different.