----- Original Message -----
Sent: Tuesday, October 26, 1999 5:05
PM
Subject: Re: Traffic engineering
tools
> 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
---------------------------------------------------------------
"No matter how hard you push and no matter what
the priority,
you can't increase the speed of light."
Fundamental Truth
#2 -- RFC 1925
---------------------------------------------------------------