[Cerowrt-devel] [aqm] ping loss "considered harmful"

[Dave Dolson]

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.taht at gmail.com]
Sent: Sunday, March 01, 2015 10:57 PM
To: cerowrt-devel at lists.bufferbloat.net <cerowrt-devel at lists.bufferbloat.net>; aqm at ietf.org <aqm at ietf.org>; bloat <bloat at 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
aqm at ietf.org
https://www.ietf.org/mailman/listinfo/aqm