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

Please see below inline

Regards,
Chia-Yu

-----Original Message-----
From: Cong Wang <redacted> 
Sent: Wednesday, February 26, 2025 1:41 AM
To: Chia-Yu Chang (Nokia) <redacted>
Cc: netdev@vger.kernel.org; dave.taht@gmail.com; pabeni@redhat.com; jhs@mojatatu.com; kuba@kernel.org; stephen@networkplumber.org; jiri@resnulli.us; davem@davemloft.net; edumazet@google.com; horms@kernel.org; andrew+netdev@lunn.ch; ij@kernel.org; ncardwell@google.com; Koen De Schepper (Nokia) <redacted>; g.white <redacted>; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; vidhi_goel@apple.com; Olga Albisser <redacted>; Olivier Tilmans (Nokia) <redacted>; Henrik Steen <redacted>; Bob Briscoe <redacted>
Subject: Re: [PATCH v5 net-next 1/1] sched: Add dualpi2 qdisc


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



On Sat, Feb 22, 2025 at 11:07:25AM +0100, chia-yu.chang@nokia-bell-labs.com wrote:

quoted

From: Koen De Schepper <redacted>

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.

Making two independent queues without "coupling" cannot meet the goal of DualPI2 mentioned in RFC9332: "...to preserve fairness between ECN-capable and non-ECN-capable traffic."
Further, it might even starve Classic traffic, which also does not fulfill the requirements in RFC9332: "...although priority MUST be bounded in order not to starve Classic traffic."

DualPI2 is to maintain approximate per-flow fairness on L-queue and C-queue, and a single qdisc is made with a coupling factor (i.e., ECN marking probability and non-ECN dropping probability) and a scheduler between two queues.

I would modify commit message to reflect the above points, and hope this if fine for you.

quoted

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!