Re: [aqm] ping loss "considered harmful"

Dave Taht <> Mon, 02 March 2015 20:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 450B11A874A for <>; Mon, 2 Mar 2015 12:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5E2ss52FIhvG for <>; Mon, 2 Mar 2015 12:38:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A7201A1B80 for <>; Mon, 2 Mar 2015 12:38:30 -0800 (PST)
Received: by with SMTP id wp18so32911716obc.8 for <>; Mon, 02 Mar 2015 12:38:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hSq8gnN1Lwq40DQ7On5qyZ1NgwO5x5+9yOAKPwSFNLc=; b=AIjjcA5RR/8YwEGDmgMz8UAR+3rYR4uO/EVP1JbnjmOVZM0bkzIiWmNjb8zjOASxW9 ompOsS4zu+Pv+gmyf1vT2tdCF7Y2WjEApPR4CxoYrPnt5SIv7v65VL4ryWTPeL/MyTFL rMykXHzJ5Cwho972Hg2fI9PtekFDkeCj1wTZMatUT1c7VYZwXpQpXPicGtry901Ipyfh v4wWEntHW+ONDNWjM3mssxOwwz/2khnsGGfS1WeWLECI3ejKMW5MZBux35X3ldAWUX2e g6HmfAW/aXIkgpXM8kycDURTfR0DtsnjUIzQIw3BKNoKxn/olmoPIq+9vevu1hCRQz8W 6FVw==
MIME-Version: 1.0
X-Received: by with SMTP id i3mr11851465oen.39.1425328709393; Mon, 02 Mar 2015 12:38:29 -0800 (PST)
Received: by with HTTP; Mon, 2 Mar 2015 12:38:29 -0800 (PST)
In-Reply-To: <md2fsa$o1s$>
References: <> <md2fsa$o1s$>
Date: Mon, 02 Mar 2015 12:38:29 -0800
Message-ID: <>
From: Dave Taht <>
To: Wes Felter <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, "" <>, bloat <>
Subject: Re: [aqm] ping loss "considered harmful"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Mar 2015 20:38:32 -0000

On Mon, Mar 2, 2015 at 12:06 PM, Wes Felter <> 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
), 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

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:

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 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.

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

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