[Starlink] SatNetLab: A call to arms for the next global> Internet testbed

[David Lang]

On Tue, 13 Jul 2021, Ben Greear wrote:

>>>> The problem is that with wifi at modern data rates, you have a header at 
>>>> a low data rate and then data at a much higher data rate (in extreme 
>>>> cases, a >50x difference), so the amount of data that you send has a 
>>>> pretty minor difference in the airtime used. So you really do want to 
>>>> send a large amount of data per transmission to minimize the overhead
>>>> 
>>>> IT's not quite as bad if you have disabled 802.11b speeds on the entire 
>>>> network as that raises the header/housekeeping transmissions from 1Mb/s 
>>>> to 11Mb/s
>>> 
>>> The quiesce period waiting for medium access also takes some time, so that 
>>> is another reason to try to put lots of frames on air in the same tx 
>>> operation...
>> 
>> yep, mentally I lump that into the header/housekeeping functionality as 
>> that's all fixed-time no matter how much data you are transmitting.
>
> Not exactly fixed though?  With a few transmitters trying to get on medium, 
> air-time may theoretically improve a bit for first few transmitters due to 
> random backoff timers finding clear air after shorter over-all quiesce period, 
> but I would image it gets pretty bad with several hundred radios detecting 
> collisions and increasing their backoff before accessing medium again?

the quiesce period and the header transmission time are airtime that is used by 
a transmission that does not transmit any data (header at the beginning of the 
message, quiesce period at the end of the message). Neither of them depend on 
how much data you are sending.

>>> David, I'm curious about the rate-ctrl aspect of this.  Have you found any 
>>> implementations of rate-ctrl that try harder to decrease amsdu groupings 
>>> and/or keep MCS higher (maybe based on RSSI?) in a congested environment 
>>> to deal better with hidden node problems?
>> 
>> I have not experimented with that. I help run the network at the SCALE 
>> conference each year (3500 geeks with their gear over ~100k sq ft of 
>> conference center with >100 APs running openwrt), and I'm open to 
>> suggestions for monitoring/tweaking the network stack, as long as it's easy 
>> to revert to default if we run into grief.
>
> Mucking with rate-ctrl typically involves hacking firmware in modern APs. 
> Impossible for most due to lack of
> source, and tricky stuff even for those with source.  And if you do it wrong, 
> you can completely ruin a
> network.
>
> Maybe something like MTK AX chipset will someday offer a host-based rate-ctrl 
> where experimenters could put some
> effort in this direction.  I don't know of any other chipset that would have 
> any chance of user-based rate-ctrl.

Everything I work with has to work with unmodified clients, and it's the clients 
that have the most hidden transmitter problems.

If you are doing infrastructure wifi (especially point-to-point links) there is 
a ton of stuff that you can do with antennas to cut down the signal from 
transmitters you don't care about and enhance the signal from the ones you do.

careful analysis of your building structure can let you use AP positioning and 
antennas to reduce interference between APs and different sets of clients.

but I spoke up because the assumption that wifi data errors are primarily things 
that can be solved by error correction and slowing down the bit rate are only 
true in the weak-signal environment, and are very counter-productive in a 
dense/urban environment, which is FAR more common than the weak-signal 
envioronment today.

David Lang