- From: Toerless Eckert <tte@cs.fau.de>
- Date: Fri, 16 Jul 2021 03:40:10 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mikkel Fahnø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>
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
Received on Friday, 16 July 2021 01:40:30 UTC