# Towards Adaptive Multipath Managing:
## 2 Problem Statement  
The asymmetric paths in a practical heterogeneous wireless environment with different transmission characteristics are more common and very sensitive to the variations of the real-time wireless condition. Because of this, the out-of-order data arrival will be an inevitable phenomenon in multipath transmission. What is worse, large numbers of out-of-order packets buffered in the constrained receiver buffer will result in the \"hot-potato\" receiver buffer blocking problem and thereby cause serious throughput performance degradations [22]. Several real-world measurement based studies on MPTCP reported that a huge path quality difference is a very important cause for MPTCP's low performance. [PERSON] et al. [23] performed a comprehensive large scale measurement on MPTCP in high speed mobility scenarios. Their study demonstrated that when Round-Trip Times (RTTs) in separate MPTCP paths differed, a significant out-of-order problem would arise, and the efficiency of MPTCP would be far from satisfactory. [PERSON] et al. [24] presented a measurement based study of MPTCP performance with real wireless settings and background traffic. Their study revealed that the MPTCP performance was affected by path characteristic differences in terms of RTTs and loss rates. In this paper, we are especially interested in understanding how the performance of MPTCP is affected when path characteristics are diverse and caused by path failure. Thus, we present a group of reasonable simulations to answer this question. We also seek to answer why an effective multipath management mechanism is necessary for MPTCP. To achieve the above purposes, we implemented a sample dual dumbbell network topology in Network Simulator 2 Version 2.35 (NS-2) [25], in which the MPTCP module [26] was included. The network topology is shown in Figure 2. An MPTCP sender and an MPTCP receiver were connected to each other through two independent end-to-end paths (A and B). The propagation delay of the edge links between the sender (or the receiver) and the routers was set to one microsecond with 100 Mbps of bandwidth. The bottleneck link between \(R_{1,0}\) and \(R_{1,1}\) (\(R_{2,0}\) and \(R_{2,1}\)) was set with a 10 Mbps bandwidth and a 50 milliseconds propagation delay. Path B failed after 30 s of simulation time (we simulated Path B failure by bringing down the bottleneck link between routers \(R_{2,0}\) and \(R_{2,1}\)). The total simulation time was 120 s with infinite FTP flows. Table 1 shows the parameters used in the simulations. Moreover, we performed two test cases named Case 1 and Case 2, which were examined as follows to investigate the effect of path transmission stability differences on the performance of MPTCP. Case 1. The sender turns on its first interface and turns off its second interface at the beginning of simulation, which means always only Path A is used in MPTCP for data transmission. Case 2. The sender turns on both of its interfaces, which means both Paths A and B are used in MPTCP. However, Path B suffered from network failure after 30 s of simulation time. Figures 3-5 illustrate the performance comparisons in terms of throughput, congestion window (_cwnd_), and out-of-order Data Sequence Number (DSN) when Case 1 and Case 2 were executed, respectively. As Figure 3 shows, compared with the MPTCP's throughput in Case 1, the MPTCP's throughput in Case 2 was gradually lowered from the former (before 30 s of simulation time) to backward (after 30 s of simulation time) due to failure on Path B. When a failure occurred on Path B from the 30 th s, it caused back-to-back timeouts on Path B (see Figure 4; the _cwnd_ size on Path B was always set to one after 30 s). As in the failure case, the MPTCP sender tried to transmit data after each of these timeouts on Path B (namely, unnecessary retransmission via the failure path [27]).