From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5044F20097F for ; Wed, 8 Jun 2011 06:44:30 -0700 (PDT) Received: by iyi20 with SMTP id 20so650666iyi.16 for ; Wed, 08 Jun 2011 07:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+fcf/WVo0/AHasBg4qQg0iWD117UGrX8SBCfbdrWnHs=; b=XwP5ns+8T1mW5acKrGVpG/V8XHN8QBGzDvJlmvEOqkNEdG5MN9pAnXoCujehajIA0o kSB9B+usgaB3h7YlrJUzLXCIDmp2I77A9PdRLaK0ssRufqG+WwvyBdDZXVYC0fXKmBSl mr8wgA/1VYrd1OiW5619t/valXRpOTrDXm0aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EedBkeT/VyhDT0IDdrPzd0sMIfuM7XSPGsyHceFj28ALlslBUdjRitUux5KGYtwWrI NYPKboLfIIpa9HesdRZrsT4FWLHxxdu4h3BmjxnAAO62lw2KM43QwflboR46C8iT+7Z9 kY35CU1aMNAZJwa5rIdxmDCPWpESoxJC3Fcls= MIME-Version: 1.0 Received: by 10.231.68.202 with SMTP id w10mr11881194ibi.63.1307541898455; Wed, 08 Jun 2011 07:04:58 -0700 (PDT) Received: by 10.231.13.76 with HTTP; Wed, 8 Jun 2011 07:04:58 -0700 (PDT) In-Reply-To: References: <1307537773.3057.17.camel@edumazet-laptop> Date: Wed, 8 Jun 2011 08:04:58 -0600 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: multipart/alternative; boundary=0015177407d062ebcf04a533d2ee Cc: bloat Subject: Re: [Bloat] Notes about hacking on AQMs X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:44:30 -0000 --0015177407d062ebcf04a533d2ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 bucket= s 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. Wit= h a lookup table of 48k, instead of laborously matching packets with dozens o= f rules like this: $iptables -t mangle -A Wireless -p tcp -m tcp -m multiport --ports $P2PPORT= S -j DSCP --set-dscp-class CS4 -m comment --comment 'P2P' Instead, you could have a table that had a 1to1 correspondence table betwee= n 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 tha= t 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 determin= e if you want to allow a packet of a given type or not. 00 =3D allow 01 =3D block incoming 10 =3D block outgoing 11 =3D 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 wrot= e: > >> Le mercredi 08 juin 2011 =E0 06:12 -0600, Dave Taht a =E9crit : >> >> > 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=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --0015177407d062ebcf04a533d2ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 asse= rted 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 conventiona= l iptables rules (code in progress in my Cruft repo on github)

I came up with an interesting (and possibly bogus) idea for combining Q= oS 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 bit= s. 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 $P2P= PORTS -j DSCP --set-dscp-class CS4 -m comment --comment 'P2P'
Instead, you could have a table that had a 1to1 correspondence table betw= een 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 var= ious 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 numbe= rs.

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 =3D allow
01 =3D block incoming
10 =3D block outgoing
11 = =3D block both

So a massive set of iptables and classification rules= could be replaced by a table lookup, and the tables developed and distribu= ted via means similar to how we do dnsrbls today, or adblock plus.

There are pesky problems like coping with ephemeral ports, etc, and cac= he misses, but I would hope that two table lookups would outperform two doz= en iptables rules.

And provide a means for comprehensive classificat= ion that has not been done to date.

On Wed, Jun 8, 2011 at 7:32 AM, Dave Taht <dave.taht@gmail.= com> wrote:


On Wed, Jun 8, 2011 at= 6:56 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:<= br>
Le mercredi 08 juin 2011 =E0 06:12 -0600, Dave Taht a =E9crit :

> 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 classifi= er,
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 \
=A0 =A0 =A0 =A0keys dst divisor 1024

With recent SFQ, you can play with a divisor in [256 .. 65536]



Didn't know that!! VERY COOL. How histo= ry changes.
=A0
Refs :

http://lwn.ne= t/Articles/236200/

http://www.nuclearcat.com/mediawiki/index.php/Linux_iproute= 2






--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-= edge.blogspot.com



--
Dave T=E4ht=
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--0015177407d062ebcf04a533d2ee--