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

richard richard at pacdat.net
Sat Feb 5 17:29:37 PST 2011


Hi Dave

I saw the animations but need to ask to use them as there is no CC on
the site there and I have ads on my Digital-Rag site

I'm sorry - not an artist :(


On Sat, 2011-02-05 at 15:12 -0700, Dave Täht wrote:
> richard <richard at pacdat.net> writes:
> 
> > I like your vehicle analogy but I think today's network-using public can
> > relate better to a real-world situation in the internet so I've put
> > together my own article on the problem. I'd already started the article
> > last week and finally got to finish it today.
> > http://digital-rag.com/article.php/Buffer-Bloat-Packet-Loss
> 
> Wondeful! That's 3 non-jg pieces in a row that "get" it, and explain
> specific bits of it well. 
> 
> There are three excellent animations of how TCP/IP actually works here:
> 
> http://www.kehlet.cx/articles/99.html
> 
> Perhaps that would help your piece somewhat.
> 
> I keep hoping that someone graphically talented will show up that can do
> animations similar to those above, that clearly illustrate
> bufferbloat. Anyone? Anyone know anyone?
> 
> Another analogy that was kicked around yesterday on the #bufferbloat irc
> channel was the plumbing one - where more and more stuff is poured into
> a boiling kettle (a still perhaps) until it overflows, or explodes.
> 
> Here's a title of a piece that *I* daren't write: 
> 
>                   “Draino for the Intertubes”
> 
> 
> I've struggled mightily to explain bufferbloat to so many people. For
> example I spent 3 hours talking with an artist that understood protools
> - and thought the internet was all slaved to a master clock. 
> 
If you believe the telcos, it was (and still should be) as that was the
way things like T1s and T3s and ATM all worked.

> I'm very glad to see y'all helping out. There's still lots left to do,
> not just in communication but in actually getting some work done on both
> the easy and hard engineering problems.
> 
I'm not a programmer any more - last major "bare metal" programming I
did was on an IBM 360 in assembler.

Today I'm mostly a sysadmin and systems designer and programmer manager,
but I'm doing a lot of streaming video, which is why I'm interested so
much in the buffer bloat.

> But staying on the communication front:
> 
> If a little kid asked you, in a small thin voice, 
> 
>    “Why is the internet slow today?”
> 
> How would you explain it?
> 
> How'd you explain it to a doctor? A lawyer? Your mom? Your boss?

strangely enough - this has come up with me recently. I think I
passed :)

> 
> As it happens I have studio time this weekend, if anyone is into script
> writing I can fake up a few voices. I have two ideas that I might be
> able to fit into 2 minutes each, but kind of have to tear myself away
> from email to work on... 
> 
> > It could have some more technical terms (latency for example) added to
> > it but I limited it to the concept of window and ACK for now.
> >
> 
> This, though dated, is a good reference on latency.
> 
> http://rescomp.stanford.edu/~cheshire/rants/Latency.html
> 
yes - that's a good one

> A modernized one would be great... There was some good stuff on one of
> the audio lists/web sites that I saw, I'll look for it. 
> 
I'll think about it.

> Audio guys *get* latency. So do the real time guys. Few others.
> 
So do video people - try to explain to a bunch of ageing "eagleholics"
that there is a good reason why the audio and video from two cameras in
the same eagle nest are out of sync by minutes by the time they've gone
through the internet a couple of times and various server systems that
are otherwise supposed to be identical, on the way to being viewed by
them on a web page side by side.

> > It takes the content of a recent ad from a local ISP and talks about
> > what is actually going on "under the hood"
> 
> Lots of public confusion to counter. The nice thing is - we have
> mitigations that *work*. What do they have?
> 
> 
talk to you soon

richard

> 
-- 
Richard C. Pitt                 Pacific Data Capture
rcpitt at pacdat.net               604-644-9265
http://digital-rag.com          www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333  57F0 4F18 AF98 9F59 DD73



More information about the Bloat mailing list