[Bloat] Notes about hacking on AQMs

[Dave Taht]

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 <dave.taht at gmail.com> wrote:

>
>
> On Wed, Jun 8, 2011 at 6:56 AM, Eric Dumazet <eric.dumazet at gmail.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20110608/00b6b49c/attachment-0002.html>