From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B7CCB3B29D; Tue, 3 Aug 2021 00:44:25 -0400 (EDT) Received: from dlang-laptop (unknown [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id A2373100128; Mon, 2 Aug 2021 21:44:24 -0700 (PDT) Date: Mon, 2 Aug 2021 21:44:24 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Bob McMahon cc: David Lang , Ben Greear , Luca Muscariello , Cake List , Make-Wifi-fast , Leonard Kleinrock , starlink@lists.bufferbloat.net, codel@lists.bufferbloat.net, cerowrt-devel , bloat In-Reply-To: Message-ID: References: <1625188609.32718319@apps.rackspace.com> <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> <1625773080.94974089@apps.rackspace.com> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Subject: Re: [Cerowrt-devel] [Cake] [Make-wifi-fast] [Starlink] Due Aug 2: Internet Quality workshop CFP for the internet architecture board X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 04:44:26 -0000 I agree that we don't want to make perfect the enemy of better. A lot of the issues I'm calling out can be simulated/enhanced with different power levels. over wifi distances, I don't think time delays are going to be noticable (we're talking 10s to low 100s of feet, not miles) David Lang On Mon, 2 Aug 2021, Bob McMahon wrote: > fair enough, but for this "RF emulator device" being able to support > distance matrices, even hollow symmetric ones, is much better than what's > typically done. The variable solid state phase shifters are 0-360 so don't > provide real time delays either. > > This is another "something is better than nothing" type proposal. I think > it can be deployed at a relatively low cost which allows for more > standardized, automated test rigs and much less human interactions and > human errors. > > Bob > > On Mon, Aug 2, 2021 at 9:30 PM David Lang wrote: > >> symmetry is not always (or usually) true. stations are commonly heard at >> much >> larger distances than they can talk, mobile devices have much less >> transmit >> power (becuase they are operating on batteries) than fixed stations, and >> when >> you adjust the transmit power on a station, you don't adjust it's receive >> sensitivity. >> >> David Lang >> >> On Mon, 2 Aug 2021, Bob McMahon wrote: >> >>> Date: Mon, 2 Aug 2021 20:23:06 -0700 >>> From: Bob McMahon >>> To: David Lang >>> Cc: Ben Greear , >>> Luca Muscariello , >>> Cake List , >>> Make-Wifi-fast , >>> Leonard Kleinrock , starlink@lists.bufferbloat.net, >>> codel@lists.bufferbloat.net, >>> cerowrt-devel , >>> bloat >>> Subject: Re: [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug >> 2: >>> Internet Quality workshop CFP for the internet architecture board >>> >>> The distance matrix defines signal attenuations/loss between pairs. It's >>> straightforward to create a distance matrix that has hidden nodes because >>> all "signal loss" between pairs is defined. Let's say a 120dB >> attenuation >>> path will cause a node to be hidden as an example. >>> >>> A B C D >>> A - 35 120 65 >>> B - 65 65 >>> C - 65 >>> D - >>> >>> So in the above, AC are hidden from each other but nobody else is. It >> does >>> assume symmetry between pairs but that's typically true. >>> >>> The RF device takes these distance matrices as settings and calculates >> the >>> five branch tree values (as demonstrated in the video). There are >>> limitations to solutions though but I've found those not to be an issue >> to >>> date. I've been able to produce hidden nodes quite readily. Add the phase >>> shifters and spatial stream powers can also be affected, but this isn't >>> shown in this simple example. >>> >>> Bob >>> >>> On Mon, Aug 2, 2021 at 8:12 PM David Lang wrote: >>> >>>> I guess it depends on what you are intending to test. If you are not >> going >>>> to >>>> tinker with any of the over-the-air settings (including the number of >>>> packets >>>> transmitted in one aggregate), the details of what happen over the air >>>> don't >>>> matter much. >>>> >>>> But if you are going to be doing any tinkering with what is getting >> sent, >>>> and >>>> you ignore the hidden transmitter type problems, you will create a >>>> solution that >>>> seems to work really well in the lab and falls on it's face out in the >>>> wild >>>> where spectrum overload and hidden transmitters are the norm (at least >> in >>>> urban >>>> areas), not rare corner cases. >>>> >>>> you don't need to include them in every test, but you need to have a way >>>> to >>>> configure your lab to include them before you consider any >>>> settings/algorithm >>>> ready to try in the wild. >>>> >>>> David Lang >>>> >>>> On Mon, 2 Aug 2021, Bob McMahon wrote: >>>> >>>>> We find four nodes, a primary BSS and an adjunct one quite good for >> lots >>>> of >>>>> testing. The six nodes allows for a primary BSS and two adjacent ones. >>>> We >>>>> want to minimize complexity to necessary and sufficient. >>>>> >>>>> The challenge we find is having variability (e.g. montecarlos) that's >>>>> reproducible and has relevant information. Basically, the distance >>>> matrices >>>>> have h-matrices as their elements. Our chips can provide these >>>> h-matrices. >>>>> >>>>> The parts for solid state programmable attenuators and phase shifters >>>>> aren't very expensive. A device that supports a five branch tree and >> 2x2 >>>>> MIMO seems a very good starting point. >>>>> >>>>> Bob >>>>> >>>>> On Mon, Aug 2, 2021 at 4:55 PM Ben Greear >>>> wrote: >>>>> >>>>>> On 8/2/21 4:16 PM, David Lang wrote: >>>>>>> If you are going to setup a test environment for wifi, you need to >>>>>> include the ability to make a fe cases that only happen with RF, not >>>> with >>>>>> wired networks and >>>>>>> are commonly overlooked >>>>>>> >>>>>>> 1. station A can hear station B and C but they cannot hear each other >>>>>>> 2. station A can hear station B but station B cannot hear station A >> 3. >>>>>> station A can hear that station B is transmitting, but not with a >> strong >>>>>> enough signal to >>>>>>> decode the signal (yes in theory you can work around interference, >> but >>>>>> in practice interference is still a real thing) >>>>>>> >>>>>>> David Lang >>>>>>> >>>>>> >>>>>> To add to this, I think you need lots of different station devices, >>>>>> different capabilities (/n, /ac, /ax, etc) >>>>>> different numbers of spatial streams, and different distances from the >>>>>> AP. From download queueing perspective, changing >>>>>> the capabilities may be sufficient while keeping all stations at same >>>>>> distance. This assumes you are not >>>>>> actually testing the wifi rate-ctrl alg. itself, so different >> throughput >>>>>> levels for different stations would be enough. >>>>>> >>>>>> So, a good station emulator setup (and/or pile of real stations) and a >>>> few >>>>>> RF chambers and >>>>>> programmable attenuators and you can test that setup... >>>>>> >>>>>> From upload perspective, I guess same setup would do the job. >>>>>> Queuing/fairness might depend a bit more on the >>>>>> station devices, emulated or otherwise, but I guess a clever AP could >>>>>> enforce fairness in upstream direction >>>>>> too by implementing per-sta queues. >>>>>> >>>>>> Thanks, >>>>>> Ben >>>>>> >>>>>> -- >>>>>> Ben Greear >>>>>> Candela Technologies Inc http://www.candelatech.com >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >