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

[Matt Taggart <[e-mail]>]

Dave Taht writes:

> 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."

This thread makes me realize that my standard method of measuring latency 
over time might have issues. I use smokeping

  http://oss.oetiker.ch/smokeping/

which is a really nice way of measuring and visualizing packet loss and 
variations in latency. I am using the default probe type which uses fping 
(ICMP http://www.fping.org/ ).

It has been working well, I set it up for a site in advance of setting up 
SQM and then afterwards I can see the changes and determine if more tuning 
is needed.  But if ICMP is having it's priority adjusted (up or down), then 
the results might not reflect the latency of other services.

Fortunately the nice thing is that many other probe types exist 

  http://oss.oetiker.ch/smokeping/probe/index.en.html

So which probe types would be good to use for bufferbloat measurement? I 
guess the answer is "whatever is important to you", but I also suspect 
there is a set of things that ISPs are known to mess with.
HTTP? But also maybe HTTPS in case they are doing some sort of transparent 
proxy?
DNS?
SIP?
I suppose you could even do explicit checks for things like Netflix (but 
then it's easy to go off on a tangent of building a net neutrality 
observatory).

On a somewhat related note, I was once using smokeping to measure a fiber 
link to a bandwidth provider and had it configured to ping the router IP on 
the other side of the link. In talking to one of their engineers, I learned 
that they deprioritize ICMP when talking _with_ their routers, so my 
measurement weren't valid. (I don't know if they deprioritize ICMP traffic 
going _through_ their routers)

-- 
Matt Taggart
[e-mail]