From: Sean Conner <sean@conman.org>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] First draft of complete "Bufferbloat And You" enclosed.
Date: Tue, 8 Feb 2011 15:10:29 -0500 [thread overview]
Message-ID: <20110208201028.GG7321@brevard.conman.org> (raw)
In-Reply-To: <20110208181811.GD7744@thyrsus.com>
It was thus said that the Great Eric Raymond once stated:
> Justin McCann <jneilm@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.
I didn't care for that analogy, roads and parking lots. Better might be
freeways and interchanges, because the buffers are where traffic moves from
one freeway (the path between router A and B) to another (the path between
router B and C). If the interchange is small (say, a lane that's only a few
hundred yards long) then any delay becomes immediately apparent. Buffer
bloat is analogous to either increasing the number of lanes in the
interchange, or making the interchange longer (here in South Florida, the
interchange between I-595 W and I-95 N is two lanes two miles long---I am
not making this up).
The analogy also reminded me of traffic physics
(http://amasci.com/amateur/traffic/traffic1.html). I'm not sure if that has
any bearing and is one reason why I tend to dislike analogies of computer
topics to real world phenomenon---there are so many problems and exceptions
that it tends to cloud the issue.
I took buffer bloat to be that the inflow of packets exceeds the outflow
of packets, and that the buffer does exactly that---buffers the excess,
which delays the dropping of packets that lead to congestion control to kick
in.
-spc
next prev parent reply other threads:[~2011-02-08 20:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-05 13:23 Eric Raymond
2011-02-05 13:42 ` Jim Gettys
2011-02-05 15:12 ` Dave Täht
2011-02-05 15:46 ` Dave Täht
2011-02-06 13:37 ` Eric Raymond
2011-02-05 17:56 ` richard
2011-02-05 19:48 ` richard
2011-02-05 22:12 ` Dave Täht
2011-02-06 1:29 ` richard
2011-02-06 2:35 ` Dave Täht
2011-02-06 2:50 ` richard
2011-02-08 15:17 ` Justin McCann
2011-02-08 18:18 ` Eric Raymond
2011-02-08 18:31 ` richard
2011-02-08 18:50 ` Bill Sommerfeld
2011-02-09 15:50 ` Eric Raymond
2011-02-08 20:10 ` Sean Conner [this message]
2011-02-09 4:24 ` Justin McCann
2011-02-10 14:55 ` Jim Gettys
2011-02-10 17:50 ` Dave Täht
2011-02-08 19:43 ` Juliusz Chroboczek
2011-02-08 19:52 ` richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110208201028.GG7321@brevard.conman.org \
--to=sean@conman.org \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox