Re: [Bloat] Notes about hacking on AQMs

[Eric Dumazet <eric.dumazet@gmail.com>]

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