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

From: [email-masked]
Date: Mon, 9 Aug 2010 17:33:13 EDT

In einer eMail vom 09.08.2010 22:50:03 Westeuropäische Sommerzeit schreibt  
[email-masked]:

One can  argue that our layering structure is mis-constructed (as John 
Day  does). 
I do not know John Day's arguments and therefore don't question the  
existing layering.

But even  if it is misconstructed, with the approach we use, 
flow control and  congestion response are very separate functions from 
the path finding  functions.  Intertwining them makes life much more  
complicated.
If we look at it as a layer construct,  Network is concerned with path 
finding / forwarding, and transport is  concerned with reliability, folw 
control, congestion response, and other  end systems issues.
This is related to the ideas behind moving end  functions to end systems 
(buffering and flow  control).

IMHO, buffering and flow control is the task of the transport layer while  
detour forwarding i.e. making a next hop selection out from a set of  
multipath-alternatives is a network layer task. I don't want to intertwine both  
mechanism for responding to congestions. And I don't suggest any throttle wrt 
 flow control. The huge traffic bulk is video/TV where throttling would 
destroy  the service. The solution  can only be an intelligent and concerted 
concept  for detouring the congested node( cluster). 
Some traffic can easily bypass it, some other traffic which would require  
longer detours might still be sent via the congested node.
 
Why can't we build such an intelligent network layer ?
Heiner
 
Yours,
Joel

[email-masked] wrote:
> 
> In  einer eMail vom 09.08.2010 20:08:06 Westeuropäische Sommerzeit 
> schreibt  [email-masked]:
> 
>     and congestion response  is definitely NOT
>     the network layer's  responsibility.
> 
> Joel,
> Why ? The TCP endpoints don't  have any idea how to dissolve a 
> congestion. It takes a concerted action  in the network for dissoving a 
> congestion such that it is not just  relocated. Individual TCP endpoints 
> may only try out SOMETHING ELSE -  without seeing, without knowing. 
>  
> Heiner

---

From: [email-masked]
Date: Tue, 10 Aug 2010 06:54:45 EDT

In einer eMail vom 10.08.2010 08:32:10 Westeuropäische Sommerzeit schreibt  
[email-masked]:

On Aug  9, 2010, at 8:07 AM, Joel M. Halpern wrote:

> There is an  interesting question of how to handle congestion management 
when we move the  multi-pathing down to the network layer.
> On the one hand,  architecturally it seems appropriate for network layer 
to be managing the path  selection.
> 
> On the other hand, the congestion behavior of the  various paths is 
likely to be quite different, and congestion response is  definitely NOT the 
network layer's responsibility.
> 
> The  correct balance is not obvious to me.  (This is similar to, but not 
the  same as, the path selection policy issues that the MIF working group is 
trying  to understand.

I'd recommend that we also consider locator  selection as another degree of 
freedom. 
'Right.

I agree  with Joel that flow control belongs to the transport layer, and 
that path  selection is part of the network layer.

Right.

Is  locator selection a transport function?  It would seem that having it 
be  a unilaterally network layer function is over constraining the  
architecture.  Yet, transport cannot perform intelligent  locator selection without 
network layer input.

Consider locator selection to be the host's next hop selection. Also  
consider the possibility that a congested node propagates in upstream direction  
(wrt to the congestion causing incoming flows) intelligent notification  
information ( degree of congestion: one goal might be to avoid congestion in 
the  first place; distance i.e.(transitively incremented) number of hops down 
to the  issuing congested node,....).
The more upstream node may more easily select an alternative next hop which 
 ensures bypassing the congested node - than the immediate neighbor node  
e.g.
Only eventually the upstream going congestion notification will reach the  
sending host as to induce a change of locator selection.
 
Yes, transport cannot perform intelligent locator selection without network 
 layer input.
It starts with intelligent data provisioning of an intelligent network,  
which  is forwarded upstream - up to the sending  host eventually.
 
Heiner

---

From: [email-masked]
Date: Wed, 11 Aug 2010 17:23:01 EDT

In einer eMail vom 11.08.2010 21:15:31 Westeuropäische Sommerzeit schreibt  
[email-masked]:

On Wed,  Aug 11, 2010 at 2:03 PM,  <[email-masked]>  wrote:

>
> 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.

To me it sounds like try and error.

> 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?
>
Nope, to build a high available multicast solution I  have used P2MP-TE
and looking forward to have hands on M-LDP  :-)
Sounds like MPLS marketing;    I won't take it too  serious:-) and keep 
saying that
detouring the congested node/area should be done in a concerted action  
inside the network.
Heiner

- patte