North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Traffic engineering tools
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 <[email protected]> ... >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.