Traffic engineering tools

Tue Oct 26 21:05:17 UTC 1999

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 at 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.