Re: [Bloat] Fair queuing detection for congestion control

[Dave Taht <dave.taht@gmail.com>]

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

Hey, good start to my saturday!

1) Apple's fq_"codel" implementation did not actually implement the
codel portion of the algorithm when I last checked last year. Doesn't
matter what you set the target to.

2) fq_codel has a detectable (IMHO, have not tried) phase where the
"sparse flow optimization" allows non queue building flows to bypass
the queue building
flows entirely. See attached. fq-pie, also. Cake also has this, but
with the addition of per host FQ.

However to detect it, requires sending packets on an interval smaller
than the codel quantum. Most (all!?) TCP implementations, even the
paced ones, send 2 1514 packets back to back, so you get an ack back
on servicing either the first or second one. Sending individual TCP
packets paced, and bunching them up selectively should also oscillate
around the queue width. (width = number of queue building flows,
depth, the depth of the queue). The codel quantum defaults to 1514
bytes but is frequently autoscaled to less at low bandwidths.

3) It is also possible, (IMHO), to send a small secondary flow
isochronously as a "clock" and observe the width and depth of the
queue that way.

4) You can use a fq_codel RFC3168 compliant implementation to send
back a CE, which is (presently) a fairly reliable signal of fq_codel
on the path. A reduction in *pacing* different from what the RFC3168
behavior is (reduction by half), would be interesting.

Thx for this today! A principal observation of the BBR paper was that
you cannot measure for latency and bandwidth *at the same time* in a
single and you showing, in a FQ'd environment, that you can, I don't
remember seeing elsewhere (but I'm sure someone will correct me).

On Sun, Jul 3, 2022 at 7:16 AM Maximilian Bachl via Bloat
<bloat@lists.bufferbloat.net> wrote:
>
> Hi Sebastian,
>
> Thank you for your suggestions.
>
> Regarding
> a) I slightly modified the algorithm to make it work better with the small 5 ms threshold. I updated the paper on arXiv; it should be online by Tuesday morning Central European Time. Detection accuracy for Linux's fq_codel is quite high (high 90s) but it doesn't work that well with small bandwidths (<=10 Mbit/s).
> b) that's a good suggestion. I'm thinking how to do it best since also every experiment with every RTT/bandwidth was repeated and I'm not sure how to make a CDF that includes the RTTs/bandwidths and the repetitions.
> c) I guess for every experiment with pfifo, the resulting accuracy is a true negative rate, while for every experiment with fq* the resulting accuracy is a true positive rate. I updated the paper to include these terms to make it clearer. Summarizing, the true negative rate is 100%, the true positive rate for fq is >= 95% and for fq_codel it's also in that range except for low bandwidths.
>
> In case you're interested in reliable FQ detection but not in the combination of FQ detection and congestion control, I co-authored another paper which uses a different FQ detection method, which is more robust but has the disadvantage of causing packet loss (Detecting Fair Queuing for Better Congestion Control (https://arxiv.org/abs/2010.08362)).
>
> Regards,
> Max
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[-- Attachment #2: Analysing_the_Latency_of_Sparse_Flows_in_the_FQ-Co.pdf --]
[-- Type: application/pdf, Size: 507010 bytes --]