From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CF07C21F24E for ; Sun, 1 Mar 2015 20:00:41 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id e89so22952426qgf.9 for ; Sun, 01 Mar 2015 20:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qjP4S3HlCoNev526H1QuQT9gCAkHY3GNu/gyUYdLghM=; b=A4JHqQNn/8z7YTq54xDWegqV090N2xMx7nS309Gw7/Yu8/Nav1fNfcMjNoVhtGfKqv kwecluUiNlb1h3lknG10Yd9AK/dNJMw6ZkrfM+ValWGhNHlyuHMsOx7OJfBf6f9QOfVa RGBrMrKDYC+kvL8dG8fRpO2GHCZSv+h29geXjKy5I90R4C6RUC8pILvD4LQ1okYJ1n0b YC5gipgCg4o2f553fmYjkIpsVZ2OIShiBiD83C+gy58azXaai5+i5L5OZNQnUbVAEf+N 8tAUo/+odEH2/49BIWFoKJfvCKN1dct36MVBQ7QMynhmVCBXB3Gx2IgApLMFu79LwbgB 65Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qjP4S3HlCoNev526H1QuQT9gCAkHY3GNu/gyUYdLghM=; b=c2rQdNY7uPIDIoftAsRlvNsUvfAJ1wgkgYr/bzPSOHLKW1IhE57Dr7vcXqAr6u5dcK 1P+GH5H1lPBsj53QF9xDWKnNw3EZBrJxtrVovvOPoIu6FxOIjwF1N9bMOnVCMW6MhYqI zZf9Sbye9+CDCIIAFBeK2pBMKLv/sDc3YBvksYO67ALV21OhjWk7ZnTVMtwbKOa2UEXr zSObPhGJjOv5flqROo1baDvaBtg3zVElVdmGtqt74rBcXVpKoJ1NV/grKohTQOC+TZCJ XBkhRJOL0TLDjbpau6S/1INhkXT44oXHgluF8WREPRVZAWc8301L6x2Jq+avaj34rPjn 6u7Q== X-Gm-Message-State: ALoCoQmMe/jQT+I25bXBV8m6nbAIYRpAdYVGiEW8nY6EdN+NE+2tlbr3WJLN+km1cw0kYatelTY0 MIME-Version: 1.0 X-Received: by 10.140.51.107 with SMTP id t98mr45504248qga.63.1425268840451; Sun, 01 Mar 2015 20:00:40 -0800 (PST) Received: by 10.96.68.74 with HTTP; Sun, 1 Mar 2015 20:00:40 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 15:00:40 +1100 Message-ID: From: Andrew Mcgregor To: Dave Taht Content-Type: multipart/alternative; boundary=001a1135244ef1ffc6051046420b X-Mailman-Approved-At: Sun, 01 Mar 2015 20:02:57 -0800 Cc: "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [aqm] ping loss "considered harmful" X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 04:01:10 -0000 --001a1135244ef1ffc6051046420b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hash all pings into one fq_codel bucket reserved for the purpose, so if we're getting DoSed we drop them, otherwise if they stay thin they get prioritised? On 2 March 2015 at 14: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*. > > > http://forums.dlink.com/index.php?topic=3D61634.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." > > 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=C3=A4ht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a1135244ef1ffc6051046420b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hash all pings into one fq_codel bucket reserved for the p= urpose, so if we're getting DoSed we drop them, otherwise if they stay = thin they get prioritised?

On 2 March 2015 at 14:57, Dave Taht <= dave.taht@gmail.co= m> wrote:
On this thread ov= er 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=3D61634.msg2= 51125#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<= br> 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).

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=C3=A4ht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/po= sts/TVX3o84jjmb

_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm



--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a1135244ef1ffc6051046420b--