Re: [Codel] [Bloat] Exploring the potential of codel, fq_codel, and qfq

[Eric Dumazet <eric.dumazet@gmail.com>]

On Wed, 2012-05-16 at 12:31 +0300, Jonathan Morton wrote:
> There are two goals here. One: provide real feedback to TCPs so that
> they know when the link is full and thus don't also fill up the buffer
> constantly. Two: prevent flows from unduly interfering with each
> other, so they don't have to fill the buffer just to be sure of good
> throughput. 
> 
> What you seem to be saying is that you have a queue full of
> unresponsive flows that aren't being dropped because they have ECN
> support and are being marked instead. With FQ, that doesn't matter
> because other flows can still get through with low latency, and in
> fq_codel they are treated separately for mark/drop decision purposes.
> And if the queue really does fill up physically, codel already drops
> packets at head regardless of ECN capability. 

It matters because :

1) We setup high limit for codel so "head drop" at enqueue time is a
last resort thing.

2) If you have ECN blackhole _after_ you, flow can be non responsive not
because it doesnt want to, only because of the blackhole. Detecting a
too long delay in this flow queue and reverting to drops instead of
marks can help to recover from ECN blackhole.