“Multipath TCP has several use cases, including smartphones that can use both WiFi and 3G, or servers that can pool multiple high-speed interfaces.”
I started building a home-brew application-level link sharing system once. When I realized I was basically reinventing TCP, I quit. If this multipath technique becomes commonplace, it will be awesome.
One warning though: it’s really easy to overlook when one of the links is broken. Without good diagnostics, you can be running on just the one remaining link until it, too, fails and then you’re troubleshooting multiple problems at once. It’s like RAID in that way.
http://linux.slashdot.org/story/13/03/23/0054252/a-50-gbps-connection-with-multipath-tcp
Hmm, after reading some of their “Architectural Considerations…” (http://tools.ietf.org/html/rfc6182) this worries me because asymmetric connections cause weird failure cases and buffering issues (the authors suggest that pairing a 100 Mbps link with a 1 Mbps link would be bad, and the latter should just be backup….). Again, diagnosis of failure cases can be hard.
Microsoft’s teamed NICs is a related LAN-based technology. That tech required some careful monitoring to know when one of the links was broken, but when it worked it was fantastic because apps were completely unaware when you pulled one of the ethernet cables. I hope that MPTCP is as good or better on a WAN scale.