[Bloat] RED against bufferbloat

[Alex Elsayed]

Michael Welzl wrote:

> 
>> On 25 Feb 2015, at 10:31, Alex Elsayed
>> <eternaleye at gmail.com> wrote:
>> 
>> 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.
> 
> No worries about criticism, I don't mind that - I asked because I'd only
> use an asymmetric link if I understand why, and what I'm investigating. To
> understand the basic behaviour of an AQM mechanism, asymmetry doesn't seem
> necessary to me.
> 
> 
>>> 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.
> 
> Thanks for reading!  AFAIK there's now much more work out there that
> examines the various active queue management mechanisms.
> 
>> 
>>> 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.
> 
> Same for CoDel. CoDel is very clearly designed for bulk TCP transfers. Or
> do 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 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++
>>> 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.
> 
> Well, I also haven't seen results showing that CoDel or PIE work
> particularly well with other traffic types. So unless such results exist,
> the position towards such an evaluation scenario is neutral. If ("and only
> if", I'd say) there are such results published somewhere, pre-dating our
> paper, then that's really a bad omission and you have a valid point.

My main point is about the issues where the practical meets the academic.

In the academic, you are exactly right - but what I'm seeing in this very 
thread is that "ARED beats CoDel and PIE in this one specific measure on a 
symmetric transport, which indicates that we should study this more deeply" 
is treated in the _practical_ domain as strong evidence that nothing more 
than ARED is needed.

In the practical domain, FQ is hugely relevant. In the practical domain, 
asymmetry is hugely relevant. In the practical domain, ARED++ and ARED are 
sufficiently different beasts that conflating them may be quite harmful.

And seen by someone from the practical domain who wasn't aware of the 
setting in which you were operating, your results were read as a statement 
that ARED (without FQ, and seemingly not ARED++) was very likely sufficient 
for an asymmetric, variable-load, cross-traffic-heavy deployment at internet 
scale.

My original post really was very much more disputing Bob Briscoe's 
extrapolations from your results than the validity or importance of the 
results themselves.