Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1

Bob Briscoe <> Fri, 12 July 2013 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44DF811E811E for <>; Fri, 12 Jul 2013 10:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EDpefhAWAiSs for <>; Fri, 12 Jul 2013 10:28:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A625C11E80FE for <>; Fri, 12 Jul 2013 10:28:57 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 12 Jul 2013 18:28:53 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 12 Jul 2013 18:28:55 +0100
Received: from ( by ( with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 18:28:44 +0100
Received: from ([]) by (8.13.5/8.12.8) with ESMTP id r6CHSgvq029224; Fri, 12 Jul 2013 18:28:42 +0100
Message-ID: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Fri, 12 Jul 2013 18:28:42 +0100
To: Dave Taht <>
From: Bob Briscoe <>
In-Reply-To: <CAA93jw7SkQQ=0X57wkbPY3Hiwgx_8ySs7ocjA6emcgNA6Uy+6w@mail.g>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on
Cc: "Fred Baker (fred)" <>, "" <>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1
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 17:29:04 -0000


At 02:49 12/07/2013, Dave Taht wrote:
>Since this is a rollup email, this is a rollup in response.
>On Thu, Jul 11, 2013 at 6:28 PM, Bob Briscoe <> wrote:
> > #3 Active Queue Management algorithms deployed SHOULD NOT require
> > operational tuning
> > Agree
>Agree, but I'd capitalize the REQUIRE bit, in that everything in this
>world can benefit from a little tuning here and there...
>as one major example, which is in conflict with your byte-congest
>draft, using a smaller quantum than the default helps on asymmetric
>links in fq_codel (and pie uses a probalistic drop mechanism also
>based on packet size). The smaller quantum thing has been well proven
>to work on multiple shapers/schedulers going back to wondershaper.

Pls elucidate or cite. INsufficient detail to understand. I thought I 
knew what a quantum was in a scheduler, but in these sentences I'm 
wondering whether you're talking about something else.

> > (and see same note to Dave Taht wherein I said time as a queue threshold is
> > not sufficient to get a tick in the auto-tuning box - responsiveness of the
> > algo also needs to depend on how bad the queue is getting)
>The sqrt->linear drop approach is tcp friendly and currently works
>well on a wide range of RTTs. It certainly seems like a worthwhile
>research effort to measure and act on the slope of the curve, both up
>and down, in a codel variant, in order to get better results faster.

I've transferred this response over to the separate thread 
specifically about this (rec #2), as I think my points have been missed.

>And the results of the hybrid fq_codel are interesting in that
>perspective as flows do affect one another, particularly in steady
>state. Right now a drop in one queue can be followed quickly by a drop
>in another queue (at steady state), and that could be randomized
>somewhat or fed into a feedback mechanism also.
>I do show this behavior on the rrul vs web traffic benchmark on the
>slidesets I've been showing. Note that steady state is something of a
>rarity outside of benchmarks.
>another thought is to periodically perturb the flow list. sigh. more research.


Bob Briscoe,                                                  BT