<br><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 8:57 AM, Eric Dumazet <span dir="ltr"><<a href="mailto:eric.dumazet@gmail.com">eric.dumazet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Le mercredi 08 juin 2011 à 08:04 -0600, Dave Taht a écrit :<br>
<div class="im">> It looks like adding ECN to the other qdiscs would be good, and<br>
> transparent to the upper layers, but a 10 minute glance at HTB seems<br>
> to make it a non-trivial exercise. But that's me. I would certainly<br>
> like to see ECN asserted more often than it is. Thoughts?<br>
<br>
</div>Just add to your HTB some RED qdisc ? You have a framework to build<br>
whatever is needed. Dont try to use a "single magic thing that will<br>
solve all my problems". This reminds me the ESFQ attempt : Patrick<br>
prefered to plug an external classifier in SFQ, instead of adding<br>
specialized code in each possible Qdisc.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>The core argument would be:<br><br>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.<br>
<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
I had the idea to add ECN to SFQ (my favorite qdisc for proxies dealing<br>
only with tcp flows) in the past, with a global config (shared for all<br>
flows : remember SFQ means Fair Queuing ;) )<br>
<br>
At queueing time :<br>
<br>
- we compute the flow (internal default SFQ classifier, or external user<br>
provided one)<br>
- We queue the packet into its slot X (kind of pfifo)<br>
- If queue limit is reached, take a packet from the biggest slot Y, do a<br>
head drop. Return Congestion Notification to caller if the chosen slot<br>
is the slot X (X == Y)<br>
<br>
Adding ECN/RED here could be done with very litle added cost :<br>
<br>
Adding kind of RED on each slot, instead of a regular pfifo, and<br>
probabilist mark/drop packet at enqueue time if :<br>
- Current slot length is above the RED lower threshold<br>
- Or average residency time in slot above a threshold<br>
<br>
And doing full drop if :<br>
- Current slot length is above RED upper limit<br>
- Current elapsed time of head packet above upper time limit.<br>
<br>
I like the time being the feedback instead of queue length (hard to<br>
tune, especially if bandwidth is unknown)<br>
<br>
You would say for example :<br>
        min_time = 3 ms<br>
        max_time = 30 ms<br>
        probability = 0.05<br>
        limit_time = 100 ms<br>
<br></blockquote><div><br>This sounds promising also. <br> <br></div></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>