From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eric.dumazet@gmail.com>
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(Client did not present a certificate)
	by huchra.bufferbloat.net (Postfix) with ESMTPS id 2334621F0B6
	for <codel@lists.bufferbloat.net>; Tue,  4 Sep 2012 13:10:59 -0700 (PDT)
Received: by bkty15 with SMTP id y15so4267923bkt.16
	for <codel@lists.bufferbloat.net>; Tue, 04 Sep 2012 13:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=XWTCQdc6QD5e6fF7y7XLuN2G4fugQvZA49VoH6TkVW4=;
	b=leViZ6NpN0ftzfcoa9ZU4/rWNQVydudU07cJSlrRCmy2VicvIRAvxXuYS+O/GJ/e2c
	SByBABWABn+2rgv98WDUCAdX+UWfEDGEYgRFd4N9x4y2ciIroyFRuTKFmlad6R8D/KFO
	gSmzhx3jTrm4XYRLPXxNIwa8FcH8QCw6srn3BU0T+qOP83Q36sHRmTBMfzJCuadkgPUM
	xX/FBgIZeTrLUFzA5F7ovu5TCwVa4ybk9iCinCrFRwOSNaRJf0HY6IaHqpq+jIFzaVIo
	0z3HI2wO/FkmeaclwbbdKgRcCUzF82GCEHEg/DY4nNXmZ1g0uZs1J1HCOlWIDOYWNRSr
	PrgQ==
Received: by 10.204.152.75 with SMTP id f11mr8846847bkw.83.1346789458034;
	Tue, 04 Sep 2012 13:10:58 -0700 (PDT)
Received: from [192.168.142.158] ([74.125.121.33])
	by mx.google.com with ESMTPS id c18sm11347647bkv.8.2012.09.04.13.10.55
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 13:10:56 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
In-Reply-To: <CAA93jw42vJig0ym2a-gQ8y5NboYWVcHWZVboFR_j+Gd4fOQJiQ@mail.gmail.com>
References: <CAA93jw6qKWv33zqjAGqjEA3QajoyThc6gicLorx1P4=ZaMoY=A@mail.gmail.com>
	<1346785347.13121.77.camel@edumazet-glaptop>
	<CAA93jw42vJig0ym2a-gQ8y5NboYWVcHWZVboFR_j+Gd4fOQJiQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 04 Sep 2012 22:10:53 +0200
Message-ID: <1346789453.13121.92.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] fq_codel: revenge of the standing queue
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 04 Sep 2012 20:11:00 -0000

On Tue, 2012-09-04 at 12:51 -0700, Dave Taht wrote:

> - and we exit dropping state when that queue empties, when globally,
> across all the fq_codel queues, we still need to be dropping in order
> to get to the target.
> 

Not at all. You are trying to view fq_codel as a global controller,
which it is not.

> And that first_above time for that cvars for that fq_codel queue is
> reset to 0 for that fq_codel queue when it empties, forcing a recalc
> of the right interval (sojourn) for re-entering dropping state, with a
> "hands off" interval...
> 
> It's seems reasonably ok for a fq_codel queue to go empty for a while
> but not have to go through a sojourn again to start dropping. It makes
> sense to always deliver one packet after going empty...
> 
> these thoughts are half formed, and I did my damnedest to describe the
> behavior I was seeing.

Then you describe a codel bug.

But its not a bug. If a queue is empty, we set dropping to false, so
that next time we dequeue a packet, we can check how long queue was
empty.

Once again, this has nothing to do with fq_codel.