From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 20A113B29D for ; Wed, 12 Feb 2020 19:36:57 -0500 (EST) Received: by mail-wr1-x42a.google.com with SMTP id k11so4559575wrd.9 for ; Wed, 12 Feb 2020 16:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LMRKCuhlbDJB0cq2yHxiCjQgvxpX57LVFwruOiyWECI=; b=L4LQ9wSB5fsckjuixhKEzE4UIxFnpoUIvEGGw5jxKT6ZU5Wy60joenX91U12HoylXF NYIlWJzg9bK4bqOYeQULBJ9w16zrEkt6njk7ZcVYcvDZM4KOkQeM8joE2YC+rMYd3R83 8B6WEPynPh0eP+sdvFySYOmi8eitIfqxiO2eg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LMRKCuhlbDJB0cq2yHxiCjQgvxpX57LVFwruOiyWECI=; b=g0sO6rzqI+bqccgNXfOxHLv+uykWWUIew2htBDLfjZCHFlxMsYvQj8WY9aY4v350js ikX1/V/atZoBcFClzShkzN7sGzgdCx2gaDQNlK/HEn//u+uC2llWW8SHP3fisbgtpbdB LTvH9yJ94yhhHYKRc6t5vx0iP9VeNSsrSRwMPk2HNmM9J+VT2QmfvgglzpezyXgzuQ0d LhrtJpZdmH1xPbSyVMiXi6v2YPLwgHre6T6BH9+H8yfxOGpbAL8t3oE9HHSPhe7hbHxz cF1eZqMpbtP+bgpGAwNqkglxv7GQnukdFnRxEzwBqFWGEKAuDB5MXZthN0LOo8zTYBIA PSeA== X-Gm-Message-State: APjAAAUb/ZhFOXuc7k6iAcXhh4hBvptHcLha+NU5oJEbQG1hglB45INc nI6FQMnr8OqvlVzOhALti3LDj5b3qmZthy2rRDdDEOlRVs4= X-Google-Smtp-Source: APXvYqzpjeBVAqA3x5auVQhUuzQsqOfEbyVjJUqdCwlOgDz36GOidyfJg7oPjv6JVaiJim75z4DVWvY5TYwdyi98mAU= X-Received: by 2002:a5d:4a06:: with SMTP id m6mr17973786wrq.155.1581554215962; Wed, 12 Feb 2020 16:36:55 -0800 (PST) MIME-Version: 1.0 References: <1581552513.586428831@apps.rackspace.com> In-Reply-To: <1581552513.586428831@apps.rackspace.com> From: Bob McMahon Date: Wed, 12 Feb 2020 16:36:44 -0800 Message-ID: Subject: Re: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface To: "David P. Reed" Cc: Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000003cb007059e6a49d6" X-List-Received-Date: Thu, 13 Feb 2020 00:36:57 -0000 --0000000000003cb007059e6a49d6 Content-Type: text/plain; charset="UTF-8" hmm, not sure if this helps but "excess queueing" can be hard to define. Do you know the operating systems for the WiFi devices and if tooling can be loaded upon them? iperf clients samples RTT and CWND for linux machines. Iperf 2.0.14 (in development) has a lot of latency related features Also, if there is control over the AIFS one can set that for the high rates devices such that they always win and the lower rate ones always lose. If that solves things it does suggest WiFi tx queues developing per the TXOP arbitration and air transmission as an issue. Standard cwmin/cwmax isn't as effective though it won't allow high rates to starve low rates devices as AIFS might (depending upon the values) I use latency to measure the performance and define bounds that way and it's very specific to use cases. IT does require clock sync. My devices have GPS disciplined oscillators which aren't common. As an aside, the HULL approach of phantom queues looks interesting. https://people.csail.mit.edu/alizadeh/papers/hull-nsdi12.pdf Bob On Wed, Feb 12, 2020 at 4:08 PM David P. Reed wrote: > A friend of mine (not a network expert, but a gadget freak), has been > deploying wireless security cameras at his home and vacation home. He uses > a single WiFi AP in each place, serving the security cameras etc. > > What he observes is this: > > Whenever anyone on a laptop in one of the homes uploads a modest sized > file (over the same WiFi) the security systems all lose data. > > Now I can't go to his home to diagnose this, but I've asked him to check > out his cable bufferbloat using dslreports, and he gets no bufferbloat > there. But it sure looks like *severe* lag under load is affecting the > security camera feed to the cloud servers that the company that sells the > security cameras provides. > > So, is there a way to simply *diagnose* the WiFi air link for excess > queueing in all the high rate WiFi devices? Something a non-net-head could > do? > > The situation around congestion control in the industry continues to > royally suck, in my opinion. The vendors don't care, the ISPs don't care > (they can sell a higher speed connection than is actually needed and > super-fabulous MIMO gadgets that still don't quite solve the problem). > > I'm an old guy, basically retired. I'm sad because the young folks remain > clueless. > > And it's been decades since bufferbloat was discuvered, and the basic > issue of congestion signalling being needed. I'm sure 5G (whatever it > really is) is not paying attention to this network level congestion issue... > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --0000000000003cb007059e6a49d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hmm, not sure if this helps but "excess queueing"= ; can be hard to define.=C2=A0

Do you know the operating systems for= the WiFi devices and if tooling can be loaded upon them?=C2=A0 iperf clien= ts samples RTT and CWND for linux machines. Iperf 2.0.14 (in development) h= as a lot of latency related features

Also, if there is control over = the AIFS one can set that for the high rates devices such that they always= =C2=A0win and the lower rate ones always lose.=C2=A0 If that solves things = it does suggest WiFi tx queues developing per the TXOP arbitration and air = transmission as an issue.=C2=A0 Standard cwmin/cwmax isn't as effective= though it won't allow high rates to starve low rates devices as AIFS m= ight (depending upon the values)

I use latency to measure=C2=A0the p= erformance and define bounds that way and it's very specific to use cas= es.=C2=A0 IT does require clock sync. My devices have GPS disciplined oscil= lators which aren't common.

As an aside, the HULL approach of ph= antom queues looks interesting.=C2=A0https://people.csail.mit.edu/alizadeh/pa= pers/hull-nsdi12.pdf
=C2=A0
Bob

On Wed, Feb 12, 2020 at 4:0= 8 PM David P. Reed <dpreed@deeppl= um.com> wrote:
A friend of mine (not a network expert, but a gadget freak), has been= deploying wireless security cameras at his home and vacation home. He uses= a single WiFi AP in each place, serving the security cameras etc.

What he observes is this:

Whenever anyone on a laptop in one of the homes uploads a modest sized file= (over the same WiFi) the security systems all lose data.

Now I can't go to his home to diagnose this, but I've asked him to = check out his cable bufferbloat using dslreports, and he gets no bufferbloa= t there. But it sure looks like *severe* lag under load is affecting the se= curity camera feed to the cloud servers that the company that sells the sec= urity cameras provides.

So, is there a way to simply *diagnose* the WiFi air link for excess queuei= ng in all the high rate WiFi devices? Something a non-net-head could do?
The situation around congestion control in the industry continues to royall= y suck, in my opinion. The vendors don't care, the ISPs don't care = (they can sell a higher speed connection than is actually needed and super-= fabulous MIMO gadgets that still don't quite solve the problem).

I'm an old guy, basically retired. I'm sad because the young folks = remain clueless.

And it's been decades since bufferbloat was discuvered, and the basic i= ssue of congestion signalling being needed. I'm sure 5G (whatever it re= ally is) is not paying attention to this network level congestion issue...<= br>
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--0000000000003cb007059e6a49d6--