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

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

[Toke Høiland-Jørgensen]

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

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

[Dave Taht]

On Fri, Jan 12, 2018 at 4:33 AM, Toke Høiland-Jørgensen <toke@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...

Well, it might not hurt...

> 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

Not available via sci-hub yet. :(

>
> -Toke
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

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

[Pete Heist]

> On Jan 12, 2018, at 1:33 PM, Toke Høiland-Jørgensen <toke@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)...

Pete

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

[Toke Høiland-Jørgensen]

Pete Heist <peteheist@gmail.com> writes:

>> On Jan 12, 2018, at 1:33 PM, Toke Høiland-Jørgensen <toke@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)...

Any prioritisation of ICMP may just be because ICMP replies are
generated by the kernel, whereas other traffic goes all the way to the
userspace application generating it. However, it is certainly possible
that ICMP is being prioritised - some people do that in an effort to
game benchmarks...

-Toke

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

[Pete Heist]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]


> On Jan 13, 2018, at 12:49 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Any prioritisation of ICMP may just be because ICMP replies are
> generated by the kernel, whereas other traffic goes all the way to the
> userspace application generating it. However, it is certainly possible
> that ICMP is being prioritised - some people do that in an effort to
> game benchmarks...

I somehow missed this comment from before. Here’s what makes me think this is more than just kernel vs userspace, and something Ubiquiti may be doing, at least in their M series firmware:

- To measure overhead, between a RasPI (client) and an EdgeRouter-X (server), I see only a 354µs difference between ping’s mean RTT and irtt's mean RTT when tested with 100 packets over direct cabled Ethernet (865µs - 511µs). I assume that this overhead will remain about the same for the same client and server devices, regardless of what else lies between them.

- Next, ping vs irtt (mean rtt of 100 packets) to the same EdgeRouter-X over an unloaded Internet connection where the CPE is a Ubiquiti PowerBeam M5-400:
	- ping: 17.03ms
	- irtt: 20.7ms

- Next, ping vs irtt (mean rtt of 100 packets) to the same EdgeRouter-X, same Internet connection, but with a saturated upload and no AQM:
	- ping: 22.9ms
	- irtt: 90.23ms

Saturation seems to have a much larger impact on UDP than ICMP.

This is only a rough test and I’ll need to reproduce this in my lab setup when it’s up again. That will remove all devices along the route as possible sources of this behavior. But since I know FreeNet isn’t doing this in their backhaul I’m fairly certain that’s what’s going on.

I’ll update with some results later when repro’d in the lab with NSM5s…


[-- Attachment #2: Type: text/html, Size: 6484 bytes --]