[Bloat] Overview modifications

[Eric Raymond]

I'm trawling through the mailing list archives for bits to improve the
overview document with.

jg wrote:
>Note that lossy wireless networks behave much better than "clean" 
>variable bandwidth wireless networks; packet drops due to such losses at 
>least cause TCP to back off sometimes....

This is an important enough point to be in the overview. 

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?

Ah, now I've found jg's original reply on the overview.

jg wrote:
>1) the latency-speed connection needs to be emphasised; along with 
>bandwidth !=speed. You can at least start to attack the conflation of 
>"speed" and "bandwidth" that is in the market.

*Excellent* point.

New 'graph, after the one on DNS et al going kerflooey.

    The way these latency-sensitive services degrade illustrates a
    general point.  From a user point of view, perceived speed of the
    network is much more a function of latency (time to get a
    response) than of bandwidth (ability to bulk-ship). Thus,
    bufferbloat hammers the performance characteristic users care
    about most.

jg:
>To use the highway analogy, only a few areas have carpool lanes, and 
>most of the highway is still jammed.  Once the carpool lanes are gone 
>(you get to another part of the network), you're still stuck behind 
>miles of traffic.

Yup, I'll add this to the QoS section.

Jim criticized "How Hard Is It?"  Rewritten section looks like this:

----------------------------------------------------------------------
== How Hard Is It? ==

We started by asserting that bufferbloat is easy to fix.  First
we'll lay out the both the reasons for optimism, then the problems:

First, it's easy to detect once you understand it - and verifying
that you've fixed it is easy, too.

Second, the fixes are cheap and give direct benefits as soon as
they're applied.  You don't have to wait for other people to fix
bufferbloat in their devices to improve the performance of your own.

Third, you'll usually only have to fix it once per device; continual
tuning isn't necessary.

Fourth (and importantly!), trying to fix bufferbloat won't significantly
increase your risk of a network failure. If you fumble the first time,
it's reversible.

The hard problems are these:

First, we don't yet know how to write good buffer-management rules for
networks with variable bandwidth.  This is a research area, though not
an especially difficult one: good results seem likely in 12 to 36
months.

Second, a lot of routers (especially consumer-grade ones) are difficult
enough to upgrade firmware on that they will need to be replaced. Since
the IPv6 transition is bearing down on us, however, it may be possible
to fold our upgrade wave into that one.
----------------------------------------------------------------------

dtaht wrote:
>Both ARE useful, but can be addressed in order of reducing unmanaged
>buffers, applying AQM, and then QoS. 

That priority list needs to be made explicit in the overview.  I will now do so.
End of section:

    Explicit QoS may a place in our overall strategy for network performance,
    but the right order to do things is this: first reduce unmanaged buffers, 
    then get buffer queue management right, then implement QoS on top of that.

richard wrote:
>Might add a note that if equipment does need to be changed out, isn't it
>nice that we also have to change it out for the IPV4->IPV6 problem too
>and/or that we're hoping the device manufacturers will address the
>problem in the IPV6 equipment roll out.

Done, as you can see above.

richard:
>Here in Canada the metered billing is very high visibility at the
>moment. Would love to be able to point to this from some of the
>discussion areas ASAP :)

This *doesn't* go in the overview.  Two reasons:

Here, I don't want to be topical in a way likely to go stale rapidly.

Also, dtaht and jg are right that there's a political hazard in
getting too far into the whole tiered-billing/usage-metering issue.  I
don't think we can or should avoid it entirely; the fact that fixing
bufferbloat may eliminate the technical necessity is simply too
important a fact to elide.  On the other hand, we need to be very
careful and diplomatic and not pick any fights about this.

That completes my mining of the back mail.  

I'll expect another round of responses to this post, then I'll run
an edit for conciseness and length, then I'll start transplanting 
the overview onto the wiki. 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960