Hi Junio, On 20/05/2025 17:44, Junio C Hamano wrote: > 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? Sorry, I was not clear. I meant "introducing MPTCP in the Linux kernel couldn't impact other protocols in terms of memory allocated per socket buffer or performances by adding extra checks a bit everywhere for example". The socket API can be used the same way as with TCP: read, write, set/get socket options, etc. Plus the MPTCP protocol is made to be resilient: if one host doesn't support MPTCP, the connection continues in "plain" TCP. In the worst cases, when dealing with middleboxes altering packets in a way that it messes up MPTCP options, there will be a fallback to "plain" TCP and the connections can continue using only one path. It looks like the protocol is quite strong, because Apple has been using MPTCP around the world since 2013, apparently. In the Linux kernel, when the client didn't request to use MPTCP, a listening socket supporting MPTCP on the server side will return a "plain" TCP socket to the userspace during the accept() call. That's why we recommend enabling MPTCP on the server side by default if supported: the impact is minimal, and MPTCP is only used when requested by the clients -- which are usually the ones benefiting more from MPTCP features. That's in fact the current behaviour for apps written in Go: MPTCP is now enabled by default on the server side, and it is easy to enable it on the client side when needed. > 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. Sorry, yes, that was my understanding of this RFC 6897. Indeed, they seem to suggest the kernel or the libc would decide when to use MPTCP, and the apps would not need to care about that at all. That might work for generic cases, but I guess the users and apps prefer to keep the control of that. (This RFC apparently also suggest apps to take control when needed.) Anyway, there are ways to force apps using MPTCP, but a dedicated option handled by the apps seem cleaner and clearer. > 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? Yes indeed, you are right. To be able to use multiple paths, it is required to add a few bytes in the TCP headers, in the options. If there is only one path between two machines located next to each others, or for very short connections, MPTCP and its few extra bytes are not worth it. Or to be more precise, there is no need for a client to initiate the connection with MPTCP in these cases. The servers can continue to create MPTCP listening sockets, and let the clients decide. > 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)? On the client side, I see this option similar to using Git v2 or push.gpgsign: if supported on the server side, I want to use it when my client supports it. Enabling it would be beneficial when switching from one network to another, or if I have access to multiple networks. Yet, to save a few bytes (12B per connection request), I might not want to try using MPTCP with servers that don't support it. Maybe some people will only want to use it with big repository, or all the ones handled by the same server. So yes, I think it would be good to start with a global option, and one per repository. Because it would be a new feature, people might want to start using MPTCP only with servers supporting it. > 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. Even if MPTCP is used by default, I guess it would always be safer to have an option to disable it, just in case. In the team, we are all human, I don't exclude bugs :) (This sentence doesn't make sense any more: if we were robots/AI, that would make even more sense to have an option to disable it :-D ) BTW, again thank you all for maintaining and developing Git, this crucial piece of software :) Cheers, Matt -- Sponsored by the NGI0 Core fund.
