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=
40microsoft.com@dmarc.ietf.org> 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 <quic-bounces@ietf.org> on behalf of Töma Gavrichenkov <
> ximaera@gmail.com>
> *Sent:* Thursday, July 15, 2021 6:36 AM
> *To:* Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
> *Cc:* Mark Nottingham <mnot@mnot.net>; IETF QUIC WG <quic@ietf.org>; HTTP
> Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: UDP source ports for HTTP/3 and QUIC
>
> Peace,
>
> On Thu, Jul 15, 2021, 11:57 AM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
> 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
>
>