[Cerowrt-devel] [aqm] ping loss "considered harmful"

[Dave Taht]

On Mon, Mar 2, 2015 at 12:06 PM, Wes Felter <wmf at felter.org> wrote:
> What about a token bucket policer, so more than N ICMP/second gets penalized
> but a normal ping won't be.

If I haven't expressed this too many times before, I want to thank you
all for existing.

It is the quality and caliber of all the folk on these mailing lists
coming up with new ideas, that keeps me going.

I've had a really rough could days (bronchitus, the virgin controversy
here: https://plus.google.com/u/0/107942175615993706558/posts/E1yMgbWW81C
), and I will try to write more later, but I thought I would add a bit
of light to the debate by showing you the default openwrt firewall
rules:

http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/network/config/firewall/files/firewall.config;h=d149e77957de1c80358c1e8131920867a193c9ed;hb=HEAD

Problems: They do a (very low) syn limiter (25 syns/sec I think) by
default, which made sense 10 years ago, but not now - and I had run
into trouble with it while attempting to benchmark the alexa top 1
million in parallel through two routers at isc (at 300mbit) a few
years ago, so I ripped that out of cerowrt. It was a really puzzling
set of results, I had no idea why so many syn requests were dropping
on the floor til I inspected the actual firewall rules generated.

Similarly, they rate limit icmp at 1000/sec, which is too high at low
rates and too low at others. So I ripped that out of cerowrt, and in
sqm-scripts, I just held tossed it into the background bucket for for
a min of 30% of the background bandwidth.

I note that there are conflicting definitions of CS1 (background).
Comcast, re-marks about 90% I see to CS1 from whatever it was
originally, in the hope that it is treated as background. The ancient
firmware in commercial home routers *prioritizes* CS1 on etheret and
*deprioritizes it* on wifi, into the 802.11e background queue, when
enabled. CeroWrt tries to cons

I haven't seen ANY shipped open source FQ/AQM/QoS system that squashes
inbound dscp values, either, til cero, and despite the various rfcs
out there recommending that.

Openwrt's firewall system is, sadly, one of the better and saner
firewall rule sets that exists. Other rulesets I have seen in
commercial deployments are amazingly more complex, antiquated, and
frequently wrong.

as for fq/aqm/QoS I have pointed out the flaws in the comments on
wondershaper here:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

and those flaws, exist, in copy-pasted code in nearly every subsequent
shaper I have examined *and had the time to fix*.

EVERY open source shaper I have seen, also (aside from sqm-scripts)
does not handle ipv6 right, nor do they handle dsl/atm framing issues
correctly. Notably streamboost got it terribly, terribly wrong, as did
Netgear's new "Dynamic QoS", and d-links DIR-5500. Openwrt's
qos-scripts has similar problems. So does gargoyle's stuff, and
dd-wrts... and whatever they were using at nznog on my last talk.

In the original design for sqm-scripts, I'd tried to use 3 tiers of
DRR + fq_codel - for classification, and failed due to in some
circumstances DRR getting "stuck" on a queue when codel did a drop on
it. (a bug that may only have existed at the time). So we went with
HTB, with a max of 30% for prio, a min of 30% for background (due to
all the mismarked traffic, 5% wasn't enough) and background and BE
being able to use up all the bandwidth.

That said, however free.fr did DRR + fq_codel in their implemention
benchmarks out quite nicely,  tho I can't find the relevant comparison
benchmarks at the moment.

particularly the prio queue helps for multicast IPTV traffic. I tried
to discuss some of these issues here, but the wg was not interested at
the time for a document like this.

http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html


Since then I specified the combined rate limiter + fq_codel idea
called "cake" with up to 8 progressive levels of DRR for
classification, which jonathon did a GREAT first attempt at, but he
didn't believe me that strict rate limits were not the right thing
until he got a bit of user feedback....

I should write up all the design decisions that went into sqm-scripts
as it exists today - it came out of me using varous shapers in various
environments for 12+ years and for example, I had completely forgotten
why I had deprioritized icmp the way I did! - and rip out a few test
bits (like prioritizing AF42 for mosh) that are not correct for the
real world... whenever I manage to get out of bed.

>
> --
> Wes Felter
>
>
>
> _______________________________________________
> aqm mailing list
> aqm at ietf.org
> https://www.ietf.org/mailman/listinfo/aqm



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb