From tony1@home.net Tue Oct 26 05:39:16 1999 Date: Mon, 25 Oct 1999 22:13:35 -0700 From: Tony Li <tony1@home.net> To: Alex P. Rudnev <alex@virgin.relcom.eu.net> Cc: Vadim Antonov <avg@kotovnik.com>, abender@tns-inc.com, akyol@pluris.com, nanog@merit.edu Subject: Re: Traffic engineering tools
Alex,
You are absolutely correct. A critically damped, dynamic traffic engineering system would provide benefits above and beyond that which can be derived in a static system.
However, the dynamic system is non-trivial to construct. As has been shown with routing protocols that react to dynamic changes, it is very easy to underdamp the system, with catastrophic results.
I certainly believe that such dynamic systems are possible, and certainly folks with enough background in control theory could contribute wonderfully here. However, the state of the art isn't quite there yet. Sigh.
"And that's the way it is..." - Walter Cronkite
Hear, hear! Beside simply solving the static minimization problem, decentralized computation, and consideration of disjoint restoration paths are what I see to be necessary prerequisites ( and arguably quite "interesting" ones ) for the realization of dynamic TE. Evading these is something that we seem to have succeeded at, as engineers. As "easy" as it may be to prove the computational complexity of a problem, I find offense instead in equating such a result with a decisive judgement on practical tractability. I agree with Mr. Li that this is an approachable domain, although many of its challenges remain areas of active interest. The design of contemporary network elements suggests the unfortunate level of attention this topic receives. Despite impressive improvements in datapath, equipment control planes still seem to be sized / designed for maintenance of traditional topologies with established methods. 1000MIPS* integer cores are readily available in general purpose, commodity devices, and higher performance is neither impractical nor unknown. The possibilities this suggests for performance headroom of control systems should permit more serious consideration of practical solutions for dynamic TE than is observed today, dispensing with easy reasons not to implement path otimization or TE as a (semi-) automated, online function. Regards, Andrew Bender Total Network Solutions, Inc. (* Yes, this metric is an arbitrary and somewhat bogus oversimplication)
While I fully agree with Tony's comments on damped control systems, we also have to ackowledge the desire for fast failure recovery. When a person talks about recovery times measured in the same units as link RTT, it is very difficult to create well damped systems. Many systems that work fine in simulation and in "normal operation" die a horrible death as circuits start to fail. Those people pointing to theoretical complexity tend to be proven correct, in my experience. I will also point to an idea that Vadim has championed for a long time that fast lines should go down quickly and up slowly rather than up quickly and down slowly as they do now. It doesn't solve the damping problem, but it does allow you to be more aggresive in taking failed lines down without destabilizing current algorithms. Someday YFRV may offer this as an option, perhaps some of them do already. I do believe that some of the TE folks are punting the general case solution by only attempting to do TE and protection on a small potion of their traffic. If you have a glut of web traffic that acts as a sponge, you can get away with nonoptimal management of the subset without causing meltdowns. jerry
Just to point out. IOS 12.0(6) supposts restart delay after the interface goes down. Now it doesn't really detect the line problem fast, except possibly at the CSU level, as HDLC links still depend on the default 10sec keepalive, although you could tune that also. Although it doesn't appear restart delay is documented in any of the usual places, it does seem to work. In message <Pine.BSI.4.05L.9910261246180.20140-100000@sh.lh.vix.com>, Jerry Scha rf writes:
While I fully agree with Tony's comments on damped control systems, we also have to ackowledge the desire for fast failure recovery. When a person talks about recovery times measured in the same units as link RTT, it is very difficult to create well damped systems. Many systems that work fine in simulation and in "normal operation" die a horrible death as circuits start to fail. Those people pointing to theoretical complexity tend to be proven correct, in my experience.
I will also point to an idea that Vadim has championed for a long time that fast lines should go down quickly and up slowly rather than up quickly and down slowly as they do now. It doesn't solve the damping problem, but it does allow you to be more aggresive in taking failed lines down without destabilizing current algorithms. Someday YFRV may offer this as an option, perhaps some of them do already.
I do believe that some of the TE folks are punting the general case solution by only attempting to do TE and protection on a small potion of their traffic. If you have a glut of web traffic that acts as a sponge, you can get away with nonoptimal management of the subset without causing meltdowns.
jerry
--- jerry@fc.net Freeside/ Insync Internet, Inc.| 512-458-9810 | http://www.fc.net #include <sys/machine/wit/fortune.h>
participants (3)
-
Andrew Bender -
Jeremy Porter -
Jerry Scharf