[Bloat] RED against bufferbloat

[Michael Welzl]

> On 25 Feb 2015, at 10:29, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 
> Hi Michael,
> 
> On Feb 25, 2015, at 10:18 , Michael Welzl <michawe at ifi.uio.no> wrote:
> 
>> Two points,
>> 
>> below...
>> 
>> [...]
>> 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.)
>> 
>> [...]
> 
> 	I have an opinion on that: because a) asymmetric is the general case and symmetric the special case b) a large percentage of end-nodes sit behind asymmetric paths that often are the bottlenecks that cause the queues for AQM to act on, so any AQM better work well in that situation to avoid spending its live in the ivory tower ;). So to put it in different words, as reality has an "asymmetry bias” ;) 

So this is the type of argument I object against (this "realistic rather than ivory tower" argument is also what I saw coming from Dave Taht). The reason is simple: we want to understand what's going on. The more realistic we make it, the more factors play into the behavior, and the harder it becomes to understand.

If you want to get realistic, sure, create a wireless connection with interference and other hosts, background traffic that resembles reality, realistic load on the server, and in the end you have no clue why you see the results you see.

This is why we often use simplified scenarios such as dumbbell links etc. You want to start as simple as possible to get an understanding, and build from that.

Now, asymmetry by itself doesn't necessarily have a huge effect - it very much depends on the traffic type studied. If you're looking at downloads, then asymmetry lets you study the effect of losing ACKs. Then you're likely doing an investigation into the behaviour of delayed ACK vs. non-delayed ACK, and you'll get different results with a Linux receiver than with a FreeBSD receiver because of the no-delaying-during-slow-start thing that Linux is doing (sorry, I think it's got a name, just forgot it now).

That's all fine, but did you notice that in the previous paragraph I'm not talking about AQM?

To me, it's all about understanding what's going on, which means to minimize cross-effects of things that are not under investigation. If we want to study the effect of CoDel on ACKs, fine - but let's not look at a download with CoDel and make the link asymmetric just to be "more realistic" when this CAN have an influence on the result and then we don't know what's going on.

All this being said: ACKs are not usually a huge problem (thanks to delaying them), and I would be surprised if asymmetry would have changed the results in our paper significantly in one way or another. I would be *hugely* surprised if they would have consistently rendered one AQM mechanism better than another.

I suspect that some of you folks like realistic experiments so much because they let you see the power of Fair Queuing (certainly, FQ_whatever can give you consistently less delay than any AQM mechanism when ever you have multiple flows, which is maybe even more pronounced when combined with ACKs on asymmetric links). Well great, this is fine!  :-)   but that's FQ (or FQ_CoDel's changed FQ variant), much more than the AQM mechanism in use (as we have also seen presented by Toke at the last ICCRG meeting). But this discussion is about AQM mechanisms, not (changed)FQ.

Cheers,
Michael