Subject: [aqm] adoption call: algorithm drafts

From: Wesley Eddy <[email-masked]>
Date: Tue, 16 Sep 2014 09:38:32 -0400

On the mailing list, on the summer webex, and during the last
meeting, we've discussed plans and expectations for adopting
algorithm specifications as working group drafts.

For a process description, see page 6 of:
http://www.ietf.org/proceedings/90/slides/slides-90-aqm-0.pdf
(one exception is that our charter says algorithms can be
Proposed Standard, and we must have forgot that when drawing
the chart)

Here is the list of algorithm documents and how we view their
current status (alphabetical order):

- draft-hoeiland-joergensen-aqm-fq-codel : this has cleared
  "Gate-1", and is welcome for continued discussion, but is
  heavily focused on the FQ / scheduling aspect, and relies
  on CoDel as an AQM.  It could become an appendix to the CoDel
  draft, or proceed some other way.  Feedback about how folks
  want to handle this is very welcome.

- draft-lauten-aqm-gsp : this has cleared "Gate-1" and is
  welcome for continued discussion, but we haven't yet seen
  the interest from multiple parties towards progressing it

- draft-nichols-tsvwg-codel : this is ready for the "Gate-2"
  decision about WG adoption.  We have some significant
  concerns about whether editors are available to handle this
  through the working group, however.

- draft-pan-aqm-pie : this is ready for the "Gate-2" decision
  about WG adoption.

- draft-white-aqm-docsis-pie : this could either become an
  appendix to the draft-pan specification or could progress
  in parallel to it as an Informational description of what
  has been done, and shouldn't require much additional work.

We would like feedback right now on adopting:
1 - http://tools.ietf.org/html/draft-pan-aqm-pie-01
and
2 - http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02

towards the charter milestone for submitting algorithm
specifications to the IESG.  Whether they are Proposed Standard
or Experimental can be debated now or later, but we want to
probe if there's critical mass to adopt them first.

-- 
Wes Eddy
MTI Systems

---

From: Dave Taht <[email-masked]>
Date: Tue, 16 Sep 2014 16:58:36 +0300

>   want to handle this is very welcome.

Hmm. We did not update this draft (2 minor nits in it) yet for a
 trivial reason: because the tracker does not handle hyphenated
names correctly.

I agree it relies heavily on the codel draft to keep the distinction
between flow queuing and aqm distinct. If it were to include
codel (or vice versa), the draft would get rather long.

As it is, it contains a textual description and not enough
pseudo-code, IMHO.

If a fq_pie were produced, how would that work?

>   the interest from multiple parties towards progressing it

I have no interest in this.

>   through the working group, however.

Well, I'd be willing to take it on if the primary authors would
let me.

>   has been done, and shouldn't require much additional work.

I happen to like the second draft here very much as it goes
into more of the complexities of actual real world implementation.

It didn't seem as though the working group is interested in
"comprehensive queue management" as I described in my
last preso.

(the code for that - an all-singing, all-dancing qdisc, that does
rate shaping, diffserv differentiation, AND fq_codel has been
taking shape, rapidly.)

> probe if there's critical mass to adopt them first.

+1 on both.

>
> --
> Wes Eddy
> MTI Systems
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 16 Sep 2014 10:07:09 -0400

> "comprehensive queue management" as I described in my

Actually, I would say that in the near term this is true,
since we need to get the mark/drop AQM algorithm work done,
but in the longer-term it could certainly be of interest.

-- 
Wes Eddy
MTI Systems

---

From: Dave Taht <[email-masked]>
Date: Tue, 16 Sep 2014 17:26:44 +0300

> but in the longer-term it could certainly be of interest.

I don't have a problem with letting it bake for a while! Lots of
problematic ideas in there, but a  couple that really work.

If anyone is actually interested in the state of things now, jonathon
morton has a mostly working linux patch set he can supply, and he
would like to give a talk about it at this or the next ietf. If
discussing the ideas here is out of line at the moment (and I think it
would be a distraction) we'll start talking to it over on the bloat or
cerowrt-devel lists.

-- 
Dave Täht

---

From: Greg White <[email-masked]>
Date: Tue, 16 Sep 2014 17:06:04 +0000

+1 on both

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Wed, 17 Sep 2014 23:50:07 +0000

+1 on both

Rong

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 18 Sep 2014 13:50:40 +0200

Dave Taht <[email-masked]> writes:

> between flow queuing and aqm distinct. If it were to include codel (or
> vice versa), the draft would get rather long.

IMO it would be quite possible to make the description AQM-agnostic; and
I do believe the scheduling mechanism has value in itself. I'll be happy
to present some data on this at the Honolulu meeting if there's interest
in it.

Perhaps a way forward would be to make the main description of the
scheduling mechanism AQM-agnostic, and then have a section describing
interactions with specific AQMs. This would just include CoDel right
now, of course, but would make it possible to, for instance, add in an
fq_pie at a later date...

>> 1 - http://tools.ietf.org/html/draft-pan-aqm-pie-01> and
>> 2 - http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02>

+1.

-Toke

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Sep 2014 14:15:55 +0200

>>> probe if there's critical mass to adopt them first.

+1

Michael

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 18 Sep 2014 18:16:39 +0000

On Sep 16, 2014, at 6:38 AM, Wesley Eddy <[email-masked]> wrote:

> specifications to the IESG. 

Personally, I think submitting those two as PS makes sense. No comment on the others in the list; I could imagine some of them eventually.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 18 Sep 2014 18:20:14 +0000

> If a fq_pie were produced, how would that work?

We are doing an fq_pie implementation, at least as a prototype. It merges the fq part of your existing fq_codel code RP’s PIE algorithm. There is a part of me that would want to revisit the design of fq to make it a calendar queue, but that is down the road. What we’re interested in right now is an apples/apples comparison with fq_codel. Further reports when we’re ready to report, which isn’t yet.

---

From: Greg White <[email-masked]>
Date: Fri, 19 Sep 2014 20:18:32 +0000

Fred,

I know you, Rong and Bill VS have seen it, but in case others haven't,
there is an apples-to-apples comparison of fq-codel and fq-pie in my paper
from May (along with some design notes, since the merge of fq and pie is
not as straightforward as one might think).

http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf

Best Regards,
Greg

On 9/18/14, 12:20 PM, "Fred Baker (fred)" <[email-masked]> wrote:

>We are doing an fq_pie implementation, at least as a prototype. It merges
>the fq part of your existing fq_codel code RP¹s PIE algorithm. There is a
>part of me that would want to revisit the design of fq to make it a
>calendar queue, but that is down the road. What we¹re interested in right
>now is an apples/apples comparison with fq_codel. Further reports when
>we¹re ready to report, which isn¹t yet.

---

From: Dave Taht <[email-masked]>
Date: Sat, 20 Sep 2014 00:04:43 +0300

> not as straightforward as one might think).

Please don't declare fq_codel (in the real world) equal to your setup
of ns2 sfq_codel.

It is something of a wild extrapolation to compare sfq_codel target
50ms interval 150ms flows 32

to what we have deployed in the real world against cablemodems as
fq_codel quantum 300 target 5ms interval 100ms flows 1024

as we show here:

http://burntchrome.blogspot.gr/2014_05_01_archive.html

the two level DRR in fq_codel has a bit less complexity than the ns2
SFQ_codel code and I've never felt it matched the linux code well
enough.

I otherwise mostly agree that the issues with applying fq on top of
pie induce below.

Now that the cablelabs ns2 code is mainlined, and GSOC bufferbloat
summer of code for ns3 is done, and most of that code headed for
mainline, (codel and some asymmetric network tests landed, (including
a partial CMTS emulation), fq_codel is waiting on some improvements of
packet header processing) I hope to find the time to do a real
fq_codel implemention for ns2, and maybe get netperf-wrapper up to
where it could duplicate more of your tests.

I am curious, do any of your tests assume ack prioritization is in play?

-- 
Dave Täht

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 19 Sep 2014 21:29:56 +0000

Thanks much.

---

From: Greg White <[email-masked]>
Date: Mon, 22 Sep 2014 21:44:09 +0000

>Please don't declare fq_codel (in the real world) equal to your setup

Yes, YMMV depending on a lot of things. Our comparison was specific to
DOCSIS upstreams, and used some optimized parameters to get the best
feasible mix of performance that we could.  It was apples-to-apples, but
I'm not claiming that the results should be interpreted to hold across all
possible implementations and configurations of *fq(-|_)(pie|codel).

>fq_codel quantum 300 target 5ms interval 100ms flows 1024

Different for sure, but I wouldn't characterize it as a wild
extrapolation.  We used quantum 300 as well.  For the other parameters, we
tested with the lower target values and lower interval values and saw
better performance by boosting them to the values we reported.  With *fq
in the mix, CoDel or PIE really become the second line of defense and
primarily impact latency performance when you have a hash collision.  With
1024 queues, I would expect that is somewhat rare (certainly more rare
than we saw with 32 queues), so opening up some more burst/buffer
tolerance for TCP could get you better short term TCP results in a range
of conditions (keep in mind that RRUL is a nice test, but not the only
one) with very little downside.

32 queues vs 1024 ... yes we would have seen more frequent hash collisions
in our results. But, 32 queues per Service Flow (1024 queues total) was
about the limit of plausibility for our MAC.  Also, we've already shared
our concerns about potential exacerbations of the horizontal queuing
problem, VPN tunnels, etc.

In any case, I'm not trying to say that I have a monopoly on comparisons
between *fq-codel and *fq-pie, just that we did one (and so far it's the
only one).  

>http://burntchrome.blogspot.gr/2014_05_01_archive.html

I guess I missed the comparison to *fq-pie on that page.  ?

Also, please don't declare your PIE implementation equal to the one that
is defined in DOCSIS ;-)

>SFQ_codel code and I've never felt it matched the linux code well

How so?

>I am curious, do any of your tests assume ack prioritization is in play?

No, the contrary.  We assume it is not present.