Re: [Bloat] RED against bufferbloat

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Michael Welzl <michawe@ifi.uio.no> writes:

> +1, certainly it has a big influence. This has been well known for
> many years though, and documented broadly, perhaps most notably by Jim
> Roberts.

Being "well known for many years" in the academic community
unfortunately doesn't translate into deployment. Which is why I think
there should be a place for both approaches: the "let's simplify and get
a thorough base understanding" and the "let's run this on real stuff and
see what happens".

> Here I disagree, for two reasons:
>
> 1) The AQM part kicks in per flow. So, whenever you have one flow, the
> behavior of FQ_AQM and AQM will be the same. Investigating what an AQM
> mechanism does to one flow is then worthwhile.
>
> 2) Not everyone will always want FQ everywhere. There are potential
> disadvantanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow problem).
> What's necessary is to quantify them - to see how the effect of FQ (or
> FQ_CoDel's changed FQ) plays out, and you've done a great start there in my
> opinion.

I didn't mean that investigating AQM behaviour is not worthwhile, far
from it. But I believe that FQ needs to play a much larger role than it
does currently in solving the larger problem of network (latency)
behaviour under load. And completely separating the two is academic; not
in the derogatory sense (as in "a problem not worth discussing"), but in
the literal sense (as in "the thing we do in academia").

-Toke