Re: [Cerowrt-devel] [Cake] [Make-wifi-fast] [Starlink] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

[David Lang <david@lang.hm>]

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 <david@lang.hm> 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 <bob.mcmahon@broadcom.com>
>>> To: David Lang <david@lang.hm>
>>> Cc: Ben Greear <greearb@candelatech.com>,
>>>     Luca Muscariello <muscariello@ieee.org>,
>>>     Cake List <cake@lists.bufferbloat.net>,
>>>     Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
>>>     Leonard Kleinrock <lk@cs.ucla.edu>, starlink@lists.bufferbloat.net,
>>>     codel@lists.bufferbloat.net,
>>>     cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
>>>     bloat <bloat@lists.bufferbloat.net>
>>> 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 <david@lang.hm> 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 <greearb@candelatech.com>
>>>> 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 <greearb@candelatech.com>
>>>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>