<font face="arial" size="2"><p style="margin:0;padding:0;">Since there seems to be some confusion about what aspect of bufferbloat fq_codel controls, perhaps somewhere in a HOWTO somebody should talk about how to combine tbf (for the upstream "cable modem"  case) with fq_codel  on cerowrt today - though I think the contemplated mfq_codel idea mentioned below would be nice, but it would have to be parameterized, which codel need not be.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">For even better user experience, perhaps Luci could have a "wizard" that asks a simple question like:</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">is your upstream a cable modem with bufferbloat? ( ) yes ( ) no</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">what is its rated "uplink" bitrate?   _____ Mb/sec</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">And set up the tbf+fq_codel properly for people who want simple setup.   Reasonable tbf parameters should be easy to calculate given the rate.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Monday, August 20, 2012 3:12pm<br />To: "Sebastian Moeller" <moeller0@gmx.de><br />Cc: cerowrt-devel@lists.bufferbloat.net, "Felix Fietkau" <nbd@nbd.name><br />Subject: [Cerowrt-devel] Coping with router memory limitations in fq_codel<br /><br /></p>
<div id="SafeStyles1345667809">
<p style="margin:0;padding:0;">Dear Sebastian:<br /><br />In addition to your udp flooding DoS attack, I attacked cero also by<br />using diffserv marking in netperf (-Y codepoint,codepoint) to saturate<br />all 4 wifi fq_codel queues, and also would get the router to have<br />memory allocation failures and ultimately crash in the same way you<br />are crashing it. I can similarly do what you just did with rtp<br />flooding. You are correct that codel is tuned for tcp, and that<br />fq_codel by maintaining many queues is even more susceptible to a<br />tuned udp flooding attack on a memory limited device such as this.<br /><br />I tried to cope with this in 3.3.8-10/11 by reducing the packet<br />limits, which helped a lot. Unfortunately the settings I used then<br />were below codel's reaction time, which invoked "interesting" tail<br />drop behavior, so I arbitrarily doubled them in -17. To invoke more of<br />the kind of problems you are encountering...<br /><br />0) Since then I have been looking into ways to improve codel's<br />reaction time that are in the ns2 model presently, also fixing an<br />assumption about newton's method that didn't hold in reverse, and also<br />means to incorporate more aggressive codel behavior when queue limits<br />are near to being exceeded.<br /><br />Unfortunately as the memory pressure problem starts in the driver,<br />it's not communicated up the stack to where it could be controlled<br />better...<br /><br />0) I would like avoid having to determining if a queue is tcp or<br />"other", and then having different kinds of drop strategies for each.<br />That said, it seems possible to implement that...<br /><br />1) A workaround of sorts for the 64MB 3700v2 has been to give up on<br />named and get some memory back that way.<br /><br />2) I believe, but am not sure, that Linux 3.6(5?) has some stuff in it<br />to get skb memory allocations done more efficiently. Eric and I and<br />felix had talked about it, I don't know what was implemented.<br /><br />3) It may be possible to improve how the memory allocations from the<br />2048 slab work in general. I imagine that half of memory is being<br />wasted on big packets otherwise.<br /><br />4) some options for improving fq_codel for more memory constrained<br />home environments better.<br /><br />4a) On the wifi front (as well as other devices with multiple hardware<br />queues), I envision something like "mfq_codel", which would have an<br />overall similar packet limit to a single fq_codel, but be able to<br />deliver (and fair queue) packets to the underlying hardware queues<br />independently.<br /><br />4b) On the home to-ISP gateway qos front, a rate limited (tbf)<br />mfq_codel with 2-4 queues would replace the complexity of hfsc or htb<br />with a default qdisc that "just worked" without any scripting. It<br />could be mildly more responsive (htb buffers up some data and has it's<br />own notion of time and quantums), thus cpu and memory usage would be<br />lower than htb + multiple fq_codel queues.<br /><br />Getting something that scaled down to 10s of kbits and up to gigabits<br />would be hard, tho. HTB needs to be tuned when running lower or higher<br />than it's original operating range, presently, and that is where, in<br />part, the simple_qos.sh effort is "stuck".<br /><br />4c) Another thought would be to have a weighted packet (to handle<br />classification) oriented sfq codel or qfq_codel rather than separate<br />fq_codel queues that are each byte-aware... we have CPU to burn, but<br />not memory...<br /><br />On Mon, Aug 20, 2012 at 11:24 AM, Sebastian Moeller <moeller0@gmx.de> wrote:<br />> Hi Dave,<br />><br />> so I went to play around with this a bit more. I turned to UDP flooding my cable modem through the router and this surely allows me to create enough load on the wndr3700v2 to cause the allocation errors and as a "bonus" also to drive the router to reboot (driven by the watchdog timer?). Here is the script I used over 5G wireless (from http://blog.ioshints.info/2008/03/udp-flood-in-perl.html)<br />><br />> #!/usr/bin/perl<br /><br />It would be nice to have a C or lua version of this sort of test.<br /><br />> ##############<br />><br />> # udp flood.<br />> ##############<br />><br />> use Socket;<br />> use strict;<br />><br />> if ($#ARGV != 3) {<br />>   print "flood.pl <ip> <port> <size> <time>\n\n";<br />>   print " port=0: use random ports\n";<br />>   print " size=0: use random size between 64 and 1024\n";<br />>   print " time=0: continuous flood\n";<br />>   exit(1);<br />> }<br />><br />> my ($ip,$port,$size,$time) = @ARGV;<br />><br />> my ($iaddr,$endtime,$psize,$pport);<br />><br />> $iaddr = inet_aton("$ip") or die "Cannot resolve hostname $ip\n";<br />> $endtime = time() + ($time ? $time : 1000000);<br />><br />> socket(flood, PF_INET, SOCK_DGRAM, 17);<br />><br />><br />> print "Flooding $ip " . ($port ? $port : "random") . " port with " .<br />>   ($size ? "$size-byte" : "random size") . " packets" .<br />>   ($time ? " for $time seconds" : "") . "\n";<br />> print "Break with Ctrl-C\n" unless $time;<br />><br />> for (;time() <= $endtime;) {<br />>   $psize = $size ? $size : int(rand(1024-64)+64) ;<br />>   $pport = $port ? $port : int(rand(65500))+1;<br />><br />>   send(flood, pack("a$psize","flood"), 0, pack_sockaddr_in($pport, $iaddr));}<br />><br />> called as either<br />> udp_flood.pl 192.168.100.1 0 1024 240<br />> or<br />> udp_flood.pl 192.168.100.1 32000 1024 240<br />><br />> The first version with randomized port number spreads the load nicely over many fq_codel bins/flows and seems slightly more likely to cause allocation errors and reboots than the 2nd invocation which restricts itself to port 32000 and presumably just one flow.<br />>         I wonder how to make cerowrt survive this kind of stress test…<br />><br />> best<br />>         Sebastian<br />><br />><br />> On Aug 15, 2012, at 9:08 PM, Dave Taht wrote:<br />><br />>> re: ath: skbuff alloc of size 1926 failed<br />>><br />>> as for the ath skbuff problem, I've seen that a lot. I had put hard<br />>> packet limits (~600) on fq_codel in -11 and prior that were too low<br />>> and it mostly went away, but I hit tail drop behavior everywhere,<br />>> instead of codel behavior. What I have now (typically 1200) may well<br />>> be too high, but not as overly high as the default (10k packets).<br />>> There may be another means of increasing the size of that slab pool or<br />>> making it less onerous.<br />>><br />>> I would like it if codel "kicked in" earlier than it currently does.<br />>> The code in ns2 is currently using half the period that the linux code<br />>> is. This would control things better, or so I hope (planning on trying<br />>> this as I get time)<br />>><br />>> I am also considering means of artificially upscaling the drop<br />>> scheduler when we get close to queue limits.<br />>><br />>> See some discussions on the codel list for these issues. (sims are<br />>> easier to deal with than cerowrt, too!)<br />>><br />>> as for bind, it should be automagically restarted from xinetd, no need<br />>> to fiddle with anything. However, since you are already under massive<br />>> memory pressure, it may well fail to start up that way, too. At the<br />>> moment, I've largely given up on bind on anything but a more core home<br />>> gw, and am running dnsmasq on everything (3700v2, picostations,<br />>> nanostations) but the 3800s. (and the ones I run it on, aren't being<br />>> used for wifi right now).<br />>><br />>> Lastly: Swap space won't help you on exhausting kernel limits.<br />>><br />>> I'm glad you can reproduce the ath: slab problem - I can get it too at<br />>> high rates using netperf over wifi. I will try a 3700v2 with and<br />>> without bind to see if it's still there in 3.3.8-17. In the meantime<br />>> if anyone knows how to get more allocations in that (2048? 4096?) slab<br />>> by default, perhaps that will help?<br />>><br />>><br />>><br />>> On Wed, Aug 15, 2012 at 10:23 AM, Sebastian Moeller <moeller0@gmx.de> wrote:<br />>>> Hi Dave,<br />>>><br />>>> great work, as always I upgraded my production router to the latest and greatest (since I only have one router…). And it works quite well for normal usage…<br />>>> Netalyzr reports around 2800ms seconds of uplink buffering, yet saturating the uplink does not affect ping times to a remote target noticeably, basically the same as for all codellized ceo versions I tested so far...<br />>>><br />>>> Some notes and a question:<br />>>> I noticed that even given plenty of swap space (1GB on a usb stick), using http://broadband.mpi-sws.org/residential/ to exercise UDP stress (on the uplink I assume) I can easily produce (I run the test from a macosx via 5GHz wireless over 1.5 yards):<br />>>> Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.132812] ath: skbuff alloc of size 1926 failed<br />>>> (and plenty of those…).<br />>>> What then happens is that the OOM killer will aim for bind (reasonable since it is the largest single process) and kill it. When I try to restart bind by:<br />>>> root@nacktmulle:~# /etc/rc.d/S47namedprep start<br />>>> root@nacktmulle:~# /etc/rc.d/S48named restart<br />>>> Stopping isc-bind<br />>>>  /etc/chroot/named//var/run/named/named.pid not found, trying brute force<br />>>> killall: named: no process killed<br />>>> Kicking isc-bind in xinetd<br />>>> rndc: connect failed: 127.0.0.1#953: connection refused<br />>>> And bind does not start again and the router becomes less than useful. Now I assume I am doing something wrong, but what, if you have any idea how to solve this short of a reboot of the router (my current method) I would be happy to learn<br />>>><br />>>><br />>>><br />>>> best regards<br />>>>        sebastian<br />>>><br />>>> On Aug 12, 2012, at 11:08 PM, Dave Taht wrote:<br />>>><br />>>>> I'm too tired to write up a full set of release notes, but I've been<br />>>>> testing it all day,<br />>>>> and it looks better than -10 and certainly better than -11, but I won't know<br />>>>> until some more folk sit down and test it, so here it is.<br />>>>><br />>>>> http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/<br />>>>><br />>>>> fresh merge with openwrt, fix to a bind CVE, fixes for 6in4 and quagga<br />>>>> routing problems,<br />>>>> and a few tweaks to fq_codel setup that might make voip better.<br />>>>><br />>>>> Go forth and break things!<br />>>>><br />>>>> In other news:<br />>>>><br />>>>> Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel<br />>>>> at last week's ietf meeting. Well worth watching. At the end he outlines<br />>>>> the deployment problems in particular.<br />>>>><br />>>>> http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREA&chapter=part_3<br />>>>><br />>>>> Far more interesting than this email!<br />>>>><br />>>>><br />>>>> --<br />>>>> Dave Täht<br />>>>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out<br />>>>> with fq_codel!"<br />>>>> _______________________________________________<br />>>>> Cerowrt-devel mailing list<br />>>>> Cerowrt-devel@lists.bufferbloat.net<br />>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />>>><br />>><br />>><br />>><br />>> --<br />>> Dave Täht<br />>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out<br />>> with fq_codel!"<br />><br /><br /><br /><br />-- <br />Dave Täht<br />http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out<br />with fq_codel!"<br />_______________________________________________<br />Cerowrt-devel mailing list<br />Cerowrt-devel@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/cerowrt-devel</p>
</div></font>