Re: [aqm] updated draft charter

[Bob Briscoe <[e-mail]>]

1/ Name suggestion: How about just "Queue Management (QMAN)"?
Otherwise, if we coin the term smart queue mgmt, merely by proposing 
an SQM algorithm, every idiot gets to have everyone else call his/her 
algo smart.

2/ Scope: "Internet routers, lower-layer switches, other middleboxes."
Can we have host buffers in scope pls? This is the transport area, afterall.

3/ "routers, ... include buffers or queues" Buffers and queues are 
not members of the same set (IMO). I don't think this is a picky 
terminology point. Can we adopt the convention that the buffer is the 
fixed memory allocation (hardware or software), and the queue is the 
software construct within the buffer?

It already caused confusion when the problem got called bufferbloat, 
so people thought we were implying the solution was small buffers, so 
they tune out, because they rightly believe this will lead to 
unnecessarily high loss. Actually, on a high speed line with high 
in-degree, it's good practice to have a very large buffer to absorb 
bursts, as long as you have a adaptive queue threshold within it that 
rapidly clamps a tight limit on a standing queue.

Same problem in next para:
" Extremely large buffers have been noticed in some software and
   equipment.  When these queues fill, ..." ->
" Extremely large unmanaged buffers have been noticed in some software and
   equipment.  When these buffers fill, ..." ->

4/ "...proactively managing queues ..."
Picky: I think you mean reactively. Proactively maybe a bit ambitious.

5/ I suggest the enumerated bullets are changed to those below:

"The Active Queue Management and Packet Scheduling working group
   works on algorithms for proactively managing queues in
   order to:

   (1) Minimise standing queues

   (2) help flow sources control their sending rates without unnecessary
   losses, e.g. through ECN

   (3) help minimize delays for interactive applications

   (4) /consider the merits of various techniques/ to protect flows 
from negative impacts of other more
   aggressive or misbehaving flows

Reasoning:

ECN: The original text was:
"(1) help flow sources control their sending rates before the
   onset of necessary losses, e.g. through ECN"
is not accepted wisdom. What's written in RFC3168 makes sense: that 
marking for ECN traffic has to start at exactly the same point as 
loss for non-ECN traffic. Otherwise ECN traffic starves itself. 
Certainly, under v heavy load everyone has to take losses, whether 
ECN or not, but I don't think that's what you're talking about here.

Protecting flows:
The question of whether/how to recommend flow isolation or not is 
part of chartered work - the outcome shouldn't be prejudged in the charter.

6/
"  The AQM working group will publish Informational and Best Current
   Practices documents that cover the design, use, and configuration
   of algorithms for managing queues in Internet devices and software.
"
Add: The scope will include both how best to configure existing 
equipment / software as well as recommendations on designing new 
equipment / software.

7/ "  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.
"
Add: The proper place for changes to ECN & Diffserv is TSVWG, but 
clearly any such changes will need to be co-ordinated with the AQM 
WG, given the code is likely to be entwined with AQM code.

8/  "Many AQM algorithms have been proposed in academic literature, but
   very few are widely implemented and deployed.  "

Is this trying to say very few types of AQM are deployed, or very few 
instances? I think it is trying to say the latter, but that just 
isn't true (IMO). WRED is very widely deployed in enterprise 
networks. And RED is implemented near-univerally by the main 
equipment vendors, and less widely deployed, but not insignificant.

9/ Gap in charter coverage?

"Merits of whether to isolate flows and if so how."

There are multiple functions that often get lumped under "AQM":
a) minimising a standing queue
b) desynchronising losses (/marks)
c) preventing large packet lock-out
d) detecting and policing flows with excessive rate
e) isolating flows from each other (e.g. SFQ)

a,b,c) can be done neutrally and imply no possible policy control.
d,e) depend on policy (which may or may not be hard-coded rather than 
configurable, e.g. all flows get equal scheduler priority).

There's been significant discussion on the list about the merits of 
different ways of doing flow isolation. This is the area where I 
think there is most latent disagreement. We have pretty good 
consensus already around the recommendations in Fred's doc. We will 
have to grasp the flow-isolation and policing nettles, so the charter 
ought to say we're going to.

For instance, my stance is that policy-related functions (d+e) should 
only be deployed at edge-policy enforcement points, not in every 
buffer. Altho SFQ clearly makes an associated AQM like CoDel work 
nicely, I preferred the direction Fred described in:
<http://www.ietf.org/mail-archive/web/aqm/current/msg00081.html>
in which there's a distinguished shared queue, then anything that 
starts causing delay in that queue gets either isolated in its own 
queue or focused policing. Rather than isolating every flow into 
separate queues from the start, because that requires prejudging the 
share of the scheduler everyone gets.

We have found that with multiple real-time video streams, they all 
have highly variable rates, so they multiplex really well together in 
a FIFO. However, if you put them through FQ or WRR, they all get 
forced into ruts that are always the wrong size for all of them. This 
isn't a problem if the sum is not often close to capacity (which is 
why SFQ can appear to be OK with multiple videos). However, the whole 
point of isolation is to protect flows when the system /is/ close to capacity.


Bob

At 18:35 11/07/2013, Jim Gettys wrote:



>On Thu, Jul 11, 2013 at 12:21 PM, David Ros 
><<mailto:[e-mail]>[e-mail]> wrote:
>
>On 11 juil. 2013, at 18:06, 
><mailto:[e-mail]>[e-mail] wrote:
>
> >
> > I agreed that AQM has to some extent already been deployed in some places
> > and this could be confusing to then redefine or obsolete this.
> >
>
>+1
>
>
> > For what it's worth I don't like "smart" queueing as a name - implying
> > it's sounds like a marketing term rather than a combination of "AQM"
> > mark/drop and flow scheduling.
>
>+1
>
>
> >
> > If SQM was short for  scheduling and queue management I may have liked the
> > abbreviation more, ... let's see where this discussion ends.
>
>
>Scheduling and Queue Management is fine with me...
>
>Since we're looking for acronyms that (a) are pronounceable, (b) do 
>not sound like a marketing gimmick, (c) match to a WG name that 
>conveys the essence of what the WG will do, then why not simply: 
>QMAPS? (Queue Management And Packet Scheduling).
>
>
>I'm not willing to bikeshed working group names and will live with 
>whatever people like.  I'm certainly not great at selecting names, 
>having bound the free variable with a window system name.
>
>Names can be important: one of the problems with the "RED" 
>algorithm, whose initial formation was, IIRC, "Random Early 
>Discard".  The name's connotation implied it "randomly" discarded 
>your packets and does so sooner rather than later; not what most 
>network operators want to hear. Kathie and Van named CoDel both 
>because "Constant Delay" describes its intended behavior, but also 
>because "coddling" your packets sounds warm and fuzzy, rather than 
>nasty and random. The great unwashed fail to understand that packet 
>drops can be good for their network's health...
>
>I will not reply further to this thread.
>                                            - Jim
>
>
>David
>
>
> >
> > Gorry
> >
> >
> >> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy 
> <<mailto:[e-mail]>[e-mail]> wrote:
> >>
> >>> I think the attached updated draft charter reflects most of the
> >>> feedback that we've heard so far.
> >>>
> >>> Note that Dave Taht suggested we might want to go with something
> >>> like "Smarter Queue Management" (SQM) for the WG name, because
> >>> purely AQM as a name may not capture FQ type of mechanisms that we
> >>> may want to have in-scope.  I think that scoping discussion may
> >>> still be going on into Berlin, but it's a good point, and likely
> >>> some other people have cute ideas for a name that could capture
> >>> the potential broader scope.
> >>>
> >>
> >> Both Dave's and my experience as relative newcomers to this area is that
> >> the term AQM is pretty tightly bound to mark/drop algorithms in the minds
> >> of many people in the IETF, who also categorize other algorithms as
> >> queuing
> >> algorithms. and make a pretty strong mental distinction between them.
> >>
> >> As my blog post this week
> >> 
> <http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues>http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues,
> >> the killer combination is a cross between rapidly autotuning
> >> mark/drop algorithms with what we're calling flow queueing (since it isn't
> >> "fair" in the also traditional sense of TCP fair queueing at all, and may
> >> not involve TCP flows necessarily either).
> >>
> >> So while I'd be happy to lump this all into the AQM name bucket
> >> personally,
> >> I do think that a name that makes clear we're considering algorithms that
> >> may marry both lines of intellectual thought together will avoid confusion
> >> among many who have worked in one area or the other, but not both.  "Smart
> >> queue management" or SQM is the best we've come up with for a term.
> >>                                                               - Jim
> >>
> >>
> >>> --
> >>> Wes Eddy
> >>> MTI Systems
> >>>
> >>> _______________________________________________
> >>> aqm mailing list
> >>> <mailto:[e-mail]>[e-mail]
> >>> https://www.ietf.org/mailman/listinfo/aqm
> >>>
> >>>
> >> _______________________________________________
> >> aqm mailing list
> >> <mailto:[e-mail]>[e-mail]
> >> https://www.ietf.org/mailman/listinfo/aqm
> >>
> >
> >
> > _______________________________________________
> > aqm mailing list
> > <mailto:[e-mail]>[e-mail]
> > https://www.ietf.org/mailman/listinfo/aqm
>
>=================================================================
>David ROS
><http://www.rennes.enst-bretagne.fr/~dros/>http://www.rennes.enst-bretagne.fr/~dros/
>
>I love deadlines. I like the whooshing sound they make as they fly 
>by. -- Douglas Adams
>
>
>
>
>_______________________________________________
>aqm mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm
>
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT