From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2B09021F742 for ; Tue, 28 Jul 2015 07:55:24 -0700 (PDT) Received: by wibud3 with SMTP id ud3so163422175wib.0 for ; Tue, 28 Jul 2015 07:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=9LdtEnkaiVdmVsGXZ/nVfuHImZr33ikWiHImrFFWfB4=; b=m+yzxemaFobDry4Dn1VsYIiLjacbcArYSnK5HmEdhUJdse1WUI9JVvmacxJrE1vuEZ dGrF9bkFkesWpn5yYuZEn0vRpc2jnKBY0Jloqa5vegIMwIupFr2lrr6cJwTsy5LkoJZ/ CPLv7q3RWnyGWU+5VyNGjK9j8aLEK10XuqXFA07fApZJO63AsO+WK05gRh7nZIoeQHhI wcEAujVdaWOljXg8jYTyalOC9bHFcOHjGKK35fenIPhAD6vlO3tBaR4owfBXmac9fXaP yrYzNUCpDhgvAobbsZ7Lo5bg57BgzZA/k/yaHKkeBg7Jfw9QPgnidj8dDg5eKsdt3LGt maFA== X-Received: by 10.180.206.14 with SMTP id lk14mr7634374wic.50.1438095322209; Tue, 28 Jul 2015 07:55:22 -0700 (PDT) Received: from [172.16.39.41] ([172.16.39.41]) by smtp.gmail.com with ESMTPSA id lz10sm33625996wjb.48.2015.07.28.07.55.20 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 07:55:21 -0700 (PDT) Message-ID: <1438095319.20182.56.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Simon Barber Date: Tue, 28 Jul 2015 16:55:19 +0200 In-Reply-To: <1438094970.20182.53.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> <14ed5136170.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1438094970.20182.53.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: bloat , Juliusz Chroboczek 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:55:53 -0000 On Tue, 2015-07-28 at 16:49 +0200, Eric Dumazet wrote: > On Tue, 2015-07-28 at 07:31 -0700, Simon Barber wrote: > > 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. > > As I said, I've never seen what you describe. > > 100ms value is not a go/nogo threshold. It is a hint, based on real > world values. We are speaking of 100 ms sojourn time in the CoDel queue, typo : 5 ms ( codel target )