[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190325063829.GA8856@nanopsycho.orion>
Date: Mon, 25 Mar 2019 07:38:29 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Olga Albisser <olgabnd@...il.com>
Cc: netdev@...r.kernel.org, Olga Albisser <olga@...isser.org>,
Koen De Schepper <koen.de_schepper@...ia-bell-labs.com>,
Oliver Tilmans <olivier.tilmans@...ia-bell-labs.com>,
Bob Briscoe <research@...briscoe.net>,
Henrik Steen <henrist@...rist.net>
Subject: Re: [PATCHv2 net-next] sched: add dualpi2 scheduler module
Sun, Mar 24, 2019 at 10:52:53PM CET, olgabnd@...il.com wrote:
>DUALPI2 provides extremely low latency & loss to traffic that uses a
>scalable congestion controller (e.g. L4S, 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 their 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.
>
>There is an AQM in each queue.
>* 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.
>* The low latency AQM is, by default, a simple very shallow ECN marking
>threshold similar to that used for DCTCP.
>
>The DualQ isolates the extremely low queuing delay of the Low Latency
>queue from the larger delay of the 'Classic' queue. However, from a
>bandwidth perspective, flows in either queue will share out the link
>capacity as if there was just a single queue. This bandwidth pooling
>effect is achieved by coupling together the drop and ECN-marking
>probabilities of the two AQMs.
>
>The PI2 AQM has two main parameters in addition to its target delay. All
>the defaults are suitable for any Internet setting, but it can be
>reconfigured for a Data Centre setting. The integral gain factor alpha is
>used to slowly correct any persistent standing queue error from the
>target delay, while the proportional gain factor beta is used to quickly
>compensate for queue changes (growth or shrinkage).
>
>Internally, the output of a simple linear Proportional Integral (PI)
>controller is used for both queues. This output is squared to calculate
>the drop or ECN-marking probability of the classic queue. This
>counterbalances the square-root rate equation of Reno/Cubic, which is the
>trick that balances flow rates across the queues. For the ECN-marking
>probability of the low latency queue, the output of the base AQM is
>multiplied by a coupling parameter k . This determines the balance
>between the flow rates in each queue. The default setting makes the flow
>rates roughly equal, which should be generally applicable.
>
>If DUALPI2 AQM has detected overload (when excessive non-responsive
>traffic is sent), it will switch to signalling congestion solely using
>drop, irrespective of the ECN field, or alternatively it can be
>configured to limit the drop probability and let the queue grow and
>eventually overflow (like tail-drop).
>
>Additional details can be found in the draft:
>https://www.ietf.org/id/draft-ietf-tsvwg-aqm-dualq-coupled
>
>Signed-off-by: Olga Albisser <olga@...isser.org>
>Signed-off-by: Koen De Schepper <koen.de_schepper@...ia-bell-labs.com>
>Signed-off-by: Oliver Tilmans <olivier.tilmans@...ia-bell-labs.com>
>Signed-off-by: Bob Briscoe <research@...briscoe.net>
>Signed-off-by: Henrik Steen <henrist@...rist.net>
>---
For v2 and above, please provide changelog here. Thanks!
Powered by blists - more mailing lists