Subject: [aqm] publishing algorithms

From: Wesley Eddy <[email-masked]>
Date: Tue, 01 Apr 2014 08:11:51 -0400

Hello AQMers.  As chairs, Richard and I had been planning to let
the evaluation guidelines converge and then use those to guide
adoption of algorithm documents.

However, we now think there may be value in not waiting so long,
and getting some algorithm documents moving along more quickly.

We hope you can provide some feedback on the plan below:

1) Starting soon, we may look to adopt a small number of algorithm
   drafts for Experimental, with the goal that by doing so, it will
   increase the number of eyeballs and independent reviews of them, and
   enhance the quality, since people may be implementing to the drafts
   in order to test using the evaluation guidelines.  Each algorithm
   *must* clearly identify which types of use cases / scenarios it is
   targeted for.

2) Adoption of an algorithm spec as a working group draft will require
   working group consensus that the algorithm looks attractive to
   experiment with for the stated scenarios, and multiple parties will
   plan to be looking at it, testing, analyzing, providing feedback,
   etc.

3) The evaluation guidelines / scenarios drafts being worked on
   separately will guide the later selection of one or more Experimental
   algorithms to become Proposed Standards with applicability
   statements for the scenarios they have been evaluated in.

We're interested to know if the working group thinks this sounds like
a good idea, bad idea, or any other thoughts.

-- 
Wes Eddy
MTI Systems

---

From: Michael Welzl <[email-masked]>
Date: Tue, 1 Apr 2014 14:16:06 +0200

> a good idea, bad idea, or any other thoughts.

I think it sounds like a good idea!

Nice to get stuff  documented and somewhat stabilized soon, IMHO.

Cheers,
Michael

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 1 Apr 2014 16:34:07 +0000

Makes sense to me. I do have one question. Per charter, in December we are supposed to "Submit first algorithm specification to IESG for publication as Proposed Standard”. Would this be a change of direction for the charter?

Note that I’m not pushing a given algorithm, nor am I convinced that there should be exactly one. In protocol design, we are worried about interoperability, and everyone has to implement the protocol the same way. In AQM, the different algorithms, and the ones we think of next, have to produce a specific drop or mark rate under a specified circumstance (which might be about queue depth, latency in queue, or rate through a queue), and the end systems need to respond to that predictably. The means by which the mark or drop rate is established is semi-irrelevant if the rate itself is maintained. So I’m not exactly sure what the terms “Experimental” or “Proposed Standard” mean in the context and using the definitions in RFC 2026. It would be nice if we had a status that said “recommended for consideration for operational use”, and we could put that status on several that meet our requirements, whatever we decide those are.

On Apr 1, 2014, at 5:11 AM, Wesley Eddy <[email-masked]> wrote:

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

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 01 Apr 2014 13:07:30 -0400

n 4/1/2014 12:34 PM, Fred Baker (fred) wrote:
> Makes sense to me. I do have one question. Per charter, in December 
> we are supposed to "Submit first algorithm specification to IESG for 
> publication as Proposed Standard”. Would this be a change of 
> direction for the charter?

Yes, it would be a shift in plans, and we'd have to make up some new
milestone targets.  That's why we're looking for feedback before doing
it, because it only makes sense to do if the people actually doing the
work will go along with it :).

> Note that I’m not pushing a given algorithm, nor am I convinced that 
> there should be exactly one. In protocol design, we are worried about
> interoperability, and everyone has to implement the protocol the same
> way. In AQM, the different algorithms, and the ones we think of next,
> have to produce a specific drop or mark rate under a specified
> circumstance (which might be about queue depth, latency in queue, or
> rate through a queue), and the end systems need to respond to that
> predictably. The means by which the mark or drop rate is established
> is semi-irrelevant if the rate itself is maintained. So I’m not
> exactly sure what the terms “Experimental” or “Proposed Standard”
> mean in the context and using the definitions in RFC 2026. It would
> be nice if we had a status that said “recommended for consideration
> for operational use”, and we could put that status on several that
> meet our requirements, whatever we decide those are.

I think (well, I hope) that pretty much everyone agrees on this.

My personal thought is that the Experimental ones may have some warts or
"unknowns", and that should be okay with us, as long as they seem to be
promising and there is wide interest in using them and finding out more
about how they work or how they can be tweaked further, but a baseline
is needed/desirable for multiple people to work from.

The Standards Track algorithm(s) should have substantially less warts or
unknowns about them, and people should be able to put them in their code
and products with strong confidence that:

  1) they're implementing from an unambiguous specification
  2) it will perform with well-understood results

For instance, a hypothetical Algorithm X may have been beat to death by
one set of folks for some particular use case like a home gateway cable
router. They speculate that it will do well for some other scenarios
too, and there are other people interested in implementing and trying it
out over a longer term, but nobody is fully sure that it's absolutely
the best algorithm, and maybe there are some downsides like a bit of
minor tuning or a hidden variable that has to be tweaked for other
scenarios. That sounds like a good candidate for Experimental to me.
Maybe people will go play with it, and either learn good things and fix
it up for Standards Track, or learn bad things and drop it or make it
Historic.

-- 
Wes Eddy
MTI Systems

---

From: Dave Taht <[email-masked]>
Date: Thu, 17 Apr 2014 14:58:24 -0700

> and getting some algorithm documents moving along more quickly.

I saw this came out on april 1, and have a tendency to ignore stuff
that comes out that day. :)

>    *must* clearly identify which types of use cases / scenarios it is

We submitted the codel and fq_codel drafts for consideration prior
to ietf 89, and have got no feedback from anyone as yet. The first
went into tsvwg

https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text=1

and the second is seemingly homeless as yet:

https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00

As they were being developed independently, they have a few nits
in relating to each other that need to be resolved, presently.

If this is a new requirement, and it seems like it is, then those will
need to be revised more fully, although each has caveats and
use cases described already late in the document.
(sections 6 and 9 in the first, section 10 in the second)

Are you proposing an explicit use cases and scenarios section?

>    plan to be looking at it, testing, analyzing, providing feedback,

+1

I note that I have another draft in progress that I hope to complete before
ietf-90 describing multiple deployed aqm + packet scheduling + classification
systems in the hope to get the overall conversation on track.

http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html

and I'd like to talk to that at ietf 90 if I'm not too broke to go. Otherwise
hawaii.

>    statements for the scenarios they have been evaluated in.

At this point I must confess to being deeply dissatisfied with the
progress in the AQM guidelines document. I don't know what to do about it,
I've tried to talk about the issues being totally missed in things like this:

http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management

and here on the list...

and at the moment I'd prefer more folk have better models and understanding
of actual traffic types on various media types before even trying to
write anything down as to what valid tests are.

I think I have finally come up for what I'd like this group to be doing,
which is at least partially out of scope for the charter, but the acronym is
nice: "CQM" - "Comprehensive Queue Management", and a goal is to
try and design something that leverages the work other groups such
as rmcat are doing.

> a good idea, bad idea, or any other thoughts.

By all means, let's get folk fiddling with the working algorithms and code
that exists today and is distributed now with every Linux box. Perhaps
some more BSD support will show up soon, or hardware support in
some other gear other than in what I describe above.

I'm all in favor of new algorithms too, if anybody's got some...

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article