David P. Reed
dpreed at reed.com
Wed Apr 3 19:08:43 PST 2002
At 11:53 AM 4/3/2002 -0500, J. Noel Chiappa wrote:
>I think a much better architecture is one that "nails up" a 'carrier' for a
>traffic aggregate along the entire path and then normally doesn't move it;
>new 'carriers' can be laid out and installed avoiding loaded elements. Such a
>design would be immune to load-induced oscillation. (There are still some
>second-order problems having to do with overall congestive collapse due to
>non-efficient use of resources when the network is a whole is highly loaded,
>but I'm going to gloss over them.)
I have two reactions to this.
1) What the heck is a "carrier" supposed to be? Introducing an
abstraction that has no correspondence to real application behavior or real
underlying technologies makes little sense. Unless you are trying to
transform the problem into a problem that one already knows how to
solve. Since none of these is the case, you might as well be introducing
an abstraction that behaves like a lawn chair, and managing resources as if
they are patios full of lawn chairs.
2) SInce external loads do oscillate, it isn't oscillations per se that are
the problem. Problems like non-linear responses (e.g. the analogy of
resonance in an excited system) are real problems. But it's not
oscillation you want to prevent - it's self-sustaining
oscillation. Damping is not to prevent oscillations from travelling
through the network. In fact if you prevent oscillatory input from going
through the network, you are harming the system response (by introducing
jitter/delay variance that isn't there in the input).
If you look at the flows at some Inter-AS point and they vary in an
unstable way, you don't have enough information to say that that is a
problem. The problems are ones of system behavior, not local behavior.
There is a lot of evidence that flows driven by applications in general
fluctuate on all time scales. In fact, except when you saturate network
capacity, computer-computer applications are designed to do exactly that.
More information about the end2end-interest