# Performance Evaluation of IEEE 802.11 ah Networks With High-Throughput Bidirectional Traffic
## 4 Performance Evaluation and Discussion
### Delay-Tolerant TCP  
TCP has been designed to avoid network congestion and treats all losses as such, irrespective of the cause being network propagation delay or losses due to collisions. Frequent time-outs can occur if TCP is not adjusted to the long propagation delays. Frequent time-outs would result in a build-up of (unnecessary) re-transmissions that such a network could not handle in an acceptable time, causing a significant reduction of the throughput. With the slow start mechanism, it would take a long time to get back to the optimal congestion window size. There are TCP implementations that can handle high latency networks, such as satellite networks, more gracefully such as TCP Peach [36] or TCP Noordwijk [37]. The delays introduced by waiting for the RAW slot during which the transfer can take place can become comparable to high latency networks, making these enhancements also useful to be deployed in IEEE 802.11 ah environments. Unfortunately, ns-3 does not yet provide these implementations, so TCP Westwood [38] has been used instead, which is suitable for lossy wireless connections.  
The minimum Retransmission Timeout (RTO) is set high enough such that TCP re-transmissions do not influence the results due to timeouts. Normally, the TCP congestion algorithm is smart enough to adjust the congestion window and RTO values based on the measured RTT to match the possible throughput. However, this would require a period where lots of re-transmissions are being sent until the parameters settle, which would skew the results. If TCP re-transmissions occur in an already saturated channel, it would create a snowball effect where more re-transmissions are sent until the maximum amount of re-transmission attempts have been exceeded and the TCP connection is ultimately dropped. The results should be interpreted as the absolute maximum limit. In these tests, the IEEE 802.11 ACK and subsequent re-transmission on a missed ACK check as part of in the MAC implementation was sufficient to recover lost frames, but, in real-life scenarios, a certain margin should be taken into account to allow for a graceful increase in channel traffic due to TCP re-transmissions. As shown in Figure 14, a minimal RTO value of a single beacon interval is vastly insufficient. Larger TCP segments need larger minimal RTOs in order to bring re-transmissions down  
Figure 14: To avoid build-up of unnecessary TCP retransmissions due to long delays on link layer, minimum Retransmission Timeout (RTO) should be set high enough for each MCS as illustrated for (**a**) MCS8 and (**b**) MCS4. (**a**) The minimum RTO should be as long as eight beacon intervals when 3216- and 2680-byte TCP segments are used with MCS8. For shorter TCP segments, the RTO should not be smaller than four beacon intervals; (**b**) The minimum RTO should not be shorter than 16 beacon intervals when 3216- and 2680-byte TCP segments are used with MCS4. For shorter TCP segments, the RTO should not be smaller than eight beacon intervals, except for 536-byte TCP segments that allow four beacon intervals.  
to a minimum: eight beacon intervals (819.2 ms) for MCS8 at 2 MHz channel and 16 (1.6384 s) for MCS4 at 2 MHz. For smaller TCP segments, four beacon intervals (409.6 ms) are small enough for minimal RTO. Almost all re-transmissions were eliminated after a minimal RTO value of 1.6384 s or four DTIM cycles with four TIM groups, and only MCS0 required twice larger value.