From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A66BE3CB3E for ; Sat, 13 Jan 2018 06:49:09 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1515844147; bh=xvvFqSPltkJ/7w0lzjWPAImZuw337F8nCpkYnAXivrw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=S0ZkGrR8xRdn9UtpXf2pUMoE6nXH3uhJeciGOO62X+mAR0o++Rf+1hnWn5mWeM2tE ZhVFNUE+044pENic9JzKgkOS4r1xlUv87Phncb04HNhj7OjgXMHKGH9cA1QrhLuEvQ L4of1Bnj9aN5DkoG4A0Fo3d+4ZUhctwMnM/BmRR/aCJRh+Oey1C7AhWULqLbNCjqSW 32lWNtWzUpetebs/43RzHec9R3l/Jqnnsh8aFrYkx3M5WWh0vJhU0+xLgTZjn3S7VB lYJs4KEAHXSpxDDTX3eHHv7HDJ6+JheUgCxugyTKqYLX2utx+gbsepcHmU7BEgWUqp T9eXwKIE4PC6A== To: Pete Heist Cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: <1265AA25-398F-4FA1-9D6B-279178D52EEB@gmail.com> References: <87o9lzqmsq.fsf@toke.dk> <1265AA25-398F-4FA1-9D6B-279178D52EEB@gmail.com> Date: Sat, 13 Jan 2018 12:49:07 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fu7avv0s.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Estimating WiFi congestion using different-prio pings X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 11:49:09 -0000 Pete Heist writes: >> On Jan 12, 2018, at 1:33 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> 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... >>=20 >> 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=3D3143361.3143390 >>=20 >> -Toke > > Interesting, I wonder if this could be used to evaluate congestion > within an ISP=E2=80=99s backhaul (but the article is behind a paywall). > > FreeNet Liberec currently uses SmokePing with ICMP. They have dozens > of APs, but here=E2=80=99s what results look like to the AP I use: > http://www.drhleny.cz/bufferbloat/smokeping/vysina.png > > They=E2=80=99re not all as rosy: http://www.drhleny.cz/bufferbloat/smokep= ing/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=E2=80=99ve proven for myself that Ubiquiti is prioritizing ICMP, so I > suspect that what we=E2=80=99re seeing in the SmokePing results is a meas= ure > of connectivity and maybe contention as well, but not congestion or > user-perceived latency. And even though the ping results to my AP > don=E2=80=99t vary much, I feel like web surfing latency varies considera= bly, > maybe dramatically, depending on the time of day. I=E2=80=99d like to pro= ve > 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