From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <toke@toke.dk>
Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147])
	(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 12C6321F352;
	Sun, 14 Jun 2015 10:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at mail2.tohojo.dk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310;
	t=1434302844; bh=JvDj9bIrwUuB+cPojFikRiIyfVikCCt5UFp6M2H0TH4=;
	h=From:To:Cc:Subject:References:Date:In-Reply-To;
	b=MH3kg9MefWwmq165BI4j75xceXDOdMknptDl4AyO8V68WcwInAsNkIxOAy63N5be6
	SaNYru/vyeEtLHQZZPwiKrhdrW56wPa6g66P76/c67HuZpd/DFI1xZvRl2rBArceW8
	KKOjEYdfCHAWTaDqEJ8jyEEsRy9g4T0Ft7Ofs8gM=
Sender: toke@toke.dk
Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000)
	id C5FA03DCE1; Sun, 14 Jun 2015 19:27:23 +0200 (CEST)
From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
To: Jonathan Morton <chromatix99@gmail.com>
References: <CAA93jw6R2o+M68rQq07Qm8xBkr1bSvkVriysGdACxRLvmjhsmg@mail.gmail.com>
	<CANmMgnGY1qkm9PnfKmHMoB6OYzhD5Cr9WDPPjmG1Tenw=+4E-g@mail.gmail.com>
	<CAA93jw4XzLhudtQ=1+L6csv66d_sNgF6VLg8iqMZmPJHyc5ryw@mail.gmail.com>
	<0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com>
Date: Sun, 14 Jun 2015 19:27:23 +0200
In-Reply-To: <0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com> (Jonathan
	Morton's message of "Sun, 14 Jun 2015 20:19:15 +0300")
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87a8w2qjyc.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: cake@lists.bufferbloat.net,
	Alan Jenkins <alan.christopher.jenkins@gmail.com>,
	"cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Cake] openwrt build available with latest
	cake	and fq_pie
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: Sun, 14 Jun 2015 17:28:01 -0000

Jonathan Morton <chromatix99@gmail.com> writes:

> *That* is why I put in count/2. A multiplicative decrease allows count
> to stabilise at some value which adequately controls the queue, rather
> than continuously increasing past it. For the typical cake case where
> there is one flow per Codel instance and the RTT is of Internet scale,
> this should work at least as well as an additive decrease; in
> particular, the behaviour is identical where count ended at 2, 3 or 4
> (it can=E2=80=99t end at 1).

Is there any reason why the decrease couldn't be some sort of decay?
I.e. a function of how long ago the drop state was exited?

-Toke