Le mercredi 08 juin 2011 à 08:04 -0600, Dave Taht a écrit : > It looks like adding ECN to the other qdiscs would be good, and > transparent to the upper layers, but a 10 minute glance at HTB seems > to make it a non-trivial exercise. But that's me. I would certainly > like to see ECN asserted more often than it is. Thoughts?
Just add to your HTB some RED qdisc ? You have a framework to build whatever is needed. Dont try to use a "single magic thing that will solve all my problems". This reminds me the ESFQ attempt : Patrick prefered to plug an external classifier in SFQ, instead of adding specialized code in each possible Qdisc. I had the idea to add ECN to SFQ (my favorite qdisc for proxies dealing only with tcp flows) in the past, with a global config (shared for all flows : remember SFQ means Fair Queuing ;) ) At queueing time : - we compute the flow (internal default SFQ classifier, or external user provided one) - We queue the packet into its slot X (kind of pfifo) - If queue limit is reached, take a packet from the biggest slot Y, do a head drop. Return Congestion Notification to caller if the chosen slot is the slot X (X == Y) Adding ECN/RED here could be done with very litle added cost : Adding kind of RED on each slot, instead of a regular pfifo, and probabilist mark/drop packet at enqueue time if : - Current slot length is above the RED lower threshold - Or average residency time in slot above a threshold And doing full drop if : - Current slot length is above RED upper limit - Current elapsed time of head packet above upper time limit. I like the time being the feedback instead of queue length (hard to tune, especially if bandwidth is unknown) You would say for example : min_time = 3 ms max_time = 30 ms probability = 0.05 limit_time = 100 ms _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat