Multi-Path TCP: revolutionizing connectivity, one path at a time
4 comments
·August 26, 2025musicale
IIRC Apple hired one of the developers of mptcp. Makes sense since they could implement it both on user devices as well as server-side for their cloud services. Google can probably do the same thing (or similar with multipath quic).
It would probably be nice if cloudflare supported mptcp.
mastax
> 192.168.2.143%enx2800af081bee:57756
OH! I saw addresses like this once before and couldn't find any information about it anywhere. I guess I saw some MPTCP flows from some app.
miladyincontrol
Path of least latency has always been my greatest interest in it. Shame about multipath quic being so far out.
I was super stoked when Apple started pushing MP-TCP, but unfortunately the timing was bad and I wasn't able to explore its use (my service was moving from dns based load spreading to being behind load balancers... I could have experimented with one or a handful of servers doing mptcp when iOS clients connected directly to them; but with a load balancer it's too complex. I wasn't convinced about the server side efficiency either, but improving user experience during network changes could have been worthwhile; my fundamental worry is that it would be difficult to ensure all sub-flows landed on the same NIC rx queue, so you have issues with cross-queue communication... Maybe you could use flow steering, maybe you could have sub-flows that land on the wrong queue get reconnectes, maybe it wouldn't have mattered for the kinds of connections where it would be used.
> Sadly, MPTCP IPv6 has a caveat. Since IPv6 addresses are long, and MPTCP uses the space-constrained TCP Extensions field, there is not enough room for ADD-ADDR messages if TCP timestamps are enabled. If you want to use MPTCP and IPv6, it's something to consider.
For this, I think if you know a lot about your traffic at the time of the SYN, not using tcp timestamps is reasonable. You lose Protection Against Wrapped Sequence numbers; but that's not a big deal. At one time, you would also lose larger tcp windows for iOS users, but I hope that's been changed... the two things aren't really linked, but there was (is?) a heuristic. But, if you're not planning to send/receive a large amount of data in a small amount of time, PAWS isn't super important. I'm not 100%, but I think syncookies can use tcp timestamps to get a larger cookie... so they have value then, but most services aren't being synflooded.