Re: [aqm] [Bloat] ping loss "considered harmful"

Dave Taht <dave.taht@gmail.com> Wed, 04 March 2015 05:25 UTC

Return-Path: <dave.taht@gmail.com>
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 7C6E11A038C for <aqm@ietfa.amsl.com>; Tue, 3 Mar 2015 21:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 ADCC2F8yh86e for <aqm@ietfa.amsl.com>; Tue, 3 Mar 2015 21:25:45 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D8B1A0387 for <aqm@ietf.org>; Tue, 3 Mar 2015 21:25:45 -0800 (PST)
Received: by obcva2 with SMTP id va2so4675325obc.6 for <aqm@ietf.org>; Tue, 03 Mar 2015 21:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cfMjDhDusw3t9D1PGDxFm2tkEWvRuoF2WXSU6lieigk=; b=b89rCOMDlQjfvSoe16wvngdw8eoPqbjcU1BeADQIHUt6+ctelhj6fwVczhJjf2Vcaw BqEt+g62z5QbaEtA2WrnAfEWS842WxRTlUd2n0e84c6243G9Lu2QL73xCQ3K2NBlrYM6 hWVMLPlUvcdRTKpe0sVhwxYSaMxPW5QLEOnc+PiWkpTwb4SNgCG0o11IhSnwaWRqj2Ym tvXu1sE2c8IDb5TdOJejZaUpeuOxB8zlc/tIYxcgB/yeoafhPJCDMHxyim1KqYYTdICt UJ3NAq7YcrJJMuLnPLB/7P6HZHQVgFPFvZ7Kl4AxzFAqtGyZj41n3c3q6sYykXmPkXPA BG0A==
MIME-Version: 1.0
X-Received: by 10.202.62.70 with SMTP id l67mr1613480oia.59.1425446700031; Tue, 03 Mar 2015 21:25:00 -0800 (PST)
Received: by 10.202.51.66 with HTTP; Tue, 3 Mar 2015 21:24:59 -0800 (PST)
In-Reply-To: <E44C11DD-68F9-4340-8F99-18D2894FE36B@cisco.com>
References: <CAA93jw7KW=9PH002d3Via5ks6+mHScz5VDhpPVqLUGK2K=Mhew@mail.gmail.com> <F2745259-5DEB-49B1-AB7C-C8E4E1217360@cisco.com> <54F5EF7B.4000006@mti-systems.com> <E44C11DD-68F9-4340-8F99-18D2894FE36B@cisco.com>
Date: Tue, 3 Mar 2015 21:24:59 -0800
Message-ID: <CAA93jw4F7iffbTRUt5RFsF0wgoOAXPUVHdu7JESVq4uM17cm7A@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/wnUQ0Civer7ykZG8RiVv7djcXyI>
Cc: Wesley Eddy <wes@mti-systems.com>, "aqm@ietf.org" <aqm@ietf.org>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [aqm] [Bloat] 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: Wed, 04 Mar 2015 05:25:47 -0000

On Tue, Mar 3, 2015 at 10:00 AM, Fred Baker (fred) <fred@cisco.com> wrote:
>
>> On Mar 3, 2015, at 9:29 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>>
>> On 3/3/2015 12:20 PM, Fred Baker (fred) wrote:
>>>
>>>> On Mar 1, 2015, at 7:57 PM, Dave Taht <dave.taht@gmail.com
>>>> <mailto:dave.taht@gmail.com>> wrote:
>>>>
>>>> How can we fix this user perception, short of re-prioritizing ping in
>>>> sqm-scripts?
>>>
>>> IMHO, ping should go at the same priority as general traffic - the
>>> default class, DSCP=0. When I send one, I am asking whether a random
>>> packet can get to a given address and get a response back. I can imagine
>>> having a command-line parameter to set the DSCP to another value of my
>>> choosing.
>>
>> I generally agree, however ...
>>
>> The DSCP of the response isn't controllable though, and likely the DSCP
>> that is ultimately received will not be the one that was sent, so it
>> can't be as simple as echoing back the same one.  Ping doesn't tell you
>> latency components in the forward or return path (some other protocols
>> can do this though).
>>
>> So, setting the DSCP on the outgoing request may not be all that useful,
>> depending on what the measurement is really for.
>
> Note that I didn’t say “I demand”… :-)

My point was A), I have seen tons of shapers out there that actually
prioritize ping over other traffic. I figure everyone here will agree
that is a terrible practice, but I can certainly say it exists, as it
is a dumb mistake replicated in tons of shapers I have seen... that
makes people in marketing happy.

Already put up extensive commentary on that bit of foolishness on
"wondershaper must die".

Please feel free to review any shapers or firewall code you might have
access to for the same sort of BS and/or post the code somewhere for
public review. A BCP for these two things would be nice.

And B) Deprioritizing ping (slightly) as I do came from what has
happened to me multiple times when hit by a bot that ping floods the
network. One time, 30+ virtual windows boxes in a lab got infected by
something that went nuts pinging the entire 10/8 network we were on.
It actually DID melt the switch - and merely getting to isolating that
network off from the rest was a PITA, as getting to the (SFQ-ing)
router involved was nearly impossible via ssh. (like, 2 minutes
between keystrokes).

Thus, ping, deprioritized. I tend to feel deprioritizing it slightly
is much more important in the post ipv6 world.


> I share the perception that ping is useful when it’s useful, and that it is at best an approximation. If I can get a packet to the destination and a response back, and I know the time I sent it and the time I received the response, I know exactly that - messages went out and back and took some amount of total time. I don’t know anything about the specifics of the path, of buffers en route, or delay time in the target. Traceroute tells me a little more, at the cost of a more intense process. In places I use ping, I tend to send a number of them over a period of time and observe on the statistics that result, not a single ping result.



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb