[Bloat] [aqm] ping loss "considered harmful"
Fred Baker (fred)
fred at cisco.com
Tue Mar 3 13:00:14 EST 2015
> On Mar 3, 2015, at 9:29 AM, Wesley Eddy <wes at 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 at gmail.com
>>> <mailto:dave.taht at gmail.com>> wrote:
>>> How can we fix this user perception, short of re-prioritizing ping in
>> 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
> 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”… :-)
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Bloat