Re: UDP source ports for HTTP/3 and QUIC

[Willy Tarreau <[e-mail]>]

On Fri, Jul 16, 2021 at 03:40:10AM +0200, Toerless Eckert 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 ? 

That's exactly what I meant by "compatible with UDP", i.e. a datagram
oriented, bidirectional transport protocol. The source port is solely
used to know what socket to deliver the return traffic to.

> > 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.

Sure :-)

> > 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.

Stefan made a good point about the problem that might result, with
inbound load balancing between multiple listeners (typically what's
achieved by L3 switches doing L3+L4 hash between multiple servers,
and operating systems hashing the source+destination port to pick a
different listening socket). Thus a suggestion might be to possibly
save resources by using a small amount of sockets, with "small" left
to the appreciation of the implementation.

> 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.

Sure, but at the application level it does require to check the
connection ID anyway.

> 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.

Yep, at least as a debug option to help with captures or to trace
file descriptors activities.

Willy