Subject: [aqm] Alia Atlas' Yes on draft-ietf-aqm-codel-07: (with COMMENT)

From: Alia Atlas <[email-masked]>
Date: Wed, 12 Apr 2017 22:28:47 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-aqm-codel-07: Yes

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-codel/

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

Thank you for a clear and very well written document.  This was well
worth staying up
past 1am to read fully.  I do have one primary comment and a couple minor
points.

First, the document status is Experimental.   While encouraging
experimentation, the
document doesn't really articulate what the concerns are or how
experimentation might
determine that this should be changed to standards track.  While
regrettably I haven't
personally followed the AQM work, I might assume that some of the issues
to general
applicability might be tied to aspects around the challenges of applying
CoDel to a 
system architecture built around WRED AQM and enqueue complexity rather
than dequeue
complexity.  Having a paragraph that gave context in the introduction for
the questions
still to be explored would be helpful.

a) In Sec 3.4 :  "This property of CoDel has been exploited in
   fq_codel [FQ-CODEL-ID], which hashes on the packet header fields to
   determine a specific bin, or sub-queue, for each five-tuple flow,"
  For the general case of traffic, it would be better to focus on using a
microflow's
  entropy information  - whether that is derived from a 5-tuple, the IPv6
flow label, 
  an MPLS Entropy label, etc.  Tying this specifically to the 5-tuple is
not ideal.
  Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but even a
slight rephrasing
to "for each microflow, identifiable via five-tuple hash, src/dest + IPv6
flow label, or
other entropy information" would encourage better understanding of
micro-flow identification.
Of course, this is just a comment - so do with it what you will.

b) (Nit) In Sec 5.1: " We use this insight in the pseudo-code for CoDel
later in the draft."
  The pseudo-code is actually earlier in the draft.  Also
s/draft/document for publication.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 13 Apr 2017 12:34:46 +0200

Hi Alia,

thanks for your feedback! Just on your first point regarding the status. The working group felt that there was not enough deployment to go directly to standards track and given AQM algorithm don’t need interoperability it was not really important for them to go to standards track right away. However, I leave it to the authors if they are able to add more text on how experimentation should be further performed.

Mirja

> Am 13.04.2017 um 07:28 schrieb Alia Atlas <[email-masked]>:
> 
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: Alia Atlas <[email-masked]>
Date: Thu, 13 Apr 2017 09:56:07 -0400

Hi Mirja,

Thanks for the information.  I completely agree that it is up to the
authors, shepherd & WG Chairs as to what
clarity to add.

On the standards track not being required due to not needing
interoperability with at the same time not enough
deployment, I do think that having a clear statement would help encourage
that deployment.  Otherwise, it's a
catch-22.  I also don't know if codel or fq-codel is actually preferable
and the reasoning - but I haven't gone and
reread the latter.   For this work, where the deployment has real hardware
(ASIC, etc) consequences with long
lead-times, being clearer would help.

It's nice to see this work moving ahead.

Regards,
Alia

On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Hi Alia,
>
> thanks for your feedback! Just on your first point regarding the status.
> The working group felt that there was not enough deployment to go directly
> to standards track and given AQM algorithm don’t need interoperability it
> was not really important for them to go to standards track right away.
> However, I leave it to the authors if they are able to add more text on how
> experimentation should be further performed.
>
> Mirja
>
>
>

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Apr 2017 10:20:34 -0700

> authors, shepherd & WG Chairs as to what

There seems to be consensus on moving 5 to 2 and a few nits
worth fixing - but I'm not an author of the codel draft.

> deployment, I do think that having a clear statement would help

At the time these documents were semi-final (going on 3 years back)
it didn't seem like pursuing standards track was the right idea.

We still do not have enough deployment data on enough underlying media
types - so far we have decent data on cable modems, ethernet, and now
wifi. Could use an LTE enodeb and MPLS implementation, at least.

> encourage that deployment. Otherwise, it's a
> catch-22. I also don't know if codel or fq-codel is actually
> preferable and the reasoning - but I haven't gone and

I don't know of any pure codel deployments, what's in the third
generation in the field is all fq_codel based, with a little bit
of uptake of cake[1] with january's "lede-project" release.

still waiting for the first pie based cable modems to appear.

still hoping we see more than middle tier vendors than ubnt
move forward.

Codel's ideas do apply independently to all sorts of queue management
problems, not just packets per se', and it seems hard enough to wedge
them into a standalone draft.

> reread the latter. For this work, where the deployment has real
> hardware (ASIC, etc) consequences with long

Well, what I know of the initial fpga attempt - one company went under,
another went dark. There's some work that may apply (soon) in cambridge's
netfpga project. Certainly hope that there is HW IP in progress!

There's plenty of time to standardize, and it seems like a great
jump to move from experimental to standards track.

On the fq_codel front, we found it advantagous to add a bulk dropper
last year[2], and we learned a lot from the fq_codel on wifi
effort [3], and recently made a nice fix for locally terminated vpns[4].

Given how long the process has taken I've thought about pulling the
fq_codel draft and adding in the insights from those efforts... (but
that has been stuck behind the codel draft for 2 years in NEEDREF,
review was all done). As it will take another year or two to get back
decent data from the field on the wifi front, I think getting out the
fq_codel draft as it is, is just fine, and 3 or so more years more we
can go *.bis on everything.

If there is any one thing I'd like to re-add to the aqm lists' workload
it is the standard need for something like "BQL" to manage underlying
ring buffers better, as that was the core technology that made doing any
level of aqm on high speed ethernet possible.

[1] https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/
[2] Bulk dropping and dequeuing:

   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=9d18562a227874289fda8ca5d117d8f503f1dcca
   https://lwn.net/Articles/692399/
   
[3] "Ending the Anomaly - Achieving Low Latency and Airtime Fairness in
WiFi" Toke Høiland-Jørgensen, Michał Kazior, Dave Täht, Per Hurtig, Anna
Brunstrom https://arxiv.org/abs/1703.00064

[4] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=264b87fa617e758966108db48db220571ff3d60e

> On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF)
> <[email-masked]> wrote:
>
>     Hi Alia,
>     
>     thanks for your feedback! Just on your first point regarding the
>     status. The working group felt that there was not enough
>     deployment to go directly to standards track and given AQM
>     algorithm don’t need interoperability it was not really important
>     for them to go to standards track right away. However, I leave it
>     to the authors if they are able to add more text on how
>     > Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     > -
>     ---------------------------------------------------------------------
>    
>     > COMMENT:
>     > -
>     ---------------------------------------------------------------------
>    
>     >

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Apr 2017 16:18:22 -0400

> experimentation should be further performed.
​This should be revisited.

fq_codel is the default queue discipline on many/most Linux distributions
on the planet at this date.
                                                   - Jim
​

---

From: Jim Gettys <[email-masked]>
Date: Thu, 13 Apr 2017 16:23:08 -0400

> on the planet at this date.

​Actually, I take that back.

Codel is present in Linux, but essentially unused; it is there for
experimentation​ (to make it easy for people to compare with fq_codel, PIE,
etc, and to allow the fq_codel spec to reference it.

So Experimental is appropriate for Codel, though explaining why would be
good.  Fq_codel is a different story: it's widely deployed, and there are
multiple implementations (I believe the BSD folks finally got their act
together).
                                                  - Jim

                                                   - Jim

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 19 Apr 2017 19:43:59 +0200

Hi Alia,

nearly forgot that I quickly want to come back to you on this one.

Actually there is no one good recommendation to make. This is why the working 
ended up standardizing multiple schemes. However, the general guidance given 
in RFC 7567 is to deploy at least one of the solution. And there is also 
RFC7928 that gives guidelines for the characterization of AQM scheme that can 
support operator to evaluate which one fits best their own requirements.

Mirja

On 13.04.2017 15:56, Alia Atlas wrote:
> Hi Mirja,
>
> Thanks for the information.  I completely agree that it is up to the authors,
> shepherd & WG Chairs as to what
> clarity to add.
>
> On the standards track not being required due to not needing interoperability
> with at the same time not enough
> catch-22.  I also don't know if codel or fq-codel is actually preferable and
> the reasoning - but I haven't gone and
> On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Alia,
>
>     The working group felt that there was not enough deployment to go
>     directly to standards track and given AQM algorithm don’t need
>     interoperability it was not really important for them to go to standards
>     track right away. However, I leave it to the authors if they are able to
>     add more text on how experimentation should be further performed.
>
>     Mirja
>
>
>
>     > Am 13.04.2017 um 07:28 schrieb Alia Atlas <[email-masked]
>     <mailto:[email-masked]>>:
>     >
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/>
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/aqm>
>
>