On Mon, Jun 25, 2012 at 10:48 AM, Jonathan Morton <[email protected]> wrote: > 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.
Malice will exist. It is easy to create a set of flows that will overwhelm either codel or fq_codel, with ecn enabled. fq_codel does respond well to udp flooding, I note, far better than pfifo_fast. > > 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. the first version of fq_codel had a separate codel queue per flow, which would behave as you say. The lastest version uses the global drop probability, which makes more sense in the general case. I continue to prototype with qfq+codel which has the first behavior, presently. I like the idea of a more perfect fluid model, especially at the bandwidths I operate at (2-30Mbit), with the cpu horsepower available to make more better choices than fq_codel can. > 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. Well, an example algo for that would be helpful. SFB tried to do this. I note that codel operates independently of RTT and I am thinking hard that RTT related issues need to be explored overall. > The key to knowledge is not to rely on others to teach you it. I am an experimenter first and foremost. My inspirations are more from edison than tesla. Queue behavior is rarely intuitive, and the only way to build intuition, for me, at least, is to design an experiment and observe what happens. Kelly Johnson could "see air". Perhaps van and kathie can "see packets". Me, on the other hand... > > 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 -- Dave Täht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!" _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
