On Wed, Jun 8, 2011 at 8:57 AM, Eric Dumazet
<eric.dumazet@gmail.com> wrote:
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 agree that the new (1997) solution for SFQ, embedding the ESFQ principle is better. It's NOT embedded in the shaper scripts I've been playing with, it certainly seems saner for flows into the home to be doing it against dest ips rather than ips and port numbers, in the bittorrent age.
I will also attempt to argue persuasively that having ECN packet marking in HTB and elsewhere - when possible - in addition to packet drop would probably result in better behavior overall, but to do that well would require coding it up.
The core argument would be:
By the time a packet gets to a RED sub-qdisc, it's already been through HTB, and dropped if it is overlimit. RED has it's own idea as to the 'bandwidth' available, and does not understand what it's getting has already been shaped by HTB.
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
This sounds promising also.