From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <swmike@swm.pp.se>
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by huchra.bufferbloat.net (Postfix) with ESMTPS id 430DB21F248
	for <cerowrt-devel@lists.bufferbloat.net>;
	Mon, 26 May 2014 07:11:24 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501)
	id 19D309C; Mon, 26 May 2014 16:11:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail;
	t=1401113481; bh=BhekkyLMF0WBu3RSEi6HG3ao8TNNH9eQNJBMF1WUE70=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Bwq3sRB7c8rtKFzdnqzcNM8fwt08lSswhqQ8nwQW+yygwcqIMzVhueif6nbAAPIMT
	SVZdWYOyi9QwXsVETNti32hxx48k/WtIxSscDE0lCdNDoDGiIaDqpTUK2u+812cjrU
	FO/3siHG3unrwagetVInt8CXUYWINdjvwsInq65w=
Received: from localhost (localhost [127.0.0.1])
	by uplift.swm.pp.se (Postfix) with ESMTP id 0CF579A;
	Mon, 26 May 2014 16:11:21 +0200 (CEST)
Date: Mon, 26 May 2014 16:11:21 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: dpreed@reed.com
In-Reply-To: <1401112879.32226492@apps.rackspace.com>
Message-ID: <alpine.DEB.2.02.1405261604541.29282@uplift.swm.pp.se>
References: <CABsdH_FMqARQQ7oT2gGE6PEZWk1E6b6CDGdBH958nL2=FmFv-A@mail.gmail.com>
	<alpine.DEB.2.02.1405251740360.29282@uplift.swm.pp.se>
	<1401048053.664331760@apps.rackspace.com>
	<alpine.DEB.2.02.1405260213590.29282@uplift.swm.pp.se> 
	<1401079740.21369945@apps.rackspace.com>
	<alpine.DEB.2.02.1405261454070.29282@uplift.swm.pp.se>
	<1401112879.32226492@apps.rackspace.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Ubiquiti QOS
X-BeenThere: cerowrt-devel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Development issues regarding the cerowrt test router project
	<cerowrt-devel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cerowrt-devel>
List-Post: <mailto:cerowrt-devel@lists.bufferbloat.net>
List-Help: <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 14:11:24 -0000

On Mon, 26 May 2014, dpreed@reed.com wrote:

> I would look to queue minimization rather than "queue management" (which 
> implied queues are often long) as a goal, and think harder about the 
> end-to-end problem of minimizing total end-to-end queueing delay while 
> maximizing throughput.

As far as I can tell, this is exactly what CODEL and PIE tries to do. They 
try to find a decent tradeoff between having queues to make sure the pipe 
is filled, and not making these queues big enough to seriously affect 
interactive performance.

The latter part looks like what LEDBAT does?
<http://tools.ietf.org/html/rfc6817>

Or are you thinking about something else?