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

From: [email-masked]
Date: Wed, 11 Aug 2010 07:03:04 EDT

In einer eMail vom 11.08.2010 12:28:37 Westeuropäische Sommerzeit schreibt  
[email-masked]:

On Wed,  Aug 11, 2010 at 11:55 AM,  <[email-masked]> wrote:
> 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.

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
> should continue to  pass the congested node while others should detour it.

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

A better way is to go with my proposed concept.
BTW, concurrently I tried to launch a state-less multicast  solution: 
State-less in the sense that approx. 1% of the participating routers  have to 
have states. It was nevertheless rated poor.
 
Now consider a congestion which is hampering multiple multicasts (e.g.  
multiple TV multicasts with receivers all over the world)  - may  they be 
according to my proposed cascade tree multicast or according to any  other 
classic multicast solution: In either case, it doesn't make any sense  to detour 
the hereby occurring congestions  (there may be  multiples,btw) by informing 
the source as tó change the source's locator.  Don't you agree?
 
Heiner
 
It just doesn't make

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 11 Aug 2010 22:15:25 +0300

> A better way is to go with my proposed concept.

Maybe, maybe not.
I'm not familiar with your approach - and it is too early to decide
for a proposal when ideas are needed.

The idea I had is quiet simple - if there are subflows with the flag
set as alternate subflow and a congestion occurs, then forward these
packets to an alternate path that is e.g. calculated by the LFA
algorithm. This shouldn't send the alternate subflow too far away from
the shortest path - but offload the congested link. If a link gets
congested at the LFA node, it should send its alternate subflows to
its LFA nodes - except to the one which has went into congestion
avoidance (so some extension is needed at the IGP). If the congested
link breaks the subflows with flag not set are rapidly restored,
alternate subflows are switched to the new LFA path  - if there is no
new LFA path, well, alternate subflows are lost.
With this scheme you could move alternate subflows to less congested
links when traffic load increases, away from the hot spot. When there
is less traffic and no congestion occurs there are no need to shuffle
subflows away from their shortest path.

This is an early idea, it would need a new forwarding plane (but LFA
algorithm exist already in some router OS) and a lot of multipath
enabled hosts. But most of all, some research work and simulations is
needed to verify if this really could work in a real backbone with x %
multipath subflows. Also, what will the scheduler at the transport
protocol do when it notice that the roundtrip for one subflow
increases - send more packets to the other subflow ?
It could also be the case that the alternate subflows works better
than the ordinary subflow, using the LFA congestion avoidance may not
clear up the congested link but the alternate subflow might have no
congestion at another node though roundtrip increases with a few
milliseconds.

> classic multicast solution: In either case, it doesn't make any sense
> to detour the hereby occurring congestions  (there may be multiples,btw) by
> informing the source as tó change the source's locator. Don't you agree?
>
Nope, to build a high available multicast solution I have used P2MP-TE
and looking forward to have hands on M-LDP :-)

- patte