[Bloat] Designer of a new HW gadget wishes to avoid bufferbloat

[Albert Rafetseder]

> Yes, I know how ring buffers work. :-)

No offense meant :-)

>> The trick is now to push the read =
>> pointer forward a bit instead of holding back the write pointer.
> 
> Can't do that: the ^r pointer will normally point at some cell in the
> middle of a packet being transmitted.  Jerking that pointer forward
> will cause us to transmit garbage consisting of partial packets, which
> is the last thing we want.

As it turns out from your answer to Jonathan, we were talking about the same (kind of) implementation, i.e. keep additional information on the start cells of packets, advance the read pointer systematically if needed, so as not to stop transmitting in the middle of packets, etc.

To save you the additional ring buffer, the starts-of-packets information could be stored as a length or number of cells field in front of the stream of cells of one packet. In a 46kibibit RAM, this will consume 3-4 cells' worth of data as overhead.

> But we still have to have tail drop (or my
> "modified tail drop") as the backup packet drop mechanism that
> protects the integrity of the ring buffer.  I guess the trick is to
> design the AQM policy such that it does most of the job and the
> out-of-buffer packet drop mechanism is rarely exercised.

"Caudal" (near tail / tail-side) drop? I wonder if it suffices to head-drop more than one packet's worth of cells if required to keep the read and write pointers sufficiently far apart. With a buffer of less than four Ethernet MTUs, what's the worst case really?

I'll need to get myself an envelope to scribble on...
  Albert.
-- 
Albert Rafetseder BSc. MSc.
Member of Scientific Staff

University of Vienna
Faculty of Computer Science
Research Group Future Communication
(Endowed by A1 Telekom Austria AG)
Waehringer Strasse 29/5.46, A-1090 Vienna, Austria

T +43-1-42777-8620
albert.rafetseder at univie.ac.at
http://www.cs.univie.ac.at/fc