Small patch to add support for MPTCP on Linux

Small patch to add support for MPTCP on Linux

[Muhammad Nuzaihan]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]


Patch to enable the use of MPTCP on Linux (when available)

IPPROTO_MPTCP v1 (not the old v0) has been improved to go about the
limitations of middleboxes.

MPTCP protocol is an extension of vanilla TCP which enables multiple
IP to aggregate bandwidth at layer 4 of the OSI stack across
as said IP(s).

Similar to link aggregation which works at layer 2. MPTCP works on top
of IP layer.

Other than aggregating bandwidth, MPTCP also allows seamless failover
when one network path (not just link) is down (or having high latency)
by reinjecting the packets to a path that is available.

This patch enables IPPROTO_MPTCP if IPPROTO_MPTCP is available and
uses plain TCP if the Linux system does not support it.

Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin 
<zaihan@unrealasia.net>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-mptcp.diff --]
[-- Type: text/x-patch, Size: 522 bytes --]

diff --git a/connect.c b/connect.c
index 3280435331..8473f0b02e 100644
--- a/connect.c
+++ b/connect.c
@@ -827,8 +827,11 @@ static int git_tcp_connect_sock(char *host, int flags)
 	else if (flags & CONNECT_IPV6)
 		hints.ai_family = AF_INET6;
 	hints.ai_socktype = SOCK_STREAM;
-	hints.ai_protocol = IPPROTO_TCP;
-
+#ifdef IPPROTO_MPTCP
+        hints.ai_protocol = IPPROTO_MPTCP;
+#else
+        hints.ai_protocol = IPPROTO_TCP;
+#endif
 	if (flags & CONNECT_VERBOSE)
 		fprintf(stderr, _("Looking up %s ... "), host);
 

Re: Small patch to add support for MPTCP on Linux

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]

On 2025-05-16 at 17:56:07, Muhammad Nuzaihan wrote:
> 
> Patch to enable the use of MPTCP on Linux (when available)
> 
> IPPROTO_MPTCP v1 (not the old v0) has been improved to go about the
> limitations of middleboxes.
> 
> MPTCP protocol is an extension of vanilla TCP which enables multiple
> IP to aggregate bandwidth at layer 4 of the OSI stack across
> as said IP(s).
> 
> Similar to link aggregation which works at layer 2. MPTCP works on top
> of IP layer.
> 
> Other than aggregating bandwidth, MPTCP also allows seamless failover
> when one network path (not just link) is down (or having high latency)
> by reinjecting the packets to a path that is available.
> 
> This patch enables IPPROTO_MPTCP if IPPROTO_MPTCP is available and
> uses plain TCP if the Linux system does not support it.

What happens here if I compile this on a system that has a kernel that
supports MPTCP but then switch to one that does not?  The reason I ask
is that I have worked at places where we shipped binaries, including
Git, based on a standard CentOS or RHEL system, but then some people
used our software on a system with a very stripped down kernel (in some
cases, where IPv6 was not even compiled in) because doing so meant that
they could make about $5 more per server per month.

Do the operating systems which support MPTCP make it a compulsory part
of the TCP stack, or could we end up with cases where we're unable to
connect here?

In addition, Wikipedia mentions that FreeBSD has only IPv4 support, but
I don't know if that's up to date.  What happens if we run on a system
where MPTCP is used, but it doesn't work with IPv6 and the only remote
IP is IPv6?  Do we fall back properly, or do things fail?

I ask these questions not because I'm opposed to this feature but
because I want to be sure we don't accidentally break things for users.
I know that for instance Go 1.24 enabled MPTCP and that ended up causing
problems in some environments, so I would recommend that we make this a
configurable option instead.  We can definitely default to MPTCP, but we
probably need an option to fall back.

Of course, this code path is only used by the unauthenticated Git
protocol usually run on port 9418, which practically nobody uses anymore
(because it lacks the privacy, integrity, and authentication which are
necessary and prudent on the modern Internet), so maybe nobody cares
about edge cases there.  My guess, though, is that the people most
likely to be using something that isn't HTTPS or SSH are also the people
most likely to be using odd or unusual configurations, so we may very
well want to add an option for them.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: Small patch to add support for MPTCP on Linux

[Muhammad Nuzaihan]

Hi Brian.

On Fri, May 16 2025 at 08:33:03 PM +0000, brian m. carlson 
<sandals@crustytoothpaste.net> wrote:
> On 2025-05-16 at 17:56:07, Muhammad Nuzaihan wrote:
>> 
>>  Patch to enable the use of MPTCP on Linux (when available)
>> 
>>  IPPROTO_MPTCP v1 (not the old v0) has been improved to go about the
>>  limitations of middleboxes.
>> 
>>  MPTCP protocol is an extension of vanilla TCP which enables multiple
>>  IP to aggregate bandwidth at layer 4 of the OSI stack across
>>  as said IP(s).
>> 
>>  Similar to link aggregation which works at layer 2. MPTCP works on 
>> top
>>  of IP layer.
>> 
>>  Other than aggregating bandwidth, MPTCP also allows seamless 
>> failover
>>  when one network path (not just link) is down (or having high 
>> latency)
>>  by reinjecting the packets to a path that is available.
>> 
>>  This patch enables IPPROTO_MPTCP if IPPROTO_MPTCP is available and
>>  uses plain TCP if the Linux system does not support it.
> 
> What happens here if I compile this on a system that has a kernel that
> supports MPTCP but then switch to one that does not?  The reason I ask
> is that I have worked at places where we shipped binaries, including
> Git, based on a standard CentOS or RHEL system, but then some people
> used our software on a system with a very stripped down kernel (in 
> some
> cases, where IPv6 was not even compiled in) because doing so meant 
> that
> they could make about $5 more per server per month.
> 
MPTCP supports *both* IPv4 and IPv6. Don't tell me people would also 
remove
even IPv4 as well? I had written an #ifdef statement to check if 
IPPROTO_MPTCP
exists and enables that.


> Do the operating systems which support MPTCP make it a compulsory part
> of the TCP stack, or could we end up with cases where we're unable to
> connect here?
> 
> In addition, Wikipedia mentions that FreeBSD has only IPv4 support, 
> but
> I don't know if that's up to date.  What happens if we run on a system
> where MPTCP is used, but it doesn't work with IPv6 and the only remote
> IP is IPv6?  Do we fall back properly, or do things fail?

This patch *specifically* targets Linux to check if IPPROTO_MPTCP exists
in the Linux system. I think you have not read my initial patch 
description
properly nor even read about the new changes for MPTCP.

MPTCP support is now officially in the mainline kernel and not 
out-of-tree.

This *current* implementation of MPTCP is v1 and not v0 (v0 had 
problems and
v1 already solved the issue with middleboxes. again, please read my 
patch
description properly)

Please read up on how MPTCP falls back to regular TCP if it could not 
connect
using MPTCP.
> 
> I ask these questions not because I'm opposed to this feature but
> because I want to be sure we don't accidentally break things for 
> users.
> 
I'm not sure but you have not even bothered to read the documentation 
about MPTCP.
> I know that for instance Go 1.24 enabled MPTCP and that ended up 
> causing
> problems in some environments, so I would recommend that we make this 
> a
> configurable option instead.  We can definitely default to MPTCP, but 
> we
> probably need an option to fall back.
MPTCP v1 (again i am repeating myself) and not the old MPTCP v0 does 
the fallback
more effectively.

Do you know of any references that mentions that Go 1.24 with MPTCP 
enabled
(normally this is the current MPTCP v1) is causing the issues?

If you could give me evidences of such issues, maybe i can reconsider 
it again.
> 
> Of course, this code path is only used by the unauthenticated Git
> protocol usually run on port 9418, which practically nobody uses 
> anymore
> (because it lacks the privacy, integrity, and authentication which are
> necessary and prudent on the modern Internet), so maybe nobody cares
> about edge cases there.  My guess, though, is that the people most
> likely to be using something that isn't HTTPS or SSH are also the 
> people
> most likely to be using odd or unusual configurations, so we may very
> well want to add an option for them.

Again, the unauthenticated Git protocol is the *most basic* setup that 
anyone
can use to test MPTCP out. I understand from your point of view but it 
does
not make sense to support ssh and http when the most basic git protocol 
is
not supported.

git protocol is the *most basic* protocol. For ssh and https that would 
fall
under other project's implementing (like openssh or apache)

I would consider adding an option to read from .gitconfig to enable 
MPTCP
where i can leave MPTCP disabled by default.

But what you explained about the downsides of MPTCP (without evidences)
and not even implementing MPTCP for git protocol does not make sense.

Regards,
Zaihan
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA

Re: Small patch to add support for MPTCP on Linux

[Muhammad Nuzaihan]

[-- Attachment #1: Type: text/plain, Size: 6240 bytes --]

Hi all,

I've made the git daemon to work (for the git protocol), as attached
in the wireshark screenshot.
As i had mentioned that the most basic implementation of the protocol 
should be
the basic git protocol to test the implementation and not git over ssh 
or git over http.


Unless if everyone wants to deprecate the git protocol entirely then it
might be a different issue.

But i think there need to be a discussion as i have mentioned this 
thread
about the concerns being raised by others.

Thanks,
Zaihan

On Sat, May 17 2025 at 10:21:00 AM +0300, Hridoy Ahmed 
<ariyanhridoy130@gmail.com> wrote:
> 
> 
> On Sat, 17 May 2025 at 10:20 AM Muhammad Nuzaihan 
> <zaihan@unrealasia.net> wrote:
>> Hi Brian.
>> 
>>  On Fri, May 16 2025 at 08:33:03 PM +0000, brian m. carlson
>>  <sandals@crustytoothpaste.net> wrote:
>>  > On 2025-05-16 at 17:56:07, Muhammad Nuzaihan wrote:
>>  >>
>>  >>  Patch to enable the use of MPTCP on Linux (when available)
>>  >>
>>  >>  IPPROTO_MPTCP v1 (not the old v0) has been improved to go about 
>> the
>>  >>  limitations of middleboxes.
>>  >>
>>  >>  MPTCP protocol is an extension of vanilla TCP which enables 
>> multiple
>>  >>  IP to aggregate bandwidth at layer 4 of the OSI stack across
>>  >>  as said IP(s).
>>  >>
>>  >>  Similar to link aggregation which works at layer 2. MPTCP works 
>> on
>>  >> top
>>  >>  of IP layer.
>>  >>
>>  >>  Other than aggregating bandwidth, MPTCP also allows seamless
>>  >> failover
>>  >>  when one network path (not just link) is down (or having high
>>  >> latency)
>>  >>  by reinjecting the packets to a path that is available.
>>  >>
>>  >>  This patch enables IPPROTO_MPTCP if IPPROTO_MPTCP is available 
>> and
>>  >>  uses plain TCP if the Linux system does not support it.
>>  >
>>  > What happens here if I compile this on a system that has a kernel 
>> that
>>  > supports MPTCP but then switch to one that does not?  The reason 
>> I ask
>>  > is that I have worked at places where we shipped binaries, 
>> including
>>  > Git, based on a standard CentOS or RHEL system, but then some 
>> people
>>  > used our software on a system with a very stripped down kernel (in
>>  > some
>>  > cases, where IPv6 was not even compiled in) because doing so meant
>>  > that
>>  > they could make about $5 more per server per month.
>>  >
>>  MPTCP supports *both* IPv4 and IPv6. Don't tell me people would also
>>  remove
>>  even IPv4 as well? I had written an #ifdef statement to check if
>>  IPPROTO_MPTCP
>>  exists and enables that.
>> 
>> 
>>  > Do the operating systems which support MPTCP make it a compulsory 
>> part
>>  > of the TCP stack, or could we end up with cases where we're 
>> unable to
>>  > connect here?
>>  >
>>  > In addition, Wikipedia mentions that FreeBSD has only IPv4 
>> support,
>>  > but
>>  > I don't know if that's up to date.  What happens if we run on a 
>> system
>>  > where MPTCP is used, but it doesn't work with IPv6 and the only 
>> remote
>>  > IP is IPv6?  Do we fall back properly, or do things fail?
>> 
>>  This patch *specifically* targets Linux to check if IPPROTO_MPTCP 
>> exists
>>  in the Linux system. I think you have not read my initial patch
>>  description
>>  properly nor even read about the new changes for MPTCP.
>> 
>>  MPTCP support is now officially in the mainline kernel and not
>>  out-of-tree.
>> 
>>  This *current* implementation of MPTCP is v1 and not v0 (v0 had
>>  problems and
>>  v1 already solved the issue with middleboxes. again, please read my
>>  patch
>>  description properly)
>> 
>>  Please read up on how MPTCP falls back to regular TCP if it could 
>> not
>>  connect
>>  using MPTCP.
>>  >
>>  > I ask these questions not because I'm opposed to this feature but
>>  > because I want to be sure we don't accidentally break things for
>>  > users.
>>  >
>>  I'm not sure but you have not even bothered to read the 
>> documentation
>>  about MPTCP.
>>  > I know that for instance Go 1.24 enabled MPTCP and that ended up
>>  > causing
>>  > problems in some environments, so I would recommend that we make 
>> this
>>  > a
>>  > configurable option instead.  We can definitely default to MPTCP, 
>> but
>>  > we
>>  > probably need an option to fall back.
>>  MPTCP v1 (again i am repeating myself) and not the old MPTCP v0 does
>>  the fallback
>>  more effectively.
>> 
>>  Do you know of any references that mentions that Go 1.24 with MPTCP
>>  enabled
>>  (normally this is the current MPTCP v1) is causing the issues?
>> 
>>  If you could give me evidences of such issues, maybe i can 
>> reconsider
>>  it again.
>>  >
>>  > Of course, this code path is only used by the unauthenticated Git
>>  > protocol usually run on port 9418, which practically nobody uses
>>  > anymore
>>  > (because it lacks the privacy, integrity, and authentication 
>> which are
>>  > necessary and prudent on the modern Internet), so maybe nobody 
>> cares
>>  > about edge cases there.  My guess, though, is that the people most
>>  > likely to be using something that isn't HTTPS or SSH are also the
>>  > people
>>  > most likely to be using odd or unusual configurations, so we may 
>> very
>>  > well want to add an option for them.
>> 
>>  Again, the unauthenticated Git protocol is the *most basic* setup 
>> that
>>  anyone
>>  can use to test MPTCP out. I understand from your point of view but 
>> it
>>  does
>>  not make sense to support ssh and http when the most basic git 
>> protocol
>>  is
>>  not supported.
>> 
>>  git protocol is the *most basic* protocol. For ssh and https that 
>> would
>>  fall
>>  under other project's implementing (like openssh or apache)
>> 
>>  I would consider adding an option to read from .gitconfig to enable
>>  MPTCP
>>  where i can leave MPTCP disabled by default.
>> 
>>  But what you explained about the downsides of MPTCP (without 
>> evidences)
>>  and not even implementing MPTCP for git protocol does not make 
>> sense.
>> 
>>  Regards,
>>  Zaihan
>>  > --
>>  > brian m. carlson (they/them)
>>  > Toronto, Ontario, CA
>> 
>> 
>> 


[-- Attachment #2: Screenshot from 2025-05-17 16-40-40.png --]
[-- Type: image/png, Size: 460350 bytes --]

Re: Small patch to add support for MPTCP on Linux

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 5350 bytes --]

On 2025-05-17 at 07:19:59, Muhammad Nuzaihan wrote:
> Hi Brian.
> 
> On Fri, May 16 2025 at 08:33:03 PM +0000, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > What happens here if I compile this on a system that has a kernel that
> > supports MPTCP but then switch to one that does not?  The reason I ask
> > is that I have worked at places where we shipped binaries, including
> > Git, based on a standard CentOS or RHEL system, but then some people
> > used our software on a system with a very stripped down kernel (in some
> > cases, where IPv6 was not even compiled in) because doing so meant that
> > they could make about $5 more per server per month.
> > 
> MPTCP supports *both* IPv4 and IPv6. Don't tell me people would also remove
> even IPv4 as well? I had written an #ifdef statement to check if
> IPPROTO_MPTCP
> exists and enables that.

I provide this as an example of people compiling even "essential"
features out of their kernel.  The question remains: if I compile on,
say, Debian, which has this, and then I switch to the same version of
Debian, but with a custom kernel that removes MPTCP from the kernel
completely, does this change continue to work, or do we end up with an
EINVAL from the `socket` call?

I want to point out that the kernel and libc headers used to compile a
binary need not reflect the actual code in the running kernel.  With the
advent of containers, people frequently run a different operating system
inside a container than they do outside a container and thus we need to
consider all of the possible combinations.

> > Do the operating systems which support MPTCP make it a compulsory part
> > of the TCP stack, or could we end up with cases where we're unable to
> > connect here?
> > 
> > In addition, Wikipedia mentions that FreeBSD has only IPv4 support, but
> > I don't know if that's up to date.  What happens if we run on a system
> > where MPTCP is used, but it doesn't work with IPv6 and the only remote
> > IP is IPv6?  Do we fall back properly, or do things fail?
> 
> This patch *specifically* targets Linux to check if IPPROTO_MPTCP exists
> in the Linux system. I think you have not read my initial patch description
> properly nor even read about the new changes for MPTCP.

Git runs on lots of operating systems, not just Linux.  If the case is
that the `IPPROTO_MPTCP` #define is only ever available on Linux and no
other operating system ever ships that option or ever will, then that's
fine, but the commit message needs to say that.  I know that many
operating systems ship MPTCP, so I'm going to ask about how this works
on some non-Linux systems because your commit message didn't explain
that to me.

> Please read up on how MPTCP falls back to regular TCP if it could not
> connect using MPTCP.

Again, your patch tells me how things work on Linux.  I am interested in
patches that work across a variety of other operating systems as well.

> > I ask these questions not because I'm opposed to this feature but
> > because I want to be sure we don't accidentally break things for users.
> > 
> I'm not sure but you have not even bothered to read the documentation about
> MPTCP.

On the Git list, we try not to assume that everyone has read all of the
technical documentation about a subject and instead we explain, at a
high level, how the change is and how it's supposed to work.  Your
commit message should convince me (and everyone else, especially Junio,
the maintainer) that your change is valuable and should be applied.

> > I know that for instance Go 1.24 enabled MPTCP and that ended up causing
> > problems in some environments, so I would recommend that we make this a
> > configurable option instead.  We can definitely default to MPTCP, but we
> > probably need an option to fall back.
> MPTCP v1 (again i am repeating myself) and not the old MPTCP v0 does the
> fallback
> more effectively.
> 
> Do you know of any references that mentions that Go 1.24 with MPTCP enabled
> (normally this is the current MPTCP v1) is causing the issues?

I know that there were circumstances in which there could be kernel
panics or similar problems with it enabled[0].  I haven't heard of
actual network problems, though.  Since most people were previously not
using MPTCP and Go 1.24 enabled it by default, upgrading to that version
caused some people's systems to panic under load.

I do think that enabling features that cause Git to induce a kernel
panic or the like, even though that's a bug in the kernel, should be
configurable.

> But what you explained about the downsides of MPTCP (without evidences)
> and not even implementing MPTCP for git protocol does not make sense.

I'm not arguing any downsides of MPTCP.  I'm stating that we have a
large variety of platforms that have to be supported and you haven't
explained how this works or will work anywhere other than Linux; that
there are people who compile out important features from their kernel
and, though that is improvident, we should probably not break Git for
them; and that we should be careful about enabling features which have
been known to cause system problems.

[0] https://www.wiz.io/vulnerability-database/cve/cve-2022-49198
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: Small patch to add support for MPTCP on Linux

[Muhammad Nuzaihan]

On Sat, May 17 2025 at 10:15:33 AM +0000, brian m. carlson 
<sandals@crustytoothpaste.net> wrote:
> On 2025-05-17 at 07:19:59, Muhammad Nuzaihan wrote:
>>  Hi Brian.
>> 
>>  On Fri, May 16 2025 at 08:33:03 PM +0000, brian m. carlson
>>  <sandals@crustytoothpaste.net> wrote:
>>  > What happens here if I compile this on a system that has a kernel 
>> that
>>  > supports MPTCP but then switch to one that does not?  The reason 
>> I ask
>>  > is that I have worked at places where we shipped binaries, 
>> including
>>  > Git, based on a standard CentOS or RHEL system, but then some 
>> people
>>  > used our software on a system with a very stripped down kernel 
>> (in some
>>  > cases, where IPv6 was not even compiled in) because doing so 
>> meant that
>>  > they could make about $5 more per server per month.
>>  >
>>  MPTCP supports *both* IPv4 and IPv6. Don't tell me people would 
>> also remove
>>  even IPv4 as well? I had written an #ifdef statement to check if
>>  IPPROTO_MPTCP
>>  exists and enables that.
> 
> I provide this as an example of people compiling even "essential"
> features out of their kernel.  The question remains: if I compile on,
> say, Debian, which has this, and then I switch to the same version of
> Debian, but with a custom kernel that removes MPTCP from the kernel
> completely, does this change continue to work, or do we end up with an
> EINVAL from the `socket` call?
> 
> I want to point out that the kernel and libc headers used to compile a
> binary need not reflect the actual code in the running kernel.  With 
> the
> advent of containers, people frequently run a different operating 
> system
> inside a container than they do outside a container and thus we need 
> to
> consider all of the possible combinations.

In that case, i'll add a check for the OS that git is built on with 
"defined(__linux__)"
if that helps.

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.

MPTCP has been in development for the last 15 years and the major 
change/overhaul (MPTCP v1)
occured in 2020 and now is accepted in Linux mainline kernel.

I am working on this git code change as i have large git repositories 
with about 50 gigabytes
of code and i have multiple WAN links which i can aggregate bandwidth 
across and even
when one path (even in between my CPE router to internet) is down, i 
will not
get interrupted.

Also i am using a Linux laptop that has WiFi and 5G module. So this kind
of adds my drive of adding support for git (on Linux)

MPTCP helps in situations when one of my WAN links have a high latency 
and
automatically choose a link with a path with less latency.

MPTCP aggregates the MPTCP connection by using subflows where two or 
more
links can be utilised with subflows. A single flow of data can have 
multiple
subflows across different IP interfaces and thus increases network
throughput.

Apple for example had been using MPTCP for their cloud services since 
MPTCP v0 which had
issues (not MPTCP v1) since 2013.

Compared to MultiPath QUIC which is still years away from being 
implemented.

The main issue back then with MPTCP v0 was middleboxes such as 
firewalls and NAT gateways
that discards TCP options header which is crucial when using MPTCP.

> 
>>  > Do the operating systems which support MPTCP make it a compulsory 
>> part
>>  > of the TCP stack, or could we end up with cases where we're 
>> unable to
>>  > connect here?
>>  >
>>  > In addition, Wikipedia mentions that FreeBSD has only IPv4 
>> support, but
>>  > I don't know if that's up to date.  What happens if we run on a 
>> system
>>  > where MPTCP is used, but it doesn't work with IPv6 and the only 
>> remote
>>  > IP is IPv6?  Do we fall back properly, or do things fail?
>> 
>>  This patch *specifically* targets Linux to check if IPPROTO_MPTCP 
>> exists
>>  in the Linux system. I think you have not read my initial patch 
>> description
>>  properly nor even read about the new changes for MPTCP.
> 
> Git runs on lots of operating systems, not just Linux.  If the case is
> that the `IPPROTO_MPTCP` #define is only ever available on Linux and 
> no
> other operating system ever ships that option or ever will, then 
> that's
> fine, but the commit message needs to say that.  I know that many
> operating systems ship MPTCP, so I'm going to ask about how this works
> on some non-Linux systems because your commit message didn't explain
> that to me.
> 
>>  Please read up on how MPTCP falls back to regular TCP if it could 
>> not
>>  connect using MPTCP.
> 
> Again, your patch tells me how things work on Linux.  I am interested 
> in
> patches that work across a variety of other operating systems as well.

My main focus is Linux so i will add a check if it's built on a Linux 
machine.

macOS would be a later focus but it's not a priority for now. I would 
avoid
adding MPTCP on other systems such as FreeBSD as their implementation
for example is still considered experimental.
> 
>>  > I ask these questions not because I'm opposed to this feature but
>>  > because I want to be sure we don't accidentally break things for 
>> users.
>>  >
>>  I'm not sure but you have not even bothered to read the 
>> documentation about
>>  MPTCP.
> 
> On the Git list, we try not to assume that everyone has read all of 
> the
> technical documentation about a subject and instead we explain, at a
> high level, how the change is and how it's supposed to work.  Your
> commit message should convince me (and everyone else, especially 
> Junio,
> the maintainer) that your change is valuable and should be applied.

It's just a small trival amount of code but anyway.

I will email my latest patch in a separate email.

In my latest code i added checks for the OS it's built on 
defined(__linux__) and if IPPROTO_MPTCP is
defined. Additional checks for error if EAI_SOCKTYPE is returned, it 
will revert to
regular IPPROTO_TCP (regular TCP)
> 
>>  > I know that for instance Go 1.24 enabled MPTCP and that ended up 
>> causing
>>  > problems in some environments, so I would recommend that we make 
>> this a
>>  > configurable option instead.  We can definitely default to MPTCP, 
>> but we
>>  > probably need an option to fall back.
>>  MPTCP v1 (again i am repeating myself) and not the old MPTCP v0 
>> does the
>>  fallback
>>  more effectively.
>> 
>>  Do you know of any references that mentions that Go 1.24 with MPTCP 
>> enabled
>>  (normally this is the current MPTCP v1) is causing the issues?
> 
> I know that there were circumstances in which there could be kernel
> panics or similar problems with it enabled[0].  I haven't heard of
> actual network problems, though.  Since most people were previously 
> not
> using MPTCP and Go 1.24 enabled it by default, upgrading to that 
> version
> caused some people's systems to panic under load.
> 
My initial patch deals with *client* side of git. Not the *server* end 
of git (like daemon.c).

The crash that was reported was about the network pressure of the 
software that
runs as on a *server*.

But nevertheless it might still impact the client although the CVE does 
not state
that.

Look, i'm really under an impression you didn't look at the patch that 
says the code
change is in "connect.c" and not "daemon.c". If you look closer it does 
not have to do
with server side of things.
> 
> I do think that enabling features that cause Git to induce a kernel
> panic or the like, even though that's a bug in the kernel, should be
> configurable.
I've also added a flag for the git-daemon (git daemon.c code is a new 
code).

the flag would be `--mptcp` which can be enabled on the git-daemon 
server
side.

Example: ./git-daemon --reuseaddr --base-path=/all/repos/here 
--export-all --mptcp
> 
>>  But what you explained about the downsides of MPTCP (without 
>> evidences)
>>  and not even implementing MPTCP for git protocol does not make 
>> sense.
> 
> I'm not arguing any downsides of MPTCP.  I'm stating that we have a
> large variety of platforms that have to be supported and you haven't
> explained how this works or will work anywhere other than Linux; that
> there are people who compile out important features from their kernel
> and, though that is improvident, we should probably not break Git for
> them; and that we should be careful about enabling features which have
> been known to cause system problems.

Got it. I'll be more informed the next time. Anyway, i'll pass some 
links
that you might be interested.

https://www.mptcp.dev/faq.html#mptcpv0-vs-mptcpv1
https://www.mptcp.dev/faq.html#what-about-middleboxes

> 
> [0] https://www.wiz.io/vulnerability-database/cve/cve-2022-49198
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA

Re: Small patch to add support for MPTCP on Linux

[Phillip Wood]

On 17/05/2025 14:10, Muhammad Nuzaihan wrote:
>> I want to point out that the kernel and libc headers used to compile a
>> binary need not reflect the actual code in the running kernel.  With the
>> advent of containers, people frequently run a different operating system
>> inside a container than they do outside a container and thus we need to
>> consider all of the possible combinations.
> 
> In that case, i'll add a check for the OS that git is built on with 
> "defined(__linux__)"
> if that helps.

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.

>> On the Git list, we try not to assume that everyone has read all of the
>> technical documentation about a subject and instead we explain, at a
>> high level, how the change is and how it's supposed to work.  Your
>> commit message should convince me (and everyone else, especially Junio,
>> the maintainer) that your change is valuable and should be applied.
> 
> It's just a small trival amount of code but anyway.
That maybe so but please make sure that the commit message explains the 
reason for this change - what the advantages and disadvantages of using 
MPTCP are and what steps you have taken to make sure git continues to 
work on systems that do not support MPTCP.

Thanks

Phillip

[1] 
https://www.kernel.org/doc/html/next/networking/mptcp.html#creating-mptcp-sockets

Re: Small patch to add support for MPTCP on Linux

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> 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.

Re: Small patch to add support for MPTCP on Linux

[Muhammad Nuzaihan]

[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]



On Mon, May 19 2025 at 04:49:00 PM -0700, Junio C Hamano 
<gitster@pobox.com> wrote:
> Phillip Wood <phillip.wood123@gmail.com> 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.
> 
Taking into scenario that i have WiFi access and regular Ethernet access
on my Laptop and i'm cloning or pulling a large set of code from git 
(which uses
regular ethernet as primary interface and WiFi as secondary.)

On the regular TCP, my connection will reset when disconnecting 
(plugging off) from Ethernet
and switching to WiFi but MPTCP solves that issue for me and allows 
uninterrupted
work on git cloning/pulling, especially when i have to work with huge 
codebases.

I think that's the relevant use-case for a laptop user working with git.

Apple had been using MPTCP for 12 years and their cloud services run on
Linux servers with iOS clients and for that i can say that it's pretty 
much production ready.

And it's not just Apple. Intel and RedHat had been involved and 
RedHat[1] pretty much
are into MPTCP.

Honestly, i love reading the git codebase as it is very simple and 
straightforward and
i think my previous patches were a bit too big and needs to be 
simplified so,

I have reached out to Matthieu Baerts <matttbe@kernel.org> who works on 
Linux MPTCP
on this issue and i've greatly simplified the code from his comments.
(I've also added him to the loop in this email)

The patch i am attaching is a preview (still WIP) as i need some 
feedback from the linux
mptcp developers if my implementation is correct. But it's greatly 
simplified to follow
git codebase's structure.

Changed the part for the git server daemon to enable mptcp by 
default[0] and modified
the git client to use .gitconfig (global or per repository) with:

git config --global core.mptcp true (or a single repo without --global)

which defaults to false (mptcp disabled for client) as per[0] and 
removed client-side the env var configuration.


[0] 
https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-enabled-by-default 
(Thanks @matt!)
[1] 
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/getting-started-with-multipath-tcp_configuring-and-managing-networking#proc_monitoring-mptcp-sub-flows_getting-started-with-multipath-tcp


> 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-mptcp-temp.diff --]
[-- Type: text/x-patch, Size: 3310 bytes --]

diff --git a/cache.h b/cache.h
index eba12487b9..6839b3acbc 100644
--- a/cache.h
+++ b/cache.h
@@ -944,6 +944,7 @@ extern int verify_ce_order;
 
 /* Environment bits from configuration mechanism */
 extern int trust_executable_bit;
+extern int enable_mptcp;
 extern int trust_ctime;
 extern int check_stat;
 extern int quote_path_fully;
diff --git a/config.c b/config.c
index 2317a76696..833396aa4b 100644
--- a/config.c
+++ b/config.c
@@ -1464,6 +1464,11 @@ static int git_default_core_config(const char *var, const char *value, void *cb)
 	if (!strcmp(var, "core.editor"))
 		return git_config_string(&editor_program, var, value);
 
+	if (!strcmp(var, "core.mptcp")) {
+		enable_mptcp = git_config_bool(var, value);
+		return 0;
+	}
+
 	if (!strcmp(var, "core.commentchar")) {
 		if (!value)
 			return config_error_nonbool(var);
diff --git a/connect.c b/connect.c
index eaf7d6d261..ebeac99bd6 100644
--- a/connect.c
+++ b/connect.c
@@ -721,6 +721,16 @@ static void enable_keepalive(int sockfd)
 		error_errno(_("unable to set SO_KEEPALIVE on socket"));
 }
 
+static const int needs_mptcp(void)
+{
+	int mptcp = 0;
+
+	if (git_config_get_bool("core.mptcp", &mptcp))
+		return mptcp;
+
+	return mptcp;
+}
+
 #ifndef NO_IPV6
 
 static const char *ai_name(const struct addrinfo *ai)
@@ -770,7 +780,11 @@ static int git_tcp_connect_sock(char *host, int flags)
 
 	for (ai0 = ai; ai; ai = ai->ai_next, cnt++) {
 		sockfd = socket(ai->ai_family,
-				ai->ai_socktype, ai->ai_protocol);
+				ai->ai_socktype,
+#ifdef IPPROTO_MPTCP
+				needs_mptcp() ? IPPROTO_MPTCP :
+#endif
+				ai->ai_protocol);
 		if ((sockfd < 0) ||
 		    (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0)) {
 			strbuf_addf(&error_message, "%s[%d: %s]: errno=%s\n",
@@ -817,6 +831,7 @@ static int git_tcp_connect_sock(char *host, int flags)
 	char **ap;
 	unsigned int nport;
 	int cnt;
+	const int needs_mptcp;
 
 	get_host_and_port(&host, &port);
 
diff --git a/daemon.c b/daemon.c
index b1fcbe0d6f..08a16ccf03 100644
--- a/daemon.c
+++ b/daemon.c
@@ -17,6 +17,7 @@ static enum log_destination {
 } log_destination = LOG_DESTINATION_UNSET;
 static int verbose;
 static int reuseaddr;
+static int mptcp;
 static int informative_errors;
 
 static const char daemon_usage[] =
@@ -1007,6 +1008,10 @@ static int setup_named_sock(char *listen_addr, int listen_port, struct socketlis
 	for (ai = ai0; ai; ai = ai->ai_next) {
 		int sockfd;
 
+#if defined(__linux__) && defined(IPPROTO_MPTCP)
+		sockfd = socket(ai->ai_family, ai->ai_socktype, IPPROTO_MPTCP);
+		if (sockfd < 0)
+#endif
 		sockfd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
 		if (sockfd < 0)
 			continue;
@@ -1360,6 +1365,10 @@ int cmd_main(int argc, const char **argv)
 			reuseaddr = 1;
 			continue;
 		}
+		if (!strcmp(arg, "--mptcp")) {
+			mptcp = 1;
+			continue;
+		}
 		if (!strcmp(arg, "--user-path")) {
 			user_path = "";
 			continue;
diff --git a/environment.c b/environment.c
index 9da7f3c1a1..72f1adef6c 100644
--- a/environment.c
+++ b/environment.c
@@ -33,6 +33,7 @@ int warn_ambiguous_refs = 1;
 int warn_on_object_refname_ambiguity = 1;
 int repository_format_precious_objects;
 int repository_format_worktree_config;
+int enable_mptcp;
 const char *git_commit_encoding;
 const char *git_log_output_encoding;
 char *apply_default_whitespace;

Re: Small patch to add support for MPTCP on Linux

[Matthieu Baerts]

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@gmail.com> 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@unrealasia.net/

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: Small patch to add support for MPTCP on Linux

[Junio C Hamano]

Matthieu Baerts <matttbe@kernel.org> writes:

> @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).

"Couldn't impact" meaning that unconditionally passing IPPROTO_MPTCP,
even when MPTCP is not available, would not hurt at all and falls
back on using regular TCP?

I am assuming that that is not what you meant.  Otherwise, you would
not be calling RFC 6897 optimistic, and either the kernel or libc
layer would be tweaking the socket() call "to make the right thing
happen transparently" for everybody, and there wouldn't be any need
for this conversation to happen here.

So I am assuming that at least for now, the choice to use or not use
MPTCP needs to be made somehow.  Leaving it at the application
level, by the way, does not sound like a winning strategy, but
anyway, I think the reason why the platform folks do not take
responsibility and make it up to the application is because MPTCP
may not always be better than TCP; it may boost throughput by
utilizing multiple links but may hurt latency, for example?

What are the criteria the end-user may want to use to decide its
use, then?  If interacting with a specific remote repository over
MCTCP proves better, would the user safely be able to say "I'll
always use MCTCP when talking to that repository"?  Would it be per
host (i.e. if one repository on a host is better with MCTCP, would
all other repositories on the same host better off using MCTCP)?

What I am getting at is that the choice between IPPROTO_TCP and
_MPTCP may not be "If Git is compiled with MPTCP support, always use
MPTCP", so we need to see where the configuration knob for end-users
should be.

Thanks.

Re: Small patch to add support for MPTCP on Linux

[Matthieu Baerts]

Hi Junio,

On 20/05/2025 17:44, Junio C Hamano wrote:
> Matthieu Baerts <matttbe@kernel.org> writes:
> 
>> @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).
> 
> "Couldn't impact" meaning that unconditionally passing IPPROTO_MPTCP,
> even when MPTCP is not available, would not hurt at all and falls
> back on using regular TCP?

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".

The socket API can be used the same way as with TCP: read, write,
set/get socket options, etc. Plus the MPTCP protocol is made to be
resilient: if one host doesn't support MPTCP, the connection continues
in "plain" TCP. In the worst cases, when dealing with middleboxes
altering packets in a way that it messes up MPTCP options, there will be
a fallback to "plain" TCP and the connections can continue using only
one path. It looks like the protocol is quite strong, because Apple has
been using MPTCP around the world since 2013, apparently.

In the Linux kernel, when the client didn't request to use MPTCP, a
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.

> I am assuming that that is not what you meant.  Otherwise, you would
> not be calling RFC 6897 optimistic, and either the kernel or libc
> layer would be tweaking the socket() call "to make the right thing
> happen transparently" for everybody, and there wouldn't be any need
> for this conversation to happen here.

Sorry, yes, that was my understanding of this RFC 6897. Indeed, they
seem to suggest the kernel or the libc would decide when to use MPTCP,
and the apps would not need to care about that at all. That might work
for generic cases, but I guess the users and apps prefer to keep the
control of that. (This RFC apparently also suggest apps to take control
when needed.) Anyway, there are ways to force apps using MPTCP, but a
dedicated option handled by the apps seem cleaner and clearer.

> So I am assuming that at least for now, the choice to use or not use
> MPTCP needs to be made somehow.  Leaving it at the application
> level, by the way, does not sound like a winning strategy, but
> anyway, I think the reason why the platform folks do not take
> responsibility and make it up to the application is because MPTCP
> may not always be better than TCP; it may boost throughput by
> utilizing multiple links but may hurt latency, for example?

Yes indeed, you are right. To be able to use multiple paths, it is
required to add a few bytes in the TCP headers, in the options. If there
is only one path between two machines located next to each others, or
for very short connections, MPTCP and its few extra bytes are not worth
it. Or to be more precise, there is no need for a client to initiate the
connection with MPTCP in these cases. The servers can continue to create
MPTCP listening sockets, and let the clients decide.

> What are the criteria the end-user may want to use to decide its
> use, then?  If interacting with a specific remote repository over
> MCTCP proves better, would the user safely be able to say "I'll
> always use MCTCP when talking to that repository"?  Would it be per
> host (i.e. if one repository on a host is better with MCTCP, would
> all other repositories on the same host better off using MCTCP)?

On the client side, I see this option similar to using Git v2 or
push.gpgsign: if supported on the server side, I want to use it when my
client supports it. Enabling it would be beneficial when switching from
one network to another, or if I have access to multiple networks. Yet,
to save a few bytes (12B per connection request), I might not want to
try using MPTCP with servers that don't support it. Maybe some people
will only want to use it with big repository, or all the ones handled by
the same server.

So yes, I think it would be good to start with a global option, and one
per repository. Because it would be a new feature, people might want to
start using MPTCP only with servers supporting it.

> What I am getting at is that the choice between IPPROTO_TCP and
> _MPTCP may not be "If Git is compiled with MPTCP support, always use
> MPTCP", so we need to see where the configuration knob for end-users
> should be.

Even if MPTCP is used by default, I guess it would always be safer to
have an option to disable it, just in case. In the team, we are all
human, I don't exclude bugs :) (This sentence doesn't make sense any
more: if we were robots/AI, that would make even more sense to have an
option to disable it :-D )

BTW, again thank you all for maintaining and developing Git, this
crucial piece of software :)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: Small patch to add support for MPTCP on Linux

[Junio C Hamano]

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.

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-<.

> 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.

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.

Re: Small patch to add support for MPTCP on Linux

[Matthieu Baerts]

Hi Junio,

On 21/05/2025 00:02, Junio C Hamano wrote:
> 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...

>> 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?

> 
> 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.