0

I am trying to understand how MPTCP differentiates itself from "normal" TCP implementations running over multiple paths.

Specifically, I want to know whether the best impementations of TCP are really less robust to packet reordering than MPTCP implementations.

I have come across two interesting sources, first an analysis of packet reordering in TCP Linux. It describes various ways how TCP implementations may handle reordering more or less efficiently. This is NOT about MPTCP, but TCP over multiple paths! The thesis highlights an interesting strategy, apparently implemented in the default linux TCP solution (and interestingly, also used in the more-experimental TCP Westwood implementations) (here, the 'interesting strategy' I'm talking about is using DSACKs to distinguish between reordered packets over packet losses).

Weirdly enough, though, the latter link compares the Linux TCP solution with MPTCP, and concludes that MPTCP is less effective. This, though, is over a low bandwidth on the order of Megabytes per second. The throughput of MPTCP is very stable, but apparently overall less efficient than the Linux TCP.

Now, I've looked at an analysis of MPTCP performance from 2012, which suggests in several places that MPTCP suffers a great deal from reordering when the traffic goes over links with widely different RTTs (which is typical for packet reordering), as well as Gigabyte-capacity links.

Now, my question is... how and where does MPTCP suffer from reordering? MPTCP describes itself as creating subflows for each separate link, where a subflow is essentially a small TCP connection. What I don't understand is, if MPTCP validates the order-of-arrival of its packets on each separate flow, how can it still suffer from packet reordering?

My intuition is that when the subflows "merge," there may be a need for a reordering of the packets, but there should be no confusion as whether the packets were lost or simply delayed (out-of-order), which means no significant performance loss should be witnessed resulting from out-of-order pakcets.

0

I have found a sufficient answer in this MPTCP paper. Essentially, MPTCP has a sequence order for the "overall" flow as well as for each flows. This means that MPTCP should, in theory, have no advantage over TCP in the area of packet reordering.

The MPTCP receiver uses the connection-level sequence number to reassemble the data streams coming from different [SubFlows] inorder (sic) to pass them to the application layer insequence (sic). Therefore, MPTCP uses a data sequencing mapping (DSM) to convert between the two sequence spacing. The DSM can be depicted clearly in Fig.1 where packet (5-S2) for example has a data-sequence-number equal to 5 and a subflow-sequence number equal to 2.The arrival packet is said to be in-sequence if and only if both the subflow-sequence and data-sequence are as expected.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.