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

[Dave Taht <dave.taht@gmail.com>]

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