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

Bob Briscoe <> Fri, 12 July 2013 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7729221F9E7D for <>; Fri, 12 Jul 2013 11:27:16 -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 jpIjlBVCSg44 for <>; Fri, 12 Jul 2013 11:27:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FB0921F93F3 for <>; Fri, 12 Jul 2013 11:27:09 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 12 Jul 2013 19:27:00 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 12 Jul 2013 19:27:03 +0100
Received: from ( by ( with Microsoft SMTP Server id 14.2.342.3; Fri, 12 Jul 2013 19:27:02 +0100
Received: from ([]) by (8.13.5/8.12.8) with ESMTP id r6CIR019029342; Fri, 12 Jul 2013 19:27:00 +0100
Message-ID: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Fri, 12 Jul 2013 19:27:00 +0100
To: Dave Taht <>, "Fred Baker (fred)" <>
From: Bob Briscoe <>
In-Reply-To: < om>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on
Cc: Wesley Eddy <>, "" <>
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: Fri, 12 Jul 2013 18:27:16 -0000

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

I hope that's been improved in more recent CoDel code. 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.

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

[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 


Bob Briscoe,                                                  BT