| |||||||||||||
Multipath TCP: an overviewMultipath TCP: an overviewPosted Mar 27, 2013 7:23 UTC (Wed) by gylle (subscriber, #15057)Parent article: Multipath TCP: an overview
Combining multiple paths for increased performance (link aggregation) works very well for identical paths, like the port trunking done between two Ethernet switches. Trying to do the same over very different paths as in the Wi-Fi and cellular example in the article is more difficult. Ordinary TCP suffers from out-of-order delivery. If the same TCP session is naively load balanced over Wi-Fi and cellular you often get performance that is a bit worse than the slower of the links alone. How does MPTCP deal with this?
(Log in to post comments)
Multipath TCP: an overview Posted Mar 27, 2013 9:03 UTC (Wed) by christophpaasch (subscriber, #54567) [Link]
If the paths have different delays (e.g., WiFi vs. 3G), the Head-of-line blocking is "fixed" by reinjecting the blocking segment on the faster subflow.
You can have a look at the scientific paper, which describes this mechanism:
(Section 4.2)
Multipath TCP: an overview Posted Mar 27, 2013 11:46 UTC (Wed) by gylle (subscriber, #15057) [Link]
Thanks! That was what I was looking for. Quite a costly fix though.
Multipath TCP: an overview Posted Mar 27, 2013 12:43 UTC (Wed) by christophpaasch (subscriber, #54567) [Link]
Costly, in terms of what?
Because we reinject the data on another subflow and thus use its bandwidth?
Multipath TCP: an overview Posted Mar 27, 2013 12:45 UTC (Wed) by christophpaasch (subscriber, #54567) [Link]
Actually, I agree that the stack should reinject as few packets as possible to prevent wasting bandwidth.
But there won't ever be more than one reinjection per RTT of the fast subflow.
|
|||||||||||||