From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <simon@superduper.net>
Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by huchra.bufferbloat.net (Postfix) with ESMTPS id EF0EF21F82B
	for <bloat@lists.bufferbloat.net>; Tue, 28 Jul 2015 07:31:46 -0700 (PDT)
Received: from block9.public.monkeybrains.net ([162.217.75.161]
	helo=[192.168.128.5])
	by masada.superduper.net with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:128)
	(Exim 4.80) (envelope-from <simon@superduper.net>)
	id 1ZK5ut-0002Sx-B8; Tue, 28 Jul 2015 15:31:40 +0100
From: Simon Barber <simon@superduper.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 28 Jul 2015 07:31:36 -0700
Message-ID: <14ed5136170.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net>
In-Reply-To: <1438093312.20182.49.camel@edumazet-glaptop2.roam.corp.google.com>
References: <87a8ugqvid.wl-jch@pps.univ-paris-diderot.fr>
	<87r3nstnj5.fsf@toke.dk>
	<876154qtkt.wl-jch@pps.univ-paris-diderot.fr>
	<87mvygtm1a.fsf@toke.dk>
	<14ed5013130.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net>
	<1438093312.20182.49.camel@edumazet-glaptop2.roam.corp.google.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29
	(build: 21070094)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.9 (--)
Cc: bloat <bloat@lists.bufferbloat.net>,
	Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Subject: Re: [Bloat] AQM and PPP on Linux
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2015 14:32:16 -0000

The issue is that Codel tries to keep the delay low, and will start 
dropping when sojourn time grows above 5ms for 100ms. For longer RTT links 
more delay is necessary to avoid underutilizing the link. This is due to 
the multiplicative decrease - it's worst with Reno, where the halving of 
cWind means that you need to have a full BDP of data in the buffer to avoid 
the link going idle when cWind is halved. With longer RTTs this means more 
delay than Codel allows is required to avoid a throughput hit. The worst 
case happens when a single flow is controlled, but that can be a common 
situation. My proposal is to sense and have the target value in Codel 
automatically adjust when this worst case scenario happens - which would 
mitigate most of the downside.

Simon

Sent with AquaMail for Android
http://www.aqua-mail.com


On July 28, 2015 7:21:56 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:

> On Tue, 2015-07-28 at 07:11 -0700, Simon Barber wrote:
> > The main danger is the negative effects on performance of using Codel. You
> > may experience low throughput on high RTT links.
>
> Really ? I've never seen this, unless you mess with codel qdisc
> attributes maybe.
>
> (Some guys seem to not really understand whole concept of a queue, and
> set very low values for 'limit' attribute for example)
>
>
>
>