Draft: Add MinstrelHt retry chain test

I am working on a test for MinstrelHt retry chain prompted by issue #886 on the tracker. I ran into an unexpected behavior in which MinstrelHt was retransmitting frames more than 7 times. I believe this happens because MinstrelHt overrides the function WifiRemoteStationManager::DoNeedRetransmission() and sets the maximum amount of retries for a frame based on the output of the function MinstrelHtWifiManager::CountRetries(). This function will return the sum of whatever amount of retransmissions are calculated for each segment of the retry chain. The number of retransmissions per segment are calculated in the function MinstrelHtWifiManager::CalculateRetransmits(). Every segment of the retry chain will be allowed to have any amount of retries as long as these two conditions are true:

1. The number of retransmissions fit within the segment (how many retransmissions can you do using that rate in 6 ms).
2. The number of retransmissions per stage is less than 7. (hard-coded value)

Therefore, a frame may be retransmitted up to 18 times; 6 times per segment of the retry chain (bestTpRate(x6), bestTpRate2(x6), bestProbRate(x6)). So, the total amount of retransmissions is not being limited by the attributes MaxSsrc and MaxSlrc of the base class WifiRemoteStationManager.

This might not be the correct behavior as one would expect to see a frame retransmitted a total amount of 4 or 7 times according to if RTS/CTS is enabled/DISABLED? To verify this, you can run this test to see MinstrelHt trigger up to 15 retransmissions per frame. Now, since I am unsure if this was the correct behavior, I inspected the Linux kernel, and this is what I found. Original MinstrelHt Commit

In the Linux kernel file net/mac80211/rc80211_minstrel_ht.c the function minstrel_ht_get_rate() calls minstrel_ht_set_rate() for each of the rates in the retry chain including the sample rate (here a Boolean flag is set to determine if RTS/CTS will be used). In the function, minstrel_ht_set_rate() the function minstrel_calc_retransmit() calculates the number of retransmissions per rate of the retry chain with two main differences from the ns-3 version:

1. The first being that another separate counter is also kept accounting for retransmissions when using RTS/CTS (retry_count_rtscts).
2. The second difference is that the maximum amount of retries allowed per rate is set by the variable mp->max_retry which by default is set to seven in the file (net/mac80211/rc80211_minstrel.c) but can change if there is any value greater than zero assigned to the variable hw->max_rate_tries which changes based on the chip set (ath9k uses default 10 max retries).

The calculated values of the function minstrel_calc_retransmit() are set to the variable rate->count which get used by the atheros drivers to countdown the retries per rate. (drivers/net/wireless/ath/ath9k/rc.c). To my understanding, this means that a frame could be retransmitted up to 27 times if using ath9k chipset (max_tp_rate (x9), max_tp_rate2 (x9), max_prob_rate (x9)).

I would appreciate it if anyone could provide some feedback if they also agree that this is the behavior of the Linux implementation or if you know of another mechanism that would stop frames from being retransmitted additional times in a real implementation.

I think a simple solution to ensure at most 7 or 4 frames are transmitted would be to create Getters for MaxSsrc, MaxSlrc and RtsCtsThreshold. This way in the function MinstrelHtWifiManager::DoNeedRetransmission() an if statement can be included to set maxRetries to either MaxSsrc or MaxSlrc based on whether the size of the frame is smaller or greater than the attribute RtsCtsThreshold. Then, in the function MinstrelHtWifiManager::CalculateRetransmits() change the hard-coded value of 7 to maxRetries and include some if statements to handle how many retransmissions to give to each rate (possibly give more retransmissions to bestTp and bestTp2 and the least amount to bestProb?)