Hi Junio, Phillip, Muhammad, Brian, I'm part of the team maintaining MPTCP in the Linux kernel. Do not hesitate to reach me if you have any questions about MPTCP (I don't know if there were still opened questions in this email thread). @Muhammad: thank you for having initiated this email thread. On 20/05/2025 01:49, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> As brian has already said I think it would be better to have a >> Makefile knob to control this which defaults to being on for >> linux. Take a look at the various USE_xxx definitions in the Makefile >> and config.mak.uname for setting default compile flags for different >> operating systems. >> >>> Also another check if a socket is supported by looking for a return >>> value of >>> "EAI_SOCKTYPE" (not EINVAL) and fallback to regular TCP if that is >>> returned. >>> EAI_SOCKTYPE should work across different UNIX systems as this is a >>> posix error code. >> >> That error is not mentioned in the documentation for MCTCP on Linux >> [1]. Please make sure your code checks for the errno values described >> in the documentation. > > Also according to RFC 6897, "MPTCP is designed to be totally > backward compatible to applications". I understand that this is > quite unlike introducing IPv6 into IPv4-only world. You can tell > the system that supports MPTCP to use it in specific ways by > updating your application, but your system's local policy may > allow MPTCP to automatically set up multiple subflows even your > application is not quite aware of MPTCP. > > So, ... I somehow would be mildly surprised if Git were a kind of > application that needs to take advantage of "several additional > degrees of freedom that applications may wish to exploit" by using > API that is "a simple extension of TCP's interface for MPTCP-aware > applications". Requiring a simple application like ours to tweak > and rebuild in today's world does not sound like a winning strategy > to promote a technology that "is designed to be totally backward > compatible to applications", at least to me. @Junio: Good point! This RFC 6897 was a bit optimistic I think. To get MPTCP in the upstream Linux kernel, we had to make it opt-in, and the modifications we suggested couldn't impact "plain" TCP performances (or any other sockets). The previous implementation we were maintaining in a fork was following RFC 6897 guidelines, and there was no need to modify the apps at all, but that was not realistic either. I then agree, this situation is different from the IPv6 vs IPv4 one, and MPTCP in the Linux kernel is using the same socket API as with TCP. It then means that to support MPTCP, all you need to do is to create a socket with a specific argument: IPPROTO_MPTCP instead of IPPROTO_TCP for the protocol, that's it [1], the rest doesn't need to be modified. socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP); Knowing that, it is then possible to change the behaviour of some apps by forcing them to create an MPTCP socket instead of a TCP one, e.g. using LD_PRELOAD, and that's what "mptcpize" does, e.g. mptcpize run git clone git://git.kernel.org/(...) There are other techniques (eBPF, SystemTap, etc.) [2], but it sounds better to have a "native" support by modifying apps to change how socket() is called, this modification should be minimal -- see Muhammad's last WIP patch [4] -- and MPTCP could be used only when needed. That's what many apps are already doing [3]. (Also some sysadmins don't want to use other workarounds.) @Brian, Phillip, Muhammad, I think it is better not to set IPPROTO_MPTCP in arguments passed to getaddrinfo(), but modify what is given to the socket() syscall. Something closed to what Muhammad suggested in his last WIP patch [4]. I guess Muhammad will do a proper submission with good commit messages when the new version will be ready and tested. [1] https://www.mptcp.dev/implementation.html [2] https://www.mptcp.dev/setup.html#force-applications-to-use-mptcp [3] https://www.mptcp.dev/apps.html [4] https://lore.kernel.org/git/ZXLJWS.WPQLCXFNN8TH@xxxxxxxxxxxxxx/ Cheers, Matt -- Sponsored by the NGI0 Core fund.
