# Towards Adaptive Multipath Managing:
## 4 Performance Evaluation
### Simulation Results
Although the path management behaviors of both MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\) (removing or reconnecting a path in multipath transmission) influenced the jitter performance, which was occasionally less than that of the baseline MPTCP, we argue that this was acceptable and worthy of achieving high level performance since MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\) could adaptively select appropriate paths for multipathing. In contrast, the baseline MPTCP, as previously mentioned, was bound to out-of-order data reception (due to path  
Figure 9: The comparison of out-of-order Data Sequence Number (DSN). quality characteristics) and unnecessary retransmission (due to path failures), resulting in a lower quality of service than both MPTCP-LM\({}^{3}\) and MPTCP + (PU)\({}^{2}\)M\({}^{2}\). When comparing the MPTCP + (PU)\({}^{2}\)M\({}^{2}\) and MPTCP-LM\({}^{3}\) methods, it was noted that MPTCP + (PU)\({}^{2}\)M\({}^{2}\) more or less generated a higher level of jitter than MPTCP-LM\({}^{3}\). This was because MPTCP + (PU)\({}^{2}\)M\({}^{2}\) frequently deactivated or reactivated a path for data transmission, which incurred the additional overhead for data offloading and reordering and, thus, increased the amount of packet delay variations. In contrast, MPTCP + (PU)\({}^{2}\)M\({}^{2}\) provided a more stable path group for data transmission than MPTCP + (PU)\({}^{2}\)M\({}^{2}\), and it could possibly reduce the overhead of data offloading and reordering and correspondingly generate a lower level of jitter performance than MPTCP + (PU)\({}^{2}\)M\({}^{2}\). (5) Throughput performance: Figure 12 shows a comparison of throughput performance when using the three schemes. MPTCP + (PU)\({}^{2}\)M\({}^{2}\) and MPTCP-LM\({}^{3}\) prevented the usage of underperforming or broken paths in multipath transmission, which could not only reduce the probability of receiver buffer blocking, but also reduce transmission interruptions in the other high performing paths. Therefore, both MPTCP + (PU)\({}^{2}\)M\({}^{2}\) and MPTCP-LM\({}^{3}\) performed better than the baseline MPTCP. When comparing MPTCP + (PU)\({}^{2}\)M\({}^{2}\) and MPTCP-LM\({}^{3}\), it was noted that the MPTCP-LM\({}^{3}\) achieved higher association average throughput than the MPTCP + (PU)\({}^{2}\)M\({}^{2}\). This was because MPTCP + (PU)\({}^{2}\)M\({}^{2}\) detected an underperforming or a broken path by monitoring the delay changes of paths. This path estimation method was very sensitive to variations of delay and could cause throughput performance degradation because of frequently changing the paths in multipath transmission. In contrast, MPTCP-LM\({}^{3}\) declared an underperforming or a broken path by monitoring the receiver buffer blocking, and in this way, it helped MPTCP-LM\({}^{3}\) provide stable transmission performance. In order to illustrate the throughput comparison better, we calculated the cumulative average throughput of the three schemes respectively, by averaging the total average throughput values in a total of 100 s of simulation time. The subfigure in Figure 12 shows a comparison of cumulative average throughput when the three schemes were used, respectively. As the subfigure shows, MPTCP-LM\({}^{3}\) performed the best among the three schemes compared. However, it is noteworthy that the cumulative average throughput of MPTCP-LM\({}^{3}\) was about 2.8 Mbps, which corresponded only to 12% of the aggregated bandwidths of the three access links (10 Mbps + 11 Mbps + 2 Mbps = 23 Mbps). We argue that this phenomenon was caused by several reasons: (i) the VBR competing traffic could consume a certain amount of each path's access bandwidth; (ii) the two wireless loss models attached to each of the three access links could lead to the degradation of MPTCP throughput performance; (iii) the path failures on Path C will inevitably caused transmission interruption in Paths A and B and, thus,  
Figure 10: The comparison of end-to-end delay.