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

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

[Dave Taht]

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.

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.

On Sat, Feb 26, 2022 at 8:45 AM Bob Briscoe <ietf@bobbriscoe.net> 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/
>


-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC