Re: [Bloat] First draft of complete "Bufferbloat And You" enclosed.

[Justin McCann <jneilm@gmail.com>]

On Sat, Feb 5, 2011 at 8:23 AM, Eric Raymond <esr@thyrsus.com> wrote:
> Please fix typos and outright grammatical errors. If you think you have spotted
> a higher-level usage problem or awkwardness, check with me before changing it.
> What you think is technically erroneous may be expressive voice.

This may be intentional, but the text launches into an explanation of
why bufferbloat is bad without concisely explaining what it is--- you
have to read the whole first two sections before it's very clear.
Maybe fitting Jim's phrase "the existence of excessively large
(bloated) buffers" (from
http://www.bufferbloat.net/projects/bloat/wiki/Bufferbloat) toward the
beginning would help, bI guess your new third paragraph will have
that.

The second of the three main tactics states, "Second, we can decrease
buffer sizes.  This cuts the delay due to latency and decreases the
clumping effect on the traffic." Latency *is* delay; perhaps "cuts the
delay due to buffering" or "due to queueing" would be better, if more
tech-ese.

I've re-read through the Bell Labs talk, and some of the earlier
posts, but could someone explain the "clumping" effect? I understand
the wild variations in congestion windows ("swing[ing] rapidly and
crazily between emptiness and overload"), but clumping makes me think
of closely spaced packet intervals.

This statement is one I find problematic: "A constantly spaced string
of cars coming in tends to turn into a series of clumps coming out,
with size of each clump controlled by the width of the exit from the
the parking lot." If the bottleneck bandwidth is a constant 10 Mbps,
then the outgoing packets will be spaced at the 10 Mbps rate (the ACK
clocking effect). They aren't really more clumped going out than they
came in-- in fact, with more traffic joining at the choke point, a
given flow's packets will be spaced out even more than they were
before. This isn't quite so true on a wireless link, where it's not
the buffering so much as the variation in actual layer-2 goodput due
to retransmissions and rate changes that cause clumping.

The essential problem is that the increase in RTT slows the feedback
loop, so if a queue is creating an 8 second delay, there can be 8
seconds of badness and changes before *any* connection slows down (or
speeds up). The problem isn't clumping so much as it is the delay in
feedback.

    Justin