| |||||||||||||
Multipath TCP: an overviewMultipath TCP: an overviewPosted Mar 27, 2013 5:20 UTC (Wed) by dlang (✭ supporter ✭, #313)Parent article: Multipath TCP: an overview
This definitely sound interesting. As I see it the issue is going to boil down to how the subflows are managed.
It is also going to matter a lot on how the subflows are handled at each end (both ends have to work well)
If every application ends up having to implement this logic themselves, I don't think it has a chance of working outside of niche cases.
The question is if this logic belongs in a common library or in the kernel.
For now we are at the experimental stage where it should be done in userspace to allow for more experimentation. It will be interesting to see how the experiments settle out, especially in terms of catastrophic interactions between different strategies on the two ends.
(Log in to post comments)
Multipath TCP: an overview Posted Mar 27, 2013 9:07 UTC (Wed) by Lennie (subscriber, #49641) [Link]
That part is all mostly done.
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:
|
|||||||||||||