“Multipath” TCP Could Turbocharge Bandwidth(technologyreview.com)
technologyreview.com
“Multipath” TCP Could Turbocharge Bandwidth
http://www.technologyreview.com/news/519646/how-apple-could-boost-speeds-20-times-on-the-next-iphone/
7 comments
So, how long has SCTP been around? And how many consumers are actually able to use it?
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.
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.
I wasn't advocating SCTP - I was simply using it as an example. Anyone can use it, just like any other protocol. Most operating systems support it today, but again, not advocating it as the "replacement", just using it as an example.
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.
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.
MPTCP does not claim to address the fundamental flaws of TCP. It allows a single TCP connection to be transmitted accross multiple TCP connections on different interfaces. No more, no less. If that's a hack for you, then a hack it is.
Nitpicking: ISIS is /FAR/ more prevalent than OSPF in the really real world of ISPs. Both run Dijkstra at their core, but ISIS handles multipath much more cleanly.
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.
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.
Maybe in the EU - but ISIS fell off the bandwagon in the US years ago. I'd be curious to your claim, I've rarely run into ISIS in prod and I've had my hands on a lot of G2000 networks.
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.
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.
All of the backbone providers use ISIS. OSPF does not scale as well (# of vertices).
I am the IGP principle at a Tier 1.
I am the IGP principle at a Tier 1.
I'm not really sure why the article mentions both Multipath TCP and network coding. They are very different techniques at different layers of the stack.
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).
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).
> 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. :)
Citations don't sell. Sex, violence, and realistic-sounding, baseless, faulty journalism does. Welcome to the 20xx's. :)
Disappointed that this holds for TR too.
Don't both endpoints have to support Multipath TCP? So I imagine we wouldn't see real gains for standard HTTP traffic in a good long while. Unless Apple passes the traffic through some intermediate proxy, of course...
Yes, as the article suggests, Apple is using it for reliability and latency for their built-in services.
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.
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.
I imagine it'd be pretty similar to the adoption curve SPDY has seen. First Chrome implemented it to talk to Google's servers, then a few other websites, and now nginx will do it for you "for free."
An insane amount of trafic is Google, and I can see them imolementing MPTCP.
Multipath TCP doesn't magically increase the amount of bandwidth either, it just allows a single TCP-like connection to use multiple internet connections. It would allow you to use all bandwidth available on multiple connections in a single TCP connection but right now we can already use all bandwidth available over multiple separate TCP connections.
The article is very weak on substance, but I imagine the encoded possibilities of heavy computation based parallel stream. The obvious challenges are timing/synchronization and additional processing based power consumption.
It would have been nice if the author would have included a reference to the actual open-source project that powers this, along with the authors http://multipath-tcp.org/mptcp_stats/authors.html
Huh? That's the Linux kernel MPTCP project. The article is talking about Apple's use, which rely on a Cisco implementation and an Apple implementation; pretty sure neither are based on the Linux impl.
MTCP is a standardized protocol extension to TCP documented in a handful of RFCs, there's multiple implementations. Apple didn't use the one you linked to.
They didn't write the code Apple is using, which is what the article is about?
Aren't well-seeded torrents essentially multipath TCP? The main thing they get around seems to be per-flow limits instituted on network provider routers and SPOFfy fileservers, the first being a flow deSPOF, and the second being an endpoint deSPOF. Multipath TCP (though I'm not very familiar with it) seems to be only a flow deSPOF, and therefore only solves half the resiliency domains solved by torrents. Of course, they are no doubt faster to set up and don't require half the world to be interested in something .. both significant benefits.
Isn't part of the point of wifi to dodge your 4G usage limits?
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.
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.
If its only being used for Siri and Maps, those are both low-bandwidth applications but with high expectations with regards to latency and availability.
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).
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).
Multiparty sounds great and all. But I'd be happy if they could make a laptop use both a hard-wired Ethernet and a wifi connection at the same time. Is it really that difficult?
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.
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.
You can "shotgun" connections but hardwired and wifi usually isn't a win since the wifi will be more error prone and higher latency than the wired. So if you have both you should probably just do the wired.
Like I said, for embedded systems. The wired connection is not an active link to the internet.
My laptop can use both connection at the same time. Maybe you need a better OS.
You should read up on how routing works. In particular - source-based routing.
It may just be my laptop, but I was able to get both WiFi and Ethernet working on an HP Elitebook 8460p after toggling a setting in the BIOS.
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.