From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 071EB21F913 for ; Tue, 28 Jul 2015 10:11:42 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZK8Pg-0005iq-Tc; Tue, 28 Jul 2015 19:11:36 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZK8Pg-0006dj-DI; Tue, 28 Jul 2015 19:11:36 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Tue, 28 Jul 2015 19:11:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <052B5B2C-E784-4B48-8447-6EDCCB987CB4@ifi.uio.no> 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> To: Sebastian Moeller X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 10 sum msgs/h 2 total rcpts 31599 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6A7CE2CFF0515B80C15E22582A281588FF5A25DB X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1341 max/h 13 blacklist 0 greylist 0 ratelimit 0 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 17:12:11 -0000 > On 28. jul. 2015, at 18.22, Sebastian Moeller wrote: >=20 > Hi Simon, >=20 > On Jul 28, 2015, at 16:31 , Simon Barber wrote: >=20 >> 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. >=20 > According to theory you should adapt interval if at all and the = set target between 5-10% of that interval. See = https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=3D1 = sections 4.3 and 4.4. Now that could all be off.The upshot is increasing = target as a response for long RTTs will sacrifice latency again for = bandwidth, pretty much that the avoidance of is codel=92s claim to fame = ;) The only way to fix this trade-off is to change TCP, to back off less = *only when the queue was small*. We tried what we think is the simplest = possible way to do this: only a sender-side change, using ECN as an = indication that there is an AQM mechanism on the path, not a long queue = (and hence backing off by less is ok). It works pretty well. See: http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf (a few of the graphs are simulations, but many were from real-life tests = - appendix B says which). ...and the draft, which was presented to TCPM at the Prague IETF last = week: https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn Cheers, Michael