Re: [PATCH v5 net-next 1/1] sched: Add dualpi2 qdisc

[Cong Wang <xiyou.wangcong@gmail.com>]

On Sat, Feb 22, 2025 at 11:07:25AM +0100, chia-yu.chang@nokia-bell-labs.com wrote:
> From: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
> 
> DualPI2 provides L4S-type low latency & loss to traffic that uses a
> scalable congestion controller (e.g. TCP-Prague, DCTCP) without
> degrading the performance of 'classic' traffic (e.g. Reno,
> Cubic etc.). It is intended to be the reference implementation of the
> IETF's DualQ Coupled AQM.
> 
> The qdisc provides two queues called low latency and classic. It
> classifies packets based on the ECN field in the IP headers. By
> default it directs non-ECN and ECT(0) into the classic queue and
> ECT(1) and CE into the low latency queue, as per the IETF spec.

Thanks for your work!

I have a naive question here: Why not using an existing multi-queue
Qdisc (e.g. pfifo has 3 bands/queues) with a filter which is capable of
classifying packets with ECN field.

> 
> Each queue runs its own AQM:
> * The classic AQM is called PI2, which is similar to the PIE AQM but
>   more responsive and simpler. Classic traffic requires a decent
>   target queue (default 15ms for Internet deployment) to fully
>   utilize the link and to avoid high drop rates.
> * The low latency AQM is, by default, a very shallow ECN marking
>   threshold (1ms) similar to that used for DCTCP.

Likewise, PIE or other AQM Qdisc's can be combined with other Qdisc's to
form an hierarchy, which could perpahs achieve the same goal of yours.

Taking one step back, even if all the current combinations are not
suitable, please evaluate what piece is missing and see if we could just
bring a smaller new piece to this puzzle to solve it.

The reason why we usually prefer small pieces is because users would
have their freedom to combine all the reasonable piecies in their own
way.

Thanks!