Re: [Codel] why RED is not considered as a solution to bufferbloat.

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

> If dequeue rate is predictable (true for some links, less so for others)
then the NotCodel approach can be designed such that it will drop (or mark)
*the same packets* that the CoDel approach would.

In other words, in certain specific cases it is possible to behave as
though you were head-dropping even though you actually aren't. And that's
fine, as long as you don't forget that head-drop is the gold standard and
you're just faking it. It's a general technique used in all sorts of
hardware and software.

But as soon as conditions change from that fairly ideal situation, you
start having to genuinely do the work at the head of the queue in order to
obtain the accurate sojourn times. Given the audience that I wrote that
explanation for (you have seen the calibre of their questions...), I
thought it best to keep away from gritty implementation details in order to
keep it conceptually simple.

And even on switched Ethernet - one of the more obvious candidates for the
technique - the line rate can vary unexpectedly. Pause frames are the most
likely cause, and one possible source of pause frames is a cable or DSL
modem signalling its own link rate back to the host. But until the link is
unpaused, the head packet can't be dequeued, and the sojourn time of it and
any other packets behind it increases, throwing off any estimates that
might have been taken at enqueue time. The likely symptoms would be similar
to running normal Codel on an overbuffered Ethernet device without BQL.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 1637 bytes --]