Posted Mar 28, 2013 16:53 UTC (Thu) by raven667 (subscriber, #5198)
Parent article: Multipath TCP: an overview
I don't have the background to comment on this intelligently but I showed this to someone with more experience and they pointed out that they had seen many such research projects in the '80s but that they always failed because they were unable to account for all the complex interactions between the multiple streams and balancing data across them. Essentially they get bogged down in new and impressive corner cases where traffic stops or where it causes extreme congestion. This may be something that is only useful on a local managed network and not across the open Internet.
Posted Mar 28, 2013 17:44 UTC (Thu) by christophpaasch (subscriber, #54567)
[Link]
Does your friend you are mentioning may share the references of his claims?
MPTCP has no issues with head-of-line blocking, because the receive-window is not on a per-subflow level but rather on the data-level [1].
I don't see, how MPTCP could cause extreme congestion, because the coupled congestion control makes sure that MPTCP is fair to other flows across shared bottlenecks [2].
Posted Mar 29, 2013 13:51 UTC (Fri) by paulj (subscriber, #341)
[Link]
I don't quite remember the details, but I sat through a presentation by someone involved with MP-TCP. They were a mathematician who'd been brought on to work on the congestion control side and formulate a mechanism that would work and be fair to both MP-TCP and plain TCP flows.
Not vouching for their success in this, but they do appear to have thought about congestion control.
Multipath TCP: an overview
Posted Mar 30, 2013 8:37 UTC (Sat) by gdt (subscriber, #6284)
[Link]
There are no end of those protocols. I work in academic networking and I've experienced my fair share of them. Usually they are to compensate for poor single-flow performance, a problem Linux generally doesn't have if you simply give enough memory to the autotuned TCP buffers.
MPTCP is the idea implemented well. That's a good thing, as it gives us a place to point users who think they might do better implementing this idea themselves.