Re: [aqm] ping loss "considered harmful"

Dave Dolson <> Mon, 02 March 2015 10:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A55F91A86F3 for <>; Mon, 2 Mar 2015 02:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UhCU0abd-9bz for <>; Mon, 2 Mar 2015 02:47:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CDE931A86F7 for <>; Mon, 2 Mar 2015 02:47:09 -0800 (PST)
Received: from ([fe80::68ac:f071:19ff:3455]) by ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Mon, 2 Mar 2015 05:47:09 -0500
From: Dave Dolson <>
To: "''" <>, "''" <>, "''" <>, "''" <>
Thread-Topic: [aqm] ping loss "considered harmful"
Thread-Index: AQHQVJ0J+9InyssQxUGw8Kj3YWubiJ0JAzt7
Date: Mon, 02 Mar 2015 10:47:07 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
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 10:47:11 -0000

I'm rather new to the aqm community, but IMHO, it is wrong to deprioritize the ping traffic by default. I would not have expected a forwarding agent to do this. 

And I think measuring ping times and loss is a reasonable thing to do, never expecting forwarding agents along the path to place more value on some IP packets than others. (Especially in my own network/lab when I did not configure such a policy)

There aren't many tools available to an end user. Ping, traceroute, speed test... The network is a black box to most users. 

As for the flood attack aspect, of course a flood of pings should wait their turn in a queue and be dropped as the queue fills.

It would be appropriate if this was fair to different ping flows in the same way TCP SYN packets are treated fairly. Treat ping flood like TCP SYN flood.  

My 2cents. 
-Dave Dolson

----- Original Message -----
From: Dave Taht []
Sent: Sunday, March 01, 2015 10:57 PM
To: <>; <>; bloat <>
Subject: [aqm] ping loss "considered harmful"

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!

aqm mailing list