Subject: [tsvwg] qdisc hash customization as a path to shared RFC3168 queues

From: Pete Heist <[email-masked]>
Date: Tue, 29 Jun 2021 11:41:08 +0200

In the L4S safety discussion we've talked about ways that L4S and non-
L4S traffic can wind up in the same RFC3168 queue, even with FQ:

https://github.com/heistp/l4s-tests/#unsafety-in-shared-rfc3168-queues

I don't think we've mentioned that the hash used for Linux's FQ qdiscs
(fq_codel and cake included) can be customized, for example to provide
host fairness, "subscriber" fairness, or otherwise. I wrote this up
with a test script showing some ways to use it:

https://github.com/heistp/qdisc-custom-classification/

It's easy to see how this could lead to L4S and non-L4S traffic sharing
the same queue. If an operator does not want flow-fairness, but wants
fairness e.g. among destination hosts, this can be done by attaching a
flow filter to fq_codel (where 10: is the fq_codel handle):

tc filter add dev enp1s0 protocol all parent 10: handle 1 \
        flow hash keys dst divisor 1024

That would cause all traffic to a given IP to share one queue.

This has been in the wild for some years, so it might be worth adding
to the l4sops draft.

Pete

---

From: Greg White <[email-masked]>
Date: Tue, 29 Jun 2021 20:32:04 +0000

On 6/29/21, 3:41 AM, "tsvwg on behalf of Pete Heist" <[email-masked] on behalf of [email-masked]> wrote:

    Pete

Hi Pete,

Yes, I can add a comment on this in Section 6 of L4Sops.  The current text in that section equates FQ with 'flow-queuing' (as opposed to host-queuing or *-queuing). I think I can fairly easily add a note about non default hashing. 

What do you think about this, at the end of section 6:

<t>Note that some FQ schedulers can be configured to intentionally aggregate multiple flows into each queue. This might be used, for instance, to implement per-user or per-host fairness rather than per-flow fairness.  In this case, if the flow aggregates contain a mix of Classic and L4S traffic, one would expect to see the same potential unfairness as is seen in the FIFO case. The same remedies mentioned above would apply in this case as well.</t>

-Greg

---

From: Pete Heist <[email-masked]>
Date: Wed, 30 Jun 2021 14:16:08 +0200

Hi Greg,

...

On Tue, 2021-06-29 at 20:32 +0000, Greg White wrote:
> On 6/29/21, 3:41 AM, "tsvwg on behalf of Pete Heist"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> Yes, I can add a comment on this in Section 6 of L4Sops.  The current
> text in that section equates FQ with 'flow-queuing' (as opposed to
> host-queuing or *-queuing). I think I can fairly easily add a note
> about non default hashing. 
> 
> <t>Note that some FQ schedulers can be configured to intentionally
> aggregate multiple flows into each queue. This might be used, for
> instance, to implement per-user or per-host fairness rather than per-
> flow fairness.  In this case, if the flow aggregates contain a mix of
> Classic and L4S traffic, one would expect to see the same potential
> unfairness as is seen in the FIFO case. The same remedies mentioned
> above would apply in this case as well.</t>

That probably about does it from the perspective of the l4sops
document.

It's more up to the WG how acceptable this would be as a risk to non-
L4S flows in existing installations...

Thanks,
Pete