[Make-wifi-fast] Estimating WiFi congestion using different-prio pings

Pete Heist peteheist at gmail.com
Sat Jan 13 05:53:09 EST 2018

> On Jan 12, 2018, at 1:33 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Some people over at Skype have implemented a technique for a client to
> estimate congestion at the WiFi AP by pinging the AP at VO and BE
> priority and measuring the difference in response times. Pretty neat,
> except that it would presumably break if the AP was FQ-CoDel-enabled...
> Paper here, including a description of the bandwidth estimation stuff
> they apply to Skype based on the information:
> https://dl.acm.org/citation.cfm?doid=3143361.3143390
> -Toke

Interesting, I wonder if this could be used to evaluate congestion within an ISP’s backhaul (but the article is behind a paywall).

FreeNet Liberec currently uses SmokePing with ICMP. They have dozens of APs, but here’s what results look like to the AP I use: http://www.drhleny.cz/bufferbloat/smokeping/vysina.png

They’re not all as rosy: http://www.drhleny.cz/bufferbloat/smokeping/studankaA.png

When I get back to it, I want to write a SmokePing plugin for irtt to try in the same environment. The results may be interesting, because I’ve proven for myself that Ubiquiti is prioritizing ICMP, so I suspect that what we’re seeing in the SmokePing results is a measure of connectivity and maybe contention as well, but not congestion or user-perceived latency. And even though the ping results to my AP don’t vary much, I feel like web surfing latency varies considerably, maybe dramatically, depending on the time of day. I’d like to prove that.

The summary of what they did at Skype makes me think it would also be interesting to see the _difference_ between ICMP and irtt (UDP at best effort)...


More information about the Make-wifi-fast mailing list