Michael Welzl wrote: > Two points, > > below... > > On 25 Feb 2015, at 09:42, Alex Elsayed > <[email protected]<mailto:eternaleye- [email protected]>> > wrote: <snip> > 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. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
