From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id CC9BE21F301 for ; Wed, 25 Feb 2015 01:32:04 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YQYK0-0006Ep-PY for bloat@lists.bufferbloat.net; Wed, 25 Feb 2015 10:32:00 +0100 Received: from 66.87.138.144 ([66.87.138.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Feb 2015 10:32:00 +0100 Received: from eternaleye by 66.87.138.144 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Feb 2015 10:32:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: Alex Elsayed Date: Wed, 25 Feb 2015 01:31:47 -0800 Message-ID: References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 66.87.138.144 User-Agent: KNode/4.14.3 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 09:32:33 -0000 Michael Welzl wrote: > Two points, > > below... > > On 25 Feb 2015, at 09:42, Alex Elsayed > > > 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.) It was less a criticism of your work itself, and more pointing out that Bob Briscoe was applying research on symmetric paths to asymmetric paths without questioning the applicability of its conclusions. > and the > latter is a one-line mention under "future work": > > "More realistic traffic types (here, only bulk TCP traffic) including > bursty traffic" > > Considering those, that slide deck convinces me of very, very little > indeed. > > - it's not just a slide deck, it's a paper, in case you're interested. The > longer version is freely available: > https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf?sequence=5 Thanks for the link! I hadn't seen the full paper, reading it now. > Why no other traffic types? Because we felt that looking at just bulk TCP > 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. My objection to that is twofold: 1.) The traffic pattern it's testing is the pattern RED-like AQM was designed for - largely predictable both in terms of the transport's capabilities and the traffic traversing it. I find it relatively unsurprising ARED does well with that. 2.) It doesn't model what's actually seen in the real world. In designing a solution, an important pitfall is defining the problem out of existence. > 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++ as > a replacement for CoDel or PIE" should have that. Sure, but the sad fact of the matter is that the fine print of "We only tested it on a very narrow set of traffic patterns" tends to get lost behind "Look, this graph shows ARED beating CoDel and PIE!" in many cases. See the message I was replying to - that research was taken as relatively solid evidence that ARED - not necessarily even ARED++ - would be sufficient for internet-scale deployment, on an asymmetric transport, with real-world variable loads. > My point is: when developing something new, compare against the state of > the art. RED is *not* the state of the art, it's very old. I have seen > arguments like needing parameterless operation because that was the > failure of RED. Well, Sally Floyd addressed that with ARED ages ago. Most > papers cited in this survey: > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6329367 begin > with "RED didn't work because parameters had to be tuned. We propose a > mechanism that doesn't require such tuning..." I fully agree; I just think there's also danger in how people read a lot more into narrow comparisons than is justified. > What I've seen so far: > - CoDel compared with RED and BLUE > - PIE compared with CoDel > - ARED compared with CoDel and PIE > > ... it would seem reasonable to take one of the many, many mechanisms that > exist - one that was already shown to be better than RED and many others - > , make it use delay as input, and test CoDel and PIE against that. Then > I'd say we have a comparison against the state of the art. Now we don't > really have that, there's a gap here. Definitely agreed. I think we're on the same page in terms of _goals_ - really figuring out how the various algorithms compare in terms of their fitness in the solution space. There's just the fiddly bits of phrasing that scare me.