| |||||||||||||
Multipath TCP: an overviewMultipath TCP: an overviewPosted Mar 26, 2013 23:17 UTC (Tue) by marcH (subscriber, #57642)Parent article: Multipath TCP: an overview
Looks like SCTP but done in a backward compatible way. Not just in term of middle boxes but also in the term of the socket programming API (so good bye message boundaries)
Other differences?
(Log in to post comments)
Multipath TCP: an overview Posted Mar 27, 2013 0:09 UTC (Wed) by nhorman (subscriber, #31658) [Link]
I'm not sure backward compatible is really accurate. Multipath joins still would require the application establishing two connections, ostensibly specifying the second connection as a join rather than a separate connection. Its certainly a neat idea, but it will certainly require some application modification, like sctp.
I wonder if there would be value in a user library that remapped tcp streams on toof multihomed sctp streams? Not universally useful of course, but perhaps a nice alternate solution in some situations
Multipath TCP: an overview Posted Mar 27, 2013 3:50 UTC (Wed) by ebiederm (subscriber, #35028) [Link]
Some API augmentation will doubtless be needed for refined control.
But you can establish a MP-TCP connection using the existing socket APIs. As part of that connect establishment the MP-TCP stack can share all of your routable IP addresses and see which IPs on either side can connect to each other.
With those additional connections MP-TCP can with proper congestion control load-balance your traffic across those flows.
Additionally MP-TCP can add and drop subflows as your device meanders around and connects and disconnects from different networks.
API augmentation is only needed for the times when the defaults aren't optimal for some configuration.
Multipath TCP: an overview Posted Apr 4, 2013 4:04 UTC (Thu) by kevinm (guest, #69913) [Link]
What do the getsockname() and getpeername() APIs do on a MPTCP connection?
Multipath TCP: an overview Posted Apr 4, 2013 6:24 UTC (Thu) by christophpaasch (subscriber, #54567) [Link]
It returns the info from the initial TCP subflow.
So, even if the host has moved away (e.g., moved away from its WiFi access-point and MPTCP switched to 3G), the syscalls still return the old address of the WiFi interface.
Multipath TCP: an overview Posted Mar 27, 2013 4:02 UTC (Wed) by corbet (editor, #1) [Link] The whole idea behind MPTCP is that applications don't need to be changed. It just looks like another TCP connection; the establishment of multiple subflows happens transparently.
Multipath TCP: an overview Posted Mar 27, 2013 13:58 UTC (Wed) by nhorman (subscriber, #31658) [Link]
Except that that really doesn't seem to be the case, at least not completely, and especially if you want application level control over stream selection policy. in the simplest case, consider hosts A and B each with ip addresses A1,A2,B1,B2. If an application on A makes two TCP connections from A1 to B1 and A2 to B2 on the same port, at minimum, the application will need to specify if the second connection is an independent connection (which would be the default without the existance of MP-TCP), or if its meant to join in the prior connection (i.e. flag the second connect with the MP_JOIN flag).
Note, I'm not implying that this is a knock against the notion of MP-TCP, just pointing out that its not completely transparent. Nor should it necessecarily be so. I'm sure that applications will want some level of policy control over which path they take (i.e. phones connected to celular and wifi networks will want to prioritize the wifi as its likely a faster connection).
Multipath TCP: an overview Posted Mar 27, 2013 14:07 UTC (Wed) by corbet (editor, #1) [Link] It seems to me that you are saying that an application doing explicit multipathing now will continue to need to be explicit about it in the future. And yes, when the ability to control MPTCP at the application level becomes available, such an application may well want to avail itself of those controls. But such applications are relatively rare. The vast majority of applications just make "a TCP connection" to somewhere; they will be able to benefit from multiple subflows (if their traffic is of the type that benefits, of course) without any changes at all.
Multipath TCP: an overview Posted Mar 28, 2013 17:13 UTC (Thu) by kov (subscriber, #7423) [Link]
Doing that transparently by default may be a problem for most mobile use cases. Consider a smartphone with a metered cellular connection and a WiFi connection. Most applications would probably not want to download big chunks of data from the cellular connection, even though it could be used to speed things up. That could be controlled at a system level, I imagine, but you'd either need a way of distinguishing at the system-level which applications should be allowed to use multi-path and which not. Or (what I think would be more likely) you'd disable it by default and have applications which really want to use it request it explicitly.
Multipath TCP: an overview Posted Mar 30, 2013 21:12 UTC (Sat) by roblucid (subscriber, #48964) [Link]
True, but wouldn't it be simpler and cleaner to have this policy as part of a virtual router in the device which actually kept the application IP/port the same?
Why should applications, worry & account for multi-homing an so on? You still end up adminstering firewalls to set a policy at a more feasible level.
Multipath TCP: an overview Posted Mar 30, 2013 22:02 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
remember that the server application/port can remain the same if the client has multiple connections. It's only in the case where the server has multiple connections that the it needs multiple IP addresses, and in that case I don't see any way around the issue.
I also don't expect servers to expose multiple connections very frequently, they don't need to and if they are serving substantial numbers of clients, they probably don't want to have any one client be able to use a substantial amount of bandwidth.
I see two categories where multipath TCP makes lots of sense
1. multi-homed clients (wifi + cell, DSL + cable + cell backup, etc)
Here, only the client has multiple IP addresses
2. huge file transfers within one organization on specially setup paths
Here both the client and server may have multiple IP addresses, and even with just a single IP at both ends, they may want to use many subconnections to be more resistant to the effects of packet loss.
Multipath TCP: an overview Posted Mar 31, 2013 7:43 UTC (Sun) by paulj (subscriber, #341) [Link]
There are a lot of trade-offs in multi-homing, because the different available connections may have different properties, e.g. in terms of cost, latency, throughput. The appropriate choice of trade-offs may well differ at different times, and/or for different users, and/or for different applications.
Trying to make the network handle choosing these trade-offs would require either building lots of complex logic into it, to try dynamically second-guess the needs of each user, and/or lots of signalling, to allow the user to instruct the network what it wants (with attendant state overheads in the network).
Pushing these problems out to the edges of the network - ideally to the end-stations - avoids the need for complex, fragile networks. Complex networks also tend to have an ossifying effect on development of new applications. Have a read of "The rise of the stupid network", mirrored at, e.g,: http://www.rageboy.com/stupidnet.html .
Basically, the network should be as simple as it needs to be, but no simpler. ;)
Multipath TCP: an overview Posted Apr 1, 2013 13:24 UTC (Mon) by intgr (subscriber, #39733) [Link]
> Pushing these problems out to the edges of the network - ideally to the end-stations - avoids the need for complex, fragile networks
Sorry to hijack this thread, but I wanted to stress this point. This is exactly what's wrong with NAT: it builds too much smarts into devices whose real purpose is just juggling packets around.
And you see the pains every time someone wants to add an extension to TCP (like MPTCP, ECN and others) or introduce a new transport protocol (SCTP, DCCP). In fact, even application developers suffer and have to come up with clever workarounds (STUN, TURN) or less clever (UPnP). People have to spend heroic amounts of time to work through all the potential issues these "smart" middleboxes introduce, with every vendor bringing their own quirks and bugs on the table.
In the end, innovation suffers and robustness of networks in general suffers due to all the workarounds that have to be employed.
It drives me nuts when people deploy IPv6 and still don't get it, "we're an enterprise, we need NAT". No you don't, you need a firewall.
</rant>
Multipath TCP: an overview Posted Apr 1, 2013 13:44 UTC (Mon) by paulj (subscriber, #341) [Link]
Note though "the network should be as simple as it needs to be, but no simpler." - to paraphrase someone.
While complexity generally should be pushed to the end-stations and kept out of the network, as much as possible, that does not mean *all* complexity should be kept out of the network. There are certain basic functions that *should* be kept in the network, along with whatever complexity is required to support those functions.
E.g. the original designers of TCPIP believed it was very important for the network to abstract away differences in MTUs. They argued that otherwise it would be difficult for end-stations to reliably work-around differences in MTU, so that it would become difficult for the network to make use of larger MTUs. This would block the use of techniques such encapsulation, extra-addressing, etc., by end-stations to solve problems such as mobility, etc. For this reason they made TCPIP support fragmentation at the network level.
Sadly, later implementors and stewards of IP concluded differently. They moved to deprecate fragmentation from IPv4, and excluded it completely from IPv6. Instead, it was left to the end-stations to negotiate the correct MTU. Unfortunately however the original designers of IP have been proven correct. End-station MTU discovery has been proven to be fragile, and often does not work, due to stupid intermediate nodes blocking the required signalling (which is out of band). At the best of times it probably adds more latency than network level fragmentation.
As a result, the Internet is crippled with a 1500 MTU. :( The success of IPv6 would likely set this in stone.
See my blog: http://pjakma.wordpress.com/2011/06/28/cerf-and-kahn-on-w...
Multipath TCP: an overview Posted Apr 1, 2013 15:46 UTC (Mon) by intgr (subscriber, #39733) [Link]
> End-station MTU discovery has been proven to be fragile, and often does not work, due to stupid intermediate nodes blocking the required signalling
Sounds like PMTU discovery has the same enemies: "smart" middleboxes (NAT) and enterprise admins (firewalls).
While I agree that protocol designers should have seen it coming, I still think the larger part of the blame lies with device vendors not implementing existing protocols to the specification and not releasing updates even when those problems are pointed out to them -- basically holding the whole industry hostage because the cost is externalized.
Which brings me to a crazy idea -- perhaps we need an "Acid test of consumer routers" -- following the model of acidtests.org, which pressured several browser vendors to improve on their standards conformance, because every savvy user could easily see how broken their choice was. Has anyone attempted something like this already?
Multipath TCP: an overview Posted Mar 27, 2013 14:47 UTC (Wed) by christophpaasch (subscriber, #54567) [Link]
An MPTCP-api is standardized in [1].
Yes, it could be useful for some applications to have better control on the paths being used. But, this assumes that applications actually know what they want... ;)
Right now, the implementation automatically creates a full mesh among the availabe IP-addresses on the client and the server.
Concerning your use-case where one wants to push more traffic on WiFi than 3G:
[1] https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
Multipath TCP: an overview Posted Apr 1, 2013 20:55 UTC (Mon) by cesarb (subscriber, #6266) [Link]
It is not "more traffic on wifi". If your 3G is metered and you are connected to wifi, _all_ traffic should be on wifi.
Multipath TCP: an overview Posted Apr 1, 2013 21:08 UTC (Mon) by christophpaasch (subscriber, #54567) [Link]
The protocol allows to not use 3G for data-traffic with the "backup-flag" (MP_PRIO-option in RFC 6824).
Or, it is also possible to simply not open up a subflow across 3G and only create it after the phone lost the WiFi connection. MPTCP supports break-before-make scenarios.
It is simply a question of instructing the kernel to do one or the other through some kind of configuration interface (may it be sockopts, sysctl,...)
Multipath TCP: an overview Posted Apr 1, 2013 22:11 UTC (Mon) by marcH (subscriber, #57642) [Link]
Just FYI: my home Wifi is routed to... a 3G, metered connection.
Far from ideal, but less and less unusual:
https://www.google.ie/search?q=3g+hotspot
Multipath TCP: an overview Posted Mar 27, 2013 0:09 UTC (Wed) by butlerm (subscriber, #13312) [Link]
SCTP is not designed for concurrent multipath transfer, although there are folks working to adapt it for that. Message boundaries, ordered and unordered message delivery, and logically independent message streams are the big differences.
The SCTP socket API is simple enough unless you want to communicate with multiple peers on the same socket or use multiple streams. Then it gets complicated.
Multipath TCP: an overview Posted Mar 27, 2013 3:30 UTC (Wed) by tterribe (✭ supporter ✭, #66972) [Link]
> Message boundaries, ordered and unordered message delivery, and logically
> independent message streams are the big differences.
Those can be done on top of TCP, too. See Minion: http://arxiv.org/abs/1103.0463
Multipath TCP: an overview Posted Mar 27, 2013 8:32 UTC (Wed) by butlerm (subscriber, #13312) [Link]
Minion looks like a great idea, and I hope they are successful.
Multipath TCP: an overview Posted Apr 4, 2013 7:45 UTC (Thu) by eternaleye (guest, #67051) [Link]
I thought it might be worthwhile to point out the main page of the Tng group, who created Minion: http://dedis.cs.yale.edu/2009/tng/
They also have a 'cross-layer negotiation' design, allowing the decision of *which* minion is used to be made on a per-connection basis.
Their general concept of splitting the Transport layer up is (in my view) a very useful one. Even though the IETF passed on codifying it into the literature, it's a very useful pattern in designing protocols - layer an endpoint layer, a congestion layer, an isolation layer, and a semantic layer.
By using UDP as the endpoint layer, you can (potentially) avoid some of the problems MPTCP had to engage in heroics to deal with.
By using (say) a portless variant of DCCP on top of that as congestion control, you have something that could still be within the kernel (after all, there are various protocols implemented in the kernel that go on top of UDP or TCP) but because of the benefits of using UDP as the endpoint layer you don't have the horrific barriers to deployment DCCP proper ran aground on. Plus, this makes per-link congestion control feasible without breaking end-to-end reliability - which has been a significant problem due to the absolutely atrocious interaction of TCP, wireless LAN, and multiple layers of retransmission latency.
Layering the isolation layer here (rather than on top of the semantics) is genius. Aside from that it means you only need a design for datagrams, and not streams (so you can use DTLS regardless of the application-level semantics), it also means that the (intelligent in braindead ways) middleboxes only know information that they might have a valid reason to touch. Beyond that, they basically get told to push off.
Finally, you can build just about any semantics you like on top, by using the resulting building block of secure, point-to-point, CC-friendly unreliable datagram channels.
|
|||||||||||||