From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 1A46921F2AC for ; Wed, 25 Feb 2015 02:54:54 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YQZcA-0005Cs-5G; Wed, 25 Feb 2015 11:54:50 +0100 Received: from mail-ex11.exprod.uio.no ([129.240.120.73]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YQZc9-00049H-Gs; Wed, 25 Feb 2015 11:54:50 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex11.exprod.uio.no (2001:700:100:120::73) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Feb 2015 11:54:48 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Wed, 25 Feb 2015 11:54:48 +0100 From: Michael Welzl To: "toke@toke.dk" Thread-Topic: [Bloat] RED against bufferbloat Thread-Index: AQHQUNv0sUKvBGCaSEK1SlX4B/tmiw== Date: Wed, 25 Feb 2015 10:54:48 +0000 Message-ID: References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> <3F47B274-B0E4-44F2-A434-E3C9F7D5D041@ifi.uio.no> <87twyaffv3.fsf@toke.dk> In-Reply-To: <87twyaffv3.fsf@toke.dk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 6 sum rcpts/h 20 sum msgs/h 7 total rcpts 25976 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6F44BE15121933D4B32DE3B4FA86AB0545586BB2 X-UiO-SPAM-Test: remote_host: 129.240.120.73 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 263 total 599609 max/h 438 blacklist 0 greylist 0 ratelimit 0 Cc: Alex Elsayed , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] RED against bufferbloat 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: Wed, 25 Feb 2015 10:55:23 -0000 > On 25 Feb 2015, at 11:24, toke@toke.dk wrote: >=20 > Michael Welzl writes: >=20 >> but that's FQ (or FQ_CoDel's changed FQ variant), much more than the >> AQM mechanism in use (as we have also seen presented by Toke at the >> last ICCRG meeting). >=20 > Well, actually, that presentation did also include an evaluation of the > AQMs in an asymmetrical scenario. And that shows that while generally > ARED does perform fairly well, it tends to be a bit on the aggressive > side. In the asymmetrical case this results in too many drops on the > slow side of the asymmetrical link (typically upload), hurting throughput > in the other direction due to lost ACKs. >=20 > There's also some other issues in there, with PIE and CoDel in > particular, most notably their reactions when conditions change: it can > take tens of seconds for the algorithms to get queueing latency under > control in this case. >=20 > Slides for the IETF presentation available here: > http://www.ietf.org/proceedings/91/slides/slides-91-iccrg-4.pdf >=20 > There's also a longer version of the talk (from the Stanford Netseminar) > available on Youtube: https://www.youtube.com/watch?v=3DkePhqfKA3SM >=20 >> But this discussion is about AQM mechanisms, not (changed)FQ. >=20 > While the academic side of me enjoys studying AQMs (and I'm still far > from anything resembling a thorough understanding of them), the > practical "I just want my network to work" side of me has become > increasingly convinced (in part by doing the experiments in the above > mentioned talk) that FQ is more important than AQM in many scenarios. +1, certainly it has a big influence. This has been well known for many yea= rs though, and documented broadly, perhaps most notably by Jim Roberts. > As > such, I think that excluding FQ from the conversation is mostly of, well, > academic interest ;) Here I disagree, for two reasons: 1) The AQM part kicks in per flow. So, whenever you have one flow, the beha= vior of FQ_AQM and AQM will be the same. Investigating what an AQM mechanis= m does to one flow is then worthwhile. 2) Not everyone will always want FQ everywhere. There are potential disadva= ntanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow problem). What= 's necessary is to quantify them - to see how the effect of FQ (or FQ_CoDel= 's changed FQ) plays out, and you've done a great start there in my opinion= . Cheers, Michael