Traffic Engineering

Kent W. England kwe at geo.net
Wed Sep 17 17:19:04 UTC 1997


At 09:59 AM 9/17/97 -0500, pkavi at pcmail.casc.com wrote:
>     
>     As a former network design guy who's done traffic engineering and 
>     design (and redesign) on many networks (Internet and otherwise), I 
>     disagree that traffic engineering doesn't work for the Internet.
>     

Prabhu;

Thanks for the treatise on network engineering. I agree that network
engineering is useful and that there should be traffic engineers. However,
the engineering managers must not forget to see the forest for the trees
and must heavily discount the traffic engineering studies, when faced with
out-of-the-box data.

Here are some examples:

>     2.  Identify which % of traffic, if any, has regional locality.
>         For pure Internet traffic, the probability that the source and 
>         destinatino of traffic are within the same metropolitan area 
>         tends to be low (10% or lower for metros within the US).  

This is true only so long as the density of the Internet is low. This is so
because so long as the density is low, few of your neighbors will be on the
Internet and therefore local issues are irrelevant. However, at some point,
the density of the Internet gets to a critical point, say 30% to 40%. At
that point a pizza parlor owner says to himself "two out of every five of
my customers are on the Internet. Perhaps I need a web page." And,
suddenly, pizza on the Net makes a lot of sense and the traffic patterns
shift. As the density grows to 90%, local traffic becomes dominant over
distant traffic.

Another example is distributed web hosting. When distributed web hosting
takes off, your backbone will be heavily discounted and your peripheral
interconnect bandwidth will be woefully short. Web traffic will zoom as
performance dramatically improves, but your backbone bandwidth will drop.
That breaks your traffic model.

So, by all means, do your traffic studies, but be prepared to throw them
out or re-write them when the environment changes. Then throw bandwidth
where it will do the most good.  :-)

--Kent




More information about the NANOG mailing list