[HN Gopher] MPTCP for Linux
___________________________________________________________________
MPTCP for Linux
Author : SweetSoftPillow
Score : 110 points
Date : 2025-10-13 09:25 UTC (13 hours ago)
(HTM) web link (www.mptcp.dev)
(TXT) w3m dump (www.mptcp.dev)
| majke wrote:
| Hey! MPTCP again!
|
| Back in Jan I wrote a piece about how to actually use MPTCP
|
| https://blog.cloudflare.com/multi-path-tcp-revolutionizing-c...
|
| But plenty has changed since then. It seems all my complains
| about the API are now addressed. Maybe it's a good time to
| actually run with MPTCP again :)
|
| In my private affairs, I realised I need MPTCP less, since I
| started using tailscale. My SSH sessions tend to last longer when
| going over it.
| Sesse__ wrote:
| My biggest disappointment with MPTCP was that seemingly, you
| need both the old and new address to be available when doing
| handover. So you cannot suspend your laptop, go to a different
| place, and resume the TCP sessions on the new Wi-Fi.
| matttbe wrote:
| Of course you can do that. There are different timeouts
| (MPTCP level, TCP (and SSH) keep alive, etc.) to prevent
| having dangling connections for a while, but they can be
| changed if needed.
| imglorp wrote:
| Sort of related, I'm curious why SCTP did not take off more in
| this space? It might have had more telecom origins maybe but
| seemed to fill some of the same needs back in the day.
|
| https://docs.kernel.org/networking/sctp.html
|
| PS the kernel work goes back to 2003!
| _flux wrote:
| I believe it's because of firewalls. You need to be either UDP
| or TCP to work in the Internet at large.
|
| Though SCTP did find its place as a layer in WebRTC.
| BuildTheRobots wrote:
| Coming from the telecoms space, I was slightly amazed to see
| how little well known SCTP actually is in the networking
| world.
|
| My old company/offices had site internet provided by one of
| the top 50 UK Managed Service Providers. They swapped out the
| on-site router not many years ago as the fibre to site was
| being upgraded from 100mbit to gigabit and so a new Juniper
| firewall with GBE ports was required.
|
| Turns out the newer, faster, shinier, though albeit lower
| model numbered'd Juniper SRX fundamentally didn't support
| passing SCTP data and suddenly we lost access to all our
| remote stuff that used it. Ended up on a call with the MSPs
| Head of Networks (who was not a stupid person), but their
| opening gambit was "Are you sure you mean SCTP? Oh. What is
| that then?"
|
| There was also numerous weird kernel bugs with
| implementations on CentOS 5, 6 and 7 which all would manage
| to get themselves into weird states where only a reboot would
| clear - not really what you want from a multi-endpoint,
| 'copes and recovers well from network weirdness' tunnelling
| protocol.
| JoelMcCracken wrote:
| Funny enough, the first and last time I heard of sctp was
| in "Unix network programming". It seemed so promising
| according to Stevens.
| BuildTheRobots wrote:
| It did see a lot of use. I forgot to say, but the
| majority of 3G UMTS and 4G LTE radios (operator level and
| even down to tiny things like femtocells) required it to
| connect back to the $(core network) and encapsulated a
| mix of control and user data through it (though often
| also encapsulating SCTP in a VPN). That is to say, there
| were a lot of devices out there that used it in anger. If
| you made a call or used a cellular data session for over
| a decade, your traffic was likely getting encapsulated
| through it.
| teddyh wrote:
| Wasn't it T/TCP that had a large presence in the book?
| jcelerier wrote:
| > Juniper SRX fundamentally didn't support passing SCTP
| data and suddenly we lost access to all our remote stuff
| that used it.
|
| did you file a customer complaint for the device you bought
| not supporting basic internet protocols? If I look here it
| mentions "internet" but not TCP or UDP. I'd argue it's
| false advertising if it actually only supports a percentage
| of actual internet traffic.
| BuildTheRobots wrote:
| It was one of those situations where the internet was
| part of the lease, and the property owners got the MSP to
| provide for multiple companies on the site. Sadly I
| wasn't a customer of either Juniper or the MSP, and it
| wasn't something they ever actually claimed to support.
|
| Juniper themselves stated in the manual that this base
| model device didn't support SCTP, though on ever other
| level it was faster, more capable and more featureful
| than the mid-range but much older device it replaced. The
| MSP didn't have a clue that we (or anyone else for that
| matter) used SCTP so missed the single footnote mention
| that the command to enable SCTP forwarding might not be
| available on some base-level devices.
|
| In their defence, I'm not sure _I'd_ have thought to
| check if SCTP was supported and I had it running on my
| network. It works over the internet, it's basically IP,
| how could it not be suppo---oh.
| jeroenhd wrote:
| Windows doesn't have kernel mode SCTP so it was slow for most
| consumer devices for a long time. Even now, Linux SCTP is slow
| in comparison to other protocols. Plus, it's complicated enough
| already to get UDP and TCP traffic to make it's way through
| middleboxes. Also, not a lot of consumer routers support things
| like port forwards and combining SCTP with NAT doesn't seem to
| be widely tested. Things just didn't work out when SCTP stood
| to gain adoption.
|
| It's an interesting protocol, but these days I think the
| internet has ossified so far that you're probably better off
| relying on hacks like QUIC and MPTCP to get the protocol
| features that SCTP stood to introduce.
| o11c wrote:
| SCTP has several fundamental design flaws, which are sufficient
| to discourage anyone from actually trying to make all the
| middleware support it.
| skissane wrote:
| What are those flaws? And are they inherent, or something
| that could be fixed with enhancements/revisions?
|
| TCP as originally specified had fundamental design flaws too,
| but the TCP of today has significant differences from the
| 1981 TCP standard (not the first version of TCP, but the
| first version to see significant production use).
| o11c wrote:
| Off the top of my head: stream count is static (an
| extension exists nowadays, but it's still usually
| unsupported), startup requires requires excessive round
| trips, and it's unfixably insecure (TCP actually shares
| this last flaw - you can only detect, not discard, injected
| packets - and this causes massive reliability problems in
| the real world). Some of the default tools were also
| horribly flawed even by 1990s standards (e.g. a shell
| script which uses $* instead of $@) last I checked.
|
| Certainly there are things that _could_ be done to improve
| the ecosystem - but why bother when you can just use a
| reliability layer on top of UDP instead? And these days
| there 's a "standard" solution so you don't even need to
| compare choices or worry about design flaws affecting just
| your program: just use QUIC, everybody uses it and if
| something goes wrong the world will scream and the shared
| library will be upgraded by the distro.
| sherinjosephroy wrote:
| Great to see the continued work on MPTCP integration for Linux.
| Having this as a mature, native option for better session
| resilience and bandwidth aggregation is a huge win for network
| performance.
| senshan wrote:
| Seems like a fool's errand. The cited RFC8684 starts from the
| wrong premise:
|
| > TCP/IP communication is currently restricted to a single path
| per connection, yet multiple paths often exist between peers.
|
| In reality, IP modules of all the hosts and routers _can_ load-
| balance over a set of all available interfaces, as long as global
| routing information is available.
| Sesse__ wrote:
| It is very rare that a single TCP connection will be load-
| balanced over multiple interfaces, since that would frequently
| cause out-of-order delivery, which sucks quite a lot if the
| receiver isn't prepared for it.
| xmichael909 wrote:
| Check out http://www.openmptcprouter.com which works excellent!
| muhammadn wrote:
| I've tried to get MPTCP support in Chrome (default OFF, with a
| knob to turn on in GUI) but the reason most often people gave was
| that there is how to handle support.
|
| Heck. I even tried to add it into git because i was having issues
| with reliable connectivity with WiFi and 5G (i was in a hotel at
| that time) while working on a project.
|
| So unless, if there is some reason why people kept giving reasons
| of not include it. I just do not have a reason to add support for
| $(name your favorite software)
|
| https://chromium-review.googlesource.com/c/chromium/src/+/63...
___________________________________________________________________
(page generated 2025-10-13 23:01 UTC)