Draft: changes to allow Wi-Fi rate control to support peek operations and to skip TXOPs
I would like to get some review/feedback from Sebastien and Stefano (and anyone else interested) on proposed changes to Wi-Fi rate control's main API.
Currently, WifiRemoteStationManager
(the base class for all rate controls) implements two public methods, GetDataTxVector()
and GetRtsTxVector()
, which return a WifiTxVector
for use, typically by the frame exchange managers.
There are two limitations with this:
-
The API does not allow for the rate control to decline to use a TXOP-- there is no way to return a null value. This hasn't been needed yet, but as we move towards coordinated spatial reuse use cases, there will be situations in which an AC wins a backoff, but the rate control decides not to use the TXOP, possibly because of interference concerns or it is in a power-restricted mode. Therefore, it would be nice to be able to return a null value.
-
Sometimes, this API is used not for fetching a WifiTxVector for actual frame transmission, but to peek at what value will be used next. The
HeRrMultiUserScheduler
uses it this way, for example. However, from the perspective of the rate control, it cannot distinguish between these uses, and may lead to broken assumptions about the value that will be returned in the next call to the method, and may lead some rate controls to incorrectly count usage of WifiTxVector instances.
I have been looking at using std::optional<WifiTxVector>
as a replacement return value for these methods, and also at providing a Peek
variant to our Get
variants (by default, the Peek
would call Get
, but could be overridden in subclasses). This should not affect user API but would break a lot of internal Wi-Fi API; this draft MR just takes the first initial step of such a change.
In conclusion, the main proposal is to allow null WifiTxVectors to be returned from these methods, and make the calling methods robust to a null value. The API change would be:
- WifiTxVector GetDataTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
+ std::optional<WifiTxVector> GetDataTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
- WifiTxVector GetRtsTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
+ std::optional<WifiTxVector> GetRtsTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
+ std::optional<WifiTxVector> PeekDataTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
+ std::optional<WifiTxVector> PeekRtsTxVector(const WifiMacHeader& header, uint16_t allowedWidth);
The DoGet...()
variants would also change in this way.
Opinions on proceeding with this?