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? On the diffserv front, I'd meant to link to this RFC: http://tools.ietf.org/html/rfc4594 in the first message on this thread. ... While laboring to classify hundreds of packet types into various buckets using conventional iptables rules (code in progress in my Cruft repo on github) I came up with an interesting (and possibly bogus) idea for combining QoS and firewalling that seems both simple and low overhead (thus suspect) There are only 64k ports in the world. To do diffserv, you need 6 bits. With a lookup table of 48k, instead of laborously matching packets with dozens of rules like this: $iptables -t mangle -A Wireless -p tcp -m tcp -m multiport --ports $P2PPORTS -j DSCP --set-dscp-class CS4 -m comment --comment 'P2P' Instead, you could have a table that had a 1to1 correspondence table between ports and DSCP values, and load that into the kernel at run time (generated perhaps from iana's list + some other collection, modified for decent diffserv classes by various providers (similar to how adblock plus provides varying lists) That would result in a 48k table lookup, and would mostly stay 'hot' in that you would typically match against the lower of the port numbers. The *crazy* part of the idea was that you basically need 2 bits to determine if you want to allow a packet of a given type or not. 00 = allow 01 = block incoming 10 = block outgoing 11 = block both So a massive set of iptables and classification rules could be replaced by a table lookup, and the tables developed and distributed via means similar to how we do dnsrbls today, or adblock plus. There are pesky problems like coping with ephemeral ports, etc, and cache misses, but I would hope that two table lookups would outperform two dozen iptables rules. And provide a means for comprehensive classification that has not been done to date. On Wed, Jun 8, 2011 at 7:32 AM, Dave Taht wrote: > > > On Wed, Jun 8, 2011 at 6:56 AM, Eric Dumazet wrote: > >> Le mercredi 08 juin 2011 à 06:12 -0600, Dave Taht a écrit : >> >> > SFQ is the second most commonly used qdisc, but doesn't balance in >> > ways ESFQ could. >> > >> > ESFQ really looked like a winner and I'm sorry it never made the >> > mainline kernel. >> >> Hmm, since 2007 SFQ has all ESFQ provided, if you use a flow classifier, >> you can exactly match your needs. >> >> [ SFQ uses an internal flow classifer on >> src,dst,proto,proto-src,proto-dst ] >> >> Say you want to make something only about dst addresses : >> >> tc filter add ... flow hash \ >> keys dst divisor 1024 >> >> With recent SFQ, you can play with a divisor in [256 .. 65536] >> >> >> > Didn't know that!! VERY COOL. How history changes. > > >> Refs : >> >> http://lwn.net/Articles/236200/ >> >> http://www.nuclearcat.com/mediawiki/index.php/Linux_iproute2 >> >> >> >> > > > -- > Dave Täht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com