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

[Eric Raymond]

Justin McCann <jneilm at gmail.com>:
> 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.

Not intentional, exactly, but's inherent.  Thec reader *can't* get what
bufferbloat.

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

Good catch, I'll fix.
 
> 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.

It's intended to.  This is what I got from jg's talk, and I wrote the
SOQU scenario to illustrate it. If my understanding is incorrect (and
I see that you are saying it is) one of the real networking people
here needs to whack me with the enlightenment stick.

The underlying image in my just-so stories about roads and parking lots
is that packet flow coming in smooth on the upstream side of a buffwer
gets turned into a buffer fill, followed by a burst of packets as it 
overflows, followed by more data coming into the buffer, followed by
overflow...repeat.

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

I don't understand "ack clocking". Alas, my grasp of networking becomes
sketchy below the level of socket APIs. I know what's in a TCP packet, 
roughly, but have no precise feel for what happens with bits on the wire.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>