W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

Re: UDP source ports for HTTP/3 and QUIC

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 16 Jul 2021 08:06:44 +0200
To: Toerless Eckert <tte@cs.fau.de>
Cc: (wrong string) øe Jørgensen <mikkelfj@gmail.com>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20210716060644.GA3469@1wt.eu>
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.

Received on Friday, 16 July 2021 06:07:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 16 July 2021 06:07:22 UTC