Hi Willy, Thank you for your quick reply!
On 23/08/2024 15:58, Willy Tarreau wrote: > On Fri, Aug 23, 2024 at 03:34:08PM +0200, Aperence wrote: (...) > I'll comment on each patch separately, Thank you, please take your time! > though I'll respond to the > question below: > >> - Patch 2: >> - Fix a warning about TCP_MAXSEG not being supported while MPTCP is >> used by declaring new constants sock_inet(6)_mptcp_maxseg_default. >> Those constants represent the MSS supported by MPTCP (== -1 for the >> moment, as long as TCP_MAXSEG is not supported). For the moment, >> MPTCP doesn't support TCP_MAXSEG socket option, mainly because it >> has apparently never been requested before, apparently. It should >> not be difficult to implement it, but is it an important option >> for HAProxy? > > It's not that common anymore but 15 years ago when ADSL over PPPoE was > everywhere, it was super frequent to see users not able to upload large > POST data over TCP because their PC connected with a 1500 MTU to their > PPPoE modem/router was seeing its packets rejected due to the extra 8 > bytes of PPPoE encapsulation. Many people had by then implemented the > set-mss rule in iptables on the server infrastructure to deal with this, > but high-bandwidth hosting providers couldn't even just place a firewall > in front of haproxy just to deal with that, so in this case it was very > convenient to permit haproxy to simply configure the socket to negotiate > a lower MSS compatible with everyone's setup. > > Nowadays with everyone having a triple-play box provided by the ISP, > all this stuff is transparent to the user (when needed at all). However > I've been aware of users doing that as well to fixup trouble caused by > inter-company VPN links. You know, the type of places where everyone > says "it's right on my side, it must be the other side"... > > So I guess that nowadays the mss setting mostly serves to fixup VPN > environments, and it's not much likely that we'll see that with MPTCP > soon I think (but I could of course be wrong). Many thanks for this explanation! I just filled a new ticket on MPTCP side, not to forget about that: https://github.com/multipath-tcp/mptcp_net-next/issues/515 > With that said, from an implementation perspective, it would seem right > to make sure that most TCP tunables also work with MPTCP. That's what we tried to do. All "common" ones are supported, but it is not always easy to define what is "common" and what is not! There are many obscure/specific socket options out there :) Cheers, Matt -- Sponsored by the NGI0 Core fund.
