Traffic engineering tools

[Vadim_Antonov2]

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>

...

[John_Patteson]

TE [snip] simply reallocates existing resources differently.

In reading your mail, I’m reminded of one of my favorite RFC’s…
“The Twelve Networking Truths”

(10) One size never fits all.

On the whole as a global solution, I would agree with you that different is not necessarilly better, and sub-optimal routing is not the best of solutions. There is an ISP we deal with who bounces their traffic around the network until it finds an available exit. All the exit points are nearly equally balanced, but the network as a whole is slow.

In some specific cases however (mostly peering), the peer’s dynamic routing chooses what it believes to be the optimal exit path by choosing ‘closest gateway’/‘nearest exit’ routing. In these cases, sub-optimal utilization of your own external connections by the peer creates severe congestion/loss.

As an example I would present a peer with multiple connections to your network in topologically distributed locations (ie. opposite sides of your network). If the peer is utilizing one link in one direction at 80% and the other two at 10%, you need to make some adjustments in local pref, or redirect your outbound traffic destined for that peer (or his downstreams) to the peer’s underutilized path(s). Otherwise you’re going to have packets all over the floor at the link with 80% utilization. (!)

TE is necessary more often than most would care to admit, and occurs mostly at network borders, because none of the carriers/providers like having to pay for additional external connectivity any sooner than they absolutely have to.

If you are a large provider with a large number of multiply-connected peers, traffic engineering (though rare) is a fact of life. Of course from an implementation standpoint Truth number 6 says:

(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.

…aww, heck, from any standpoint.

Note that customers do not generally care about bandwidth.

You didn’t actually think I’d let this one slide, did you?

Next time you can talk to the guy who’s whining that his 1.544Mb T1 (ESF, AMI, B8ZS & TCP/IP) is only getting ~1.4Mb throughput (and of course, he’s testing it with a web browser). After all, he’s paying for bandwidth, and he’s the customer, and the customer is always right.

[the solution is] adequate provisioning and capacity planning

Which of course is the BEST way to handle most network problems, IF you have the money. Which brings me to the corollary to fundamental truth number 7:

Good, Fast, Cheap: Pick any two (you can’t have all three).

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.

Of course there are benefits! They just don’t have anything to do with the network. Why spend $1,000’s on new pipes/routers when you can solve your problems for (almost) free by buying whatever will allow you to tweak your routing and ‘optimize your utilization of existing resources’.

(I cut and pasted that from a certain vendor’s marketing literature)

Vendor Marketing plays on your Management’s fears. There’s nothing that scares management more than justifying money spent, especially money spent for ‘unneeded’ resources. The fact that that shiny new gigabit pipe WILL eventually be fully utilized is immaterial. It’s not being used NOW.

Small money is a small risk, and traffic engineering alleviates the problem at the problem point sufficiently to make it appear that it has gone away. It does this for minimal cost expenditure, which is an ‘optimal’ solution where management is concerned.

Which brings me to my own personal addage:

You can troubleshoot layers 1-7,
and work with layer 8 (users/engineers),
but there is absolutely nothing you can do with layer 9 (Management).

As for why anyone would use ATM (B-ISDN):

(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.

–JP