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

David Lang <david@lang.hm> Mon, 02 March 2015 04:06 UTC

Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BBC1A0056 for <aqm@ietfa.amsl.com>; Sun, 1 Mar 2015 20:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vg4TRw8KUPL for <aqm@ietfa.amsl.com>; Sun, 1 Mar 2015 20:06:49 -0800 (PST)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5813E1A0053 for <aqm@ietf.org>; Sun, 1 Mar 2015 20:06:49 -0800 (PST)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t2246kTk022368; Sun, 1 Mar 2015 20:06:46 -0800
Date: Sun, 01 Mar 2015 20:06:46 -0800
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Dave Taht <dave.taht@gmail.com>
In-Reply-To: <CAA93jw7KW=9PH002d3Via5ks6+mHScz5VDhpPVqLUGK2K=Mhew@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1503012004060.26262@nftneq.ynat.uz>
References: <CAA93jw7KW=9PH002d3Via5ks6+mHScz5VDhpPVqLUGK2K=Mhew@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1289212444-1425269206=:26262"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/pxO4fWvLkBmVpmnWhoWyveSyDT4>
X-Mailman-Approved-At: Sun, 01 Mar 2015 22:52:05 -0800
Cc: "aqm@ietf.org" <aqm@ietf.org>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [aqm] [Cerowrt-devel] 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 04:06:51 -0000

On Sun, 1 Mar 2015, 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*.
>
>
> http://forums.dlink.com/index.php?topic=61634.msg251125#msg251125
>
> (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."

People make the assumption that if ping packets are being dropped, their data is 
getting dropped as well. This is part of the "dropped packets are bad, so buffer 
so you don't drop packets" mentality

To address this, the test results should first show all the stats without 
showing dropped packets, or if you need to show them, add a comment at that 
point that says that data packets are given priority over ping packets, so 
dropped ping packets don't imply that data packets would be dropped.

David Lang


> 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).
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die
>
> 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
> deprioritized....
>
> How can we fix this user perception, short of re-prioritizing ping in
> sqm-scripts?
>
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
>
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel