Re: UDP source ports for HTTP/3 and QUIC

[Toerless Eckert <[e-mail]>]

Inline

On Thu, Jul 15, 2021 at 11:29:37AM +0200, Willy Tarreau wrote:
> On Thu, Jul 15, 2021 at 10:56:28AM +0200, Mikkel Fahnøe Jørgensen wrote:
> > It is perhaps worth noting that due to QUIC (optionally) having unique
> > connection identifiers, it is feasible to have many connections on the same
> > source port. Therefore that could be a recommendation in cases where some
> > source ports might be blocked.
> 
> I think that this is an excellent idea! The simple fact that this is
> being discussed precisely is because the source port serves no purpose
> here other than being compatible with UDP.

Huh ?? The UDP source port serves as the UDP destination port for
return packets. Otherwise how do you redirect the packet to he
right socket ? 

> So basically we could have
> a recommendation that each application preferably uses a single socket
> and source port for outgoing communication. 

Sure, but different UDP source port (socket) for different applications.

> This will also lower the
> stress on source port allocation (and recycling) as well as the need
> for file descriptors.

Yes, especially for systems with many simultaneous connections,
likely servers/responders.

Unless scale is a problem its somewhat hard to say whats better or worse.
Using separate sockets/port-numbers even within a sinle app allows
to distinguish the connections easier with the usual suspsects such
as per-socket kernel diagnostics, network tools such a IPfix or the
like. If i where to implement a stack for clients i'd certainly
wanted to offer the option of whether to allocate separate sockets
(source ports) per connection or not - and see what users do with it.

Toerless

> Willy