Matthieu Baerts <matttbe@xxxxxxxxxx> 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.
