The CoDel queue management algorithm

The CoDel queue management algorithm

I've been working on better flow control for most of this year, as part of my net2o project. Minimizing delay is only one piece of the picture, and of course, it is necessary. Using an experimental protocol instead of TCP gives the benefit that you can do acquire whatever data you need (timestamps, mostly).

I've figured out that I need to do a bit more. First of all, I try to measure the achievable bandwidth by sending short bursts of packets out, and let the receiver time them. From that timing (burst start to end), the receiver can calculate a transmission rate, and communicate that back to the sender. This is important to quickly adapt to changing conditions, as we have them in our networds now - especially WLANs, where the achievable rate can drop and raise quickly, as we move our mobile equipment around.

This measurement would be good enough for competing data streams if the routers would do fair queuing in the buffer instead of the FIFO they do (fair means: round-robin between different connections). The FIFO nature however means that I need to measure a bit more - I've also to take into account what happens with the burst heads. If they get delayed more, it's too fast. The calculation here is: Take the additional delay between bursts, and multiply it by the number of bursts in flight at the current (too fast) rate. Wait this time, before you send the next burst.

This works quite well most of the time. But if there is more delay even though, I have added an exponential slow-down. The parameter for this is not fixed, it's derived from the measured maximum vs. minimum delay. As correctly stated in the article, "tuning" by the user is no good. For a gigabit LAN, 100ms are already excessive. The rule of thumb is that the buffer should capture a round trip delay worth of data - but when you compete with buffer-bloat TCP streams, it can be more. For the LinuxTag WLAN (worst case I've seen so far), 2s were quite right. Hope it's better next year, when the majority uses Linux 3.5 or later ;-).

BTW: People designed these buffers around Windows XP, which has no window scaling, i.e. the maximum "in flight" data are 64kB. That's what I now assume as save guess for minimal buffer size, so a net2o connection initially sends out 64kB quite fast, and then waits for the response.