Traffic Engineering

Pushpendra Mohta pushp at CERF.NET
Wed Sep 17 23:23:21 UTC 1997

Kent W. England writes:
> 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.

Even in the scenario where physical proximity automatically implied
network proximity, I think the assumption that local traffic will
dominate communications needs to be revisited. It is true today, only
because that is how people live lives and conduct business _today_. The
concept of "community" today is geographical.. the communities of
tommorrow may not be so restricted.

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

This is true of a business model based around content distrubution only.
Most ISPs of size will have both publishers and consumers of information
so the backbones utilization should be balanced.

> 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.  :-)

No debate here.

> --Kent


Pushpendra Mohta          pushp at        +1 619 812 3908
TCG CERFnet        +1 619 812 3995 (FAX)

More information about the NANOG mailing list