It happens a lot when I am with my iPhone at boundary of a Wi-Fi network coverage, the network is very unstable with oscillations between Wi-Fi and 4G. The phone stays in the status with connected Wi-Fi but it's actually not working. If there was multi-path TCP, mobile devices can establish simultaneous streams on both Wi-Fi and 4G. When Wi-Fi is not responsive, the data stream can be automatically offloaded onto 4G seamlessly without causing latency in application layer.
Another protocol that may achieve this is SCTP. And it's been around for years. But migrating existing services to another transport protocol is a challenge, which makes it difficult to adopt SCTP. I'm curious how multi-path handles this. Is it an extension to TCP that can handle backward compatibility with TCP, or yet another new transport protocol?
EDIT: More details about its design decisions and goals: http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
I remember the first mobile prototypes that were used around Motorola were dying of battery after few hours if used wifi instead of mobile data (that was about 8 years ago - so probably we are talking GPRS here).
Checkout the tech talk if you want to know more.
MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows. Benefits of this include better resource utilization, better throughput and smoother reaction to failures. Slides - explaining MultiPath TCP - are available in .pdf and .pptx format. You can also have a look at our Google Techtalk about MPTCP.
The IP Networking Lab is implementing MPTCP in the Linux Kernel and hosting it on this website for users, testers and developers.
For questions, feedback,... please contact us at the mptcp-dev Mailing-List
I had to laugh when I saw the charts of LTE+wifi beating wifi alone in throughput. Even if the phone os was setup to try to exploit that, any wireless provider able to tie their own shoelaces is going to monitor multipath traffic like that and once they infer your alternate link is reasonably fast they'll start intentionally congesting their side of the path to force the bulk onto the local route.
I wonder what sort of additional profiling this could enable. Right now my phone is on 3g and my dual homed wifi network. It seems possible that being able to see my traffic from wireless, wireline ip4 and via my ip6 tunnel provider at the same time along with each path's latency would leak more data than existing hard handoffs.
Also, wifi already tend to be so much better that the bulk of the traffic would already go that way if possible without carrier interference.
The project has a number of working kernels for various android phones available.
Carriers would widely deploy ISM nets or whitespace if the handoff was painless and your streaming video worst case lagged out a couple of seconds.
I'm not saying multipath TCP will be very nice for mobiles, but it will mostly be home and work networks that will be used, just like how it is for wifi use in the mobiles today.
As for 2 second handoff being smoother than anything else out there today, that is just not true. The situation for phones doing handoff with EAP-SIM/AKA is pretty similar if not better.
Something considered a two second handoff is going to result in a far longer stream interruption than that in any method I've seen used especially considering the app is not assisting with the process or getting state transition info which it could be if built with mptctp aware libs.
+--------+ +---------+ +---------+
| Smart- +----WiFi----->| Gateway +---1Gb--->| Youtube |
| phone +-----3G------>| | | |
+--------+ +---------+ +---------+
Encapsulating tcp/udp inside it probably doesn't work very due to conflicts between the layers of buffers and congestion control.
Slides with more info:
What isn't mentioned is basically, because the change is 10KLoC to the kernel (unprecedentedly huge change for just the functionality they added) it hasn't even been submitted yet, and mainline hasn't even considered it yet.
I'd love to see it hit mainline, or parts of it start getting submitted, but the biggest thing will probably be re-writing the whole thing to have a much smaller impact on the kernel, while still providing the functionality they need (e.g. use the TCP backoff instead of their own, etc).
Edit: one advantage I can think of is you don't have to ask your users to set up a bond0 interface, for example. Any other advantages?
Because of that, LAG/MLAG can support more than just MPTCP and, in fact, the two aren't mutually exclusive.
It seems like the kernel's just treating it as a "dumb" tcp connection that rx's and tx's on more than one interface. In this case you're taking the problems existing tcp connections have and multiplying them by the number of links. SCTP works around these problems and makes both the connection and the delivery of arbitrary messages more reliable, though seemingly at a heavy cost to performance.
I would also be interested in hearing what needs to be done on the Client End for Multipath TCP to be supported; For example, say I was to build a Linux Server with the Multipath TCP enabled Kernel (to serve my App), would the Clients (likely Mobile Smartphones) also need to run an O/S with a Multipath TCP enabled Kernel? I'm assuming the answer is Yes, but I'm kind of hoping I missed something and the answer is No. Because if this is the case, then both Android and iOS would need to support Multipath TCP (which means this may not become mainstream for quite some time).
Also, I noticed the referenced PDF said the Technology was already being Licensed (with a Non-Disclosure Agreement). This seems to imply it will not be Open Source. I checked the Git Repo, and don't see anything about this. Are the Developers / Researchers related to Multipath TCP intending to Open Source this?
In any event, Thank you for this release, something fun to play with!
2. I'm in the team working in the Linux Kernel implementation and yes this is open source! http://multipath-tcp.org/pmwiki.php?n=Users.DoItYourself
Routers today are doing 32x100GbE in a single chassis. That's an investment in hardware that isn't going to go away any time soon.
SCTP already solved this problem. Multipath TCP is an also-ran.
SCTP requires either recompiling applications or using a TCP/SCTP proxy, and it doesn't solve the middlebox or discoverability problems. There's room for both solutions.
I think the parent comment is valid though. If we wind up holding 2 or more TCP connections to multiplex, with failover, we are basically creating an overlay network that will have the same needs as the lower levels. Namely, routing, link cost metrics, fragmentation, etc... This is effectively what IP attempts to add on top of 802.3.
With that in mind, it seems like it would be more faithful to the point (possible, if not practical) to use the Ethernet+IP stack directly on top of two TCP connections (providing simulated physical links), creating a throw-away network segment between two hosts that could re-use existing routing and bonding logic. I don't think Linux could handle that many virtual interfaces or taps, but that feels like the right place for it...
I'm not aware of any device that is software-based that could come remotely close to handling that about of traffic. Most current PC-level hardware has trouble w/ 2x10GbE links (if they can even support that).
Going forward, I suspect GPUs could also be applied to make routing decisions with acceptable speeds. Have a look at http://www.date-conference.com/proceedings/PAPERS/2010/DATE1... for some trials.
On a typical Intel PC, the MMU's TLB is implemented in CAM as well but it's tiny in comparison to the ones in routers. CAMs are pretty power hungry compared to RAM. They are becoming commodities though and the router manufacturers are getting away from doing custom ASIC designs. Intel bought Fulcrum which makes these packet processors and companies like Big Switch are doing cool stuff with white box network hardware. It's really going to bring the cost of the hardware down pretty dramatically in the next couple years.
Basically, ANYTHING you try to do at the speed and scale you'd end up needing to use these routers for would be at least as complicated if not more so.
The level of engineering required to de-encapsulate a packet, deal with the L2(Ethernet),L2.5 (MPLS), L3(IP) headers, perform a lookup in the appropriate table (might be more than one), possibly deal with any encapsulations INSIDE that packet (cough-cough GRE) which starts the whole process over again is IMPRESSIVE. You're not going to do that in software, my friend. And anything you build that even begins to look like a general purpose processor will be unable to perform to the degree to which the custom ASICs already do.
NPU (Network Processor Units) were supposed to make this easy but they never took off so now what few remain are doing things like NAT or Application Firewalls, and doing a relatively poor job for the money compared to a reasonable x86 server with appropriate I/O engineering.
tl;dr: you're woefully ignorant about what it takes to make the Internet run fast.
The rest of your comment is pretty insulting. :)
Go read up on how IP routers actually function and then report back with what you've learned.
Source: I've been doing this (networking) since before there was an Internet. I currently don't touch routers that do anything less than 10Gbps/port and really prefer to work with 100Gbps/port. That's a cool couple o'million bucks per chasis, yo.
Also, we have a measurements campaign running, if you want to contribute ;)
Given the subject matter, I should probably include my usual disclaimer string: I work as a software engineer for F5 Networks. Anything I post here is my own thought and is not intended to represent F5.
In this particular case we owned both the client and server-side networking libraries - but all-in-all it worked quite well and helped us deal with NAT traversal issues among other things.
SCTP is the solution to the problem that Multipath TCP is trying to solve. The biggest challenge is the penetration of TCP libraries vs. SCTP libraries.
Some applications will perform much faster over TCP because the link is short, reliable, and the application only needs to stream data in-line. Heck, even with network loss you can see gains in TCP vs SCTP.
Some applications will be faster with SCTP because of either the nature of how the application handles network data, or the properties of the network they're traveling over. But speed was never a design consideration of SCTP.
If you want speed, use UDP. If you want something that's fast and "just works", use TCP, or this multipath TCP thing. If you want something designed to pass multiple independent unidirectional data messages across a single "connection" that can span multiple network paths and never miss a beat, use SCTP.