[aqm] ping loss "considered harmful"

Dave Taht <dave.taht@gmail.com> Mon, 02 March 2015 03:57 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A223F1A0029 for <aqm@ietfa.amsl.com>; Sun, 1 Mar 2015 19:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id L1pfDnNPGpB9 for <aqm@ietfa.amsl.com>; Sun, 1 Mar 2015 19:57:38 -0800 (PST)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B421A001B for <aqm@ietf.org>; Sun, 1 Mar 2015 19:57:37 -0800 (PST)
Received: by mail-ob0-f172.google.com with SMTP id nt9so28873071obb.3 for <aqm@ietf.org>; Sun, 01 Mar 2015 19:57:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=zD7xRnvOs947C+rzc57VQTQ5DAFf/LAb+lrlrW7POxM=; b=OUJaetAQAnWZIa+cmfQ64Sla46rw2xbr5/QkDQsjiY48J73nPfiHYcL1p5ExMV/AyO 1OVwENhQMzUH9sGR2ppT0Lcbzab+d3L5npyMrrena/zt9L0UaxiwxC7JCSq//vdnneqp Lm2wU1YSZCfV2Qkz0r7mZnLC1IyX7mYHqWcYeAhxmpYFaxm0zL/0955gtZyDw4vdWV4k M3NaorCD6zW/z5B2rB93TDlVWRGodmd2PjjcKXXKzLGSdNuETEZcykvSMzc8V/nFQo+j HswQ6JlD7EtGeZFSr+92ZJ9Ht2aQiLRhAbzMyXC5yzmc6E8Ge+8Je/5dXdJsjMwlNHfB cA3Q==
MIME-Version: 1.0
X-Received: by with SMTP id v3mr16792561oik.133.1425268657046; Sun, 01 Mar 2015 19:57:37 -0800 (PST)
Received: by with HTTP; Sun, 1 Mar 2015 19:57:37 -0800 (PST)
Date: Sun, 01 Mar 2015 19:57:37 -0800
Message-ID: <CAA93jw7KW=9PH002d3Via5ks6+mHScz5VDhpPVqLUGK2K=Mhew@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>, "aqm@ietf.org" <aqm@ietf.org>, bloat <bloat@lists.bufferbloat.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/ueOVRnLBxjdfksMBu0DgWLAOpsk>
Subject: [aqm] ping loss "considered harmful"
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2015 03:57:39 -0000

On this thread over here, an otherwise pretty clueful user chose
openwrt's qos-scripts over the sqm-scripts, because sqm-scripts had
*higher ping loss*.


(I note that both fq_codel enabled QoS systems outperformed
streamboost by a lot, which I am happy about)

wow. It never registered to me that users might make a value judgement
based on the amount of ping loss, and in looking back in time, I can
think of multiple people that have said things based on their
perception that losing pings was bad, and that sqm-scripts was "worse
than something else because of it."

sqm-scripts explicitly *deprioritizes* ping. In particular, this
reduces the impact of ping floods from ipv6 to your entire /64, or to
your whole ipv4, fairly well. And I had made the point that
prioritizing ping was a bad idea here (including some dripping sarcasm
later in the piece).


but wow, it never occurred to me - in all these years - that ping was
the next core metric on simple tests. I can be really dumb.

I use netperf-wrapper and tend to ignore most of the ping data, but
certainly on some benchmarks we have published ping doesn't look as
good as the other stuff, *because it is deprioritized below all the
other traffic*. Not strictly rate limited - as some systems do by
default, including openwrt, which is impossible to get right - just

How can we fix this user perception, short of re-prioritizing ping in

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