[Bloat] RED against bufferbloat

[Alex Elsayed]

Michael Welzl wrote:

> Two points,
> 
> below...
> 
> On 25 Feb 2015, at 09:42, Alex Elsayed
> <eternaleye at gmail.com<mailto:eternaleye-
Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>>
> 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.