Re: [aqm] updated draft charter

Dave Taht <> Fri, 12 July 2013 02:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A30211E80A5 for <>; Thu, 11 Jul 2013 19:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id woHWgEhBwSry for <>; Thu, 11 Jul 2013 19:12:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22d]) by (Postfix) with ESMTP id 65FE721F9CEC for <>; Thu, 11 Jul 2013 19:12:24 -0700 (PDT)
Received: by with SMTP id k13so19428392iea.18 for <>; Thu, 11 Jul 2013 19:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6bDLbgcsU5dEcWaVhZrg9YwbR31grncNhpeWfhkNUzE=; b=pJOosM5Ya1L7OmOPJNMFr7B90EKXbuzl/Izwf6vFNqF8rAqXVCWA7OZwWB1CtvfM8V hqHwIYrrcjshiY7HWO+s5wIzz1suH2NTC92Hp+h6xY9/Q3qiA+Qb0FtIj8yIwVsSWWvv OISBlYXl/nJolEJmlgtfac8ml0X0wO6nAhg8dCiFs1y1M8U/1XYOQJetdzHSqZ16D+LN 6YeITsYRwu9clSRSKKpEi/iqqxkGl4UubinbBqo45bY7JYaTyDUnOCV5w2XK1/Kmy+qJ Izly4poNqZlhI1J8AMik/2uuaEtDryZENhu7VlNJGRY3Nl8IqFoTHTnmfM2ihzPYWXnc wwwQ==
MIME-Version: 1.0
X-Received: by with SMTP id g2mr12239759ict.49.1373595143914; Thu, 11 Jul 2013 19:12:23 -0700 (PDT)
Received: by with HTTP; Thu, 11 Jul 2013 19:12:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 11 Jul 2013 19:12:23 -0700
Message-ID: <>
From: Dave Taht <>
To: Bob Briscoe <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Wesley Eddy <>, Gorry Fairhurst <>, "" <>, Jim Gettys <>, David Ros <>
Subject: Re: [aqm] updated draft charter
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2013 02:12:27 -0000

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


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


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

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 <>
> wrote:
> On 11 juil. 2013, at 18:06, 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 <>
>>> 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
>>> ,
>>> 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
>>> _______________________________________________
>>> aqm mailing list
>> _______________________________________________
>> aqm mailing list
> =================================================================
> David ROS
> I love deadlines. I like the whooshing sound they make as they fly by. --
> Douglas Adams
> _______________________________________________
> aqm mailing list
> _______________________________________________
> aqm mailing list
> ________________________________________________________________
> Bob Briscoe,                                                  BT
> _______________________________________________
> aqm mailing list

Dave Täht

Fixing bufferbloat with cerowrt: