From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp71.iad3a.emailsrvr.com (smtp71.iad3a.emailsrvr.com [173.203.187.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0D0243B29D for ; Wed, 12 Feb 2020 20:56:44 -0500 (EST) Received: from app29.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C5B1642D6; Wed, 12 Feb 2020 20:56:43 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app29.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Wed, 12 Feb 2020 20:56:43 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app29.wa-webapps.iad3a (Postfix) with ESMTP id B318C20048; Wed, 12 Feb 2020 20:56:43 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 12 Feb 2020 20:56:43 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Wed, 12 Feb 2020 20:56:43 -0500 (EST) From: "David P. Reed" To: "Bob McMahon" Cc: "Make-Wifi-fast" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <1581552513.586428831@apps.rackspace.com> Message-ID: <1581559003.730714516@apps.rackspace.com> X-Mailer: webmail/17.2.8-RC Subject: Re: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface 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: Thu, 13 Feb 2020 01:56:44 -0000 I know this is hard to measure, in general. Especially to isolate the issue= because it combines packet scheduling, the AP's own activity, and the inse= rtion of excess buffering in each device's hardware and driver software. = =0A=0AHowever, what I'm looking for is evidence that helps locate the probl= em, which of course is a "distributed scheduling and buffering" problem, un= like the simple bufferbloat we all saw in the CMTS's of DOCSIS 2.0,, ALU's = LTE deployments in the early days of 4G (at ATT Wireless), or the overbuffe= ring in Arista Networks's switches, which were quite simple to measure and = diagnose.=0A=0AOn Wednesday, February 12, 2020 7:36pm, "Bob McMahon" said:=0A=0A> hmm, not sure if this helps but "excess q= ueueing" can be hard to define.=0A> =0A> Do you know the operating systems = for the WiFi devices and if tooling can=0A> be loaded upon them? iperf cli= ents samples RTT and CWND for linux=0A> machines. Iperf 2.0.14 (in developm= ent) has a lot of latency related=0A> features=0A> =0A> Also, if there is c= ontrol over the AIFS one can set that for the high rates=0A> devices such t= hat they always win and the lower rate ones always lose. If=0A> that solve= s things it does suggest WiFi tx queues developing per the TXOP=0A> arbitra= tion and air transmission as an issue. Standard cwmin/cwmax isn't=0A> as e= ffective though it won't allow high rates to starve low rates devices=0A> a= s AIFS might (depending upon the values)=0A> =0A> I use latency to measure = the performance and define bounds that way and=0A> it's very specific to us= e cases. IT does require clock sync. My devices=0A> have GPS disciplined o= scillators which aren't common.=0A> =0A> As an aside, the HULL approach of = phantom queues looks interesting.=0A> https://people.csail.mit.edu/alizadeh= /papers/hull-nsdi12.pdf=0A> =0A> Bob=0A> =0A> On Wed, Feb 12, 2020 at 4:08 = PM David P. Reed wrote:=0A> =0A>> A friend of mine (n= ot a network expert, but a gadget freak), has been=0A>> deploying wireless = security cameras at his home and vacation home. He uses=0A>> a single WiFi = AP in each place, serving the security cameras etc.=0A>>=0A>> What he obser= ves is this:=0A>>=0A>> Whenever anyone on a laptop in one of the homes uplo= ads a modest sized=0A>> file (over the same WiFi) the security systems all = lose data.=0A>>=0A>> Now I can't go to his home to diagnose this, but I've = asked him to check=0A>> out his cable bufferbloat using dslreports, and he = gets no bufferbloat=0A>> there. But it sure looks like *severe* lag under l= oad is affecting the=0A>> security camera feed to the cloud servers that th= e company that sells the=0A>> security cameras provides.=0A>>=0A>> So, is t= here a way to simply *diagnose* the WiFi air link for excess=0A>> queueing = in all the high rate WiFi devices? Something a non-net-head could=0A>> do?= =0A>>=0A>> The situation around congestion control in the industry continue= s to=0A>> royally suck, in my opinion. The vendors don't care, the ISPs don= 't care=0A>> (they can sell a higher speed connection than is actually need= ed and=0A>> super-fabulous MIMO gadgets that still don't quite solve the pr= oblem).=0A>>=0A>> I'm an old guy, basically retired. I'm sad because the yo= ung folks remain=0A>> clueless.=0A>>=0A>> And it's been decades since buffe= rbloat was discuvered, and the basic=0A>> issue of congestion signalling be= ing needed. I'm sure 5G (whatever it=0A>> really is) is not paying attentio= n to this network level congestion issue...=0A>>=0A>> _____________________= __________________________=0A>> Make-wifi-fast mailing list=0A>> Make-wifi-= fast@lists.bufferbloat.net=0A>> https://lists.bufferbloat.net/listinfo/make= -wifi-fast=0A> =0A