Multipath TCP: an overview

It is just the standard existing socket API, if the other side supports it, it will automatically use multiple TCP-connections (subflows).

It also just looks like standard TCP-connections (with some extra option fields filled in) and it automaticalled falls back to regular TCP if something does not work. That means it also works when it encounters NAT.

There is no need to create any userspace code. It can even automatically use IPv6 when you already have connected to an IPv4 address.

It can also handle loss of the first connection.

It's working code, other than that this is a out of tree kernel patch you can run it in a production environment right now (I'm not a developer on this project, just an observer, so don't take my word from it). The RFC is done, the code was developed in parallel to writing the RFC.

As I see it most of work now is trying to shape the patch in such a way that it is ready for mainline. Yes, it can still use some tweaking, but there was already years of evaluating solution and performance testing done.

I really doubt there will be any large changes other then lots and lots of refactoring to get it into mainline.

One thing 'missing' might be an API extension for an application to ask for which IP-addresses/port-numbers it is using right now. Currently you can only use the existing API, which reports the original IP-address/port-numbers that were involved to create the connection.

And it looks like the developers are trying to make it easier to setup the needed routing (when you want to use 2 Internet connections, you'll need two network connections, so: 2 sets of IP-addresses and 2 default gateways).

Here are the demos:

https://www.youtube.com/user/cpaasch11/videos?view=0&...