That's a pretty specific type of blackhole - one that can pass enough ECN information to permit negotiation of an ECN flow, but which then squashes Congestion Experienced codepoints. How common are those?
If fq_codel drops from the head of the longest flow when the queue is physically full, rather than the next one to be serviced, all should be well even in that case. The key to knowledge is not to rely on others to teach you it. On 16 May 2012, at 12:37, Eric Dumazet <[email protected]> wrote: > 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. > > > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
