openssh-portable icon indicating copy to clipboard operation
openssh-portable copied to clipboard

Mptcp support

Open evrardco opened this issue 1 year ago • 6 comments

The first commit on this branch of our fork is a patch aimed at providing openssh with MPTCP support, the rest are to udapte the man pages and config according to the new MPTCP support.

MPTCP stands for multipath tcp, it can be seen as an extension to tcp sockets which allows the use of multiple network interface at the same time, or to switch from one to another seamlessly. The support for MPTCP is native in the more recent linux kernels, so it is only natural that it becomes native for openssh as well.

The changes to the code base are minimal and the use of MPTCP is controlled by a yes/no configuration parameter "UseMPTCP". This port was made during the OpenWeek event of this year at UCLouvain, in collaboration with Professor Olivier Bonaventure, his research team (mainly François Michel and Maxime Piraux) along with a few students, including me (Colin Evrard), Maxime Postaire and Simon Arys.

The main part of our work was about testing the implementation under various conditions, including real world ones, which is all described in this blog post article.

evrardco avatar Aug 15 '22 16:08 evrardco

Sorry, we're not willing to support a protocol that is only available on one of the platforms that OpenSSH supports. If/when MPTCP becomes more widely supported we can reconsider.

Until then I recommend that users who want MPTCP to use a ProxyCommand on the client or an equivalent wrapper for sshd

djmdjm avatar Aug 17 '22 02:08 djmdjm

Sorry, we're not willing to support a protocol that is only available on one of the platforms that OpenSSH supports. If/when MPTCP becomes more widely supported we can reconsider.

Could you elaborate on what lead to this decision and conclusion?

While obviously your point of view can be understood better once you expand on that, as I see the current decision to be hasty and possibly misguided given that:

  • The new parameter merely signals opting into protocol extensions without actually having to support them. You've surely seen that it's just an extra parameter affecting one of the parameters of a single syscall, everything else is boilerplate, so there is no need for protocol supporting code.
  • While MPTCP is indeed not widespread yet, the experimental standard RFC 6824 ended up having implementations for many platforms. You are likely thinking only of the currently pushed RFC 8684, which indeed may have a native implementation on only a single platform currently. Regardless of which standard is being used, programs need to opt into using the extensions, and while I am not fully certain that opting in is done the exact same way, there will be surely no cross-platform standard for syscall details either.
  • Even though kernel-level support may be lacking, note that RFC 8684 can be already considered multi-platform even if it's not natively supported yet on multiple platforms: https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Windows-10
  • I believe there's not much to support to begin with given how trivial the provided code is, and how well it is constructed to be out of the way by default unless it's explicitly turned on by the user. Of course I honor your desire to include only what you deem worthy, but one of the significant reasons why I'm inquiring how high is the bar is, because the project seems to support odd niches too, like providing workarounds for the broken and hostile platform, Android.

I hope I could put this small pull request in a different light, and I humbly request you to reconsider the inclusion. While you are correct regarding wrappers and shims working like they always were, I am looking forward to such friction points getting removed which is an important step in solving the chicken and egg problem of both individual project maintainers, and OS developers avoiding considering support before mass adoption.

The only horse I have in the race is the continuous need to look for ways to improve both the performance and reliability of my SSH connections because even when not working in quite isolated areas as far as internet connectivity goes, I am not fortunate enough to have a high speed or at least reliable connection. While the OpenSSH project is surely not supposed to solve all of the problems of the world, given the (unfortunately removed) roaming, and the compression option, it does appear to be concerned with such reliability and performance problems which is at least partially resolved by MPTCP.

voidpointertonull avatar Aug 25 '22 22:08 voidpointertonull

MPTCP is supported on macOS as well. So, that would make it 2 platforms already.

cpaasch avatar Sep 14 '22 21:09 cpaasch