[e2e] EC++N

[J. Noel Chiappa]

    > From: "David P. Reed" <dpreed at reed.com>

    > 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.)

    > 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.

I was purposely using a new, previously undefined and unloaded term - I was
trying to avoid the pointless angst that often happens when you use some
existing idea that raises peoples blood pressure (e.g. "flows", "micro-flows",
"circuits" - all of which have existing ancillary mechanism baggage).


    > 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.

First, I'm not talking about oscillations in load. I'm talking about
oscillations in path: i.e. the simplistic example is that all the traffic
moves from link A to alternative parallel link B, then back to link A, then
back to B, etc.

Definitely you would want to prevent self-sustaining path osciallations.
However, I need to go away and think about your point of externally induced
oscillations.

My first take is that the issue is how the system responds, and what the
effects are. I mean, at some level you probably don't care what caused the
osciallation, *iff the results are harmful*. Whether it's purely internal, or
'pumped' by external inputs, is not the issue; if the results are bad, you
want to get rid of them.

I guess what I'm saying is that for "oscillation" I was assuming I was talking
about the subset which is undesirable, and those you do want to try and deal
with, I think. How well you can do so when the impetus is external is of
course an interesting point.

    > 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).

Again, you seem to be talking about osciallations in load, not path.
Oscillations in load will of course (modulo smoothing introduced by queueing,
etc) pass through unaffected - and probably should.

However, if the network can handle more traffic (i.e. not "clip" the offered
load) by reconfiguring the routing, it probably should, yes? (Modulo not
driving the routing into oscillation.)

I realize this whole topic of how to maximize the throughput of a mesh, given
a offered traffic load matrix, is a complex one, but it does seem to be one
that people care about.

	Noel