[Bloat] RED against bufferbloat

[Michael Welzl]

> 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.

Cheers,
Michael