[ohnoesjmr]

I've heard about MPTCP back in 2013.

It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day.

It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http calls in multiple retry handlers, and mobile operating systems have abstracted network connectivity to the point where it feels more like you are using zeromq rather than tcp.

[ajb]

I suspect that a lot of innovation energy moved to QUIC, because with TCP your nice new variant can be randomly nobbled by middleboxes. For example, see https://blog.apnic.net/2021/12/08/efficient-multipath-transp...

[karma_pharmer]

QUIC is a step backwards here; it has no multipath support: https://lwn.net/Articles/964377/

Multipath: There are several areas where TCP still has an advantage over QUIC. One of those is multipath support. Multipath TCP connections can send data on different network paths simultaneously — for example, sending via both WiFi and cellular data — to provide better throughput than either path permits individually.

Server connection migration is explicitly forbidden by QUIC:

https://github.com/quicwg/base-drafts/pull/2031

[xvilka]

QUIC is a step back, IMHO. Especially, given how many national networks work poorly with UDP protocols.

[gsich]

Nobody cares about those middleboxes, those are only relevant in corporate networks.

[toast0]

I wanted to like it, and Apple included it in iOS, but supporting it on real servers was going to be too hard...

When I was deployed on FreeBSD with no load balancers, there weren't recent patches. And even if there were, I'd need to do some serious work to avoid advertising the private network ips as alternates...

When I was on Linux behind a load balancer, it's too complex to get the streams to the right place. And the load balancer doesn't want to do it anyway.

Processing two streams together involves a lot of complexity in a high throughput code path. It's a lot of risk, and you've got to reboot for changes.

And then you do all that work and it only benefits iOS users, who tend to be on better networks anyway.

[bbss]

Apple also contributed[1] MPTCP support to Envoy Proxy.

[1]https://github.com/envoyproxy/envoy/pull/18780

[DEADMINCE]

> iOS users, who tend to be on better networks anyway.

I don't think there is any basis to claim that.

[RulerOf]

It sounds like this would have taken off if it were added to various managed cloud load balancers based on what you're saying.

The only question I have is if it opens up a different can of worms even if you've got a magic box terminating layer 7 for you or not. Never dug deep enough into mptcp myself to know.

[quectophoton]

> I've heard about MPTCP back in 2013.

> I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day.

You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far.

[1]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...

[throw0101b]

> You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far.

Probably partly because middleware boxes (e.g., firewalls) either didn't/don't support it and/or rules were written to only support "TCP" (as opposed to 'stream') or "UDP" (as opposed to 'dgram'; see also "DCCP").

[fanf2]

SCTP is used a lot inside telco networks for carrying switching control metadata for voice connections. https://en.wikipedia.org/wiki/SIGTRAN

[gamegod]

WebRTC data channels use SCTP, which ain't nothing! https://datatracker.ietf.org/doc/html/rfc8831

(SCTP over DTLS, that is...)

[dheera]

I was excited about it because we were working on delivery robots and I wanted a good solution for instant failover given 2 cellular modems.

We ended up going with PepLink's SpeedFusion to save engineering time. But the license was costly. I really hope for a free solution in the future for 2 cellular networks and <50ms failover.

Multipath UDP + OpenVPN would also probably be a viable solution.

[kariemf]

I created something like what you're describing with the addition of P2P communication using NAT traversal (https://www.hyperpath.ie)

It will connect your devices in a P2P Mesh VPN and allow them to send and receive data using multiple links (e.g. multiple 5G or 5G + Satellite).

It is significantly cheaper than Peplink's license, less latency and no bandwidth / data limits.

You need to bring your own hardware though. Like a Raspberry Pi with 3 USB 4G/5G dongles.

[tubs]

Hehe, I also worked on a delivery robot with exactly the same problem. We ended up licencing phantom auto. Expensive and ... Not particularly amazing.

[bennyhill]

I see it as depressing that this is gaining traction it doesn't deserve. TCP doesn't need one hack at a time and then to make us choose combinations that sort of work in half the use cases in the modern world, it needs to be replaced with SCTP.

[zoobab]

ZeroMQ yeah!