# An Accurate Platform for Investigating TCP Performance in Wi-Fi Networks
## 4 Evaluation
### Comparison to the Actual Network and CCAs
\begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**CCA**} & \multicolumn{2}{c}{**Queue Size = 20 Packets**} & \multicolumn{2}{c}{**Queue Size = 100 Packets**} \\ \cline{2-5}  & **RTT Ratio** & **Tx Ratio** & **RTT Ratio** & **Tx Ratio** \\ \hline Reno & 1.206 & 1.021 & 1.037 & 1.018 \\ \hline BIC & 0.972 & 1.023 & 1.010 & 1.020 \\ \hline CUBIC & 0.942 & 1.002 & 1.060 & 0.997 \\ \hline Highspeed & 0.984 & 1.025 & 1.026 & 1.003 \\ \hline H-TCP & 1.163 & 1.021 & 1.040 & 1.023 \\ \hline Hybla & 0.983 & 1.020 & 1.054 & 1.006 \\ \hline Scalable & 1.136 & 1.018 & 1.100 & 1.016 \\ \hline Vegas & 0.891 & 1.022 & 0.690 & 1.035 \\ \hline NV & 0.821 & 1.002 & 2.682 & 1.015 \\ \hline BBR & 1.033 & 1.001 & 0.666 & 0.997 \\ \hline CDG & 1.187 & 1.007 & 1.164 & 1.013 \\ \hline Illinois & 0.835 & 1.004 & 0.947 & 1.008 \\ \hline Westwood & 1.496 & 1.022 & 1.092 & 1.006 \\ \hline YeAH & 0.978 & 1.003 & 1.150 & 1.007 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Qualitative evaluation results. Figure 6: Throughput comparison in two-client scenario. In addition to the above conclusion, we can also determine whether bufferbloat occurs as the queue size is varied. Since the bottleneck bandwidth is completely occupied, latency variation may be a sign of bufferbloat. Figure 5a illustrates that for almost all CCAs, the RTT increases as the queue size increases from 20 to 100 packets, with the exceptions of Vegas, NV, BBR, and CDG. For those CCAs with large RTTs, we can consider them to be caused by bufferbloat. Because the results in the two networks are similar, it is possible to determine whether bufferbloat has occurred more quickly with the emulator. Moreover, we can compare the throughput and RTT values under different CCAs using the experimental results from our emulation platform. As mentioned, regardless of which CCA is used, the throughput values are similar. This is because there is no loss in this scenario; the CCA's only responsibility is to adjust the sending rate in accordance with the capacity of the bottleneck. In the 60-s experiment, all CCAs can fill the bottleneck link (i.e., a bandwidth of 10 Mbps). The RTT results in Figure 5a are arranged by CCA type from the left as follows. For the loss-based CCAs (Reno, BIC, Hightspeed, H-TCP, Hybla, and Scalable), the RTT increases as the queue size increases. When the queue size is 20, the RTT is approximately 20 ms, but when the queue size is 100, the value is greater by approximately four times or more. The most significant RTT increase is seen for Scalable, with an average RTT of 117 ms for a queue size of 100. The reason is that the loss-based algorithms use the packet loss as the index of congestion, so congestion is not judged to have occurred when the RTT increases. Therefore, although the amount of data should be suppressed, it is not controlled, and the network performance deteriorates. Among the delay-based and hybrid CCAs, some algorithms show a significant increase in RTT, while others do not. The delay-based NV algorithm and the hybrid Illinois, Westwood, and YeAH algorithms all suffer increases in the RTT with an increased queue size, similar to the loss-based algorithms. On the other hand, the RTT increases are slight for Vegas, BBR, and CDG compared to the other algorithms. In particular, Vegas and BBR show little change in RTT as the queue size increases: there is no change in Vegas from 4 ms or in BBR from 15 ms. Based on these observations, it can be said that Vegas and BBR are algorithms that keep the RTT at a constant value.