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.
This has given me an idea to use a proxy like quicssh which can then connect me to some other ssh servers of mine (if I get any in the future)
and then I can simply have a laptop that can then switch between networks since quic does support this right, and no problemo.
Something similar to mptcp but something that can work maybe right now, that doesn't require me some complicated software as I will be honest, I am not a hardcore software programmer but just a funny little guy who loves messing with software and building simple shit and it would be dope if I can build something like this that feels useful. Its on my imaginary bucket list one day.
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.
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.
I had a GSOC student where we added MPTCP support in OpenWRT:
https://blog.freifunk.net/2017/08/28/gsoc-2017-add-mptcp-sup...
This has given me an idea to use a proxy like quicssh which can then connect me to some other ssh servers of mine (if I get any in the future)
and then I can simply have a laptop that can then switch between networks since quic does support this right, and no problemo.
Something similar to mptcp but something that can work maybe right now, that doesn't require me some complicated software as I will be honest, I am not a hardcore software programmer but just a funny little guy who loves messing with software and building simple shit and it would be dope if I can build something like this that feels useful. Its on my imaginary bucket list one day.
Path of least latency has always been my greatest interest in it. Shame about multipath quic being so far out.
Hopefully not that far out, we're actively working on it at n0/iroh https://github.com/n0-computer/quinn/pull/28
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.
> 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.