MPTCP: use it be default on the server side #146
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On the listener side, an MPTCP socket will accept both "plain" TCP and MPTCP requests, not MPTCP requests only. It is also important to note that when the client didn't request to use MPTCP, a "plain" TCP socket is returned to the application. Link: https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-enabled-by-default Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
It is not used, and not recommended: when packages are distributed, a different kernel will be used at build time and at run time. These kernels can have different versions, different parameters, etc. Also, on Linux, it is common to use containers at build time to reproduce a specific environments, except that it doesn't include the right kernel. Instead, IPPROTO_MPTCP can be checked to see if the OS supports it or not. Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
IPPROTO_MPTCP has been introduced in the Linux kernel v5.6, more than 5 years ago. It has been added in netinet the same year. In other words, it should be available on systems having a kernel supporting MPTCP. In this case, IPPROTO_MPTCP can be used to identify OS where MPTCP is supported directly where it is used. This will simplify the next patch. Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
If not, a "plain" TCP socket is used like before. It is interesting to do so to let only the clients deciding if MPTCP is going to be used or not: clients are probably the ones who know if they can benefit from using MPTCP or not, not the server side. Like that, it is easier to do experimentations with MPTCP without having to explicitly ask sysadmin to enable this option with a long explanation. On the server side, it is safe to enable MPTCP by default because MPTCP will only be used if requested by clients. If not, a "plain" TCP socket is returned to the application, not impacting the performances and then not introducing any regressions. Note that GO server applications are using MPTCP by default since v1.24 [1]. Link: https://go.dev/doc/go1.24#netpkgnet [1] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
Here are some small modifications to enable MPTCP support on the server side by default, if supported. If not, TCP is used like before.
MPTCP in OpenSSH is currently only supported on Linux. On Linux, an MPTCP socket support "plain" TCP and MPTCP requests. In case of "plain" TCP request, a "plain" TCP socket is returned to the application at the
accept()time: no performance impact compared to before. With this in place, clients can decide if MPTCP is used or not: typically clients benefit the most on MPTCP, and know if it is interesting to use it or not.Note that this is also what GO applications are doing: since GO v1.24, all listening sockets have MPTCP support by default (if supported).