Active Queue Management and Packet Scheduling
charter-ietf-aqm-01

[Ballot comment]
When these buffers fill, interactive
applications and other traffic can be severely impacted or
completely broken, due to high and potentially oscillating delays.

I think you mean

"When these buffers start to fill"

Of course when they actually fill you get packet drop which introduces
a different class of error than that induced by late packets.

[Ballot comment]
I'm sure it is an English/American thing, but "When these buffers fill"
means to me "When these buffers have become full" and I don't think you
are talking about buffer depletion. So maybe you should say "When a
large number of packets are queued."

A similar language issue arises in...

  (1) minimize standing queues, helping to reduce delay for
      interactive applications

...where I think it is the queue *length* (measured in packets or
bytes?) that you want to minimise, not the number of queues.

[Ballot comment]
I assume "potentially policing of flows" is about throttling users/abusers, but I think that it does require significant attention not just from the wg but also from the wider community.  I'm loathe to add in the "we'll coordinate with x, y, and z wgs" here because I think noting it here is enough and because I trust sponsoring AD to get 'er done!

[Ballot comment]
  Many AQM algorithms have been proposed in academic literature, but  a smaller number are widely implemented and deployed.  The goal of the  working group is to produce recommendations that will actually be used,  and algorithms that will actually be implemented, deployed in equipment,  and enabled.

What is the difference between "deployed in equipment" and "enabled"?

Changed charter milestone "Submit AQM evaluation guidelines to IESG for publication as Informational", set description to "Submit AQM algorithm evaluation guidelines to IESG for publication as Informational"

[Ballot block]
1.
  The AQM working group will produce Informational, Best Current
  Practices, and Standards Track Applicability Statement documents
  that cover the design, use, and configuration of algorithms for
  managing queues in Internet devices and software. The scope
  includes both how to best configure existing equipment and
  software, as well as recommendations on designing new equipment
  and software.

I hope monitoring is included. A black box queue management system is not appropriate from an operational point of view. Queue management is mentioned, but not really the monitoring of the algorithm & queue state, which is the basis for my management (OPS). We don't need a MIB or anything. Show commands are good enough (to start with). A fine output in the specification could be: "an implementer must provide the value of the dynamic parameter A, the per flow queue parameters B, etc... for operators"

I would be happy with the additional "and monitoring" below.

  The AQM working group will produce Informational, Best Current
  Practices, and Standards Track Applicability Statement documents
  that cover the design, use, configuration, and monitoring of algorithms for
  managing queues in Internet devices and software. The scope
  includes both how to best configure existing equipment and
  software, as well as recommendations on designing new equipment
  and software.

2.
-
From the charter text, could not understand what the entry is about
Jul 2014
Submit AQM evaluation guidelines to IESG for publication as Informational

AQM Evaluation guidelines?
  - criterias for accepting an algorithm in the AQM WG?
  - criterias to compare the different algorithms, and select the best one to standardize
  - algorithm benchmarking?
  - algorithm comparisons?

After discussing briefly with Martin, I guess that this entry is more about development of guidelines on how to test the different algorithms and evaluate their respective performance.
Whatever it is, we must elaborate this entry.
At the very minimum, from which I understand, this is about algorithm
    OLD: Submit AQM evaluation guidelines
    NEW: Submit AQM algorithm evaluation guidelines

[Ballot comment]

  Many AQM algorithms have been proposed in academic literature, but  a smaller number are widely implemented and deployed.  The goal of the  working group is to produce recommendations that will actually be used,  and algorithms that will actually be implemented, deployed in equipment,  and enabled.

What is the difference between "deployed in equipment" and "enabled"?

[Ballot comment]
Please consider the development of Standards Track Applicability Statements in this working group, rather than just Informational (or BCP) documents.  AS seems the perfect way to propose the use of certain techniques, and to have those proposals mature along with the protocols (perhaps going from Proposed Standard to Internet Standard).

[Ballot comment]
Thanks for considering my previous comments. I'm still a "Yes", but on the new version of the charter ...

If working group charters are contracts, and I was co-chair for AQM, I would have absolutely no idea what this text obligates the working group to do.

  Furthermore, the group
  will jointly work with the Routing and Internet Area in order to
      ^^^^^^^              ^^^^^^^^^^^^^^^^^^^^^^^^^

  involve vendors of networking equipment in the development of the
  AQM mechanisms.

First, if there are specific working groups in INT and RTG that AQM should be "jointly working with", naming them would be helpful. I can make guesses, but the current text says AQM will work jointly with the Routing Area (which has 19 active working groups) and with the Internet Area (which has 23 active working groups), so I'm hoping we could narrow that down somewhat.

Second, what does "jointly work with" mean in practice? I note that SUNSET4 in INT has Tech Advisers from OPS, RTG and TSV. Are we talking about something like that? Are we expecting AQM documents to go through WGLCs in multiple working groups?

I'm guessing and I'm shooting in the dark, and I'm sure other ADs could think of other specific ways to accomplish what's being described in general terms. If I was co-chair, I'd want to know what the IESG intends that the working group will do.

[Ballot comment]
Again, please change:

OLD:
  The AQM working group will produce Informational, Best Current
  Practices, and Standards Track Applicability Statement documents
NEW:
  The AQM working group will produce documents that...

(You could change the "and" to an "or" if you really wanted to list the types of documents.)

I think it's quite possible in the end that documents of this sort might end up on the standards track, or might be Informational, and I'd rather the WG not get into an argument about which is which. They should produce a consensus document with recommendations, and the WG and the IESG can figure out the appropriate status once we see the actual content of the document.

Changed charter milestone "Submit AQM recommendations to IESG for publication as BCP obsoleting RFC 2309", set description to "Submit AQM recommendations to IESG for publication, obsoleting RFC 2309"

[Ballot block]
A significant concern with congestion technology that operates
in the network rather than simply on the host, is that it has
hardware and fast-path implications for routers and switches.

It is regrettable that the discussion of congestion technologies
so often occurs without the deep involvement of router
and switch designers. To be successful I therefore think
that the charter needs to mandate an approach to the execution
of the task that that ensures the involvement of the expertise
in Routing and Internet. In particular an execution
model needs to be sought so as to involve engineers
that do not know that they need to be involved because
so few look outside outside their core IETF area to see
what is happening in Transport.

Thus I am concerned with the text:

"Towards these ends, the group actively encourages
participation from operators and implementers, and will coordinate with
the IETF OPS area and other relevant parts of the IETF and Internet
community. "

This seems too weak in terms of validating that the
technology output  from AQM is viable in network
elements that need to deploy it in the home, network
edge, data center and network core.

This is a work area that needs to be fundamentally
a cross-area technology development from day one.

[Ballot comment]
I agree with Barry, and would like two specific changes:

OLD:
  The AQM working group will publish Informational and Best Current
  Practices documents that...
NEW:
  The AQM working group will produce documents that...

And change the milestone not to indicate the status of the first document as "BCP".

I think it's quite possible in the end that documents of this sort might end up on the standards track, or might be Informational, and I'd rather the WG not get into an argument about which is which. They should produce a consensus document with recommendations, and the WG and the IESG can figure out the appropriate status once we see the actual content of the document. (If you want to make a more extensive change, you could even include some text that says pretty much this.)

[Ballot comment]
Probably a nit...

  When these buffers fill, interactive
  applications and other traffic can be severely impacted or
  completely broken, due to high and potentially oscillating delays.

It isn't the fact that the buffers fill that causes the problem. 
Indeed, one might argue that if they did fill we would see a bunch
of different problems that the buffers were put in place to stop us
seeing.

maybe s/When these buffers will/When large numbers of packets are buffered/

[Ballot comment]
Please consider the development of Standards Track Applicability Statements in this working group, rather than just Informational (or BCP) documents.  AS seems the perfect way to propose the use of certain techniques, and to have those proposals mature along with the protocols (perhaps going from Proposed Standard to Internet Standard).

Tiny nit: the semicolon in list item 1 should be a comma.

[Ballot comment]
I have some suggested edits, but I'm already a Yes.

...


  Extremely large unmanaged buffers have been noticed in some
  software and equipment.  When these buffers fill, interactive
  applications and other traffic can be severely impacted or

Is there a better description of "and other traffic"? Is this realtime media and/or streaming media? Are there other categories?

  completely broken, due to high and potentially oscillating delays.
 
...


  (1) minimize standing queues; helping to reduce delay for
  interactive applications

I don't think "minimize standing queues" is the right way to say this (if minimizing standing queues was the goal, stop-and-wait protocols would be awesome).

Is this "preventing uncontrolled growth in standing queues" or something like that?

...


  The AQM working group will also publish algorithm specifications
  that are found to be broadly applicable and beneficial.  Evaluating
  these algorithms shall be done in coordination with the Internet
  Congestion Control Research Group (ICCRG) in order to select and
  assess the relevant criteria, scenarios, and metrics.

Is there any interaction with RMCAT's chartered work on "Defining evaluation criteria for proposed congestion control mechanisms"? (If there's not, would it be helpful to say there's no interaction? Or am I the only one who might be confused? :-)

...

 
  The working group will not make changes to ECN, DiffServ, or other
  IETF protocols, though existing ECN, DiffServ, and other mechanisms
  may be used within the algorithms proposed. 

This is deep in Nit-burg, but I might have said this as

"The working group will not make changes to existing IETF protocols, but the working group may use ECN, Diffserv, and other mechanisms maintained by the TSVWG working group. Since the implementation of these mechanisms is likely to be entwined with AQM algorithms, there is expected to be close coordination between the TSVWG and AQM groups.


  As their implementation
  is likely to be entwined with AQM algorithms, there is expected to be
  close coordination between both TSVWG and AQM groups.