I'm rather new to the aqm community, but IMHO, it is wrong to deprioritize the ping traffic by default. I would not have expected a forwarding agent to do this.
And I think measuring ping times and loss is a reasonable thing to do, never expecting forwarding agents along the path to place more value on some IP packets than others. (Especially in my own network/lab when I did not configure such a policy) There aren't many tools available to an end user. Ping, traceroute, speed test... The network is a black box to most users. As for the flood attack aspect, of course a flood of pings should wait their turn in a queue and be dropped as the queue fills. It would be appropriate if this was fair to different ping flows in the same way TCP SYN packets are treated fairly. Treat ping flood like TCP SYN flood. My 2cents. -Dave Dolson ----- Original Message ----- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Sunday, March 01, 2015 10:57 PM To: cerowrt-devel@lists.bufferbloat.net <cerowrt-devel@lists.bufferbloat.net>; a...@ietf.org <a...@ietf.org>; bloat <bl...@lists.bufferbloat.net> Subject: [aqm] ping loss "considered harmful" On this thread over here, an otherwise pretty clueful user chose openwrt's qos-scripts over the sqm-scripts, because sqm-scripts had *higher ping loss*. http://forums.dlink.com/index.php?topic=61634.msg251125#msg251125 (I note that both fq_codel enabled QoS systems outperformed streamboost by a lot, which I am happy about) wow. It never registered to me that users might make a value judgement based on the amount of ping loss, and in looking back in time, I can think of multiple people that have said things based on their perception that losing pings was bad, and that sqm-scripts was "worse than something else because of it." sqm-scripts explicitly *deprioritizes* ping. In particular, this reduces the impact of ping floods from ipv6 to your entire /64, or to your whole ipv4, fairly well. And I had made the point that prioritizing ping was a bad idea here (including some dripping sarcasm later in the piece). http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die but wow, it never occurred to me - in all these years - that ping was the next core metric on simple tests. I can be really dumb. I use netperf-wrapper and tend to ignore most of the ping data, but certainly on some benchmarks we have published ping doesn't look as good as the other stuff, *because it is deprioritized below all the other traffic*. Not strictly rate limited - as some systems do by default, including openwrt, which is impossible to get right - just deprioritized.... How can we fix this user perception, short of re-prioritizing ping in sqm-scripts? -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ aqm mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
