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

[Pete Heist <[e-mail]>]

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"
> <[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>

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

> 
> 
> -Greg
> 
> 
>