News for hackers. Stuff that matters.

A comment on Linux Kernel MultiPath TCP Project.

Re:Linux Kernel MultiPath TCP Project by londons_explore on Sunday October 16, 2022 @02:40AM (#33221564)
> Programs that were built to use TCP will still use the TCP connections when running on an MPTCP-enabled kernel unless the programmer/user/admin opts-in to using Multipath TCP.

So, if MPTCP is a drop-in replacement for TCP, why do programs need to opt into it?

Without being enabled by default, this project will go nowhere.

[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by bheadmaster on Sunday October 16, 2022 @03:28AM (#33221838)
I didn't see the phrase "drop-in replacement" anywhere in the linked text, so I assume it's not supposed to be a drop-in replacement.
[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by tracnar on Sunday October 16, 2022 @04:49AM (#33222165)
MPTCP is an extension of TCP and is "drop-in". But AFAIK making it opt-in was a concession to get it upstreamed in Linux, understandably as this is a risky change.

There are different ways to enable it on unmodified applications, e.g. via a wrapper or using eBPF.

[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by kevincox on Sunday October 16, 2022 @06:18AM (#33222557)
Hopefully there will eventually be a sysctl to do it by default and maybe with enough testing enable tbat be default.
[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by simoncion on Sunday October 16, 2022 @07:00AM (#33222699)
> Without being enabled by default, this project will go nowhere.

The maintainers of Linux distributions will enable it, if they see doesn't cause trouble with regular network traffic.

After all, there are instructions for the "old" implementation: <https://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP>, <https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting> and the "new" implementation: <https://github.com/multipath-tcp/mptcp_net-next/wiki/#how-to...>.

[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by datastoat on Sunday October 16, 2022 @07:09AM (#33222730)
MPTCP is a drop-in replacement -- but its original designers were paranoid about e.g. packet-sniffing middleboxes, so they made it opt-in.

Suppose for example there's a packet-sniffing security appliance along the path, and it only sees packets on one path of the MPTCP flow, and it says "This stream of packets doesn't look like a legitimate TCP flow, so it's probably an attack, so I'll block it."

[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by pid-1 on Sunday October 16, 2022 @09:41AM (#33223549)
Tangencial, but that's also the reason QUIC (used by HTTP/3) was built upon UDP.
[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by usrnm on Sunday October 16, 2022 @10:27AM (#33223843)
Wasn't it used to avoid head of line blocking?
[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by tracnar on Sunday October 16, 2022 @11:14AM (#33224189)
Built over UDP rather than directly over IP. Introducing a new layer 4 protocol on the internet is not realistic for the foreseeable future.
[ Parent | on HN ]
Re:Linux Kernel MultiPath TCP Project by londons_explore on Sunday October 16, 2022 @10:31AM (#33223864)
I think the real answer is to test a lot of middleboxes, come up with some fallback behaviour that will at least work with 99% of them, and then just break the last 1%.

The same happened with Max Segment Size detection - and that mostly works now.

[ Parent | on HN ]