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

[dpreed@reed.com]

It's a heavy burden to place on ICMP ping to say that it should tell you about all aspects of its path through all the networks between source and destination.

On the other hand, I'll suggest that Fred's point - treat ICMP Ping like any other IP datagram with the same header options is the essence of Ping's function.

I'd suggest that a more flexible rule would be for the echo reply to set header options (including DSCP) based on the ping packet's content tells it to be set to.

DSCP should not be changed en route, so the receiver of the echo reply should be able to know what DSCP was used on the reply packet.

Clearly the value of Ping is its standardized form and its ubiquity.  Being able to control all header options from the sender is useful for that function.  If the receiver cannot satisfy the request (e.g. it doesn't support the DSCP mechanism), it can just refuse to set it. That way, Ping acquires an option, but the option is upward compatible if not supported.

(I specifically talk about all header options here, rather than DSCP in particular.  For example, one could request ECN marking in the same way, with the same rules. I'm not a big fan of DSCP because I think the code points are poorly defined and so forth, but that's irrelevant to the thinking about Ping vs. "envelope" option - fully end-to-end modular services like ECN clearly should be testable in this way, and in the case of ECN, the notion of just not doing it if you can't do it fits into the Ping conceptual framework).




On Tuesday, March 3, 2015 1:00pm, "Fred Baker (fred)" <fred@cisco.com> said:

> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
>> 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”… :-)
> 
> 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.
>