Hello! On Fri, Aug 23, 2024 at 03:34:08PM +0200, Aperence wrote: > Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension > that enables a TCP connection to use different paths. > > Multipath TCP has been used for several use cases. On smartphones, MPTCP > enables seamless handovers between cellular and Wi-Fi networks while > preserving established connections. This use-case is what pushed Apple > to use MPTCP since 2013 in multiple applications [2]. On dual-stack > hosts, Multipath TCP enables the TCP connection to automatically use the > best performing path, either IPv4 or IPv6. If one path fails, MPTCP > automatically uses the other path. > > To benefit from MPTCP, both the client and the server have to support > it. Multipath TCP is a backward-compatible TCP extension that is enabled > by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...). > Multipath TCP is included in the Linux kernel since version 5.6 [3]. To > use it on Linux, an application must explicitly enable it when creating > the socket. No need to change anything else in the application. > > These patches are a continuation of the work [4] realized by Dorian > Craps and Matthieu Baerts.
It's great to see Dorian's work pursued, thank you for this series! I'll comment on each patch separately, 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). With that said, from an implementation perspective, it would seem right to make sure that most TCP tunables also work with MPTCP. Thanks! Willy
