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 14AE921F301 for ; Wed, 25 Feb 2015 02:11:12 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YQYvu-0003dj-0e; Wed, 25 Feb 2015 11:11:10 +0100 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YQYvo-00067M-Hx; Wed, 25 Feb 2015 11:11:09 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Feb 2015 11:10:47 +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:10:47 +0100 From: Michael Welzl To: Sebastian Moeller Thread-Topic: [Bloat] RED against bufferbloat Thread-Index: AQHQUNv0sUKvBGCaSEK1SlX4B/tmiw== Date: Wed, 25 Feb 2015 10:10:46 +0000 Message-ID: <3F47B274-B0E4-44F2-A434-E3C9F7D5D041@ifi.uio.no> References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> In-Reply-To: <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> 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="Windows-1252" Content-ID: <9B0C2A097EB9854BAB429FE83F0AD180@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 25962 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: 943D6A565EFB5C344F7C8237B909AB31F2182D53 X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 52 total 598350 max/h 480 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:11:41 -0000 > On 25 Feb 2015, at 10:29, Sebastian Moeller wrote: >=20 > Hi Michael, >=20 > On Feb 25, 2015, at 10:18 , Michael Welzl wrote: >=20 >> Two points, >>=20 >> below... >>=20 >> [...] >> 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 inv= estigated, and why.) >>=20 >> [...] >=20 > I have an opinion on that: because a) asymmetric is the general case and= symmetric the special case b) a large percentage of end-nodes sit behind a= symmetric paths that often are the bottlenecks that cause the queues for AQ= M to act on, so any AQM better work well in that situation to avoid spendin= g its live in the ivory tower ;). So to put it in different words, as reali= ty has an "asymmetry bias=94 ;)=20 So this is the type of argument I object against (this "realistic rather th= an ivory tower" argument is also what I saw coming from Dave Taht). The rea= son is simple: we want to understand what's going on. The more realistic we= make it, the more factors play into the behavior, and the harder it become= s to understand. If you want to get realistic, sure, create a wireless connection with inter= ference and other hosts, background traffic that resembles reality, realist= ic load on the server, and in the end you have no clue why you see the resu= lts you see. This is why we often use simplified scenarios such as dumbbell links etc. Y= ou want to start as simple as possible to get an understanding, and build f= rom that. Now, asymmetry by itself doesn't necessarily have a huge effect - it very m= uch depends on the traffic type studied. If you're looking at downloads, th= en asymmetry lets you study the effect of losing ACKs. Then you're likely d= oing an investigation into the behaviour of delayed ACK vs. non-delayed ACK= , and you'll get different results with a Linux receiver than with a FreeBS= D receiver because of the no-delaying-during-slow-start thing that Linux is= doing (sorry, I think it's got a name, just forgot it now). That's all fine, but did you notice that in the previous paragraph I'm not = talking about AQM? To me, it's all about understanding what's going on, which means to minimiz= e cross-effects of things that are not under investigation. If we want to s= tudy the effect of CoDel on ACKs, fine - but let's not look at a download w= ith CoDel and make the link asymmetric just to be "more realistic" when thi= s CAN have an influence on the result and then we don't know what's going o= n. All this being said: ACKs are not usually a huge problem (thanks to delayin= g them), and I would be surprised if asymmetry would have changed the resul= ts in our paper significantly in one way or another. I would be *hugely* su= rprised if they would have consistently rendered one AQM mechanism better t= han another. I suspect that some of you folks like realistic experiments so much because= they let you see the power of Fair Queuing (certainly, FQ_whatever can giv= e you consistently less delay than any AQM mechanism when ever you have mul= tiple flows, which is maybe even more pronounced when combined with ACKs on= asymmetric links). Well great, this is fine! :-) but that's FQ (or FQ_C= oDel'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). But this discu= ssion is about AQM mechanisms, not (changed)FQ. Cheers, Michael