My impression is that ECN ignorant flows do exist, because of stupid routers rather than malice, and that Dave considers this a problem worth tackling in codel.
However I would disagree that the problem needs tackling here, at least for fq_codel which already segregates non-responsive flows from others. The ignorant flows will experience higher latency if this link is a bottleneck for them, that is all. Plain codel might need a more robust defence, but I have a different suggestion for that. Determine whether a prolonged bout of marking is being caused by ECN ignorant flows, and if so disable ECN marking (just drop) until the ignorant flows have clearly gone away. The key to knowledge is not to rely on others to teach you it. On 25 Jun 2012, at 18:45, Eric Dumazet <[email protected]> wrote: > On Mon, 2012-06-25 at 08:30 -0700, Dave Taht wrote: > >> It was the way I was leaning until I observed me dropping ecn enabled >> mosh, ssh, and babel packets , which tend to be small, so I started >> thinking in terms of dropping ecn packets on a graduated packet size >> scale after exceeding target. ESPECIALLY in case of overload you want >> command and control packets to get through. >> > > Don't try to add in CoDel things that should be done at another layer. > There is no classification in CoDel : Its a FIFO. > > Only way is to prioritize control packets if you need to, and use > several queues. > > I dont understand... Are you saying that you feel the need to drop > packets instead of marking them in a 'good citizen world' (none of your > flow pretends to use ECN to avoid drops) ? > > > > _______________________________________________ > Codel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/codel _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
