# On the Fidelity of NS-3 Simulations of Wireless Multipath TCP Connections
## 6 Results
### Mptcp Rtt  
RTT is an influential parameter in the network performance of MPTCP. The default MPTCP scheduler makes path selection decisions based on the RTT of each available path. When multiple subflows are available to transmit data, the default scheduler sends the data segments to the subflow with the minimum RTT to fill its congestion window first. Multiple congestion algorithms directly rely on RTT to calculate the congestion window size such as LIA (3), OLIA (4), and wVegas (7) and (8). Since the simulator MPTCP throughput results generally match the testbed results for downlink scenarios, we focus here on investigating the RTT for uplink experiments. Figure 11 shows the average RTT of LTE and Wi-Fi subflows observed during the uplink MPTCP experiment using Setup 1, whereas Table 3 presents the numerical RTT values and their corresponding standard deviation for the testbed (TB) and simulator (Sim). The figure depicts a clear difference in the RTT values, especially for the LTE interface, between the simulator and testbed, despite using the transmitter-receiver distance in the simulator that leads to recording the same LTE MCS and Wi-Fi signal at the receiver as the testbed following Equations (11)-(18) for the LTE network and Equation (19) (with Yans model) for the Wi-Fi network. Figure 10: Setup 2 Downlink MPTCP Throughput. Figure 9: Setup 1 Downlink MPTCP Throughput. Indeed, the difference in the average RTT values between subflows has a direct impact on the performance of MPTCP. When there is a similar difference in the average RTT between the Wi-Fi and LTE subflows, a close match is noticed in the throughput performance between the simulator and the testbed results, as observed for the LIA algorithm in Figure 5. On the contrary, a significant average RTT difference is noticed with wVegas, which leads to a different throughput performance between the simulator and testbed. The reason behind the different behavior in wVegas is that it is sensitive to the measurement accuracy of the \(base\_RTT_{i}\) parameter, which influences the calculation and evolution of the subflow weights (\(\alpha_{i}\)), and hence affects the effectiveness of the algorithm [34]. Figure 12 shows the average RTT values, and Table 4 provides the corresponding numerical values with their standard deviation observed when transferring a large data flow (75 MB) over the uplink in Setup 1. As denoted by the difference arrow in Figure 12, the difference in RTT (measured between the Wi-Fi subflow and the LTE subflow in the testbed and the simulator) is close among all the congestion control algorithms. This translates to a small difference in the throughput results of the simulator and testbed for large data volume as revealed in Figure 6.  
Regarding the effect of bottleneck links, Figure 13 depicts the average RTT values observed in Setup 2 for a relatively small flow size (20 MB). In addition, Table 5 presents the average and standard deviation of the RTT values for the same experiment. Generally, a significant difference is noticed between the RTT values of the LTE subflow and the Wi-Fi subflow. However, it is clearly shown in the figure that the RTT difference of the subflows measured with the testbed is smaller when compared to the simulation RTT values. As a result, the simulator experienced a varied throughput performance compared with the testbed, as demonstrated in Figure 7.  
For long-lived flows sharing a bottleneck link, Figure 14 displays the average RTT values observed with a larger data size (75 MB) in Setup 2, and Table 6 provides the standard deviation as well. The difference arrow apparently shows that the Wi-Fi subflow RTT value is 5-6 times greater than the LTE subflow RTT for all the congestion control algorithms for both the simulator and testbed.