# On the Fidelity of NS-3 Simulations of Wireless Multipath TCP Connections
## 6 Results
### Uplink MPTCP Throughput  
During uplink transmission, unlike real-time, when we try to start transmitting simultaneously on all nodes in the ns-3 simulator using DCE-_iperf_, the data transfer starts exactly at the same time on all nodes with no slight difference. Therefore, we compare the real hardware experimental results with the simulation case where all the sender nodes are scheduled to start their transmission nearly at the same time (10 ms second jitter is applied as recommended by ns-3 developers and experts [44; 45]). This allows the nodes to compete for the available network resources similar to practical scenarios.  
Figure 5 shows the MPTCP throughput for OLIA, LIA, Cubic, and wVegas algorithms obtained with the real hardware testbed and ns3-simulations using Setup 1. In this experiment, the data volume  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Wi-Fi Parameter** & **Value** \\ \hline Wi-Fi Standard & 802.11a \\ Wi-Fi Rate Manager & AarfWiFi Rate Manager \\ Wi-Fi Model & YansWiFi \\ Channel Width & 20 MHz \\ Wi-Fi TX-Power level & 30 dbm \\ Wi-Fi RX-sensitivity & \(-\)101 dBm \\ \hline \hline \end{tabular}
\end{table}
Table 2: Wi-Fi Simulation Parameterstransferred by the sending nodes is 20 MB. The results reveal that the throughput observed with the simulator is generally smaller than the testbed throughput results, where wVegas exhibits the largest and LIA the smallest throughput difference between the simulator and the testbed.  
The simulation results show the same throughput performance among the algorithms except for wVegas. However, the testbed demonstrates different throughput performance with different congestion control algorithms.  
Figure 6 presents the uplink MPTCP throughput obtained when the data volume is increased to 75 MB. The figure shows that the MPTCP throughput achieved with long-lived flows in ns-3 is much closer to the testbed throughput results than short-lived flows. In particular, Cubic exhibits a close match between the simulator and the testbed results. Similar to relatively short-lived flows, the simulator, as shown in Figure 6, demonstrates almost no difference in the throughput performance among the congestion control algorithms for long-lived flows, except with wVegas. Alternatively, a slight difference in throughput is observed among the congestion control algorithms with the testbed.  
For Setup 2, the testbed throughput results are also greater than the simulation results, as depicted in Figure 7. However, the throughput difference observed between the testbed and the simulator is significantly higher for 20 MB flows in Setup 2 than in Setup 1. Although the simulator shows the same throughput among the congestion control algorithms (except wVegas), the testbed shows a noticeable difference in throughput among them. Generally, the simulator gives different results from the hardware testbed for short-lived flows with Setup 2.  
Figure 5: Setup 1 uplink MPTCP throughput for 20 MB flows.  
Figure 6: Setup 1 Uplink MPTCP Throughput for 75 MB flows.  
The results from Figure 8 reveal that the difference between simulation and hardware testbed results in Setup 2 is smaller with long-lived flows (75 MB) than short-lived flows (shown in Figure 7). However, Figure 8 depicts that the throughput difference varies among algorithms since it is significant with the Cubic algorithm and almost vanishes with wVegas.  
In short, the simulator generally underestimates the uplink MPTCP throughput performance with short-lived flows. However, the simulation results match the testbed ones for long-lived uplink flows when no bottleneck link exists. With long-lived uplink flows passing through a bottleneck link, the simulator results match the testbed results with wVegas, but it slightly underestimates the throughput of LIA and OLIA and gives a noticeable lower throughput than the testbed with Cubic.