> On Mar 3, 2015, at 9:29 AM, Wesley Eddy <w...@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.t...@gmail.com >>> <mailto:dave.t...@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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat