Re: [Codel] [Cake] hard limit codel

[Andrew McGregor <andrewmcgr@gmail.com>]

Of course it fails at high RTT.  Unfortunately, long RTTs are pretty
common... for almost anything EXCEPT VIDEO.  Video, on the other hand,
is almost always served a) by application paced servers and b) over
the shortest RTT available.  So video isn't even a question for
high-RTT evaluations.  Even the upload stream from a VC client (not
usually TCP at all in the first place) is not usually going half way
round the world.

On Thu, Apr 16, 2015 at 10:00 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 16 Apr, 2015, at 14:50, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> I'll add, though, that I have seen the sentiment expressed here ("we
>> need to limit the max delay of CoDel") in other contexts. And, well,
>> delay spikes *is* a problem!
>
> Yes, they are.
>
> But in general AQM can’t be used to solve that problem without also suffering poor throughput; combining AQM with FQ *does* solve it.  Just like FQ is unfair to single flows competing against a swarm, but classifying the swarm traffic into a separate traffic class fixes that problem too.
>
> Which of course is why cake uses AQM, FQ *and* Diffserv, all at once.
>
> The linked paper didn’t measure HLC against fq_codel, even though they mention fq_codel.  That’s a major shortcoming.
>
>  - Jonathan Morton
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel