# Towards Adaptive Multipath Managing:
## 4 Performance Evaluation
### Simulation Results  
We here compare the performance of our MPTCP-LM\({}^{3}\) with the baseline MPTCP [7] and our previous work (PU)\({}^{2}\)M\({}^{2}\)[14]. For convenience, we portray the results of MPTCP-LM\({}^{3}\) as \"MPTCP-LM\({}^{3}\)\" in the result figures, and the results when applying the baseline MPTCP and (PU)\({}^{2}\)M\({}^{2}\) schemes are portrayed as \"the baseline MPTCP\" and \"MPTCP + (PU)\({}^{2}\)M\({}^{2}\)\", respectively. (1) Sending and receiving data DSN: Figure 8 shows the comparison results of data sending and receiving times when the baseline MPTCP, MPTCP + (PU)\({}^{2}\)M\({}^{2}\), and MPTCP-LM\({}^{3}\) were used, respectively. In order to better illustrate the comparison, the results between t = 30 s and t = 100 s are illustrated (including the no path failure phase (between 30 s to 50 s) and path failure phase (after 50 s)), representative for all the simulation results. From the figure, we can observe that between 30 and 50 s of simulation time, MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\) performed at a lower level of data sending and receiving times than the baseline MPTCP. This was because the baseline MPTCP fully utilized the three paths for data transmission (Path C was available and reused in multipath transmission after 30 s). In both MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\), Path C may be prevented from multipathing due to the quality gap (compared with Paths A and B). \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Network Parameters** & **Path A** & **Path B** & **Path C** \\ \hline Wireless access bandwidth & 10 Mbps & 11 Mbps & 2 Mbps \\ Wireless link delay & 10–20 ms & 10–20 ms & 10–60 ms \\ Wireless link queue type & Droptail & Droptail & Droptail \\ Core network bandwidth & 100 Mbps & 100 Mbps & 100 Mbps \\ Core network delay & 30 ms & 30 ms & 30 ms \\ Uniform loss rate & 1–2\% & 1–4\% & 1–6\% \\ Markov loss rate & 1\% & 1\% & 1\% \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Path parameter configuration used in the simulation. Figure 7: Simulation topology. However, MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\) could achieve a higher level of data sending and receiving times than the baseline MPTCP after 50 s. This was because in both MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\), the sender only selected the stable paths for multipath transmission, while in the baseline MPTCP, the path failure declaring was inherited from TCP's operations (in the TCP, the time required to declare a broken path needs at least \(1+3+6+12+24=46\) s (_TcpMaxDataRetransmissions_\(=5\) and _RTO_\(=1\) s)). That is, between 50 and 100 s, the broken Path C could also be used in multipath transmission, which caused the interruptions in Paths A and B and, thus, constrained the sender from transmitting data traffic. Besides, we can also see that between 50 and 70 s of simulation time, MPTCP + LM\({}^{3}\) achieved a lower level of data sending and receiving times than the MPTCP + (PU)\({}^{2}\)M\({}^{2}\) scheme. This was because MPTCP + LM\({}^{3}\) detected path failures based on the counts of receiver buffer blocking, while MPTCP + (PU)\({}^{2}\)M\({}^{2}\) was based on the path's delay variations, which means MPTCP + LM\({}^{3}\) could possibly find out and prevent the usage of a broken path or a poorly performing path more slowly than MPTCP + (PU)\({}^{2}\)M\({}^{2}\). However, in MPTCP + (PU)\({}^{2}\)M\({}^{2}\), a path could be removed/reconnected frequently if its delay performance was getting worse accidentally or suddenly. This limitation made MPTCP + (PU)\({}^{2}\)M\({}^{2}\) not able to provide stable transmission efficiency and perform worse than MPTCP + LM\({}^{3}\) in the rest of the simulation time (between 70 and 100 s). (2) Out-of-order DSN: The Out-Of-Order DSN (OOO DSN) is a good metric to select for studying and analyzing the performance of multipath protocols.