[tsvwg] FQ-CoDel response to unresponsive traffic (was: Related to "Non-L4S traffic abusing the L-queue" discussion during the interim)

[Bob Briscoe <[e-mail]>]

Dave,

I will keep reminding everyone that this shift of topic to FQ-CoDel is 
distracting from the task at hand:
     "Is Jonathan going to confirm that his 'throughput bonus' and 'fast 
lane' accusations against DualQ are baseless because his experiment was 
broken?"

Nonetheless, response on FQ-CoDel is below, tagged [BB]...

On 25/02/2022 21:06, Dave Taht wrote:
> while I do not want to spend much time nitpicking this document...
>
> "causing most of the time tail-drop" stood out. codel, fq_codel, cake
> all do head drop, and always have.

[BB] For the list, we're talking about Figure 5 here: 
https://l4steam.github.io/overload-results/

I'm nearly certain that the cap at 600 ms is tail drop.
Cause: The control law increases head drop so slowly that the flow-queue 
containing the unresponsive flow eventually fills the buffer allocated 
to the whole qdisc. Then I believe it moves into what Jonathan calls 
'tallest sunflower' drop mode (tail drop focused on the longest flow-queue).

To help prove this, here's an experiment Asad ran for me last Oct on 
FQ-CoDel with an unresponsive flow rate just greater than the link rate.
https://bobbriscoe.net/projects/latency/CoDel-delta-bug.pdf#page=4
We were testing very slight overload, so it would stay in head drop 
mode, without hitting the need for tail drop. The plot shows a similar 
series of humps in the queue, but without the cut-off due to tail drop. 
So it's fairly conclusive that Koen's Fig 5 is showing tail drop.

I'll answer your question (on the SANE list) about why the humps repeat, 
but that's a trivial bug compared to the time CoDel takes in the first 
place.
It's a design flaw, not a bug.
The so-called 'control' law never even measures the queue it is meant to 
be controlling.
Here's some history:

* On 12-Nov-2013 I reported that to Kathie and Van as CoDel designers, 
cc the AQM list:
https://mailarchive.ietf.org/arch/msg/aqm/l4H1QdRl8B-E5FWpJh4w50B_nQE/
* No response by anyone for over 18 months, until...
* 07-Jun-2015: Toke confirmed my analysis empirically (see it, via same 
thread above)
    Toke's plot: 
https://kau.toke.dk/ietf/codel-drop-rate/codel-drop-rate.svg
* On 30-Sep-2015 you (DaveT) said "cake uses a better curve for CoDel 
but we still need to do more testing in the lab"
    As far as I understand it, that missed the point: CAKE's curve is 
still extremely slow, but somewhat faster than CoDel.
    But, CAKE's control law still never measures the queue it is meant 
to be controlling.
* 25-Feb-2022: You say you don't want to spend much time nitpicking 
Koen's experiment.
     If not you, someone needs to grasp this nettle, given FQ-CoDel is 
the default qdisc in the Linux mainline.



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/