Re: unique tuples

[Martin Thomson <[e-mail]>]

Yes, with the change to connection IDs, it should be possible to have
multiple connections running concurrently on the same address tuple.  This
is true at any stage of the connection, including the handshake.

Of course, you have to use a connection ID if this is what you want to do.
On Fri, May 4, 2018 at 3:27 PM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> There has been a lot of back and forth on unique tuples in QUIC, and I am
not quite sure where it all landed.

> It is my understanding that at some meeting it was decided to require
unique tuples in V1, if only in certain contexts like handshake for the
sake of simplicity. At the same time, having introduced dual CID’s the need
for unique tuples is greatly reduced along with random initial CID’s that
are reflected in version negotiation and stateless retry.

> Reading through the spec, I can’t find any obvious places where unique
tuples are still required unless a peer volunteer to have a 0-length CID.

> This does matter a lot, because there is a world of difference between
managing a single socket and many concurrent sockets in how you talk to the
OS. QUIC makes it possible to move all the 10K multiplexing problem into
QUIC and out of the OS interface, except for this one detail. Even if it is
only for, say, handshake, it still places a constraint that must be handled.

> It of course also matters wrt. ephemeral port exhaustion although the
argument here is that if you limit it to the duration of handshakes you
should be good. But especially in server p2p with many concurrent
connections between same hosts, this adds complexity.

> So bottom line, do we still have constraints in this area, and are they
really worth keeping? And if so, could this be made more obvious in the
spec? And if not, could it be made explicit that unique tuples are only
required if the CID is 0 - it already almost says so for connection
identification, but this does not exclude certain packet types from having
such a constraint.


> Kind Regards,
> Mikkel Fahnøe Jørgensen