Subject: [aqm] Alia Atlas' No Objection on draft-ietf-aqm-fq-codel-05: (with COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Thu, 17 Mar 2016 06:59:19 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-aqm-fq-codel-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think it would be useful to have a reference to the Linux
implementation ("current" version and pointer).

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 17 Mar 2016 18:13:55 +0100

Hi Alia

I've added a reference pointing to the fq_codel code in Linux git tree
to the latest updated version, available here:
https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-06.html (or .txt).

-Toke

---

From: Alia Atlas <[email-masked]>
Date: Thu, 17 Mar 2016 14:18:34 -0400

Thanks!

---

From: Dave Taht <[email-masked]>
Date: Thu, 17 Mar 2016 13:41:34 -0700

> https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-06.html (or .txt).

I'm not huge on calling this reference [LINUX]. [LINUXSRC]? [SRC]?

I also felt compelled, after this round of cite-adding, to add a few
more cites, (what will be) rfc7806, BQL, HTB, and HFSC, with a brief
section explaining why they are needed also. BQL was the under
appreciated breakthrough that made scaling past a gbit possible, and
would (if implemented) make dsl and cable modems a lot better,
at their (much slower) speeds.

https://github.com/dtaht/bufferbloat-rfcs/commit/7d500133008857b7b78000abac9d592e66477ffb

adding:

## Device queues must also be well controlled

It is best that these AQM and FQ algorithms run as close to the hardware
as possible. Scheduling such complexity at interrupt time is difficult, so
a small standing queue between the algorithm and the wire is often needed
at higher transmit rates.

In Linux, this is accomplished via "Byte Queue Limits" {{BQL}} in the
device driver ring buffer (for physical line rates), and via a software
rate limiter such as {HTB}}, {{HFSC}}, or {{CAKE}} otherwise.

Other issues with concatenated queues are described in {{CODEL}}.

...

There has been such an accumulation of small changes in response to
this wonderful review process that I fear that going through another
"last, last" call will be needed.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 17 Mar 2016 22:37:14 +0100

> I'm not huge on calling this reference [LINUX]. [LINUXSRC]? [SRC]?

Figured the RFC editor was going to fix that.

> Other issues with concatenated queues are described in {{CODEL}}.

Will fix up your additions before submitting the updated draft tomorrow
(from eyeballing, I'm pretty sure it doesn't currently compile).

> "last, last" call will be needed.

Well, while there has been a bunch, they're all clarifications and minor
changes; the substance is not changed from the version that went to last
call.

-Toke