Created an attachment (id=615) [details]
Proposed fix

(In reply to comment #0)
> Created an attachment (id=614) [details] [details]
> Propsed fix (no testcase)
> 
> Slot time shall be corrected by propagation delay in the same manner as CTS and
> ACK timeouts, i.e 2*GetDefaultMaxPropagationDelay () shall be added in types of
> standard. Path is applied.

s/in types of standard/for all 802.11{a,b,g} standard/
s/Path is applied/Patch is attached/

Can you point me to the relevant piece of the standard which mandates this ?

I don't believe the proposed patch is correct.

In IEEE Std 802.11-2007, both Table 15-2 and Table 18-5 specify slot time to be
20 microseconds for 802.11b. Also, the following is from section 19.1.2
Operational modes:

"The slot time is 20 μs in accordance with 18.3.3, except that an optional 9 μs
slot time may be used when the BSS consists of only ERP STAs."

Thus, for 802.11g, it can be 9 microseconds if there is no 802.11b stations.

gary appears to agree with me that this a correct patch. Do you have more
information to add ? If not, I think I will mark this as INVALID in a day or
two.

(In reply to comment #5)
> gary appears to agree with me that this a correct patch. Do you have more
> information to add ? If not, I think I will mark this as INVALID in a day or
> two.
Please, wait for Kirill to return from his vacation until next Monday
(November, 30th).

aSlotTime = aCCATime + aRxTxTurnaroundTime + aAirPropagationTime
+ aMACProcessingDelay.
(See 9.2.10)
So, Table 15-2 specifies the following:
aCCATime <= 15 us
aMACProcessingDelay <= 2 us
aRxTxTurnAroundTime <= 5 us
aAirPropagationTime 1 us

and a slot is specified as 20 us

Also there is a coverage class (table 7-27), which specifies
aAirPropagationTime, and, respectively, aSlotTime.

And, finally, aAirPropagationTime is 2 * GetMaxPropagationDelay (), as
specified in 10.4.3.2.

So, aSlotTime must be corrected in accordance with propagation delay

(In reply to comment #0)

> Slot time shall be corrected by propagation delay in the same manner as CTS and
> ACK timeouts, i.e 2*GetDefaultMaxPropagationDelay () shall be added in types of
> standard. Path is applied.
> 

Ok, your references to the standard sections did help quite a bit to understand
your suggestion. However, I don't really agree on your interpretation. What the
sections you quoted explain is how aSlotTime was calculated from a number of
primitive values. However, the standard also mandates default values for
aSlotTime as pointed out by gary (tables 15-2 and 18-5). So, what we could
potentially do is invert the equations you quoted to retrieve the primitive
values. Here are the set of constraints I get from table 15-2 and section
9.2.10:

aSlotTime = aCCATime + aRxTxTurnaroundTime + aAirPropagationTime
+ aMACProcessingDelay.
aSlotTime = 9
aCCATime <= 15
aRxTxTurnaroundTime <= 5
aMACProcessDelay <= 2

The above simply means that you can derive bounds for aAirPropationTime but it
does not mean that you should adjust the value of aSlotTime specified by the
standard.

> Also I think, that it is worth to make a convinient attribute of propagation
> delay with virtual getters and setters (like SetSlot) of WifiMac class.

If you do this, the problem is that you have to explain to users what happens
when they set both MaxPropagationDelay and SlotTime to explicit values. Which
of them wins ? What you need to do is either export all the low-level primitive
configuration values such as aCCATime, aRxTxTurnaroundTime, etc. or all the
high-level configuration values such as SlotTime, etc. i.e., you can't allow
the user to set a mix of these values.

To summarize, I plan to close this bug as INVALID in a week or so unless you
add more comments.