Re: Small patch to add support for MPTCP on Linux

From: Matthieu Baerts <matttbe@kernel.org>
Date: May 22, 2025, 11:12 UTC
Message-ID: <79398137-999a-4d88-96d5-86d7184a9101@kernel.org>
In-Reply-To: <xmqqfrgzgctv.fsf@gitster.g>

Hi Junio,

On 21/05/2025 00:02, Junio C Hamano wrote:

Show 9 quoted lines

> Matthieu Baerts <matttbe@kernel.org> writes:
> 
>> Sorry, I was not clear. I meant "introducing MPTCP in the Linux kernel
>> couldn't impact other protocols in terms of memory allocated per socket
>> buffer or performances by adding extra checks a bit everywhere for example".
> 
> Ah, OK.  What you meant is that the networking maintainers did not
> allow you to affect the "normal" codepath when adding MPTCP support
> to their subsystem.

Yes, that's what I meant to say, but you better said it :)

> Which is conservative and probably a good thing, I guess.
> 
> But that choice means each and every application need to opt-in,
> which is cumbersome, inconvenient, and hampers adoption X-<.

Indeed... But it looks like it is often the case with new protocols and extensions...

Show 20 quoted lines

>> listening socket supporting MPTCP on the server side will return a
>> "plain" TCP socket to the userspace during the accept() call. That's why
>> we recommend enabling MPTCP on the server side by default if supported:
>> the impact is minimal, and MPTCP is only used when requested by the
>> clients -- which are usually the ones benefiting more from MPTCP
>> features. That's in fact the current behaviour for apps written in Go:
>> MPTCP is now enabled by default on the server side, and it is easy to
>> enable it on the client side when needed.
> 
> That reminds me about one thing I forgot to ask.
> 
> The git:// protocol is the only one we have control over what to ask
> to the socket() system call and the posted patch was about the
> client side [*].
> 
> On the other end of the connection, even though you could use the
> dedicatd "git daemon" process sitting and listening on a socket, my
> understanding is it is more common to spawn it via inetd(8).  Does
> it mean that the host needs to run inetd with MPTCP enabled?  I do
> not know how common that is.

Good point. Indeed, for the server side, someone should then also look at inetd. I don't know how Muhammad's servers are deployed on his side. From what I see, inetd relies on the /etc/protocols file, which should already contain an entry for "mptcp", at least on Debian-like and Fedora-like distributions. So 'inetd' should already support MPTCP.

@Muhammad: do you mind checking this case please?

Show 8 quoted lines

> 
> Thanks.
> 
> [Footnote]
> 
> * On the public Internet, hopefully nobody is using that protocol
>   anymore, and instead using either https:// or ssh:// that gives
>   better integrity assurances.

Indeed. I already used MPTCP with ssh:// thanks to 'mptcpize', but that looked more like a workaround. For the client side, if an option can be set to ask to use MPTCP, this info should be passed to what is being used for the HTTPS and SSH connections.

@Muhammad: do you plan to look at that too?

For HTTP(S), it looks like the libcurl is used. If yes, then `CURLOPT_OPENSOCKETFUNCTION` can be used, see:

  https://github.com/curl/curl/pull/13278/files

For SSH, I'm a bit annoyed: we already asked OpenSSH maintainers to add MPTCP support by sending small patches, but they didn't want it because it is not officially supported by BSD... It is supported on Linux, macOS, Windows with WSL, etc. but that's not enough apparently :-/ (or maybe anyone here is able to convince them to support MPTCP by merging one of the two patches we already sent them? :-D ). For more details and workarounds:

 https://www.mptcp.dev/faq.html#how-to-enable-mptcp-support-with-openssh

Hopefully we will find a way to support MPTCP here in git (and SSH) :)

Cheers, Matt

-- 
Sponsored by the NGI0 Core fund.