Traffic engineering tools

Thu Oct 28 04:10:38 UTC 1999

----- Original Message ----- 
From: Vadim Antonov <avg at kotovnik.com>
To: <abender at tns-inc.com>; <scharf at vix.com>
Cc: <nanog at merit.edu>
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
---------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/19991028/fd6a83c5/attachment.html>