Re: [Bloat] Overview modifications

[Eric Raymond <esr@thyrsus.com>]

Jim Gettys <jg@freedesktop.org>:
> >Change in progress -- append to the "Hating" paragraph the following
> >sentence: "Lossy networks such as wireless actually show less chaotic
> >behavior under load than clean ones."  Is this correct and adequate?
> 
> It's not chaotic behaviour.  In fact, it is much more worrying: it
> is periodic (oscillatory) behaviour.  Chaos is good, in this case.

Dave also says my take is wrong and is promising to suggest a correction.
I have enough other stuff to do that I'll wait on that.
  
> My nightmare, is that as traffic shifts over more and more to
> saturated links as XP retires, we end up with self synchronising
> behaviour on a local, regional or global scale, and havoc ensues,
> and parts/all of the Internet stop working. Whether these fears are
> justified, I do not know.
> 
> Think: we may be a column of soldiers in cadence approaching a bridge...

New graphs at the end of "From Highway to Network":

    We also have some worries about the future.  For various reasons
    (including the gradual retirement of Windows XP) more and more
    Internet traffic is now running over saturated links.  In this new
    environment, we think there is a possibility that bufferbloat cascades
    and defects in management strategies might produce self-synchronising
    behaviour in network traffic - packet floods and network resonance on
    a local, regional or global scale that could be a greater threat to
    the Internet than the congestion-driven near-collapse of the NSF
    backbone in 1986.

    This is a classic "black swan" situation in Nassim Taleb's sense; in
    today's Internet-dependent economy there is a potential for nearly
    inacalculable havoc in the worst case, but we don't even know in
    principle how to estimate the overall risk.  Bufferbloat mitigation
    might keep us out of some very serious trouble, and is worth pursuing
    on those grounds alone.

> There is an additional point: understanding bufferbloat may allow
> you to avoid bufferbloat suffering immediately.  Example:

I think we're already noting that point fixes can be applied quickly
an effectively.

> There is tons of mining in the replies to my blog to do.

I'll look, but that sounds like it might be getting into too much detail 
for the overview.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>