Message-Id: <CDZEWS.Q5FBCC7YC2QD2@unrealasia.net>
Date: Sun, 18 May 2025 00:34:24 +0800
From: Muhammad Nuzaihan <zaihan@...ealasia.net>
To: linux-kernel@...r.kernel.org
Cc: "phillip.wood" <phillip.wood@...elm.org.uk>, "brian m. carlson"
	<sandals@...stytoothpaste.net>
Subject: PATCH v2 [1/1]: MPTCP support for Git on Linux

Hi,

This patch is about Multi-Path TCP.

Multi-Path TCP (MPTCP) had been in development for the past 15 years
which started with MPTCP v0 (version 0) which initially had issues
for middleboxes and NAT Gateways.

The current iteration is MPTCP v1 which has a fallback mechanism to 
regular
TCP to avoid issues with middleboxes and NAT Gateways.

Started to add this code change as a need as i have large git codebases
with around 50 gigabytes and i have multiple WAN links  which i can 
aggregate
bandwidth across and even when  network 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 reason of adding support for git (on Linux)

To get MPTCP to be fully working, both ends of client and server must 
implement
MPTCP.

My implementation adds support for the basic git protocol.

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.

Also, 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 with middleboxes (not MPTCP v1) since 2013.

The downside, even though i had never experienced it for other 
applications
on Linux like Google Chromium[1], is that the fallback might induce 
delays
in connectivity, if i've read it somewhere which i cannot recall where.

How this patch works:

This patch enables MPTCP protocol option only when it's built on Linux 
with
IPPROTO_MPTCP support in netinet/in.h.

On Linux, if IPPROTO_MPTCP is not defined in netinet/in.h, it will 
skipped.

IPPROTO_MPTCP should and never be enabled when it detects being built on
an OS other than Linux with defined(__linux__) check.

Another challenge is that although "getaddrinfo()" is a POSIX function,
not all glibc "getaddrinfo()" implementation is written with
IPPROTO_MPTCP support out of the box, especially on older glibc 
versions.

getaddrinfo() IPPROTO_MPTCP support had only been added to recent glibc
in 2025 eventhough IPPROTO_MPTCP definition had been around for
much longer in netinet/in.h.

So we run getaddrinfo() which is a code in glibc and check for errors,
specifically "EAI_SOCKTYPE" return value which tells us that the socket 
type
is not supported and fallback to regular TCP (IPPROTO_TCP)

Also we will also check that we are building on Linux and depending on
version number of Linux we will initialize the socket() accordingly and 
if
there is an error return value (like 
EINVAL/EPROTONOSUPPORT/ENOPROTOOPT),
we will fall back to regular TCP.

Enabling and disabling MPTCP:

By default on the client side, MPTCP will not be enabled in git client, 
however MPTCP
can be enabled by setting an environment variable "GIT_ENABLE_MPTCP" to
any value.

Persisting the configuration can be done in your shell.

Also for server side git server (daemon.c), there is a flag to 
optionally
enable mptcp with "--mptcp", example:

git-daemon --base-path=/all/my/repos --export-all --mptcp

This will tell the git server daemon to accept mptcp connections but
fallback to regular tcp when mptcp connection is not available.

PS: Can someone point me about having a "knob" in Makefile or is this
already sufficient?

[1] https://chromium-review.googlesource.com/c/chromium/src/+/6355767

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



View attachment "git-mptcp-v2.diff" of type "text/x-patch" (5187 bytes)

Powered by blists - more mailing lists