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

Jonathan Morton <> Tue, 03 November 2015 17:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B221A1B2AC2 for <>; Tue, 3 Nov 2015 09:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MtuDWlyFyOba for <>; Tue, 3 Nov 2015 09:00:32 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AC211ACEE8 for <>; Tue, 3 Nov 2015 09:00:29 -0800 (PST)
Received: by lfbn126 with SMTP id n126so25391626lfb.2 for <>; Tue, 03 Nov 2015 09:00:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ySq+M+3+szE1epxbuv2lHNM8Jg6ufZ4/IB9CYijofqY=; b=0HZwdQ1uFybmWnFlyIaZKEsbVpoQ9tip4cEjlVMz2IGVp2bTifeUsvxalZX4FWjFri j63Y0qls3o4JOe94s2c4tc4MJwI9/2WkGdnzR5BXuiYTgoRXn8XmcXpRQFKpKC2r8ry4 /3c3Sjt/ClHZHbwYKTWgp902pSE2hIu3eW6Wk0gS5uMaxy+UX7rNedX7cDLk2sU35UER aNidpV4UvofF74HqgKIzVe5kI8Kyjg7yK0SeyJoaw3Xzpb4ReemvoZ3T58yooJsNHYip WF5zu02oVTBEm0xU/zxeuqC6iPme/Ez4ISwMPCb+DF11G68uCFvE6dgW7T650MxcKL5Z tW1g==
X-Received: by with SMTP id wn6mr11031962lbb.30.1446570027471; Tue, 03 Nov 2015 09:00:27 -0800 (PST)
Received: from ( []) by with ESMTPSA id j9sm4927915lbc.19.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 09:00:26 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Tue, 3 Nov 2015 19:00:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Jeff Weeks <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: Andrew Mcgregor <>, Kathleen Nichols <>, Bob Briscoe <>, Dave Taht <>,, Van Jacobson <>, AQM IETF list <>, Dave Dolson <>
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: Tue, 03 Nov 2015 17:00:33 -0000

> On 3 Nov, 2015, at 18:22, Jeff Weeks <> wrote:
> I believe that means 'count' has to reach some nearly impossibly high value of (100ms/5198ns)^2 == 370,107,128
> I say nearly impossible, because it will take minutes (hours?) to get that high (if my math is correct, it'll take over 17 seconds just to reach 7500).

Note that since count increments on every signal given (every packet dropped, in this case), it will increment faster as time goes on, as long as there is a sufficient packet frequency to support it (as there is in this case).

However, even 17 seconds is obviously too slow to control the buffer.

> In the meantime, the queue *isn't* being effectively managed, as packets with extremely high latencies will be transmitted for far too long.

The problem is that you have an unresponsive flow here.  Codel is designed to give adequate congestion signals to *responsive* flows that require only one signal per RTT.  Unresponsive flows are instead caught by the buffer limit, causing hard packet drops.

This also means that where a responsive flow and an unresponsive flow share the same buffer, Codel doesn’t perform very well; the responsive flow backs off while the unresponsive flow continues to saturate the buffer.  (This is also what happens, intentionally, with uTP and standard TCP in a dumb FIFO.)

This is fixed if you combine Codel with flow isolation (ie. FQ), since then the responsive and unresponsive flows do not share the same buffer.  When the buffer limit is reached, only the longest queue is culled, and this will be the unresponsive flow.

 - Jonathan Morton