The best answer is: both (endpoints as well as transit nodes) have interests in routing. E.g. here multi-homing, there traffic balancing. It is up to the architecture to serve both. CES versus CEE in the sense "an enduser must never experience any network layer issue" versus "should be the only one to..." makes no sense.
Heiner -----Ursprüngliche Mitteilung----- Von: Patrick Frejborg <[email protected]> An: Russ White <[email protected]> Cc: [email protected]; Noel Chiappa <[email protected]> Verschickt: Mo., 26. Apr. 2010, 10:36 Thema: Re: [rrg] Next pass On Sun, Apr 25, 2010 at 10:40 PM, Russ White <[email protected]> wrote: > I'm not certain it has anything to do with the technology. Rather, it's > a matter of reality: if you want steer traffic, you must have more > state. Either that state must be in the packet header (source routing), > in the construction of a tunnel (semi-permanent circuit), or in the > forwarding table. You can't get better traffic flow control with less > information; it's just a logical impossibility. > Russ, what are the underlying reasons to steer traffic? I think one reason is to utilize the network as much as possible, make use of all links that are available and share the load over them. Is this a task the only the network should do or can the endpoints participate in the traffic engineering as well? If the routing architecture announces attachment points (aggregated in DFZ) to Internet - the local network is not advertised throughout the DFZ - and having MPTCP on the endpoints the traffic engineering is taken care by the endpoints. If congestion or failure occurs on either attachment point the transport protocol shifts more traffic to the other path. Also, I find Valiant load-balancing interesting, but more studies around that topic is needed. So I think you necessarily don't need more state in the network if the endpoints can take greater responsibility for their sessions and the goal is to utilize all possible paths (attachment points). TE due to other reasons need other tools. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
