nanog mailing list archives
Re: Traffic engineering tools
From: Vadim Antonov <avg () kotovnik com>
Date: Tue, 26 Oct 1999 14:05:17 -0700
Traffic Engineering is like Quality of Service - it doesn't create any more bandwidth by magic, and simply reallocates existing resources differently. That established, we have two courses of action - the first, is to bulild overcomplicated networks and then try to fix resulting suboptimal routing with TE. The second option is to simplify topologies by replacing clusters of routers with scalable and inherently fault-tolerant devices (guess which ones i have in mind :) In a long-distance backbone where routers connected directly to fibers, and where there's no overlay of level-2 topology, the cost of deliberate misrouting (sending packets down paths different from shortest) is simply too high to justify any benefits it brings. The intermediate virtual circuit layers simply obscure the fundamentals by making paths inherently non-optimal (if you do not plan to use SONET or ATM VCs to create topologies which do not match physical paths, why whould you want to install it?) Note that customers do not generally care about bandwidth. The name of the game is latency at a given load. Misrouting packets simply increases latency. So. Benefits of TE as compared with simpler and more robust techniques (such as adequate provisioning and capacity planning :) weren't demonstrated in practice. I have yet to see any real backbone operator saying something like "we've got 30% less latency because we do TE". I strongly suspect that is because there are no real measurable benefits - and that TE is being used mostly to cover up planning problems and as a short-term fix to idiocies at a transmission level. That is a very thin justification for replacing technology which is known to work with a very new can of worms. My personal theory on QoS and TE hoopla is that this is a FUD tactics used by Cisco to raise entry barriers for other vendors - and to con customers into buying more of their irrelevant ATM stuff. --vadim PS There were tons of research and articles on best methods of CPU and memory scheduling. In restrospective, building faster processors turned out to be the soultion. Even if they're 99% idle. Meanwhile, the vendors which were keen on doing detailed accounting stuff nearly all are history by now.
From: Jerry Scharf <scharf () vix com>
...
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.
Current thread:
- RE: Traffic engineering tools, (continued)
- RE: Traffic engineering tools Patrick Greenwell (Oct 21)
- Re: Traffic engineering tools Prabhu Kavi (Oct 22)
- RE: Traffic engineering tools Patrick Greenwell (Oct 21)
- RE: Traffic engineering tools Andrew Bender (Oct 22)
- RE: Traffic engineering tools Bora Akyol (Oct 22)
- RE: Traffic engineering tools Vadim Antonov (Oct 22)
- RE: Traffic engineering tools Alex P. Rudnev (Oct 25)
- Re: Traffic engineering tools Tony Li (Oct 25)
- RE: Traffic engineering tools Alex P. Rudnev (Oct 25)
- Re: Traffic engineering tools Andrew Bender (Oct 26)
- Re: Traffic engineering tools Jerry Scharf (Oct 26)
- Re: Traffic engineering tools Jeremy Porter (Oct 26)
- Re: Traffic engineering tools Jerry Scharf (Oct 26)
- Re: Traffic engineering tools Vadim Antonov (Oct 26)
- Re: Traffic engineering tools John Patteson (Oct 27)
- Re: Traffic engineering tools Vadim Antonov (Oct 26)
- Re: Traffic engineering tools Prabhu Kavi (Oct 28)
- Re: Traffic engineering tools Alex P. Rudnev (Oct 28)
- Re: Traffic engineering tools Prabhu Kavi (Oct 28)
- Re: Traffic engineering tools Vadim Antonov (Oct 28)
- Re: Traffic engineering tools Andrew Partan (Oct 28)