Re: [aqm] updated draft charter

[Dave Taht <[e-mail]>]

On Thu, Jul 11, 2013 at 6:56 PM, Bob Briscoe <[e-mail]> wrote:
>
> 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.

Heh. Like jim said, this is a bikeshed, and I'd like to stay out of it, too.

I note in trying to coin a new acronym, like "SQM", I'd said "smarter
queue management", not smart, (or at least I think I did) - and I
think AQM should be defined as queue length management to minimize
future confusion.

so QMAN works for me. There was another proposal earlier today(?) that
had another attempt I thought would be confusing out of context.

Feel free to bring in madison avenue.

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

YES, PLEASE.

> 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?

I like it.

> It already caused confusion when the problem got called bufferbloat, so

I concur jim should have called it queue bloat, but it wasn't as
catchy as bufferbloat.

> 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, ..." ->

s/buffers/queues for sure.

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

A proactive queue management algorithm SHOULD have support for tachyon
based pre-emptive feedback.

> 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

I really remain dubious about usage of ECN on the world wide internet.
If deployed widely, attacks will widely use it.

>   (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.

I'm a little vague on your intent here.

> 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.

I'm not sure that this scope needs to be so limited here.

> 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.

yep.

>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.

+1.

> 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.

Hmm.

> 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.

Cite? Not that I disagree, I've been ramping up at looking hard at
webrtc behavior of late, just that most of my foci are focused on web,
voip, and gaming traffic on the edge to date..

>
>
> Bob
>
>
> At 18:35 11/07/2013, Jim Gettys wrote:
>
>
>
> On Thu, Jul 11, 2013 at 12:21 PM, David Ros < [e-mail]>
> wrote:
>
> On 11 juil. 2013, at 18:06, [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]>
>>> 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]
>>>> https://www.ietf.org/mailman/listinfo/aqm
>>>>
>>>>
>>> _______________________________________________
>>> aqm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/aqm
>>>
>>
>>
>> _______________________________________________
>> aqm mailing list
>> [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]
> https://www.ietf.org/mailman/listinfo/aqm
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html