Re: Small patch to add support for MPTCP on Linux

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