Re: [aqm] CoDel's control law that determines drop frequency

Jeff Weeks <> Wed, 30 September 2015 15:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0157D1B5EC5 for <>; Wed, 30 Sep 2015 08:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RQzlwxFrGMk1 for <>; Wed, 30 Sep 2015 08:57:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D9F51B5ED9 for <>; Wed, 30 Sep 2015 08:57:30 -0700 (PDT)
Received: from ([fe80::ac6b:cc1e:f2ff:93aa]) by ([::1]) with mapi id 14.03.0195.001; Wed, 30 Sep 2015 11:57:31 -0400
From: Jeff Weeks <>
To: Polina Goltsman <>, Bob Briscoe <>
Thread-Topic: [aqm] CoDel's control law that determines drop frequency
Thread-Index: AQHQoVgaU5atdTCgY0uHb6M/BmhvL55NDzAAgAgi1ACAAIiFgIAABl+AgAA/OICAAC3fAP//vZ/R
Date: Wed, 30 Sep 2015 15:57:24 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>,<>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: AQM IETF list <>
Subject: Re: [aqm] CoDel's control law that determines drop frequency
X-Mailman-Version: 2.1.15
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: Wed, 30 Sep 2015 15:57:36 -0000

I don't believe codel does start fresh; there are various back-off mechanisms that have been employed in the management of 'count' such that if the drop state is entered soon after it previously left the drop state, it'll re-enter at close to the same interval.

I believe these mechanisms were put in place to combat the sluggishness, but that doesn't help the initial drop state.

In practice, I've found that incrementing 'count' more rapidly can help to a point... but incrementing it too much appears to result in the sqrt approximation diverging from the ideal value, and then things start to fall apart.


From: aqm [] on behalf of Polina Goltsman []
Sent: Wednesday, September 30, 2015 11:43 AM
To: Bob Briscoe
Cc: AQM IETF list
Subject: Re: [aqm] CoDel's control law that determines drop frequency


May I ask how curvy red is supposed to perform in those situations?

If I understand Codel's law correctly, Codel "starts fresh" every time
it enters dropping state, so when the load increases it will take more
time for the control law to reach the correct "count" value for the
queue to drop. Thus with higher load latency is increased.

Now, if I understood your curvey red report correctly, you argued that
AQM should increase latency when load increases since otherwise it will
cause too much loss. Which makes Codel's behavior at least justified ...

BTW, I haven't seen any place in the original specification that
suggested that fixed target delay is the intended design goal.

Does this make any sense?


On 09/30/2015 02:59 PM, Bob Briscoe wrote:
> Polina,
> I think this was it:
> <>
> I have a set of charts from Rong with many more tests showing CoDel's
> sluggish responsiveness, but I believe the above was the published
> summary.
> Bob
> On 30/09/15 10:13, Polina Goltsman wrote:
>> Dear Bob,
>> On 09/30/2015 10:50 AM, Bob Briscoe wrote:
>>> Early on, Rong Pan showed that it takes CoDel ages to bring high
>>> load under control. I think this linear increase is the reason.
>> Is there a link to this ?
>> Polina
>> _______________________________________________
>> aqm mailing list

aqm mailing list