From: Muhammad Nuzaihan <zaihan@unrealasia•net>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: git@vger•kernel.org
Subject: Re: Small patch to add support for MPTCP on Linux
Date: Sat, 17 May 2025 15:19:59 +0800 [thread overview]
Message-ID: <BP9EWS.WTYEEEQZEN2U1@unrealasia.net> (raw)
In-Reply-To: <aCeg_wjLCf0Sz_7X@tapette.crustytoothpaste.net>
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
next prev parent reply other threads:[~2025-05-17 7:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 17:56 Small patch to add support for MPTCP on Linux Muhammad Nuzaihan
2025-05-16 20:33 ` brian m. carlson
2025-05-17 7:19 ` Muhammad Nuzaihan [this message]
[not found] ` <CAOYsWhkMb8hxjnYRTgAb269N=e-Vyw10Go5M=RA-8PyCjXPttA@mail.gmail.com>
2025-05-17 8:46 ` Muhammad Nuzaihan
2025-05-17 10:15 ` brian m. carlson
2025-05-17 13:10 ` Muhammad Nuzaihan
2025-05-17 13:39 ` Phillip Wood
2025-05-19 23:49 ` Junio C Hamano
2025-05-20 4:32 ` Muhammad Nuzaihan
2025-05-20 10:54 ` Matthieu Baerts
2025-05-20 15:44 ` Junio C Hamano
2025-05-20 20:34 ` Matthieu Baerts
2025-05-20 22:02 ` Junio C Hamano
2025-05-22 11:12 ` Matthieu Baerts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BP9EWS.WTYEEEQZEN2U1@unrealasia.net \
--to=zaihan@unrealasia$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox