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
Pushpendra Mohta pushp at cerf.net +1 619 812 3908
TCG CERFnet http://www.cerf.net +1 619 812 3995 (FAX)
More information about the NANOG
mailing list