Comments on: The lost Van Jacobson paper that could save the Internet

By: Dave Täht

Dave Täht — Mon, 06 Feb 2012 19:08:21 +0000

The number of clueful engineers per machine deployed is at least two orders of magnitude less than it was in 1985, and our infrastructure vastly more dependent on the internet.

I’d really, really, really hate to have to try to ship tapes around to try and fix a repeat of that event.

By: Nate Lawson

Nate Lawson — Mon, 06 Feb 2012 19:03:52 +0000

Thanks for the work on this. It’s an interesting case study when you compare buffer bloat now to the 1988 congestion collapse. Are we less able to handle system-wide issues today? (I think “yes”).

By: Dave Täht

Dave Täht — Mon, 06 Feb 2012 02:53:55 +0000

A couple notes:

Nearly all the people working on solving bufferbloat are doing it on their own time and dime. Van and Kathie are working on an interesting replacement for RED, which I hope surfaces soon. Jim keeps writing papers. Me, I’ve been trying to make Linux perform more like a NS2 model (which it wasn’t until Tom Herbert’s ‘Byte Queue Limits’ got patched into the upcoming 3.3 kernel. ) Eric Dumazet has gone to town on implementing ARED and SFQ-RED (also in the 3.3 kernel), which has head drop, and ecn support…

There are a couple hundred people on the ‘bloat’ mailing list.

And all this is mostly flailing in the wind.

This problem has been largely unsolved and unresearched since the internet went asymmetric. It’s hard. I’ve been at it full time for a year. More help is highly desirable.

Westwood is mildly better than vegas. Vegas ramps up ok, totally fails on ramping down.

Ledbat scares me.

By: Nate Lawson

Nate Lawson — Sat, 31 Dec 2011 21:43:29 +0000

Yes, that’s a good point and I like djb’s summary. I still think VJ’s second comment stands as an important point to address — normal variance in RTT shouldn’t trigger backoff, but at the same time, the algorithm needs to be responsive.

Estimation would be less of an issue if we were using ECN. Instead of measuring RTT or estimating if a packet was dropped, you just read the bit out of the header. This can also distinguish legitimate drops (say, radio interference) from congestion.

We need both AQM (e.g., modified RED) with ECN (explicit notification) to fix all these problems.

By: Zooko Wilcox-O'Hearn

Zooko Wilcox-O'Hearn — Sat, 31 Dec 2011 15:44:29 +0000

DJB’s page about this (in the context of CurveCP) is interesting: http://curvecp.org/decongestion.html

The Van Jacobson critique http://root.org/ip-development/e2e/end19940314 sounds like it is critiquing the use of latency as a detector when using dropped packets as a detector is already working well. It seems like that critique wouldn’t apply to the case that using dropped packets as a detector is not working well. More specifically, if there is pervasive bufferbloat, then information from change in round trip time will be available significantly earlier than information from dropped packets, right?

By: Nate Lawson

Nate Lawson — Sat, 31 Dec 2011 00:34:36 +0000

I know you think everything done by your alma mater is great, but Vegas has issues also. ;-)

Here’s one critique and diagram:

http://root.org/ip-development/e2e/end19940314
http://root.org/ip-development/e2e/end19940314-diagram.ps

And a more recent paper. In short, natural variance in RTT, especially in the presence of rerouting isn’t handled well by Vegas.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.8588

I curated a set of articles on all this a while back. Kinda interesting to follow the history of TCP/IP through the mailing lists.

http://root.org/ip-development/