Multipath TCP for Linux (2022)

Original Article ↗ Hacker News Discussion ↗

Multipath TCP (MPTCP) for Linux aims to let a single connection use multiple network paths at once—such as Wi‑Fi and cellular—to improve reliability, throughput, and seamless roaming. Commenters explore why, despite support in Linux, iOS, and some routers and proxies, it has seen limited adoption: kernel maintainers require explicit opt‑in from applications, middleboxes and load balancers complicate deployment, and many problems it could solve are now handled in higher layers or via alternatives like QUIC and SCTP. Use cases like mobile failover, rural broadband aggregation, and home link redundancy are seen as valuable, but often constrained by operational complexity and ecosystem support.

Adoption and Kernel Design

  • Linux requires explicit application opt‑in; maintainers rejected a fully transparent default.
  • Some argue transparent MPTCP (automatic subflows, e.g., LTE failover) would cover most use cases.
  • Servers and even whole GNU/Linux distros could enable MPTCP by default via eBPF, but this is not widespread.
  • Several commenters express disappointment at slow adoption despite early promise (since ~2013).

Middleboxes, Compatibility, and Security

  • Most proxies/firewalls reportedly pass MPTCP options; main hurdle has been load balancers.
  • MPTCP falls back safely if options are stripped, assuming middleboxes don’t enforce contiguous TCP sequence space.
  • Concerns raised about new security issues when multiple IPs are used under one logical connection (e.g., IP-based ACLs).

Use Cases and Real-World Deployments

  • Strong interest in seamless Wi‑Fi/cellular handover and resilience (e.g., “parking lot” Wi‑Fi failures).
  • Some mobile apps (e.g., Siri, WeChat) and iOS support MPTCP; one user notes turning it off due to metered cellular data.
  • Delivery robots and multi‑modem setups seek <50ms failover; commercial solutions (Peplink, Phantom Auto) are used due to engineering complexity.
  • European ISPs reportedly use MPTCP proxies to combine weak DSL with cellular for rural customers.

Routers, Home Networks, and Aggregation

  • OpenWrt derivatives (e.g., OpenMPTCProuter) and Home Assistant OS now support MPTCP.
  • Users report aggregating multiple home links (cable + fiber, dual 5G) via a VPS, but note drawbacks (e.g., datacenter IP at home, TCP tunneling HoL issues).
  • Some argue home HA and aggregation are already solved with LACP/VRRP; others value per‑flow bandwidth aggregation and smoother roaming.

Relation to SCTP, QUIC, and MPQUIC

  • SCTP is cited as an earlier, similar idea with limited public internet traction but heavy telco use (and in WebRTC data channels).
  • Several see innovation shifting to QUIC because TCP extensions are often broken by middleboxes.
  • Others view QUIC as a step backward (UDP issues, initially no multipath); a standards‑track multipath QUIC draft and implementations exist.
  • MPQUIC aims to combine MPTCP‑style multipath with QUIC’s stream multiplexing.

Architectural Reflections

  • Some wish TCP had connection IDs independent of IP addresses to allow native roaming/multihoming.
  • Debate over whether such features belong at transport vs. higher layers; references to Mosh and session‑layer concepts.
  • Overall sense: MPTCP is technically valuable but hampered by ecosystem inertia, middleboxes, and load‑balancing complexity.