The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-May> msg00171



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Maybe RSVP and Q.2931, but not NHRP

  • From: Dennis Ferguson <dennis@jnx.com>
  • Date: Thu, 30 May 1996 12:22:52 -0700
  • cc: ion@nexen.com

> Actually, to be honest the thought of 1,000 or more routers all
> connected over the same ATM cloud seems a bit scary regardless of
> the routing solution. We had better have some locality of traffic
> or we are in trouble. If traffic is really fully spread out and 
> we really need 499,500 SVCs between the routers then we might be
> doing something wrong. On the other hand, if 99% of the traffic 
> is either to or from 5% of the sites, then perhaps we would need
> only 50 SVCs from each router, or 50,000 SVCs in total (and we
> could let the remaining 1% of the traffic take multiple hops 
> across the ATM subnet). This seems more reasonable.

As a data point here I'd point out that at a previous employer of mine
we normally converted from link loads, which are all you can measure with
conventional routers, to an ingress-egress traffic matrix, which you need
to do traffic engineering, by essentially assuming that the traffic we
were carrying exhibited no locality of reference at all.  As the assumption
of no traffic locality allowed us to compute the ingress-egress matrix
based solely on access circuit loads the comparison between computed
and measured backbone circuit loads provided a validation of the accuracy
of the assumption.  This worked well enough (very well in fact) that I
don't think I'd want to bet the farm that the assumption was in fact
false.

I'd also point out that many of the routers used by high-end Internet
backbone providers have used a demand-filled forwarding cache in their
fast-path forwarding code, an implementation feature which depends
critically on a very related type of traffic locality for any performance 
advantage it might provide.  There was a time when forwarding path caching
worked okay, but that time is demonstrably past and the misery of forwarding
cache failures due to the lack of any such destination locality has been
such that I suspect any service provider who would buy a new product that
relied on a forwarding-path cache for performance just hasn't been paying 
attention.

If you design something which depends on some characteristic of Internet
traffic being benign, there is a substantial body of history which suggests
that you'll screw yourself.  If not this year, then next year.

Dennis Ferguson