Re: UDP source ports for HTTP/3 and QUIC

[Toerless Eckert <[e-mail]>]

On Fri, Jul 16, 2021 at 08:06:44AM +0200, Willy Tarreau wrote:
> > 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.

That would be an example getting more resources on a load-balanced
server farm when you use multiple 5-tuple flows to the same
(cluster) server by reson of client UDP port. 

The same (more/different) resource allocation could also occur for
network bandwidth along the path when there is any type of per-flow
traffic operation, even if heuristically, such as attempts for
bandwidth fairness. Or even alternative paths choosen when there
is 5-tuple load-spliting along the path.

We have been around this block pre-HTTP2.0, using multiple
sockets to increase performance. But any HTTP2.0 fixes did
not change the network or server-farm aspects.

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

This again would be on the network side.

Cheers
    Toerless

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