From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D1C2F21F39F for ; Wed, 4 Mar 2015 09:34:43 -0800 (PST) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 26031380662; Wed, 4 Mar 2015 12:34:42 -0500 (EST) Received: from app12.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E4E493805F7; Wed, 4 Mar 2015 12:34:41 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app12.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Wed, 04 Mar 2015 17:34:42 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app12.wa-webapps.iad3a (Postfix) with ESMTP id CE415380045; Wed, 4 Mar 2015 12:34:41 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 4 Mar 2015 12:34:41 -0500 (EST) Date: Wed, 4 Mar 2015 12:34:41 -0500 (EST) From: dpreed@reed.com To: "=?utf-8?Q?Fred_Baker_=28fred=29?=" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <54F5EF7B.4000006@mti-systems.com> X-Auth-ID: dpreed@reed.com Message-ID: <1425490481.842932044@apps.rackspace.com> X-Mailer: webmail/11.3.13-RC Cc: Wesley Eddy , "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [aqm] [Bloat] ping loss "considered harmful" X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:35:12 -0000 It's a heavy burden to place on ICMP ping to say that it should tell you ab= out all aspects of its path through all the networks between source and des= tination.=0A=0AOn the other hand, I'll suggest that Fred's point - treat IC= MP Ping like any other IP datagram with the same header options is the esse= nce of Ping's function.=0A=0AI'd suggest that a more flexible rule would be= for the echo reply to set header options (including DSCP) based on the pin= g packet's content tells it to be set to.=0A=0ADSCP should not be changed e= n route, so the receiver of the echo reply should be able to know what DSCP= was used on the reply packet.=0A=0AClearly the value of Ping is its standa= rdized form and its ubiquity. Being able to control all header options fro= m the sender is useful for that function. If the receiver cannot satisfy t= he 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 com= patible if not supported.=0A=0A(I specifically talk about all header option= s 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 be= cause I think the code points are poorly defined and so forth, but that's i= rrelevant to the thinking about Ping vs. "envelope" option - fully end-to-e= nd 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 i= nto the Ping conceptual framework).=0A=0A=0A=0A=0AOn Tuesday, March 3, 2015= 1:00pm, "Fred Baker (fred)" said:=0A=0A> ________________= _______________________________=0A> Cerowrt-devel mailing list=0A> Cerowrt-= devel@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cero= wrt-devel=0A> =0A>> On Mar 3, 2015, at 9:29 AM, Wesley Eddy wrote:=0A>>=0A>> On 3/3/2015 12:20 PM, Fred Baker (fred) wrote:=0A>>= >=0A>>>> On Mar 1, 2015, at 7:57 PM, Dave Taht >>> = > wrote:=0A>>>>=0A>>>> How can we fix this user= perception, short of re-prioritizing ping in=0A>>>> sqm-scripts?=0A>>>=0A>= >> IMHO, ping should go at the same priority as general traffic - the=0A>>>= default class, DSCP=3D0. When I send one, I am asking whether a random=0A>= >> packet can get to a given address and get a response back. I can imagine= =0A>>> having a command-line parameter to set the DSCP to another value of = my=0A>>> choosing.=0A>>=0A>> I generally agree, however ...=0A>>=0A>> The D= SCP of the response isn't controllable though, and likely the DSCP=0A>> tha= t is ultimately received will not be the one that was sent, so it=0A>> can'= t be as simple as echoing back the same one. Ping doesn't tell you=0A>> la= tency components in the forward or return path (some other protocols=0A>> c= an do this though).=0A>>=0A>> So, setting the DSCP on the outgoing request = may not be all that useful,=0A>> depending on what the measurement is reall= y for.=0A> =0A> Note that I didn=E2=80=99t say =E2=80=9CI demand=E2=80=9D= =E2=80=A6 :-)=0A> =0A> I share the perception that ping is useful when it= =E2=80=99s useful, and that it is=0A> at best an approximation. If I can ge= t a packet to the destination and a response=0A> back, and I know the time = I sent it and the time I received the response, I know=0A> exactly that - m= essages went out and back and took some amount of total time. I=0A> don=E2= =80=99t know anything about the specifics of the path, of buffers en route,= or=0A> delay time in the target. Traceroute tells me a little more, at the= cost of a more=0A> intense process. In places I use ping, I tend to send a= number of them over a=0A> period of time and observe on the statistics tha= t result, not a single ping=0A> result.=0A> =0A