Subject: [multipathtcp] Multipath IP for single-home sources

From: [email-masked]
Date: Sun, 23 Aug 2009 21:31:48 +0200

Hi,

Do we really need multipath TCP? Can not we address the problem simply  
at the IP layer?

Consider the scenario of a single sender which has two paths to the  
destination with average latency of l1 and l2 (l2 > l1). The IP layer  
needs to alternate the packets between these two paths; t1 (t2) is the  
time the outgoing packets are redirected to first (second) path. If t2  
 > (l2-l1), then the unnecessary fast-retransmits/recovery events are  
avoided automatically.

The secret is that the interleaved receptions of the packets at the  
destination does not trigger the fast-retransmits/recovery timer, even  
though the packets are received reordered. The details can be read at  
pages 3276-3278, Section 6.2 of this paper: "Improving performance of  
transport protocols in multipath
transferring schemes" available at
http://dx.doi.org/10.1016/j.comcom.2007.02.017

Regards,
   Maysam Yabandeh

PS: If you do not have access to the paper, a preliminary version of  
the paper is also accessible at this address:
http://web.ut.ac.ir/routerlab/members/yabandeh/journal-reordering-v1.1.pdf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Aug 2009 17:19:02 +0200

On 23 aug 2009, at 21:31, [email-masked] wrote:

> Do we really need multipath TCP? Can not we address the problem  
> simply at the IP layer?

That would only be helpful if we don't have to duplicate TCP state in  
the IP layer. As far as I can tell from your paper, you want the IP  
layer to distribute the packets over the paths such that fast  
retransmit is avoided. This can only be done by at the very least  
tracking per-destination state, but probably requires per-session  
state. Introducing this state into the IP layer is a duplication of  
effort because it already exists in the TCP layer.

Also, in the TCP layer we can simply ignore the conditions that would  
normally trigger fast retransmit if they are merely caused by the use  
of multiple paths, so we can know for sure what we need to do, rather  
than one layer tricking another into exhibiting the desired behavior.

---

From: Maysam Yabandeh <[email-masked]>
Date: Mon, 24 Aug 2009 17:48:24 +0200

On Mon, Aug 24, 2009 at 5:19 PM, Iljitsch van Beijnum<[email-masked]> wrote:
>> Do we really need multipath TCP? Can not we address the problem simply at
>> the IP layer?
>
> That would only be helpful if we don't have to duplicate TCP state in the IP
> layer. As far as I can tell from your paper, you want the IP layer to
> distribute the packets over the paths such that fast retransmit is avoided.
> This can only be done by at the very least tracking per-destination state,
> but probably requires per-session state. Introducing this state into the IP
> layer is a duplication of effort because it already exists in the TCP layer.
>

You have a valid point. However, the only state the IP layer needs to
keep is latency of the paths and the last time a packet is forwarded
to them. It is true that it is kind of duplication, but some people
think that i) the amount of extra states are negligible and ii) it
would be a neater solution compared to updating TCP layer, specially
that the mentioned changes to the IP layer must be limited to a few
lines.

> normally trigger fast retransmit if they are merely caused by the use of
> multiple paths, so we can know for sure what we need to do, rather than one
> layer tricking another into exhibiting the desired behavior.
>

It could be true, if we knew for sure that the condition has triggered
because of multipath effect and not other normal reasons.
Differentiating between these two is not easy and adds extra
complexities to the TCP layer.

Regards,
  Maysam Yabandeh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Aug 2009 11:30:46 +0200

> that the mentioned changes to the IP layer must be limited to a few

Not sure if the IP changes are that simple: you would need a good way  
to measure RTTs. RTTs are always variable because of normal burstiness  
but also depend on packet size. So this is not entirely trivial.

Another issue is that the requirement to avoid fast retransmit limits  
the possible distributions of the packets, so an IP-based solution  
can't be as flexible shifting traffic away from congested paths as a  
TCP-based solution.

The only advantage that I see of an IP-based solution is that it could  
be implemented in routers or middleboxes.

> complexities to the TCP layer.

With SACK we know which packet was acknoweledged and if we remember  
which path that packet was sent over, we can do fast retransmit for  
each path separately. See the one-ended multipath TCP draft.