Subject: Re: [rrg] ILNP and MPTCP [was multi-homed site issues]

From: [email-masked]
Date: Wed, 11 Aug 2010 04:55:23 EDT

In einer eMail vom 10.08.2010 23:54:23 Westeuropäische Sommerzeit schreibt  
[email-masked]:

For  example, if multiple locator pairs all result in paths that coincide 
on a  particular congested link, then the benefits of multi-pathing could be  
extremely limited.

This is exactly one of the points I have been trying to make. Detouring the 
 congested node/cluster  should start  at some optimal closest  node - at 
best there where the alternate path is not really a  detour. 
A detour path that starts at the sending host may  easily melt with the 
original path prior reaching the congested node. It  may even cause additional 
problems in case the path between ingress and  "melt"-node is known to be 
"less performing" (lesser SLA).
 
And: MPTCP's intelligent locator selection can never be a concerted  
action. Note, a congestion is not caused by one single IP-flow. Nor is it caused  
by a completely broken node (unless indirectly), which means that some flows 
 should continue to pass the congested node while others should detour it.
 
I can only repeat referring to that concept which I tried to launch 6 years 
 ago but was rated poor (assumably by some RRG subscribing expert) : I  am 
still sure that it is the right way to go - no matter what MPTCP or CONEX 
are  performing.
 
Heiner

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 11 Aug 2010 13:17:26 +0300

On Wed, Aug 11, 2010 at 11:55 AM,  <[email-masked]> wrote:
> For example, if multiple locator pairs all result in paths that coincide on
> a particular congested link, then the benefits of multi-pathing could be
> extremely limited.

Good question and this is hard to overcome in Internet.

>
> And: MPTCP's intelligent locator selection can never be a concerted action.
> Note, a congestion is not caused by one single IP-flow. Nor is it caused by
> a completely broken node (unless indirectly), which means that some flows

One way to approach this problem could be that the transport protocol
is indicating to the network layer that the first subflow must always
take the shortest path through the network. The second and following
subflows belonging to the same session is market with a flag by the
transport protocol at the network layer stating "in case of congestion
(or close to congestion) on a forwarding link apply Valiant
Load-Balancing for these flows". This would achieve what Heiner is
pointing out - one sublfow  of the session is still taking the
shortest path and the other subflows are forwarded to explicit paths,
offloading the congestion point.

-- patte