public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Olga Albisser <olgabnd@gmail.com>
Cc: netdev@vger.kernel.org, Olga Albisser <olga@albisser.org>,
	Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>,
	Oliver Tilmans <olivier.tilmans@nokia-bell-labs.com>,
	Bob Briscoe <research@bobbriscoe.net>,
	Henrik Steen <henrist@henrist.net>
Subject: Re: [PATCHv2 net-next] sched: add dualpi2 scheduler module
Date: Mon, 25 Mar 2019 07:38:29 +0100	[thread overview]
Message-ID: <20190325063829.GA8856@nanopsycho.orion> (raw)
In-Reply-To: <20190324215253.14390-1-olga@albisser.org>

Sun, Mar 24, 2019 at 10:52:53PM CET, olgabnd@gmail.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@albisser.org>
>Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
>Signed-off-by: Oliver Tilmans <olivier.tilmans@nokia-bell-labs.com>
>Signed-off-by: Bob Briscoe <research@bobbriscoe.net>
>Signed-off-by: Henrik Steen <henrist@henrist.net>
>---

For v2 and above, please provide changelog here. Thanks!

  parent reply	other threads:[~2019-03-25  6:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-24 21:52 [PATCHv2 net-next] sched: add dualpi2 scheduler module Olga Albisser
2019-03-25  5:38 ` kbuild test robot
2019-03-25  6:38 ` Jiri Pirko [this message]
2019-03-26 18:37 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190325063829.GA8856@nanopsycho.orion \
    --to=jiri@resnulli.us \
    --cc=henrist@henrist.net \
    --cc=koen.de_schepper@nokia-bell-labs.com \
    --cc=netdev@vger.kernel.org \
    --cc=olga@albisser.org \
    --cc=olgabnd@gmail.com \
    --cc=olivier.tilmans@nokia-bell-labs.com \
    --cc=research@bobbriscoe.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox