Changes between Version 10 and Version 11 of 802.11/wlan_exp/app_notes/dcf_with_hidden_nodes

Timestamp:

Jun 23, 2015, 3:50:55 PM (9 years ago)

Author:

chunter

Comment:

--

802.11/wlan_exp/app_notes/dcf_with_hidden_nodes

@@ -56 +56 @@
 1. During the contention free phases (i.e., the first 60 seconds of each trial), RTS/CTS actually harmed the achieved throughput. We dropped from achieving ~10 Mbps of the 12 Mbps PHY rate to slightly more than 9 Mbps. In the absence of any collisions, RTS and CTS transmissions are purely overhead. Transmitting those frames takes a non-negligible amount of time. That time could have been spent transmitting the actual data MPDUs. The overall cost of this overhead is a function of the duration of each data MPDU. Large sized and low rate transmissions incur a relatively smaller penalty than short and/or high rate transmissions.
 1. During the contention phase (i.e. the last 30 seconds of each trial), we can see the benefit provided by RTS/CTS to overall sum throughput. Without RTS/CTS, the network achieved ~6.5 Mbps. This is a considerable loss over the ideal ~10 Mbps of achievable throughput in the contention-free phases. When RTS/CTS is enabled, however, sum throughput is recovered to 9 Mbps. This is a direct result of the improved virtual carrier sensing ability given to each station when they overhear the AP's CTS to the other station.
-1. In addition to providing a big improvement in sum throughput during the contention, RTS/CTS also radically improves the delay profile of each of the two constituent flows. Notice in the RTS/CTS disabled that any given slice of time generally sees all throughput from Flow 1 or all throughput from Flow 2 (i.e. the either the red or green line overlaps with the black sum line). This is a result of the binary exponential backoff structure of the DCF. In the event of a collision, contention windows increase and provide a longer window of time to allow another device contention-free access to the medium. The result is an extreme swing of short-term outages for each link. Each STA can potentially be stuck backing off for seconds at a time while the other STA is getting its traffic to the AP. Then, at some point, there is a chance for them to trade places if the STA that was stuck backing off is able to choose a lower slot time than its neighbor. Compare this behavior to the RTS/CTS enabled case. In general, the two stations are splitting the medium and trading off on much smaller timescales.
+1. In addition to providing a big improvement in sum throughput during the contention, RTS/CTS also radically improves the delay profile of each of the two constituent flows. Notice in the RTS/CTS disabled case that any given slice of time generally sees all throughput from Flow 1 or all throughput from Flow 2 (i.e. the either the red or green line overlaps with the black sum line). This is a result of the binary exponential backoff structure of the DCF. In the event of a collision, contention windows increase and provide a longer window of time to allow another device contention-free access to the medium. The result is an extreme swing of short-term outages for each link. Each STA can potentially be stuck backing off for seconds at a time while the other STA is getting its traffic to the AP. Then, at some point, there is a chance for them to trade places if the STA that was stuck backing off is able to choose a lower slot time than its neighbor. Compare this behavior to the RTS/CTS enabled case. In general, the two stations are splitting the medium and trading off on much smaller timescales.
 
 So, should devices use RTS/CTS? The answer is not obvious. There is clearly an inherent tradeoff between the increased overhead caused by RTS/CTS and the benefits to improved carrier sensing range. Which side wins this tradeoff is dependent on many factors including the size of the payload being delivered, the overall network contention, and the network topology. The 802.11 Standard notes this and defines a "dot11RTSThreshold" that can be specified by equipment manufacturers. Any MPDU above this threshold is considered "long" and the overhead of the RTS/CTS exchange is considered "worth it." Anything lower than this threshold uses basic access without RTS/CTS. However, we have seen from our previous experiment than even fairly long (1400 byte) frames and fairly low rates (12 Mbps) still exhibit a non-obvious tradeoff in the utility of RTS/CTS.