Hacker News Reader

Comment by vlovich123 | Hacker News Reader

Why does this require explicit opt in by applications if there’s transparent fallback? Wouldn’t it make most sense for the kernel to do it transparently for every TCP connection so that it can make more global decisions about path aggregation / link preference?

View on HN

My understanding is that it was basically a condition enforced by the maintainers of the Linux TCP / networking subsystems. If you look at the initial upstreaming discussions[1], this was setup as a ground rule.

If you look at the older multipath TCP implementation, prior to the upstreaming, it was intended to be fully transparent to the application, which I think makes more sense for the intent of the protocol. Sure, in many cases MPTCP may be better with application-guided logic, but having a standard system approach (e.g. establish sub-flows on an LTE connection for automatic failover, but don't send any data along those sub-flows) would have worked for 95% of cases.

[1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...

Yes, that's correct. In the Linux kernel, it would not be possible to switch to MPTCP by default.

But apps can use it by default. For the server case, it really makes sense: https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-ena...

GNU/Linux distributions could even switch MPTCP on by default (via eBPF).

Using this implies that there are multiple IPs per endpoint associated with a single TCP connection. That is going to need explicit support/awarness by the application in many cases.

I can imagine new security holes being opened up by allowing multiple IP's to talk over the same TCP connection...

Imagine you have an application which checks the clients IP (eg. against a whitelist) at the time of connection and then assumes it doesn't change...

Reply on news.ycombinator.com