Re: [Cerowrt-devel] [Bloat] [aqm] ping loss considered harmful
On Mar 5, 2015, at 1:56 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: 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... For an easy (but imprecise) way test the HTTP response times, try Blip - http://gfblip.appspot.com/ (or read about it on github: https://github.com/apenwarr/blip) Blip sends short http requests to a couple hosts and measures the response time of the error pages. 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 ___ Bloat mailing list bl...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat 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] [Bloat] [aqm] ping loss considered harmful
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. -- Wes Eddy MTI Systems ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] [aqm] ping loss considered harmful
On 02 Mar 2015, at 11:54, Jonathan Morton chromati...@gmail.com wrote: On 2 Mar, 2015, at 12:17, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 2 Mar 2015, Brian Trammell wrote: Gaming protocols do this right - latency measurement is built into the protocol. I believe this is the only way to do it properly, and the most likely easiest way to get this deployed would be to use the TCP stack. We need to give users an easy-to-understand metric on how well their Internet traffic is working. So the problem here is that the users can't tell how well it's working without resorting to ICMP PING to try to figure out what's going on. For instance, if their web browser had insight into what the TCP stack was doing then it could present information a lot better to the user. Instead of telling the user time to first byte (which is L4 information), it could tell the less novice user about packet loss, PDV, reordering, RTT, how well concurrent connections to the same IP address are doing, tell more about *why* some connections are slow instead of just saying it took 5.3 seconds to load this webpage and here are the connections and how long each took. For the novice user there should be some kind of expert system that collects data that you can send to the ISP that also has an expert system to say it seems your local connection delays packets, please connect to a wired connection and try again. It would know if the problem was excessive delay, excessive delay that varied a lot, packet loss, reordering, or whatever. We have a huge amount of information in our TCP stacks that either are locked in there and not used properly to help users figure out what's going on, and there is basically zero information flow between the applications using TCP and the TCP stack itself. Each just tries to do its best on its own layer. This seems like an actually good idea. Several of those statistics, at least, could be exposed to userspace without incurring any additional overhead in the stack (except for the queries themselves), which is important for high-performance server users. TCP stacks already track RTT, and sometimes MinRTT - the difference between these values is a reasonable lower-bound estimate of induced latency. For stacks which don’t already track all the desirable data, a socket option could be used to turn that on, allocating extra space to do so. To maximise portability, therefore, it might be necessary to require that option before statistics requests will be valid, even on stacks which do collect it all anyway. So there seem to me to be three separate but related problems we want to solve here: (1) How to get users who don't care what ping is useful information about their applications' network performance. (2) How to get users who do care what ping is information that actually reflects application performance when they type ping (or, more generally, how to make sure that the common diagnostic tools neither (a) provide misleading information or (b) require network misconfiguration to ensure proper operation of the diagnostic tools (cf. speedtest.net and its ilk). (3) How to get application developers tools they can use to integrate network measurement into their apps without having to roll their own (i.e., helping them to solve (1), and enabling the creation of tools for (2) ). This is an approach to (3)... but (as with many things) the key to getting it deployed and used on endpoints would be defining a universal interface to it. Yet another API to learn on every platform == I'm just going to use ping, thank you very much. Recent versions of Windows, even, have a semi-magic system which gives a little indicator of whether your connection has functioning Internet connectivity or not. This could be extended, if Microsoft saw fit, to interpret these statistics and notify the user that their connection was behaving badly in the ways we now find interesting. Whether Microsoft will do such a thing (which would undoubtedly piss off every major ISP on the planet) is another matter, but it’s a concept that can be used by Linux desktops as well, and with less political fallout. This is, I'm afraid, the kicker. As long as everyone has an interest in pointing the finger at everyone else, people will choose to interpret the metrics how they like, and fail to respond to metrics they don't, no matter how good they are. Now, who’s going to knuckle down and implement it? web10g.org is a start, for Linux anyway. Cheers, Brian 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] [Bloat] [aqm] ping loss considered harmful
On 2 Mar, 2015, at 12:17, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 2 Mar 2015, Brian Trammell wrote: Gaming protocols do this right - latency measurement is built into the protocol. I believe this is the only way to do it properly, and the most likely easiest way to get this deployed would be to use the TCP stack. We need to give users an easy-to-understand metric on how well their Internet traffic is working. So the problem here is that the users can't tell how well it's working without resorting to ICMP PING to try to figure out what's going on. For instance, if their web browser had insight into what the TCP stack was doing then it could present information a lot better to the user. Instead of telling the user time to first byte (which is L4 information), it could tell the less novice user about packet loss, PDV, reordering, RTT, how well concurrent connections to the same IP address are doing, tell more about *why* some connections are slow instead of just saying it took 5.3 seconds to load this webpage and here are the connections and how long each took. For the novice user there should be some kind of expert system that collects data that you can send to the ISP that also has an expert system to say it seems your local connection delays packets, please connect to a wired connection and try again. It would know if the problem was excessive delay, excessive delay that varied a lot, packet loss, reordering, or whatever. We have a huge amount of information in our TCP stacks that either are locked in there and not used properly to help users figure out what's going on, and there is basically zero information flow between the applications using TCP and the TCP stack itself. Each just tries to do its best on its own layer. This seems like an actually good idea. Several of those statistics, at least, could be exposed to userspace without incurring any additional overhead in the stack (except for the queries themselves), which is important for high-performance server users. TCP stacks already track RTT, and sometimes MinRTT - the difference between these values is a reasonable lower-bound estimate of induced latency. For stacks which don’t already track all the desirable data, a socket option could be used to turn that on, allocating extra space to do so. To maximise portability, therefore, it might be necessary to require that option before statistics requests will be valid, even on stacks which do collect it all anyway. Recent versions of Windows, even, have a semi-magic system which gives a little indicator of whether your connection has functioning Internet connectivity or not. This could be extended, if Microsoft saw fit, to interpret these statistics and notify the user that their connection was behaving badly in the ways we now find interesting. Whether Microsoft will do such a thing (which would undoubtedly piss off every major ISP on the planet) is another matter, but it’s a concept that can be used by Linux desktops as well, and with less political fallout. Now, who’s going to knuckle down and implement it? - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] [aqm] ping loss considered harmful
On Mon, 2 Mar 2015 15:45:10 +0100, Brian Trammell wrote: On 02 Mar 2015, at 11:54, Jonathan Morton chromati...@gmail.com wrote: On 2 Mar, 2015, at 12:17, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 2 Mar 2015, Brian Trammell wrote: Gaming protocols do this right - latency measurement is built into the protocol. I believe this is the only way to do it properly, and the most likely easiest way to get this deployed would be to use the TCP stack. We need to give users an easy-to-understand metric on how well their Internet traffic is working. So the problem here is that the users can't tell how well it's working without resorting to ICMP PING to try to figure out what's going on. For instance, if their web browser had insight into what the TCP stack was doing then it could present information a lot better to the user. Instead of telling the user time to first byte (which is L4 information), it could tell the less novice user about packet loss, PDV, reordering, RTT, how well concurrent connections to the same IP address are doing, tell more about *why* some connections are slow instead of just saying it took 5.3 seconds to load this webpage and here are the connections and how long each took. For the novice user there should be some kind of expert system that collects data that you can send to the ISP that also has an expert system to say it seems your local connection delays packets, please connect to a wired connection and try again. It would know if the problem was excessive delay, excessive delay that varied a lot, packet loss, reordering, or whatever. There is hping3 that lets you do 'ping' and 'traceroute' on TCP and UDP to any port (with different flags set if needed). Unfortunantly many people are not familiar with it. I've also run into problems that the stock build doesn't work right if you have too many interfaces (IIRC I ran into problems around 8 interfaces, but since I was working with firewalls that had up to 22 interfaces in use, I could be off by quite a bit on that number) David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
