nanog mailing list archives
the network engineering game
From: Bradley Reynolds <brad () qual net>
Date: Tue, 10 Aug 1999 13:44:57 -0400 (EDT)
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 thereforeExpecting 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 changeThis 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
Current thread:
- Re: What frame relay switch is causing MCI/Worldcom such grief?, (continued)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Prabhu Kavi (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vadim Antonov (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Tony Li (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vijay Gill (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? smd (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Alex Bligh (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? smd (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vijay Gill (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vadim Antonov (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vijay Gill (Aug 09)
- the network engineering game Bradley Reynolds (Aug 10)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vijay Gill (Aug 09)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Vadim Antonov (Aug 10)
- Re: What frame relay switch is causing MCI/Worldcom such grief? Martin Cooper (Aug 10)
- RE: What frame relay switch is causing MCI/Worldcom such grief? Martin Cooper (Aug 11)
- RE: What frame relay switch is causing MCI/Worldcom such grief? Alex P. Rudnev (Aug 11)