the network engineering game

Tue Aug 10 17:44:57 UTC 1999

> > Now, no matter how one jumps, most congestions only last seconds.
> 
> This isn't the case when you have half your bandwidth to any particular
> point down.  Excess capacity in other portions of the network may be then
> used to carry a portion of the offered load via a suboptimal path.
> 

i believe he is talking of congestion under 'normal' circumstances, in
which the assertion is correct.  chronic congestion occurs when you
oversubscribe the link and constantly fill/overflow the queue (and you see
drops as inversely related to interarrival times).  chronic congestion
(not related to link failure) should (can?  seems to be a question for
some) be accounted for in windows longer than the normal TE hack delta.

you can also engineer an ip network to accomodate circuit failures (with
no APS). You just have to understand the problem. helps to be a
consolidated CLEC/IXC too.

> > Expecting any traffic engineering mechanism to take care of these is
> > unrealistic.  A useful time scale for traffic engineering is therefore
> 
> Expecting most congestions to last only seconds is also unrealistic.  In
> most cases, there is no congestion, everything is taking the shortest path
> and then there is a loss of capacity and we have a problem.  

in a network where you have oversold core capacity at the edges, it is
certainly normal to experience congestion.  remember that the data most
are exposed to are 5 minute averages.  examining link utilization/drops at
a shorter delta is most interesting.

> Expecting the physical circuit to never go down due to sonet protect
> and diverse routing is also a bit optimistic as regrooming may
> eventually reduce your "diverse" routing to a single path.  

if you are the telco, then you are shooting yourself.  if you are not
a telco and you buy diverse path aps in contract and don't inquire about
'regrooming ticket 12341' then you are just as stupid.  

> > at least days - which can be perfectly accomodated by capacity planning in
> > fixed topology.  At these time scales traffic matrices do not change
> 
> This assumes a decent fixed topology.  The market has moved faster than
> predictions historically.
> 
so no matter what, it is impossible to give O(f(n)) growth ('O' not theta)? 
i find that hard to believe.

> highest possible." That is just plain wrong.  However, given real world
> constraints on capacity and delivery, TE is a useful tool today.
> 
s/tool/hack/g

BR