Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kernel: enable MPTCP support #3248

Merged
merged 1 commit into from Mar 14, 2024
Merged

Conversation

matttbe
Copy link
Contributor

@matttbe matttbe commented Mar 14, 2024

First, thank you for all the work around the Home-Assistant, it is a really useful project that we can control

The official description says:

Multipath TCP (MPTCP) connections send and receive data over multiple
subflows in order to utilize multiple network paths. Each subflow uses
the TCP protocol, and TCP options carry header information for MPTCP.

Thanks to MPTCP, being able to use multiple paths in parallel or simultaneously brings new use-cases:

  • Seamless handovers: switching from one path to another while preserving established connections -- Apple is using it for this reason since 2013.

  • Best network selection: using the "best" available path (latency, losses, cost, bandwidth) -- one path can be used as a "backup" one.

  • Network aggregation: using multiple paths at the same time to have a higher throughput -- e.g. to combine a fixed an mobile network to send files faster.

For example, for HA, it is possible to keep a SSH connection alive when switching from one network to another (e.g. while travelling).

To be able to use MPTCP, both ends need to support it. An application has to request it, by creating an MPTCP socket instead of a TCP one. The rest in unchanged. An alternative is to use mptcpize tool, which relies on LD_PRELOAD to create an MPTCP socket instead of a TCP one.

Note that a MPTCP-enabled server continues to accept regular TCP connections that do not use the Multipath TCP extension without any performance impact. When a connection request is received, and is linked to a listening socket with MPTCP support, the kernel will simply check if MPTCP options are present. If not, the accepted socket will be a "plain" TCP one, with the same impact as before.

To use multiple paths at the same time, additional IP addresses need to be configured, e.g. via the ip tool (IPRoute2).

MPTCP in the kernel is light, and enabled in most main Linux distributions (Debian, Ubuntu, RedHat, Fedora, etc.), but in more specific ones like Raspbian. It is available in the Linux kernel since v5.6.

It would be nice to have it supported in hassio, to let apps using it.

Copy link

@home-assistant home-assistant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @matttbe

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@home-assistant home-assistant bot marked this pull request as draft March 14, 2024 10:13
@home-assistant
Copy link

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Copy link
Member

@agners agners left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution. I agree, enabling MPTCP seems sensible and useful, given it is enabled in most general purpose Linux distros too.

buildroot-external/kernel/v6.1.y/hassos.config Outdated Show resolved Hide resolved
The official description says:

  Multipath TCP (MPTCP) connections send and receive data over multiple
  subflows in order to utilize multiple network paths. Each subflow uses
  the TCP protocol, and TCP options carry header information for MPTCP.

Thanks to MPTCP, being able to use multiple paths in parallel or
simultaneously brings new use-cases:

- Seamless handovers: switching from one path to another while
  preserving established connections -- Apple is using it for this
  reason since 2013.

- Best network selection: using the "best" available path (latency,
  losses, cost, bandwidth) -- one path can be used as a "backup" one.

- Network aggregation: using multiple paths at the same time to have a
  higher throughput -- e.g. to combine a fixed an mobile network to
  send files faster.

For example, for HA, it is possible to keep a SSH connection alive when
switching from one network to another (e.g. while travelling).

To be able to use MPTCP, both ends need to support it. An application
has to request it, by creating an MPTCP socket instead of a TCP one.
The rest in unchanged. An alternative is to use 'mptcpize' tool, which
relies on LD_PRELOAD to create an MPTCP socket instead of a TCP one.

Note that a MPTCP-enabled server continues to accept regular TCP
connections that do not use the Multipath TCP extension without any
performance impact. When a connection request is received, and is linked
to a listening socket with MPTCP support, the kernel will simply check
if MPTCP options are present. If not, the accepted socket will be a
"plain" TCP one, with the same impact as before.

To use multiple paths at the same time, additional IP addresses need to
be configured, e.g. via the 'ip' tool (IPRoute2).

MPTCP in the kernel is enabled in most main Linux distributions (Debian,
Ubuntu, RedHat, Fedora, etc.), but in more specific ones like Raspbian.
It is available in the Linux kernel since v5.6.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
@agners agners merged commit 6b062f3 into home-assistant:dev Mar 14, 2024
2 checks passed
jens-maus added a commit to jens-maus/RaspberryMatic that referenced this pull request Apr 7, 2024
@sairon sairon added os linux Linux kernel related issue labels Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed linux Linux kernel related issue os
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants