“Multipath” TCP Could Turbocharge Bandwidth

“Multipath” TCP Could Turbocharge Bandwidth
technologyreview.com

But if they can do it, we can't be that far from NetFlix, Google and others being able to flip the switch for their high bandwidth products.

I am curious whether iOS exposes multipath to applications.

TCP is broken in today's age. It's still reliant on upstream single path routes that are mainly devised via BGP and OSPF. These two routing protocols are showing age and suck at multi path without significant configuration and tuning.

MPTCP is a great idea if 1) you don't care about session state which is a fundamental to security controls 2) you don't care about QoS being impacted by differing paths 3) you know the network end to end. MPTCP wasn't designed with end consumers in mind.

Think about this. PMTUD doesn't work today because people still don't trust ICMP type 3 code 4. If everyone did the Internet would work much better and buffer bloat wouldn't be as much of a problem (that you likely have no awareness exists).

MPTCP is a hack as Apple has deployed it and it's not going to improve the upstream problem. It will, in fact, make things worse if they open it up beyond Siri. Do something innovative and start solving for TCP, not abusing it even further than it is already.

Our networks are ridiculously inefficient. I for one will not applaud Apple as tone this is just a greedy hack that won't pan out to much beyond what you see today.

The problem is, IP and TCP and NAT and firewalls and BGP and OSPF are all fairly fundamental facts of the network we operate on. There's no way to unilaterally move to something else without, well, breaking the internet. IPv6 has been around for 17 years, and we're running out of IPv4 addresses at an alarming rate, yet IPv6 still has single-digit (or less) penetration.

The advantage of MPTCP is that it operates over what look to any observer as regular TCP connections. This means it's compatible with all of the NAT and firewall technologies that know how to deal with TCP, while still giving you the bandwidth and reliability advantages of utilizing multiple paths.

I'm not really sure how your example about PMTUD is supposed to support your case. That's an example of a technology that doesn't work within the constraints of the network as it's actually built, in which ICMP is not something that can be relied upon. The whole point of the MPTCP hack is to make it compatible with the existing network, and fall back gracefully to a single path TCP connection if that doesn't work, rather than something like SCTP which simply doesn't work at all if you're behind a NAT that doesn't know what SCTP is.

What session state that is "fundamental to security controls" does MPTCP lose? There's nothing that I can think of that you could do with MPTCP that you couldn't do with just two or more single path TCP connections. I'm also not sure why you think that QoS would be particularly impacted by multiple paths; you can always just use a single path and leave the second path only as a fallback, and then the QoS story should be exactly the same as you had originally, just with higher availability. Does SCTP do something special to make QoS work better over multiple paths? And why do you think that MPTCP assumes that you know the network end-to-end? Everything I've seen about it's design seems to imply that they were very careful to design with assumptions of the most degenerate possible network conditions that are still successfully able to transmit plain old TCP.

Multipath TCP isn't something that Apple just created unilaterally; it's been in development at the IETF for years with several implementations on different operating systems, and lots of experimental data to back it up. I think it's an excellent attempt at getting a working multipath solution out there, that doesn't require boiling the oceans like SCTP or IPv6 do.