“Multipath” TCP Could Turbocharge Bandwidth
technologyreview.com
technologyreview.com
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.
There are no bandwidth or reliability advantages of using multiple path IF you have constraints of network devices upstream. Why? Generally because upstream you're going to be traversing the same endpoint path as you converge. You may have disparate paths for a number of hops but generally your Internet connections on, say, mobile and cable will be geographically tied to the same region (let's say Chicago). There is no guarantee here for reliability (especially if both hosts are NOT multi-homed) - and if there is a problem the closer it is to the destination will exponentially increase the chance that the path for both ends up broken. Beyond that MPTCP doesn't "look" like regular TCP connections - they are regular TCP connections. The only magic is on the source. Where MPTCP solves problems is 1) in wireless handoff situations where the end user doesn't want to drop a session 2) avoiding setting things up like link aggregation in a DC environment (although this means multiple L3 paths must exist which is also additional infrastructure in most cases).
PMTUD was an analogy. It is something that's implemented everywhere and doesn't work. If organizations don't want MPTCP to work - they can very easily stop it through network controls. By default most session aware devices (firewalls, load balancers, etc) can break MPTCP by default since if they don't have the entire session they often will not allow the traffic.
The bases tenant of MPTCP breaks security models by splitting same session traffic over multiple TCP sessions. If part of a conversation goes through firewall A and the other goes through firewall B you lose context. If your firewall is L7 aware you will likely break the application tracking component. I am fully aware that each subflow is it's own session (in terms of setup/teardown) - however new security technologies will need to do extensive corroboration to fully understand flows across disparate parts of the network, and yes there is fallback for when things break.
I don't think MPTCP assumes anything. My point there was that if all the stars do not align you went through extra overhead to do nothing. Back to PMTUD - it's great when it works, but 99% of the time it doesn't.
Finally I realize that Apple has not created this. I've tested MPTCP in operational environments back in 2010 (and have been following it since 2009). The point is, I've seen it in operation and it's very niche focused on where it will showcase significant advantages. It is excellent work, I don't discount that. The reality is, however, that it's not what everyone is making it out to be. I've used it, I've implemented it, I've tested and researched it. Just because Apple is testing it - doesn't mean anything.
Ultimately I feel that closed minded statements around BGP and OSPF are half the misunderstanding of the fundamental problems. LISP is far more prevalent than you likely realize and nobody is boiling the ocean on that front and finally - IPv6 has far more than single-digit penetration. I'm pretty sure you pulled that one out of thin air. Over 40% of my home Internet traffic is IPv6 - just FYI.
Bloat is a very interesting conversation, most providers are not doing sufficient analysis of the interface buffer size in relation to latency. It would be very neat to see Juniper/Cisco building interface level auto-queue management to reduce the latency inducing over buffering that occurs on badly tweaked backbone links.
Cisco and Juniper are dinosaurs, the real disruption is being done by those smaller orgs not focused on pushing overpriced big-iron.
edit: I am a network engineer by trade, and have worked in large ISPs over the years.
I am the IGP principle at a Tier 1.
Multipath TCP is a way of making what looks like a single TCP connection at the socket layer actually be transmitted over several TCP connections over the network, allowing transparent sharing of bandwidth between links and roaming or failover from one link to the other. It's an actual protocol, designed to be transparent to applications and compatible with all of the hardware and software out there that mucks with TCP connections (stateful NATs and firewalls, proxies, etc) by making each connection act just like a regular TCP connection.
Network coding is a technique for reducing the bandwidth used in broadcast applications or applications over very noisy channels. The basic idea is that rather than sending packets directly, you can send the XOR of various packets (perhaps the XOR of new packets with packets that you already know the recipient has because they sent them, or that the recipient has already acknowledged), and the recipient can do some basic linear algebra to solve for the contents of packets that they haven't yet received based on ones that they have already received. This can allow you to reduce bandwidth usage in broadcast applications, and reduce retransmission round trips over noisy channels.
The problem is, it seems better suited for channels that have those characteristics (noisy and broadcast channels), which describes link-layer wireless protocols, but not transport layer protocols like TCP in general. And to apply it to something like TCP would require fundamental changes in the protocol, changing how ACKs are handled to have them reply not based on a single packet but based on how much information they are able to solve for based on the packets received so far. I'm not sure you could do it in a fully backwards compatible way that would make sense for end-to-end multipath TCP.
And as far as I can tell, the network coding research mentioned is, well, just that, mostly research, while multipath TCP is already a series of RFCs, a few experimental implementations, and at least one deployed implementation.
It seems like this article is just trying to connect this research to the recent story about multipath TCP in iOS 7, when there really isn't any direct connection between the two. It sound more like a fluff piece about a professor's research than anything actually interesting (and frustratingly, it doesn't seem to actually link to the research that it mentions either, nor even provide enough a citation to find it).
Citations don't sell. Sex, violence, and realistic-sounding, baseless, faulty journalism does. Welcome to the 20xx's. :)
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.
For pcs and the like, very occasionally I do run into a situation where I am connected to two completely different networks. Windows automatically balances them, which is nice, but only at the applications level which is kinda a bummer. It should be by request. This technology which zippers the packets would be really cool.
I wouldn't recommend it for Netflix or bulk data transfers, but definitely for scenarios where you expect a response almost immediately (Siri, Navigation, Google Now, and so forth).
Not for bandwidth, I work with embedded systems. If the wifi is active, then it's not possible to connect to an IP address on the Ethernet port (OS X and Win7). Subnet doesn't matter, and re-arranging the priorities of the network devices doesn't help either.