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

Dave Taht <> Mon, 15 July 2013 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F1C611E8233 for <>; Mon, 15 Jul 2013 12:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.157
X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.216, 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 ifWSGyZUl3x3 for <>; Mon, 15 Jul 2013 12:51:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::234]) by (Postfix) with ESMTP id 7217111E81F2 for <>; Mon, 15 Jul 2013 12:51:04 -0700 (PDT)
Received: by with SMTP id f4so26431678iea.39 for <>; Mon, 15 Jul 2013 12:51:03 -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=KSrJa0nsIPxaREemtSq+BcT//BWgcjMmKkyBBQCHImA=; b=qW7hTxbtNhFfJl6NMQP3fGMLVGK9qtxkuNfvA1F2qmsX5qoRGqNI2VCkHAbq/H0UKc F37v0+OukXfNzsKp6vdBAFyucDVr7AjwJEI3HtUGbWYkjPcINr6od8lOZWHXH5WMv5Q+ GBiwZcguXikixl3HpyK3W0pcy+7kxmZHfWtNNgzbCaZk1L7mVkHMvV5/SnhIEuGzb2in IlpARQqxtH1edoy8crAwlS2BW52WR4LVldw6TQ6awQwBoSEp91FwKGrAy/D81ynz+NsO +MfEIu/fjrFPeld2h+VsiyO0RwIq3UVJ56vV4V1W2sALvaK8fQhAXOAmwVajy5YJjusx +RWg==
MIME-Version: 1.0
X-Received: by with SMTP id i8mr8032151igf.42.1373917862927; Mon, 15 Jul 2013 12:51:02 -0700 (PDT)
Received: by with HTTP; Mon, 15 Jul 2013 12:51:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 15 Jul 2013 15:51:02 -0400
Message-ID: <>
From: Dave Taht <>
To: Bob Briscoe <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Wesley Eddy <>, "Fred Baker (fred)" <>, "" <>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2
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: Mon, 15 Jul 2013 19:51:06 -0000

On Fri, Jul 12, 2013 at 2:27 PM, Bob Briscoe <> wrote:
> Dave & Fred, (two birds in one posting)
> At 02:06 12/07/2013, Fred Baker (fred) wrote:
>> On Jul 11, 2013, at 5:15 PM, Bob Briscoe <>
>>  wrote:
>> > As an output of this proposed AQM WG, I would like to see advice that
>> > says what auto-tuning means, not just the empty word "auto-tuning", ie. not
>> > just using time as the unit of queuing, but also an AQM should not take a
>> > hard-coded time to respond irrespective of how much the queuing delay has
>> > grown.
>> I'm all for that. Maybe we can get the WG, if there is one, to add a
>> document describing that, or add text to the AQM recommendation. Suggest
>> text/approach?
>> I'd suggest perhaps discussing this in Berlin.
> Fred, Altho I said it originally, I'm not sure how much we can or should
> write down about the basic art of controlling stuff. A standards body is
> good for people who want to check that product X has features a,b,&c. It's
> not necessarily the right place to write documents for Mr Brown in
> procurement to check that the subtleties of algorithm Y comply with articles
> d,e&f of control theory.
>> At 02:49 12/07/2013, Dave Taht wrote
>> [Bob Brisoe has copied this response across from another thread, 'cos it
>> was written in response to this point about auto-tuning]:
>> 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.
> Dave, Setting aside TCP-friendly for a minute, depending on the slope would
> be research yes. But let's get the basics first. The only thing that depends
> on queue delay (in the CoDel drop code I looked at) was when drop started
> and when it stopped. In between, the pattern of gaps between the drops was
> pre-ordained and hard coded.

It's subtle, but you'll notice the gap between restarting at a given drop rate
is dynamic. This is the bit that searches for an ideal drop rate.

This was heavily discussed towards the tail end of my stanford talk.

> If the queue was growing ridiculously long
> (e.g. due to a flash crowd), CoDel still laboriously decreased the gap
> between each drop in its preordained pattern.

"The queue". When you are using fair queuing "the queues", the
"problematic queue" grows longer and is delayed more as it is
interleaved with the other queues, thus the apparent drop rate on that
flow increases not as a proportion of packets in the flow but as a
proportion of the overall delays it is experiencing.

> I hope that's been improved in more recent CoDel code.

Codel doesn't stand alone. See last paragraph here:
We've not said anything different...

There are patches for various things floating around. In particular I
have a version that is "tighter" but I fear it will perform badly at
1sec+ rtts. I'd like to consider ewma for managing the slope rather
than the current strategy but am not there yet. I've been building up
my lab to be able to look closely at longer RTT and videoconferencing
issues in what we have so far.

patches have been posted to the codel list. We are discussing now the
nature of a more ideal replacement for the existing default queue
discipline in linux, which has three fq_codel tiers in it (priority,
best effort, and background) over there at the moment.

Yep, further research is needed.

> This is the basic
> structure of an algo - I'd hardly even call it auto-tuning, it's about
> ensuring the intensity of the dropping within the algorithm depends on the
> effect it is trying to control.

The goal of a queue is to absorb bursts. If it's possible within the
target to drain that burst entirely, then dropping at a high rate is a
bad idea. Codel will gently and eventually get there. So I agree with
the statement it's about ensuring that the intensity of the dropping
within the algorithm depending on the effect you are trying to control
- in this case, signalling the other side of the flow to slow down
with a drop or mark.

... but I'm pretty sure that's not what you meant.

> Similarly, the delay before dropping starts is completely independent of
> whether the queue  has been slightly above 'target' for 'interval' or queue
> delay has headed off into the stratosphere during 'interval'. IOW,

As I described, yes, for certain values of stratosphere, a more robust dropping
strategy should be tried. That said, the goal is to wait long enough for the
signal to reach the other side...

> I would
> challenge that the very use of the min() function in CoDel is counter to
> auto-tuning (auto-controlling) principles.
> ________
> Finally, I can't resist having a snipe at that TCP-friendly sentence. If you
> can justify it I would be most impressed. It looked like BS when I saw it in
> VJ/Nichols paper, and it still looks like BS. That sqrt is relative to the
> count of drops, which is nothing to do with the sqrt in the TCP formula.
> It's as likely to be related to mass-energy equivalence, because that's got
> a square term in it too.

Heh. I'll leave it to kathie and van to defend their usage. I think
would have been more accurate, but that's not a defined term. Perhaps it
should be?

> [Anyway, only Reno congestion window is proportional to 1/p^0.5. The cwnd of
> Cubic & Compound are proportional to 1/p^0.75 and 1/p^0.8 respectively.]
> Bob
> ________________________________________________________________
> Bob Briscoe,                                                  BT

Dave Täht

Fixing bufferbloat with cerowrt: