In einer eMail vom 11.08.2010 21:15:31 Westeuropäische Sommerzeit schreibt [email protected]:
On Wed, Aug 11, 2010 at 2:03 PM, <[email protected]> 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
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
