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 0AFB221F2AB for ; Wed, 25 Feb 2015 02:37:52 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YQZLi-0005ZY-7f; Wed, 25 Feb 2015 11:37:50 +0100 Received: from mail-ex04.exprod.uio.no ([129.240.52.7]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YQZLh-0006Dm-L6; Wed, 25 Feb 2015 11:37:50 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex04.exprod.uio.no (2001:700:100:52::7) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Feb 2015 11:37:49 +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:37:48 +0100 From: Michael Welzl To: Alex Elsayed Thread-Topic: [Bloat] RED against bufferbloat Thread-Index: AQHQUNv0sUKvBGCaSEK1SlX4B/tmiw== Date: Wed, 25 Feb 2015 10:37:48 +0000 Message-ID: <41C6ED93-286F-4008-9CBF-38A8F0CACF67@ifi.uio.no> References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> In-Reply-To: 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: <2645595943B5E04BA97ADF786FD0B6D6@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 25964 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: C897B7B016F20C33BA31FF5D5F32A8A5A3E86719 X-UiO-SPAM-Test: remote_host: 129.240.52.7 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 172 total 599122 max/h 447 blacklist 0 greylist 0 ratelimit 0 Cc: "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:38:21 -0000 > On 25 Feb 2015, at 10:31, Alex Elsayed wrote: >=20 > Michael Welzl wrote: >=20 >> Two points, >>=20 >> below... >>=20 >> On 25 Feb 2015, at 09:42, Alex Elsayed >> Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> >> wrote: > >> Why exactly did you think we should have looked at asymmetric paths? To >> study what? ( I'm not debating that asymmetric paths play out different = in >> behavior. I'm just saying that one needs to be clear about what exactly = is >> being investigated, and why.) >=20 > It was less a criticism of your work itself, and more pointing out that B= ob=20 > Briscoe was applying research on symmetric paths to asymmetric paths with= out=20 > questioning the applicability of its conclusions. No worries about criticism, I don't mind that - I asked because I'd only us= e an asymmetric link if I understand why, and what I'm investigating. To un= derstand the basic behaviour of an AQM mechanism, asymmetry doesn't seem ne= cessary to me. >> and the >> latter is a one-line mention under "future work": >>=20 >> "More realistic traffic types (here, only bulk TCP traffic) including >> bursty traffic" >>=20 >> Considering those, that slide deck convinces me of very, very little >> indeed. >>=20 >> - it's not just a slide deck, it's a paper, in case you're interested. T= he >> longer version is freely available: >> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR4= 34.pdf?sequence=3D5 >=20 > Thanks for the link! I hadn't seen the full paper, reading it now. Thanks for reading! AFAIK there's now much more work out there that examin= es the various active queue management mechanisms.=20 >=20 >> Why no other traffic types? Because we felt that looking at just bulk TC= P >> is enough to make the key point that we wanted to get across: maybe it's >> worth taking a look at the vast amount of work that exists on AQMs, as >> even a stone old mechanism like ARED does not seem to generally be >> significantly worse than CoDel and PIE. >=20 > My objection to that is twofold: >=20 > 1.) The traffic pattern it's testing is the pattern RED-like AQM was=20 > designed for - largely predictable both in terms of the transport's=20 > capabilities and the traffic traversing it. I find it relatively=20 > unsurprising ARED does well with that. Same for CoDel. CoDel is very clearly designed for bulk TCP transfers. Or d= o we have results showing something else? (note: CoDel, not FQ_CoDel). > 2.) It doesn't model what's actually seen in the real world. In designing= a=20 > solution, an important pitfall is defining the problem out of existence. Trying to model the real world doesn't help understanding what's going on. = Understanding should be prioritized higher than realism. Once we know what = happens, we can make the model gradually more real. See also my other email= (answer to Sebastian Moeller). >> We didn't really want to sell ARED as it is as a much better solution >> under all conditions and say that it should now be used instead of CoDel >> and PIE (though we do conclude that it creating an ARED++ type mechanism >> seems worth considering). To make that point, I'd agree that one would >> have to see other traffic types too. A paper saying "We propose ARED++ a= s >> a replacement for CoDel or PIE" should have that. >=20 > Sure, but the sad fact of the matter is that the fine print of "We only=20 > tested it on a very narrow set of traffic patterns" tends to get lost beh= ind=20 > "Look, this graph shows ARED beating CoDel and PIE!" in many cases. See t= he=20 > message I was replying to - that research was taken as relatively solid=20 > evidence that ARED - not necessarily even ARED++ - would be sufficient fo= r=20 > internet-scale deployment, on an asymmetric transport, with real-world=20 > variable loads. Well, I also haven't seen results showing that CoDel or PIE work particular= ly well with other traffic types. So unless such results exist, the positio= n towards such an evaluation scenario is neutral. If ("and only if", I'd sa= y) there are such results published somewhere, pre-dating our paper, then t= hat's really a bad omission and you have a valid point. Cheers, Michael