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.