In einer eMail vom 11.08.2010 12:28:37 Westeuropäische Sommerzeit schreibt [email protected]:
On Wed, Aug 11, 2010 at 11:55 AM, <[email protected]> wrote: > In einer eMail vom 10.08.2010 23:54:23 Westeuropäische Sommerzeit schreibt > [email protected]: > > 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
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
