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

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

On Tue, 13 Jul 2021, Ben Greear wrote:

> On 7/13/21 11:01 AM, David Lang wrote:
>> On Tue, 13 Jul 2021, Rodney W. Grimes wrote:
>> 
>>> It wasnt suggested "lowering the bit rate", it was suggested to make the
>>> packets smaller, which actually does address the hidden transmitter 
>>> problem
>>> to some degree as it *would* reduce your air time occupancy, but the damn
>>> wifi LL aggregation gets in your way cause it blows them back up.  When I
>>> am having to deal/use wifi in a hidden transmitter prone situation I 
>>> always
>>> crank down the Fragmentation Threshold setting from the default of 2346 
>>> bytes
>>> to the often the minimum of 256 with good results.
>> 
>> 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.

> 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.

David Lang