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

[Greg White <[e-mail]>]

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

    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



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