Re: [aqm] updated draft charter

["Rong Pan (ropan)" <[e-mail]>]

From: Bob Briscoe <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 12, 2013 9:56 AM
To: Wesley Eddy <[e-mail]<mailto:[e-mail]>>
Cc: Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>, Jim Gettys <[e-mail]<mailto:[e-mail]>>, David Ros <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [aqm] updated draft charter


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.


>>>>> Totally Agree….


Rong



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



On Thu, Jul 11, 2013 at 12:21 PM, David Ros < [e-mail]<mailto:[e-mail]>> wrote:

On 11 juil. 2013, at 18:06, [e-mail]<mailto:[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 <[e-mail]<mailto:[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 ,
>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/aqm
>>>
>>>
>> _______________________________________________
>> aqm mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/aqm
>>
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/aqm

=================================================================
David ROS
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/aqm


_______________________________________________
aqm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT