SQM Bufferbloat Issues

So here is something to keep in mind, codel style AQM's operate by allowing a small 'standing' queue (controlled by a parameter called 'target' that can be explicitly changed in codel/fq_codel but only indirectly in cake*) but will tolerate larger queues only transiently (think of a queue as a shock absorber, you typically want these to be at the default position, so they maintain the capability to absorb a shock, if you routinely operate these close to maximum compression, good luck evening out the next bump in the road).
BUT the result of this is that if you operate a link at saturation long enough your average queueing delay will end up being close to target (or for bidirectionally saturating traffic often close to 2*target). In other words with default cake/fq_codel the EXPECTED latency increase under load during a saturating test is around +5 ms... (but see **)
Also keep in mind that modern browsers are great jack-of-all-trades tools, but they are not high-precision measurement environments so expect some delay spikes in web-tests like the waveform bufferbloat test that reflect delays inside the browser, not the network.

*) According to the theory behind codel there are two control variables, interval (called 'rtt' in cake) and 'target'. Now if the minimum sojourn time for any packet (that is the time delta between the timestamp from enqueueing a packet and the time that same packet is dequeued) stays above target for a duration of interval, codel will schedule a drop/mark event and at the same time transiently set interval to a smaller value so if above target delays persists the next mark/drop will be scheduled even earlier. It can be shown that if target is set to 5-10% of interval this 'control method' results in relatively low queueing delay all the while still yielding a pretty nice throughput. Based on this cake simploy sets its internal target to 5% of the rtt variable...

**) Cake for all its great features, is a bit CPU hungry in its shaper, and unfortunately its shaper if CPU starved will try to still deliver the set shaper rate while allowing larger delays, so for cake often larger than expected delays with the achieved rate stying below the set shaper rate often indicates running out of CPU cycles...

1 Like