Created attachment 615 [details]
Proposed fix

(In reply to comment #0)
> Created an attachment (id=614) [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.

(In reply to comment #8)
> (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.

Kirill, do you have any more comments on this bug?  It will likely be marked as invalid within a week otherwise.

> To summarize, I plan to close this bug as INVALID in a week or so unless you
> add more comments.
What about setting coverage class and _add_ it to a slot? (and CTS/ACK timeout values, etc.). Coverage class is reponsible for propagation delay, and default values of slot correspond to zero coverage class. Im I right?

I've checked IEEE Std. 802.11-2007. As it often turns out, the confusion is generated by the fact that the specification changes according to which PHY specification we consider. Below the sections of the standard that I found to be relevant:

15.4.6.8 Slot time
"The slot time for the DSSS PHY shall be the sum of the RX-to-TX turnaround time (5 µs) and the energy
detect time (15 µs specified in 15.4.8.4). The propagation delay shall be regarded as being included in the energy detect time."

18.4.6.11 deals with the High Rate PHY (5.5 and 11 Mbps) and is almost identical to the above.

17.3.8.6 Slot time
"The slot time for the OFDM PHY shall be 9 s for 20 MHz channel spacing, shall be 13 µs for 10 MHz
channel spacing, and shall be 21 µs for 5 MHz channel spacing. Where dot11RegulatoryClassesRequired is true, the value of the slot time shall be increased by the value of 3 µs × coverage class. The default value of coverage class shall be zero.
NOTE--Distributed coordination function (DCF) operation over larger BSS diameters is facilitated by relaxing some PHY timing parameters, while maintaining compatibility with existing implementations in small BSS diameters."


19.4.4 Slot time
"The slot time is 20 µs, except that an optional 9 µs slot time may be used when the BSS consists of only ERP STAs capable of supporting this option. The optional 9 µs slot time shall not be used if the network has one or more NonERP STAs associated. For IBSS, the Short Slot Time subfield shall be set to 0, corresponding to a 20 µs slot time."


So, my understanding is that Kirill's proposal is standard-compliant, but only for the OFDM PHY for 5GHz. If remember correctly, this includes (using our WifiPhyStandard nomenclature) 80211a, 80211p, 80211_5Mhz and 80211_10MHz. As for 802.11b and 802.11g, using aAirPropagationTime to determine the SlotTime is not allowed.

Personally, I would be fine with a patch that does exactly what said in 17.3.8.6. Of course, I would also like to hear what other people think of this. 


> > 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.
> 

I agree with Mathieu's argument that such an attribute would mess up things for the user. I would even argue that the usability of the attribute system is broken for all parameters set by the WifiMac::Configure80211Xxx methods. For example, if a user tries to change the default value of SlotTime using the attribute system, it won't work. So I would suggest not to have a MaxPropagationDelay attribute, at least until somebody comes with a better design addressing this issue.

I am marking this bug as an enhancement (and lowering priority accordingly) since the current configuration of the code is the default one according to the standard, and the proposed modification deals with an optional configuration.

If the user wants to increase the slot value to take into account larger propagation delays than those considered initially by the standard (this is the purpose of the coverage class used in Linux drivers), it is still possible via the corresponding attribute.

I thus think this is an invalid bug. Furthermore, this bug is already very old and we never got any complain about that (except that the slot attribute was overwritten, but this has been clarified in the meantime).

I aggree with sebastien, slot time is fixed according to standard, for example, Table 18-17 in IEEE 802.11-2012 shows slot time is 9us(20Mhz),13us(10Mhz), 21us(5Mhz), a patch is no necessary.

(In reply to sebastien.deronne from comment #13)
> If the user wants to increase the slot value to take into account larger
> propagation delays than those considered initially by the standard (this is
> the purpose of the coverage class used in Linux drivers), it is still
> possible via the corresponding attribute.
> 
> I thus think this is an invalid bug. Furthermore, this bug is already very
> old and we never got any complain about that (except that the slot attribute
> was overwritten, but this has been clarified in the meantime).

I agree to not accept this patch.

This paper has more discussion about the topic of modifying slot size based on propagation delay, in case anyone is interested.

Simo Reigadas, J.; Martinez-Fernandez, A.; Ramos-Lopez, J.; Seoane-Pascual, J., "Modeling and Optimizing IEEE 802.11 DCF for Long-Distance Links," in Mobile Computing, IEEE Transactions on , vol.9, no.6, pp.881-896, June 2010

I still agree with Sebastien to stick with the standard value and allow people to manually set it otherwise with an attribute if desired.

It has been agreed to reject this bug.