[Bloat] Letter to CACM?

[Jim Gettys]

On 02/06/2011 10:42 AM, Eric Raymond wrote:
> Last night I had dinner with Drs. David and Paula Matuszek, two rather
> distinguished CS academics who happen to be old and close friends of mine.
> (They have occasionally joked about putting a brass plaque in their living
> room, which back in 1996 was the very first place the ideas that became the
> theory of open source were spoken outside of my skull.)
>
> Dave and Paula had just about the reaction you'd expect to my
> explanation of bufferbloat - initial bogglement followed by oh-shit
> followed by "how did we possibly manage to miss this?"
>
> Elapsed time from boggle to full comprehension was less than 5
> minutes. This is encouraging. Yes, they're exceptionally bright, and
> yes, I'm exceptionally capable at doing this kind of exposition; still,
> it's a good sign that they got it so fast.
>
> They had a useful suggestion.  They think we ought to ship the overview
> as a letter to CACM.  "Everybody gets that," they pointed out.
>
> Yeah, I can see it.  Getty, J., Raymond, E.S., Taht, D.  "Packet Loss
> Considered Helpful"  OK, I kid about the title.
>
> I'd have to strip out some of the babytalk about road networks, but I
> could do that in a hot minute.  Once we get the overview content final.
>
> Should I put this shipping to CACM my to-do list for when the overview
> is done?  Jim, especially looking for your judgment; you'd be the
> obvious designee for lead author even if the alphabetical order didn't
> fall that way.

There are a number of other publication venues already under way:

1) I'm writing Vint's next column for IEEE Internet Computing; draft was 
supposed to be finished yesterday, but I was feeling crummy and also 
preoccupied with other personal matters (including lots of snow). 
Hopefully, I'll finish that today or at worst tomorrow, now that I'm 
feeling OK again (I've got it about half written this instant).

That is/will be a < 1200 word introductory piece toward that audience. I 
have permission to use it on bufferbloat.net (though I don't think the 
IEEE will want it to go into other publications).

2) Vint has also suggested a SIGCOMM note to CCR.  I haven't taken any 
action on that front.  The point is it is a fast turnaround publication 
without having review cycles, and oriented toward more opinion pieces.

3) I'm presenting at the Transport Area meeting at the upcoming IETF in 
Prague in late April.  I have 30 minutes (plus questions), so have to do 
serious surgery on my existing talk.  I don't know the deadline on those 
slides yet, but suspect they will be due by around the end of the month.

4) ACM Queue is doing a major push on this; there is a case study that 
has just started preparation.  This will consist of a:
	o interview of a number the key players in the uncovering of 
bufferbloat and expert on congestion with Vint interviewing (e.g. the 
Netalyzr folks, myself, Van).
	o a number of papers surrounding it, probably including
RED in a different light, (so people don't waste time trying to make RED 
work in wireless, and to ensure nRED is out there), a paper I'll pull 
together out of what I've written, but I need a TCP and network guru to 
co-author with me to make sure I get it technically right. Probably a 
piece by Peter Bosch, who has debloated a 3g home gateway product we 
have in engineering, which provides a wonderful before/after debloating 
case study, and maybe a couple of other pieces we batted around, like 
for major core network operators, when they should worry about 
bufferbloat and when they shouldn't...
	This is aimed sometime in May/June time frame;
	Would be stupendous if we could get a home router behaving itself with 
SFB and/or nRED in time and written up, but that looks dicey at this 
date just due to timing; we'd have to have something running by mid-April.

So at this point, I'm worried about writing bandwidth, and want to make 
sure the efforts go in the right directions for best impact.

Dave Clark pointed out to me early on there is another audience we need 
to ensure "get it": that is the more hardware oriented engineers you 
find in the IEEE.  The managers of the hardware giblets need to 
understand it's something they have to worry about in the design of the 
hardware and firmware, and these guys are usually the people who pay the 
bills for the firmware/software that is developed.  If they don't "get 
it", it won't get done by the software/firmware getting done right in 
their products.

I think Dave's right.

So, in short, I think we have the ACM/CACM well in hand already; I'm 
much more worried about the other hardware oriented audience represented 
by the IEEE.

Suggestions of how to approach that audience are welcome.


			- Jim


P.s. I'll follow up with a different note on a related topic net.