From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 106FE21F613 for ; Tue, 28 Jul 2015 07:49:34 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so182872193wic.0 for ; Tue, 28 Jul 2015 07:49:33 -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=ADSK+q20PZLEfJnmpxHf5/0MnMkPyBWmNMrcmVt/WkY=; b=j7jdtZ+Mn6VJXiMwwBWdKzvKNsSTZXgZ1Qvx0za36ALMO2cQZ+gEmclEX4JkCU55a8 9FaM7Q591Jkys4quZkihFX+fTX9ujm+4dhX6Fa6ARnB+NjckCahuT+cyOApxtyLr7xAz 8cGeW1SaDA0ialKINC4H6J/CoVYCIOHpYEyAJ5+4LW/7TMoskRQdtPQPo2Ma4+ntaGjG +EVydZEWUlRtHiw2d9aI4eV/GGKJdse4/Vhddod7kH8NaEbWjAd096g5gj++Sr0Z+y+y 5pFO+LvESbxsjwWS4S3KeEtFoDGovwQqbb04PsFKai41Dj55UPLrS+9on95UGnzogFcU 5Kxw== X-Received: by 10.180.210.234 with SMTP id mx10mr7679336wic.42.1438094973092; Tue, 28 Jul 2015 07:49:33 -0700 (PDT) Received: from [172.16.39.41] ([172.16.39.41]) by smtp.gmail.com with ESMTPSA id pg9sm20020614wjb.40.2015.07.28.07.49.31 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 07:49:32 -0700 (PDT) Message-ID: <1438094970.20182.53.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Simon Barber Date: Tue, 28 Jul 2015 16:49:30 +0200 In-Reply-To: <14ed5136170.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> 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> 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:50:03 -0000 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, not sojourn time in the Internet ! You can still have flows with 500 ms or even 10 sec rtt and codel just works fine. Are you sure you understood how this was working ?