[Bloat] Letter to CACM?

[Bloat] Letter to CACM?

[Eric Raymond]

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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Bloat] Letter to CACM?

[Dave Täht]

Eric Raymond <esr@snark.thyrsus.com> writes:

>
> They had a useful suggestion.  They think we ought to ship the overview
> as a letter to CACM.  "Everybody gets that," they pointed out.

I don't but paper had a hard way of getting to me for the last 4 years.

> Yeah, I can see it.  Getty, J., Raymond, E.S., Taht, D.  "Packet Loss
> Considered Helpful"  OK, I kid about the title.

I think the title is expressive, snarky, revolutionary, chock full of
wonderful historical references, and people will "get it".

:)

I do feel that focusing on the desirability of packet loss, alone, would
have a marvelously focusing effect on a letter.

The wireless side is a quagmire that I hope to get to writing about
semi-coherently today. 

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

How to crack the economist?

-- 
Dave Taht
http://nex-6.taht.net

Re: [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.

Re: [Bloat] Letter to CACM?

[Simon Leinen]

Jim Gettys writes:
> 3) I'm presenting at the Transport Area meeting at the upcoming IETF
> in Prague in late April.

(It's actually more like "late March" :-)

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

In general, IETF practice is relatively liberal about slides being
modified until the very last moment, although it's nice to have them
uploaded so that remote attendees can browse them while following the
presentation over audio streaming.

If you/we want to submit an Internet-Draft for discussion, the cut-off
dates are 7 March for initial contributions (-00 drafts), and 14 March
for revisions. (http://www.ietf.org/meeting/cutoff-dates-2011.html).

Earlier is always better, of course.

No ideas on how to reach the IEEE audience, I'm more of an ACM type
myself.  IETF is probably not bad, because it has some overlap with the
IEEE network community.
-- 
Simon.

Re: [Bloat] Letter to CACM?

[Jim Gettys]

On 02/07/2011 05:15 AM, Simon Leinen wrote:
> Jim Gettys writes:
>> 3) I'm presenting at the Transport Area meeting at the upcoming IETF
>> in Prague in late April.
>
> (It's actually more like "late March" :-)

Yes, I misspoke: I actually have my hotel reservations now and need to 
make my plane reservations soon.

>
>> 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.
>
> In general, IETF practice is relatively liberal about slides being
> modified until the very last moment, although it's nice to have them
> uploaded so that remote attendees can browse them while following the
> presentation over audio streaming.

Lars wants a draft of the slides by around the end of this month.

>
> If you/we want to submit an Internet-Draft for discussion, the cut-off
> dates are 7 March for initial contributions (-00 drafts), and 14 March
> for revisions. (http://www.ietf.org/meeting/cutoff-dates-2011.html).

Thanks for the dates; I dunno if I can have something written by then, 
much less to ID formatting standards; it's been a while since I was in 
the ID submission business, though the lord knows I've submitted a lot 
of them for RFC 2068 and 2616.  I have no idea what tools are best for 
that these days.

>
> Earlier is always better, of course.

Heh.

>
> No ideas on how to reach the IEEE audience, I'm more of an ACM type
> myself.  IETF is probably not bad, because it has some overlap with the
> IEEE network community.

Yup.  But we do need to keep this audience firmly in mind: they are 
often in control of the purse-strings for a lot of the hardware on the 
net. ACM is but one of a number of important audiences.
			- Jim

Re: [Bloat] Letter to CACM?

[Simon Leinen]

>> If you/we want to submit an Internet-Draft for discussion, the cut-off
>> dates are 7 March for initial contributions (-00 drafts), and 14 March
>> for revisions. (http://www.ietf.org/meeting/cutoff-dates-2011.html).

> Thanks for the dates; I dunno if I can have something written by
> then, much less to ID formatting standards; it's been a while since
> I was in the ID submission business, though the lord knows I've
> submitted a lot of them for RFC 2068 and 2616.  I have no idea what
> tools are best for that these days.

The most popular tool seems to be xml2rfc (http://xml.resource.org/).
Emacs and nxml-mode work nicely with this, but any other XML editor
should be fine.  On http://tools.ietf.org/ there's a lot of useful
information about how to format and submit Internet-Drafts.
-- 
Simon.

Re: [Bloat] Letter to CACM?

[Alex Burr]

> Jim Gettys <jg@freedesktop.org> wrote:
> 
> On 02/07/2011 05:15 AM, Simon Leinen wrote:
>  No ideas on how to reach the IEEE audience, I'm more of an ACM type
> >  myself.  IETF is probably not bad, because it has some overlap with  the
> > IEEE network community.
> 
> Yup.  But we do need to keep  this audience firmly in mind: they are often in 
>control of the purse-strings for  a lot of the hardware on the 
> net. ACM is but one of a number of important  audiences.


Some places to try:
www.lightreading.com , covers the telco and networking markets. 
www.dslprime.com , a newsletter covering the same market.
www.broadband-forum.org ,  A standards organisation for the access network (dsl 
and fiber).
http://metroethernetforum.org

Analysts such as www.linleygroup.com and http://www.heavyreading.com.


Another thing is - suppose you run an ISP with a zillion switches, and you want 
to find if any of them have this problem. How do you go about it? It's easy 
enough to manually measure the latency of one path, but you want to scan your 
whole network looking for latency problems. The obvious place to do this is in 
the software which already manages the zillion switches. In the telco world this 
seems to be called OSS (Operations Systems Support, not Open Source Software). 
So another group to reach out to are the people who write that, and the 
equivalent for more internet oriented shops.
I don't know much about such software, except that it probably uses ethernet OAM 
protocols (802.1ag, ITU Y.1731 etc). Y.1731 includes latency measurement, 
although I suspect you could also get a crude latency estimate using 802.1ag. 

Alex