[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
>>> 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”… :-)

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...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150303/6b3de253/attachment-0001.sig>


More information about the Bloat mailing list