Bug 2976 - Non-uniform contention window when using EdcaTxopN and DcfManager
Non-uniform contention window when using EdcaTxopN and DcfManager
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3.28
All All
: P3 minor
Assigned To: sebastien.deronne
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-29 03:47 EDT by Henning Schepker
Modified: 2020-04-12 08:34 EDT (History)
2 users (show)

See Also:


Attachments
Debug output of this bug (4.83 KB, text/plain)
2018-08-29 03:47 EDT, Henning Schepker
Details
probability distribution of the backoff counter within the contention window due to this bug (74.19 KB, image/jpeg)
2018-09-05 05:56 EDT, Henning Schepker
Details
probability distribution of the backoff counter within the contention window due to this bug (75.13 KB, image/jpeg)
2018-09-05 06:16 EDT, Henning Schepker
Details
example setup, where this bug occurs (15.06 KB, text/x-csrc)
2018-09-21 04:40 EDT, Henning Schepker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henning Schepker 2018-08-29 03:47:38 EDT
Created attachment 3165 [details]
Debug output of this bug

This bug occurs, when the time difference to the previous transmission is less than the AIFS, e.g., saturated model or re-transmission after a failed transmission, and the backoff counter is initially set to 0 (this does not occur for all other inital counter values). In this case the EdcaTxopN re-generates the backoff counter.
If the backoff counter gets set to 0 again, it will not be re-generated again, such that a counter value of 0 is still possible. However, this bug makes a backoff counter of 0 less likely than all other counter values within the contention window, effectively increasing the delay, incresing collision probability, and no longer strictly following the standard.

In my test I was using SpectrumWifiPhy and AdhocWifiMac in 802.11n mode in simulation with a saturated model, i.e., I generate a new packet whenever the previous one was correctly received or dropped. However, I expect that the combination of EdcaTxopN and DcfManager always shows this behavior, regardless of other components.
Comment 1 Tom Henderson 2018-09-03 12:09:02 EDT
Can you please clarify what you think your log is showing?   I see one instance of a backoff of zero slots:

+6.000401000s -1 DcfState:StartBackoffNow(): [DEBUG] start backoff=0 slots

and later, one instance of a backoff of 25 slots:

+6.000401000s -1 DcfState:StartBackoffNow(): [DEBUG] start backoff=25 slots

I was expecting from your description to see some data that suggests that the observed backoff start value is biased against the value zero, across a large number of observations.

Also, do you see in the code where you think the behavior is wrong?
Comment 2 Henning Schepker 2018-09-04 02:53:48 EDT
(In reply to Tom Henderson from comment #1)
> Can you please clarify what you think your log is showing?   I see one
> instance of a backoff of zero slots:
> 
> +6.000401000s -1 DcfState:StartBackoffNow(): [DEBUG] start backoff=0 slots
> 
> and later, one instance of a backoff of 25 slots:
> 
> +6.000401000s -1 DcfState:StartBackoffNow(): [DEBUG] start backoff=25 slots
> 
> I was expecting from your description to see some data that suggests that
> the observed backoff start value is biased against the value zero, across a
> large number of observations.
> 
> Also, do you see in the code where you think the behavior is wrong?

The two lines you quoted are exactly the important lines. The problem is that for the same event (here ACK timeout) the backoff counter should not be first set to 0 and then set to 25. Especially since this behavior only occurs, if the first value of the backoff counter is 0. For all other values (i.e. > 0) the backoff counter is set once according to the window size. Thus, the 0 case is less likely than it should be.

The code lines responsible for this are the else if clause starting in line 337 of "dcf-manager.cc" and the "NotifyCollision" function of "edca-txop-n" (line 411 of "edca-txop-n.cc"). If this else if clause does not get executed in the previously described case, than the problem does not occur. However, I'm not familiar enough with the code to have an idea how to do that without potentially breaking anything else.
Comment 3 sebastien.deronne 2018-09-04 04:35:52 EDT
This is interesting, but I would expect a plot of the contention window over a large amount of time to demonstrate it is not uniform.
Comment 4 Henning Schepker 2018-09-05 05:56:07 EDT
Created attachment 3177 [details]
probability distribution of the backoff counter within the contention window due to this bug
Comment 5 Henning Schepker 2018-09-05 05:56:39 EDT
(In reply to sebastien.deronne from comment #3)
> This is interesting, but I would expect a plot of the contention window over
> a large amount of time to demonstrate it is not uniform.

I attached a plot of the probability distribution within the contention window as measured using the delay of a 802.11n transmission with ideal channel and no noise (i.e. first transmission is always successful) using ten-million packets. The previously discussed effect is clearly visible at the 0 element, since its probability is slightly less than the square of the probabilities of the other elements.

To my surprise this distribution also shows that the maximum value of the contention window (here 15) does not appear in the delays, while the logs clearly state that the backoff counter is set to this value. Since this should be an unrealted issue, I'll investigate this further.
Comment 6 Henning Schepker 2018-09-05 06:15:52 EDT
Comment on attachment 3177 [details]
probability distribution of the backoff counter within the contention window due to this bug

this figure was incorrect
Comment 7 Henning Schepker 2018-09-05 06:16:36 EDT
Created attachment 3178 [details]
probability distribution of the backoff counter within the contention window due to this bug
Comment 8 Henning Schepker 2018-09-05 06:18:07 EDT
Please disregard my earlier comment regarding the occurence of the maximum contention window size. There was just an error in my creation of the plot, that I didn't find earlier.
Comment 9 sebastien.deronne 2018-09-20 02:53:31 EDT
It's not clear for me why you mention about delay. Why not using the tracing system to count counter values?
Could you also attach a script to reproduce the plot?
Comment 10 Henning Schepker 2018-09-21 04:39:22 EDT
(In reply to sebastien.deronne from comment #9)
> It's not clear for me why you mention about delay. Why not using the tracing
> system to count counter values?
> Could you also attach a script to reproduce the plot?

I used the delay as this was something I measured anyway in my setup and since all other components of the delay are constant (in the setup I used), it is a clear indication of the contention window.
I attached the setup I used to generate the previously shown results (except parts I used in MATLAB to make the results more clear).
Comment 11 Henning Schepker 2018-09-21 04:40:20 EDT
Created attachment 3187 [details]
example setup, where this bug occurs
Comment 12 sebastien.deronne 2020-04-12 08:34:47 EDT
This was fixed by Stefano, can be closed