| |||||||||||||
Multipath TCP: an overviewMultipath TCP: an overviewPosted Mar 27, 2013 14:07 UTC (Wed) by corbet (editor, #1)In reply to: Multipath TCP: an overview by nhorman Parent article: Multipath TCP: an overview 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.
(Log in to post comments)
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?
|
|||||||||||||