Re: [aqm] ping loss "considered harmful"

Brian Trammell <> Mon, 02 March 2015 09:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A0F81A700D for <>; Mon, 2 Mar 2015 01:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oih_mJyaFFCc for <>; Mon, 2 Mar 2015 01:40:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1380D1A00B6 for <>; Mon, 2 Mar 2015 01:40:39 -0800 (PST)
Received: from [IPv6:2001:470:26:9c2:4c1d:7ca:1e7c:fd3e] (unknown [IPv6:2001:470:26:9c2:4c1d:7ca:1e7c:fd3e]) by (Postfix) with ESMTPSA id C99651A0032; Mon, 2 Mar 2015 10:40:37 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3E135866-8FAD-495E-A96D-97394FFC0271"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b5
From: Brian Trammell <>
In-Reply-To: <>
Date: Mon, 02 Mar 2015 10:40:37 +0100
Message-Id: <>
References: <>
To: Dave Taht <>
X-Mailer: Apple Mail (2.2070.6)
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 09:40:42 -0000

hi Dave,

> On 02 Mar 2015, at 04:57, Dave Taht <> wrote:
> 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 am not proud of the fact that I am not surprised by this.

> How can we fix this user perception, short of re-prioritizing ping in
> sqm-scripts?

The real solution is to create a utility called "ping" that uses traffic that gets prioritized the same way as the traffic you care about instead of ICMP echo request/reply. Users don't care about the packets on the wire so much as they do that you're supposed to ping things.

We have a protocol for this <ippm-chair-hat> called TWAMP </ippm-chair-hat> which shares the unfortunate property with all such approaches that it requires the far end to be running a reflector (the advantage of ICMP is the reflector is built into the kernel everywhere) or worse a control protocol for setting reflectors up.

Gaming protocols do this right - latency measurement is built into the protocol. For the web we already have tools and reasonably well accepted metrics (time to first byte). Wrap $YOUR_FAVORITE_BROWSER's perftools in a ping -w <url> utility and this problem goes away in that space. I presume that rtcweb clients in the browser will take advantage of these tools and provide measurements the same way games do.

Andrew's hack is probably easier to actually get deployed in a reasonable amount of time though. :)



> --
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
> _______________________________________________
> aqm mailing list