So in addition to hacking on the switch, I've been poking into the behavior<br>of multiple AQM systems in the kernel, ranging from the wondershaper, <br>to the adsl-shaper, to the qos-scripts in openwrt. <br><br>I started off with something ambitious, which was to try and implement<br>
a complete implementation of diffserv, using guidelines laid out by <br><br>not only across the outgoing to-the-internet interface, but across the <br>internal wired and wireless networks, something that would work with all protocols.<br>
<br>I rapidly got bogged down. (or rather, I've been poking at it for months, nay, years,<br>
in part trying to find feedback loops that handled 'tiny monster' packets <br>like multicast on wireless)<br><br>Some notes:<br><br>There are as many philosophies to AQM as there are shapers and classifiers.<br><br>
None of the Linux shaper scripts in the field handle ipv6 traffic.<br><br>HTB is the most commonly used qdisc, handles it's bandwidth limits by packet drop<br>and doesn't do ECN. It's usually used in conjunction with other qdiscs, too.<br>
<br>An explanation of how diffserv (dsmark) and GRED are supposed to play ball together<br clear="all">(starting here: <a href="http://www.opalsoft.net/qos/DS-27.htm" target="_blank">http://www.opalsoft.net/qos/DS-27.htm</a>) is so amazingly not opaque.<br>
<br>SFB remains promising, but until I get a ported tc for it, <br>I can't play with it much. <br><br>SFQ is the second most commonly used qdisc, but doesn't balance in ways ESFQ could.<br><br>ESFQ really looked like a winner and I'm sorry it never made the mainline kernel.<br>
<br>HFSC is mind-bending as to what it tries to do.<br>
<br>Any form of fair queuing is useful for ethernet, but actually knowing the link rate and port on the switch per dest macaddr would help in load balancing streams. <br><br>Fair queueing is very bad on wireless when packet aggregation is used. <br>
<br>PFIFO_FAST is tied to TOS bits, not diffserv bits. <br>
<br>RED is, well, RED.<br><br>GRED is far less opaque than RED, as noted earlier.<br><br>MQ and MQPrio are horribly underdocumented. I still don't 'get' how to use them<br>properly (I'm more focused on writing a good classifier at the moment)<br>
<br>802.11e does its prioritization at the vlan layer, not at the TOS or diffserv bits. Getting from tos or diffserv to mq* seems painful but I haven't looked into it too hard.<br><br>iptables seems to think ecn can only be looked at in TCP streams, where (for example), <br>
ecn bits can be copied to the outer header of a udp vpn stream, and marked when needed.<br>
<br>ip6tables has no support for looking at ecn except through a u32 match.<br><br>You are in a maze of twisty little passages, all not quite going where you want<br>to go. The intersection of all these 'solutions' is part of why wireless is so messed up, as are home routers...<br>
and I haven't even got to trying to figure out the multicast monster problem yet!<br><br>Adding ECN capability to the other qdiscs looks like low hanging fruit...<br><br>Anyway, aside from the whining^H^H^H^H^^H descriptions above, here's a quick and dirty bit of iptables useful for detecting ecn capability:<br>
<br>iptables -t mangle -X Wireless <br>iptables -t mangle -N Wireless<br>
iptables -t mangle -F Wireless <br>iptables -t mangle -A Wireless -p tcp
-m tcp --tcp-flags ALL SYN,ACK -m ecn --ecn-tcp-ece -m recent --name
ecn_enabled --set -m comment --comment 'ECN enabled streams' <br>iptables
-t mangle -A Wireless -p tcp -m tcp --tcp-flags ALL SYN,ACK -m ecn !
--ecn-tcp-ece -m recent --name ecn_disabled --set -m comment --comment
'ECN disab<br>
led streams' <br><br>iptables -t mangle -F POSTROUTING<br>iptables -t mangle -A POSTROUTING -j Wireless<br><br>You can see what ips managed to do ECN or not via<br><br>cat /proc/net/xt_recent/ecn_*<br><br>But that's just a distraction from trying to converge on a<br>
decent set of solutions for AQM. I AM happy to report that after getting buffer sizes down (via ethtool, a switch patch, txqueuelen) I am finally able to reliably see sub 10ms latencies on the wndr3700... but I wake up these days, feeling doomed.<br>
<br>-- <br>Dave Täht<br>SKYPE: davetaht<br>
US Tel: <a href="tel:1-239-829-5608" value="+12398295608" target="_blank">1-239-829-5608</a><br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>