[Bloat] Notes about hacking on AQMs
Eric Dumazet
eric.dumazet at gmail.com
Wed Jun 8 07:57:12 PDT 2011
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
More information about the Bloat
mailing list