RED in a Different Light Van told me then that: 1. There are not one, but two bugs in classic RED, discovered and proven to him by Kathy Nichols, and that the result has been a cottage industry publishing over 100 papers on RED tuning in that time, and justified mistrust by network operators. 2. The finished “RED in a Different Light” paper was never published, in part, because someone on the program committee was offended by the diagram explaining its behavior. You can inspect the draft yourself, and conclude that some people lack any sense of humor; the mechanism in the diagram is familiar to us all and a direct analogy to what is occurring, that provides insight into its behavior. 3. The improved RED algorithm was never implemented by Cisco, since the paper was never published and since therefore there was no demand from customers. Alternate algorithms have also languished, and generally not been fully automatic. 4. Van then changed jobs, and the finished paper has been lost on a backup tape for a decade. 5. At the time Van was working on that paper, he did not foresee we’d have essentially the same problem in wireless home routers, and there was little other outlet for that work except in internet routers. Van thinks the observed behavior of spotty deployment of AQM by network operators (both corporate and ISP’s) is completely understandable (even if often very unwise). RED does require tuning, and can conceivably cause trouble if not tuned properly; many operators who have not been scarred by congestion are therefore gun-shy.

An early draft of RED in a Different Light by Jacobson, Nichols, and Poduri escaped onto the internet (caution: Van says that that draft’s revised algorithm still has at least one issue but the early draft is enlightening as to a glimpse of the way forward, and you can get immediate insight into classic RED’s problems). Van told me this afternoon he has found his old files with the final draft of the paper and supporting material from backup tapes of ten years ago. Here is where you might be able to help with bufferbloat yourself: 1. if you happen to have been on the program committee for SIGCOMM (?) in that era (1999?, 2000?), and have a copy of the finished paper Postscript, please send it to Van ASAP. It would save the hassle of 2. 2. if you have access to a copy of Framemaker, we could use your help to use it to convert the paper to a modern format. 3. one aspect of the simulation of the nRED algorithm was never completed, since the final draft was not accepted. If you have research bent and are interested in completing those simulations, let Van know. 4. once the paper has been resurrected (or at least the final versions of the nRED algorithm, from his talk materials), kernel and home router implementers can have a ball making a wireless home router and operating system that actually might work well across the huge dynamic range and workloads we now face. 5. If you have other ideas of fully automatic AQM algorithms that might handle this challenging queue management problem, now is the time to try them out. Update: Van has managed to retrieve the later draft of “RED in a Different Light” and resurrect FrameMaker via VM technology, and is converting the paper to LaTex. He says that the draft only partially reflects a bug fix found in the revised algorithm, and is editing it to reflect the final version of the algorithm. It should be available soon. Van also pointed out Buffer Sizing 802.11 Based Networks, for which there is running code, of particular interest to people working on 802.11. He believes there is an easier and more robust solution, but “they have running code, and I don’t”.