From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (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 A5BC121F28B for ; Mon, 2 Mar 2015 02:49:23 -0800 (PST) Received: by qcrw7 with SMTP id w7so23616122qcr.4 for ; Mon, 02 Mar 2015 02:49:22 -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=OtxL2AWI1gj9NeZE9x6cdx50DTiwgqaXK80ix60wD0s=; b=ixxNDdN8CfaKTigLk4bOcvPV1Xcz95ZLcTIBjVYSf3p6apn6UNT0IVDz9E6Jm6YaZx 4GHzXBWNxGiWVw+Nk41iRnZZQCiSeDtP+Eoizkh+VUOoHJvuNoE2s5Ucfhc3HtmQJrdt FawUwZpcFdee6Xsx/56p2bkoUZnIHvgXVaB9b+wAxKM9tMluAFEbXD8qE9+HGM6fA2c0 HODkiKN2k30sb81/dq5ap+bhpKzUU+AKMUk5LYr37cC8GHEhOyA9YtVZZrcUDFaM2wKI 2MZPIZCt6pLA95nQW+lnlsNZ9vwvBWZS8rw2TULNtEJkQ/mbk2+oB4+Ku7CAgUxKAekP 5UqQ== 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=OtxL2AWI1gj9NeZE9x6cdx50DTiwgqaXK80ix60wD0s=; b=gvJ6bb8Q4owfJVUhsguzvYMwzrK2bIFZCdjK4iouiYLQCHe/XsFKd8/Vy0vgHo1d12 zn+O9BTuEQvY3d2WqwRTMWQ5thgGbymkm1vjFYD1PGjiydIaIRP+QWOh9im3630uwBje AkKBA9FwAAd8HjLqOGF6myWUdV/Fx9xaqfQDVddTKPxyk9THHTbJKQu+L56nHcKly+Xa uI/nhUrZYvMJJIrscUDJptHLHnd/4rOJiAvZocI6hXSeLiX9frIMemZcHLtisUWEeS7C hodmddjkFIs5TAiAs4IczC3n7S073VFybynpAAPeCc9dZTG6bCT5D1KeFO4ShCES/uo+ muLw== X-Gm-Message-State: ALoCoQkBSwfA/Oo3uO/JT5gncMJaVZLs3e/ZVEzvVIKG0bvpASM4v3a/KcE72xCb+6g1SLHAOgv0 MIME-Version: 1.0 X-Received: by 10.229.251.137 with SMTP id ms9mr284031qcb.22.1425293362135; Mon, 02 Mar 2015 02:49:22 -0800 (PST) Received: by 10.96.68.74 with HTTP; Mon, 2 Mar 2015 02:49:22 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 21:49:22 +1100 Message-ID: From: Andrew Mcgregor To: Dave Dolson Content-Type: multipart/alternative; boundary=001a11348e188d27d705104bf8f5 Cc: Jana Iyengar , "bloat@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , "aqm@ietf.org" 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 10:49:52 -0000 --001a11348e188d27d705104bf8f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, are you suggesting that, for example, Chrome's rather extensive network debugging information get more publicised? We can probably arrange that. On 2 March 2015 at 21:47, Dave Dolson wrote: > I'm rather new to the aqm community, but IMHO, it is wrong to deprioritiz= e > 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 SY= N > flood. > > My 2cents. > -Dave Dolson > > > > ----- Original Message ----- > From: Dave Taht [mailto:dave.taht@gmail.com] > Sent: Sunday, March 01, 2015 10:57 PM > To: cerowrt-devel@lists.bufferbloat.net < > cerowrt-devel@lists.bufferbloat.net>; aqm@ietf.org ; bloat = < > bloat@lists.bufferbloat.net> > 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*. > > > 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 > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a11348e188d27d705104bf8f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, are you suggesting that, for example, Chrome's rat= her extensive network debugging information get more publicised?=C2=A0 We c= an probably arrange that.

On 2 March 2015 at 21:47, Dave Dolson <<= a href=3D"mailto:ddolson@sandvine.com" target=3D"_blank">ddolson@sandvine.c= om> wrote:
I'm rather n= ew to the aqm community, but IMHO, it is wrong to deprioritize the ping tra= ffic 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, neve= r 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 conf= igure such a policy)

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

As for the flood attack aspect, of course a flood of pings should wait thei= r 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 sam= e way TCP SYN packets are treated fairly. Treat ping flood like TCP SYN flo= od.

My 2cents.
-Dave Dolson



----- Original Message -----
From: Dave Taht [mailto:dave.taht@gm= ail.com]
Sent: Sunday, March 01, 2015 10:57 PM
To: cerowrt-devel@li= sts.bufferbloat.net <cerowrt-devel@lists.bufferbloat.net>; aqm@ietf.org <aqm@ietf.org= >; bloat <bloat@li= sts.bufferbloat.net>
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*.


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

_______________________________________________
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
--001a11348e188d27d705104bf8f5--