Re: UDP source ports for HTTP/3 and QUIC

[David Schinazi <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]> on behalf of Töma Gavrichenkov <
> [e-mail]>
> *Sent:* Thursday, July 15, 2021 6:36 AM
> *To:* Mikkel Fahnøe Jørgensen <[e-mail]>
> *Cc:* Mark Nottingham <[e-mail]>; IETF QUIC WG <[e-mail]>; HTTP
> Working Group <[e-mail]>
> *Subject:* Re: UDP source ports for HTTP/3 and QUIC
>
> Peace,
>
> On Thu, Jul 15, 2021, 11:57 AM Mikkel Fahnøe Jørgensen <[e-mail]>
> 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
>
>