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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <PAXPR07MB79844B87A8573E4CFF7F6993A3CE2@PAXPR07MB7984.eurprd07.prod.outlook.com>
Date: Sun, 2 Mar 2025 15:37:49 +0000
From: "Chia-Yu Chang (Nokia)" <chia-yu.chang@...ia-bell-labs.com>
To: Cong Wang <xiyou.wangcong@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "dave.taht@...il.com"
	<dave.taht@...il.com>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"jhs@...atatu.com" <jhs@...atatu.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>, "jiri@...nulli.us"
	<jiri@...nulli.us>, "davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "horms@...nel.org"
	<horms@...nel.org>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"ij@...nel.org" <ij@...nel.org>, "ncardwell@...gle.com"
	<ncardwell@...gle.com>, "Koen De Schepper (Nokia)"
	<koen.de_schepper@...ia-bell-labs.com>, g.white <g.white@...lelabs.com>,
	"ingemar.s.johansson@...csson.com" <ingemar.s.johansson@...csson.com>,
	"mirja.kuehlewind@...csson.com" <mirja.kuehlewind@...csson.com>,
	"cheshire@...le.com" <cheshire@...le.com>, "rs.ietf@....at" <rs.ietf@....at>,
	"Jason_Livingood@...cast.com" <Jason_Livingood@...cast.com>,
	"vidhi_goel@...le.com" <vidhi_goel@...le.com>, Olga Albisser
	<olga@...isser.org>, "Olivier Tilmans (Nokia)" <olivier.tilmans@...ia.com>,
	Henrik Steen <henrist@...rist.net>, Bob Briscoe <research@...briscoe.net>
Subject: RE: [PATCH v5 net-next 1/1] sched: Add dualpi2 qdisc

Please see below inline

Regards,
Chia-Yu

> -----Original Message-----
> From: Cong Wang <xiyou.wangcong@...il.com> 
> Sent: Wednesday, February 26, 2025 1:41 AM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@...ia-bell-labs.com>
> Cc: netdev@...r.kernel.org; dave.taht@...il.com; pabeni@...hat.com; jhs@...atatu.com; kuba@...nel.org; stephen@...workplumber.org; jiri@...nulli.us; davem@...emloft.net; edumazet@...gle.com; horms@...nel.org; andrew+netdev@...n.ch; ij@...nel.org; ncardwell@...gle.com; Koen De Schepper (Nokia) <koen.de_schepper@...ia-bell-labs.com>; g.white <g.white@...lelabs.com>; ingemar.s.johansson@...csson.com; mirja.kuehlewind@...csson.com; cheshire@...le.com; rs.ietf@....at; Jason_Livingood@...cast.com; vidhi_goel@...le.com; Olga Albisser <olga@...isser.org>; Olivier Tilmans (Nokia) <olivier.tilmans@...ia.com>; Henrik Steen <henrist@...rist.net>; Bob Briscoe <research@...briscoe.net>
> 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@...ia-bell-labs.com wrote:
> > From: Koen De Schepper <koen.de_schepper@...ia-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.

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.

> >
> > 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!