Re: Small patch to add support for MPTCP on Linux

[Junio C Hamano <gitster@pobox.com>]

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.