Re: [Cerowrt-devel] [aqm] [Bloat] ping loss considered harmful
In message caa93jw4f7iffbtrut5rfsf0wgooaxpuvhdu7jesvq4um17c...@mail.gmail.com Dave Taht writes: My point was A), I have seen tons of shapers out there that actually prioritize ping over other traffic. I figure everyone here will agree that is a terrible practice, but I can certainly say it exists, as it is a dumb mistake replicated in tons of shapers I have seen... that makes people in marketing happy. Already put up extensive commentary on that bit of foolishness on wondershaper must die. Its possible to detect such a shaper prioritizing ICMP echo/reply by doing a an HTTP fetch concurrent with a ping and then and see if the TCP data packet get significantly delayed relative to the ICMP echo and echo reply packets. You'd have to do a tcpdump and match the ICMP echo to the echo reply and see if later the ICMP RTT looks very different from the TCP RTT. It might be that the SYN and SYN ACK are not delayed but the plain old TCP date packets are. If anyone has a small amount of spare time and wants to put together a shell script its certainly doable. Curtis ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [aqm] [Bloat] ping loss considered harmful
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) f...@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 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. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [aqm] [Bloat] ping loss considered harmful
On Wed, 4 Mar 2015, dpr...@reed.com wrote: 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. Changing the DSCP bits by the ISP is definitely not unheard of, so don't count on it. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [aqm] [Bloat] ping loss considered harmful
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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [aqm] [Bloat] ping loss considered harmful
On Tue, Mar 3, 2015 at 10:00 AM, Fred Baker (fred) f...@cisco.com wrote: 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”… :-) My point was A), I have seen tons of shapers out there that actually prioritize ping over other traffic. I figure everyone here will agree that is a terrible practice, but I can certainly say it exists, as it is a dumb mistake replicated in tons of shapers I have seen... that makes people in marketing happy. Already put up extensive commentary on that bit of foolishness on wondershaper must die. Please feel free to review any shapers or firewall code you might have access to for the same sort of BS and/or post the code somewhere for public review. A BCP for these two things would be nice. And B) Deprioritizing ping (slightly) as I do came from what has happened to me multiple times when hit by a bot that ping floods the network. One time, 30+ virtual windows boxes in a lab got infected by something that went nuts pinging the entire 10/8 network we were on. It actually DID melt the switch - and merely getting to isolating that network off from the rest was a PITA, as getting to the (SFQ-ing) router involved was nearly impossible via ssh. (like, 2 minutes between keystrokes). Thus, ping, deprioritized. I tend to feel deprioritizing it slightly is much more important in the post ipv6 world. 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. -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
