Chrome doesn't plan on having multiple connections share a UDP source port. In part because sharing would require the overhead of client connection IDs, but mainly the fact that switching away from the one-port-per-connection model we have today is work towards solving a problem that we don't have.
Back to Mark's original email, I think there's value in writing an RFC to document this behavior - that way clients can have code that requests a different source port from the OS if it initially assigns one that is likely to be blocked by servers. And while modifying NATs is a long game, RFCs do tend to move the needle over time. David On Thu, Jul 15, 2021 at 6:40 AM Nick Banks <nibanks= [email protected]> wrote: > You should definitely not make any assumptions around having unique source > ports for QUIC connections. MsQuic already supports sharing the local port > and is looking to make it a default behavior (for at least some scenarios) > to avoid the fairly common "port exhaustion" problems we see with TCP. This > doesn't necessarily mean all connections would be on the same source port, > but only a few ports might be used for all connections. > > Thanks, > - Nick > > Sent from Outlook <http://aka.ms/weboutlook> > ------------------------------ > *From:* QUIC <[email protected]> on behalf of Töma Gavrichenkov < > [email protected]> > *Sent:* Thursday, July 15, 2021 6:36 AM > *To:* Mikkel Fahnøe Jørgensen <[email protected]> > *Cc:* Mark Nottingham <[email protected]>; IETF QUIC WG <[email protected]>; HTTP > Working Group <[email protected]> > *Subject:* Re: UDP source ports for HTTP/3 and QUIC > > Peace, > > On Thu, Jul 15, 2021, 11:57 AM Mikkel Fahnøe Jørgensen <[email protected]> > wrote: > > As others have pointed out, I would suspect an RFC with a port list would > quickly become outdated. > > > Speaking generally of lists of a content too dynamic and too host-specific > to hardcode in RFCs, there once was a habit of putting them into DNS > records. > > -- > Töma > >
