Re: [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,

On 26/02/2022 17:13, Dave Taht wrote:
> At one level you are interpreting an observed behavior as "tail drop"
> - which may well be possible somewhere in the stack,
> but it's not clear if you were running a post 2016 kernel which is
> what added the drop_batch facility.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=9d18562a227
>
> This drops from the head, not the tail.

[BB] Yes, sry, I should have said 'head drop on arrival', not tail drop. 
I was trying to say this is not drop driven by the AQM, rather it's drop 
'cos there's no more room in buffer allocated to the qdisc.

>
> I was not satisfied with this solution btw, and in some later patch
> added an increment to the codel count in drop_batch so as to pass "bad
> things are happening elsewhere" back over to the main portion of the
> algorithm. I'm still very unsatisfied with the concept of a fixed and
> user configurable drop_batch length, rather than something that
> autotuned.
>
> elsewhere in the fq_codel_fast repo I experimented with eliminating
> the queue search, but accepting that small but constant cpu overhead
> for a optimizing for what is perceived to be (and may not be!) a
> rarely hit condition, or accepting the cost of the search when it
> happens, remains to be seen.
>
> So, while trying to disregard your conclusion this was tail drop, I am
> happy that you have clearly identified (with a kernel version), and
> described a test (yay!) that tickles a count caching problem and
> proposed some solutions here:
>
> https://bobbriscoe.net/projects/latency/CoDel-delta-bug.pdf
>
> cc-ing the codel list.

[BB] OK.

And pls would someone also take note that the much more major design 
flaw in the control law needs attention nearly 9 years after I reported 
it (see the last slide in the link above).



Bob


>
> On Sat, Feb 26, 2022 at 8:45 AM Bob Briscoe <[e-mail]> wrote:
>> 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/
>>
>

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