Re: [Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[dpreed@reed.com]

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


 
On Friday, August 7, 2015 4:03pm, "David Lang" <david@lang.hm> said:
> 

> Wifi is the only place I know of where the transmit bit rate is going to vary
> depending on the next hop address.


This is an interesting core issue.  The question is whether additional queueing helps or hurts this, and whether the MAC protocol of WiFi deals well or poorly with this issue.  It is clear that this is a peculiarly WiFi'ish issue.
 
It's not clear that the best transmit rate remains stable for very long, or even how to predict the "best rate" for the next station since the next station is one you may not have transmitted to for a long time, so your "best rate" information is old.  Queueing makes information about the channel older, by binding it too early.  Sending longer frames means retransmitting longer frames when they don't get through, rather than agilely picking a better rate after a few bits.
 
The MAC protocol really should give the receiver some opportunity to control the rate of the next packet it gets (which it can do because it can measure the channel from the transmitter to itself, by listening to prior transmissions).  Or at least to signal channel changes that might require a new signalling rate.
 
This suggests that a transmitter might want to "warn" a receiver that some packets will be coming its way, so the receiver can preemptively change the desired rate.  Thus, perhaps an RTS-CTS like mechanism can be embedded in the MAC protocol, which requires that the device "look ahead" at the packets it might be sending.
 
On the other hand, that only works if the transmitter deliberately congests itself so that it has a queue built up to look at.
 
The tradeoffs are not obvious here at all.  On the other hand, one could do something much simpler - just have the transmitter slow down to the worst-case rate required by any receiving system.
 
As the number of stations in range gets larger, though, it seems unlikely that "batching" multiple packets to the same destination is a good idea at all - because to achieve that, one must have n_destinations * batch_size chunks of data queued in the system as a whole, and that gets quite large.  I suspect it would be better to find a lower level way to just keep the packets going out as fast as they arrive, so no clog occurs, and to slow down the stuff at the source as quickly as possible.
 
[one should also dive into the reason for maintaining variable rates - multipath to a particular destination may require longer symbols for decoding without ISI.  And when multipath is involved, you may have to retransmit at a slower rate. There's usually not much "noise" at the receiver compared to the multipath environment. (one of the reasons why mesh can be a lot better is that shorter distances have much less multipath effect, so you can get higher symbol rates by going multi-hop, and of course higher symbol rates compensate for more airtime occupied by a packet due to repeating).]
 
 

[-- Attachment #2: Type: text/html, Size: 5343 bytes --]