From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003: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 7D28A21F283; Tue, 3 Mar 2015 21:25:00 -0800 (PST) Received: by obbnt9 with SMTP id nt9so4672386obb.13; 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: References: <54F5EF7B.4000006@mti-systems.com> Date: Tue, 3 Mar 2015 21:24:59 -0800 Message-ID: From: Dave Taht To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Wesley Eddy , "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [aqm] [Bloat] 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: Wed, 04 Mar 2015 05:25:29 -0000 On Tue, Mar 3, 2015 at 10:00 AM, Fred Baker (fred) wrote: > >> On Mar 3, 2015, at 9:29 AM, Wesley Eddy wrote: >> >> On 3/3/2015 12:20 PM, Fred Baker (fred) wrote: >>> >>>> On Mar 1, 2015, at 7:57 PM, Dave Taht >>> > 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=3D0. When I send one, I am asking whether a random >>> packet can get to a given address and get a response back. I can imagin= e >>> 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=E2=80=99t say =E2=80=9CI demand=E2=80=9D=E2=80=A6 :-) 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=E2=80=99s useful, and = that it is at best an approximation. If I can get a packet to the destinati= on and a response back, and I know the time I sent it and the time I receiv= ed the response, I know exactly that - messages went out and back and took = some amount of total time. I don=E2=80=99t know anything about the specific= s 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 observ= e on the statistics that result, not a single ping result. --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb