Presentation for the Prague IETF 80 Transport Area Open Meeting

I’m on the agenda for the Transport Area meeting of the Prague IETF meeting.  In it, I have 30 minutes to try to convey the gist and severity of the bufferbloat problem to that audience. I have had the opportunity to present this presentation three times in preparation; once at BattlemeshV4, and twice internally in Bell Labs, so it is much more polished than the original Murray Hill presentation.

Due to the preciousness of meeting time at the IETF, I had to choose what to elide from the much longer original presentation, which includes information of how to mitigate bufferbloat and much additional detail.  On the other hand, I will attempt to be speaking more slowly at the IETF, so it may be more understandable to people listening (or so I hope!).

If you are attending IETF 80, I urge you to attend, and not just those who are interested in transport.  Bufferbloat is terribly damaging to applications (particularly interactive and low latency applications) and general network operations. The draft of the talk itself is already available and the audio and should be available as well as part of the IETF 80 activities. It is currently scheduled (subject to change) for Wednesday morning (Prague time) in the Congress Hall III room. I’m sure hallway conversations will cause me to tweak the talk before I present it Wednesday, but it’s getting close.

One Response to “Presentation for the Prague IETF 80 Transport Area Open Meeting”

  1. skierpage Says:

    “My inlaws wired FIOS service” -> inlaws’ (apostrophe).
    “8 times in common” -> is common (?)

    Alas your writing on bufferbloat verges on the incoherent to anyone not intimately familiar with the internals of TCP congestion and the various tracing utilities that you graph. I’ve read your blog posts and several versions of your talk and even after reading the Wikipedia pages for the technical terms I still don’t comprehend it beyond the superficial “bloated buffers are defeating congestion avoidance since the buffers do not allow timely notification”. The narrative of your research is engaging, but you seem to assume that anyone looking at the resulting graphs will go “OH. MY. GOD. The horror!”; a graph is not an argument, it’s a thousand words. Maybe your presence in the room explaining the graphs makes everything clear.

    Anyway, I appreciate your efforts down there in the series of tubes!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: