Multipath TCP Ramin Khalili INTERNET-DRAFT T-Labs/TU-Berlin Intended Status: Standard Track Nicolas Gast Expires: January 5, 2015 Miroslav Popovic Jean-Yves Le Boudec EPFL-LCA2 July 4, 2014 Performance Issues with MPTCP draft-khalili-mptcp-performance-issues-06 Abstract We show, by measurements over a testbed and by mathematical analysis, that the current MPTCP suffers from two problems: (P1) Upgrading some TCP users to MPTCP can reduce the throughput of others without any benefit to the upgraded users; and (P2) MPTCP users can be excessively aggressive towards TCP users. We attribute these problems to the "Linked Increases" Algorithm (LIA) of MPTCP [4], and more specifically, to an excessive amount of traffic transmitted over congested paths. Our results show that these problems are important and can be mitigated. We believe that the design of the congestion control of MPTCP should be improved. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2015. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html Khalili, et al. Expires January 5, 2015 [Page 1] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 MPTCP's LIA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Testbed Setup . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Scenario A: MPTCP can penalize regular TCP users . . . . . . . . 6 5 Scenario B: MPTCP can penalize other MPTCP users . . . . . . . . 8 6 Scenario C: MPTCP is excessively aggressive towards TCP users . 10 7 Can the suboptimality of MPTCP with LIA be fixed? . . . . . . . 12 8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 9.2 Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Khalili, et al. Expires January 5, 2015 [Page 2] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 1 Introduction Regular TCP uses a window-based congestion-control mechanism to adjust the transmission rate of users [2]. It always provides a Pareto-optimal allocation of resources: it is impossible to increase the throughput of one user without decreasing the throughput of another or without increasing the congestion cost [5]. It also guarantees a fair allocation of bandwidth among the users but favors the connections with lower RTTs [6]. Various mechanisms have been used to build a multipath transport protocol compatible with the regular TCP. Inspired by utility maximization frameworks, [7, 8] propose a family of algorithms. These algorithms tend to use only the best paths available to users and are optimal in static settings where paths have similar RTTs. In practice, however, they suffer from several problems [9]. First, they might fail to quickly detect free capacity as they do not probe paths with high loss probabilities sufficiently. Second, they exhibit flappiness: When there are multiple good paths available to a user, the user will randomly flip its traffic between these paths. This is not desirable, specifically, when the achieved rate depends on RTTs, as with regular TCP. Because of the issues just mentioned, the congestion control part of MPTCP does not follow the algorithms in [7, 8]. Instead, it follows an ad-hoc design based on the following goals [4]. (1) Improve throughput: a multipath TCP user should perform at least as well as a TCP user that uses the best path available to it. (2) Do no harm: a multipath TCP user should never take up more capacity from any of its paths than a regular TCP user. And (3) balance congestion: a multipath TCP algorithm should balance congestion in the network, subject to meeting the first two goals. MPTCP compensates for different RTTs and solves many problems of multipath transport [10, 11]: It can effectively use the available bandwidth, it improves throughput and fairness compared to independent regular TCP flows in many scenarios, and it solves the flappiness problem. We show, however, by measurements over our testbed and mathematical analysis, that MPTCP still suffers from the following problems: (P1) Upgrading some regular TCP users to MPTCP can reduce the throughput of other users without any benefit to the upgraded users. This is a symptom of non-Pareto optimality. (P2) MPTCP users can be excessively aggressive towards TCP users. We attribute these problems to the "Linked Increases" Algorithm (LIA) of MPTCP [4] and specially to an excessive amount of traffic transmitted over congested paths. Khalili, et al. Expires January 5, 2015 [Page 3] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 These problems indicate that LIA fails to fully satisfy its design goals, especially goal number 3. The design of LIA forces a trade off between optimal resource pooling and responsiveness, it cannot provide both at the same time. Hence, to provide good responsiveness, LIA's current implementation must depart from Pareto-optimality, which leads to problems (P1) and (P2). This document provides a number of examples and scenarios (Sections 4 to 6) in which MPTCP with LIA exhibits problems (P1) and (P2). Our results show that the identified problems with LIA are important. Moreover, we show in Section 7 that these problems are not due to the nature of a window-based multipath protocol, but rather to the design of LIA; it is possible to build an alternative to LIA that mitigates these problems and is as responsive and non-flappy as LIA. Hence, we believe that the design of the congestion control of MPTCP should be improved. 1.1 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 1.2 Terminology Regular TCP: The standard version of TCP that operates between a single pair of IP addresses and ports [2]. Multipath TCP: A modified version of the regular TCP that allows a user to spread its traffic across multiple paths. MPTCP: The proposal for multipath TCP specified in [3]. LIA: The "Linked Increases" Algorithm of MPTCP (the congestion control of MPTCP) [4]. OLIA: The Opportunistic "Linked Increases" Algorithm for MPTCP proposed in [12]. RTT: The Round-Trip Time seen by a user. MSS: The Maximum Segment Size that specifies the largest amount of data can be transmitted by a TCP packet. AP: Access Point. Khalili, et al. Expires January 5, 2015 [Page 4] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 2 MPTCP's LIA The design of the congestion control algorithm of MPTCP has been described in details by Mark Handly et al. at the 77th IETF meeting in Anaheim [13]. The actual implementation of the congestion control algorithm, called "Linked Increases" Algorithm (LIA), increases the window size w_r by a quantity proportional to w_r /w_tot for each ACK received on path r (see [13, slide 3]). w_tot is the sum of the congestion windows over all paths available to the user. LIA is one of a family of multipath congestion control algorithms that can be indexed by a parameter 0p1then w2=0 and w1>0). It correspond to the fully coupled algorithm of [7] and is flappy [9]. * phi=2 corresponds to having uncoupled TCP flows on each of the path. It is very responsive and non-flappy, but does not balance congestion in the network. * phi=1 correspond to LIA and is described in RFC6356 [4]. It provides a compromise between congestion balancing and responsiveness. 3 Testbed Setup To investigate the behavior of MPTCP in practice, three testbed topologies are created representing scenarios in Sections 4, 5, and 6. We use server-client PCs that run MPTCP enabled Linux kernels. We use MPTCP for the Linux kernel 3.0.0 released in February 2012. In all our scenarios, laptop PCs are used as routers. We install "Click Modular Router" software [14] on the routers to implement topologies with different characteristics. Iperf is used to create multiple connections. In our scenarios, we are able to implement links with configurable bandwidth and delay. We are also able to set the parameters of the RED queues following the structure in [15]. For a 10 Mbps link, we set the packet loss probability equal to 0 up to a queue size of 25 Maximum Segment Size (MSS). Then it grows linearly to the value 0.1 at 50 MSS. It again increases linearly up to 1 for 100 MSS. The parameters are proportionally adapted when the link capacity changes. To verify that the problems observed are caused by the congestion- control algorithm of MPTCP and not by some unknown problems in our testbed, we perform a mathematical analysis of MPTCP. This analysis Khalili, et al. Expires January 5, 2015 [Page 5] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 is based on the fix point analysis of MPTCP. As we will see, our mathematical results confirm our measurement results. The details of these mathematical analyses are available in [12]. 4 Scenario A: MPTCP can penalize regular TCP users Consider a network with two types of users. There are N1 users of type1, each with a high-speed private connection. These users access different files on a media streaming server. The server has a network connection with capacity limit of N1C1 Mbps. Type1 users can activate a second connection through a shared AP by using MPTCP. There are also N2 users of type2; they are connected to the shared AP. They download their contents from the Internet. The shared AP has a capacity of N2C2 Mbps. We implement this scenario in a testbed similarly to Figure 1. Within router-PCs R1 and R2, we implement links with capacities N1C1 and N2C2 and RTTs of 150 ms (including queuing delay), modeling the bottleneck at the server side and the shared AP, respectively. High speed connections are used to implement private connections of type1 users. When type1 users use only their private connection, each type1 user receives a rate of C1 and each type2 user receives a rate of C2. By upgrading type1 users to MPTCP, we observe, through measurement and by mathematical analysis, that the throughput of type2 users significantly decreases. However, type1 users receive the same throughput as before, because the bottleneck for their connections is at the server side. We report the throughput received by users after upgrading type1 users to MPTCP on Table 1 for C1=C2=1 Mbps. For each case, we take 5 measurements. In each case, the confidence intervals are very small (less than 0.01Mbps). _____ N1 | | /-- Servers Type1 ------- high speed -------|N1.C1|--|--- For type1 users ---\ connections /--|_____| \-- Users \ / router R2 \ / \ _____ / \--| |--/ N2 |N2.C2| /-- Servers Type2 ----------|_____|-------------|--- For type 2 users router R1 \-- Users Figure 1: Testbed implementation of Scenario A: router R1 implements the bottleneck at the server side and router R2 implements the shared AP bottleneck. Khalili, et al. Expires January 5, 2015 [Page 6] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 In [12 Section3.2], we provide a mathematical analysis of MPTCP that confirm our measurements: The predicted rate of type1 users is always 1 and the predicted rate for type2 users is, respectively, 0.74 when N1=N2=10 and 0.50 when N1=30 and N2=10. +-------------+------------------------------------+ | Type1 users | Type1 users are multipath | | are |---------+--------------------------| | single path | MPTCP | optimal algorithm | | | |with p. cost|w/out p. cost| |(measurement)| (meas.) | (theory) | (theory) | +------+-------------+---------+------------+-------------+ N1=10 |type1 | 0.98 | 0.96 | 1 | 1 | +------+-------------+---------+------------+-------------+ N2=10 |type2 | 0.98 | 0.70 | 0.94 | 1 | ------+------+-------------+---------+------------+-------------+ N1=30 |type1 | 0.98 | 0.98 | 1 | 1 | +------+-------------+---------+------------+-------------+ N2=10 |type2 | 0.98 | 0.44 | 0.8 | 1 | +------+-------------+---------+------------+-------------+ meas.=measurements, p.=probing, w/out=without, Values are in Mbps. Table 1: Throughput obtained by type1 and type2 users in Scenario A: upgrading type1 users to MPTCP decrease the throughput of type2 with no benefit for type1 users. The problem is much less critical using optimal algorithm with probing cost. We observe that MPTCP exhibits problem (P1): upgrading type1 users to MPTCP penalizes type2 users without any gain for type1 users. As the number of type1 users increases, the throughput of type2 users decreases, but the throughput of type1 users does not change as it is limited by the capacity of the streaming server. For N1=N2, type2 users see a decrease of 30%. When N1=3N2, this decrease is 55%. We compare the performance of MPTCP with two theoretical baselines. They serve as references to see how far from the optimum MPTCP with LIA is. We show in Section 7 that it is possible to replace LIA by an alternative that keeps the same non-flappiness and responsiveness and performs closer to the optimum. The first baseline is an algorithm that provides theoretical optimal resource pooling in the network (as discussed in [7] and several other theoretical papers). We refer to it as "optimal algorithm without probing cost". In practice, however, the value of the congestion windows are bounded below by 1 MSS. Hence, with a window-based congestion-control algorithm, a minimum probing traffic of 1 MSS per RTT will be sent Khalili, et al. Expires January 5, 2015 [Page 7] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 over a path. We introduce a second theoretical baseline, called "optimal algorithm with probing cost"; it provides optimal resource pooling in the network given that a minimum probing traffic of 1 MSS per RTT is sent over each path. We show the performance of these optimal algorithms in Table 1. Using an optimal algorithm with probing cost, the entire capacity of the shared AP is allocated to type2 users. Hence, all the users in the network receives a throughput of 1 Mbps. By using an optimal algorithm with probing cost, type1 users will send only 1MSS per RTT over the shared AP. Hence, we observe a decrease on the throughput of type2 users. However, the decrease is much less than what we observe using MPTCP. The performance of our proposed alternative to LIA is shown in Section 7, Table 4. This performance problem of MPTCP can be explained by the fact that LIA does not fully balance congestion. For N1=N2, we observe through measurements that p1=0.009 and p2=0.02 (the probability of losses at routers R1 and R2). For N1=3N2, the value of p1 remains almost the same and p2 increases to p2=0.05. LIA excessively increases congestion on the shared AP, which is not in compliance with goal 3. In [12], we propose an alternative to LIA. Using this algorithm, we have p1=0.009 and p2=0.012 for N1=10 and 0.018 for N1=30. Hence, it is possible to provide a better congestion balancing in the network. Because of some practical issues, we did not study larger number of connections in our testbed. However, we have mathematical results (using LIA's loss-throughput formula [12]) as well as simulation results (using a flow-level simulator) that confirm our observation for larger number of connections. 5 Scenario B: MPTCP can penalize other MPTCP users Consider a multi-homing scenario as follows. We have four Internet Service Providers (ISPs), X, Y, Z, and T. Y is a local ISP in a small city, which connects to the Internet through Z. X, Z, and T are nation-wide service providers and are connected to each other through high speed links. X provides Internet services to users in the city and is a competitor of Y. They have access capacity limits of CX, CY, CZ, and CT. Z and T are hosts of different video streaming servers. There are two types of users: Blue users download contents from servers in Z and Red users download from servers in ISP T. To increase their reliability, Blue users use multi-homing and are connected to both ISPs X and Y. Red users can connect either only to Y or to both X and Y . We implement the scenario in a testbed similar to Figure 2. b1 and b2 Khalili, et al. Expires January 5, 2015 [Page 8] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 are the paths available to Blue users. Red users use the path r1, but can upgrade to MPTCP by establishing a second connection through path r2. The measurement results are reported in Table 2 for a setting with CX=27, CT=36, and CY=CZ=100, all in Mbps, where we have 15 Red and 15 Blue users. RTTs are around 150 ms (including queuing delay) over all paths. We also show the performance of theoretically optimal algorithms with and without probing cost. ____ ____ Blue |------b1---| |-----------b1----------| |-b1-\ Servers Users|-\ | X | | Z | | for \ ..|____|.. /-|____|-b2-/ Blue users \ . . / b2 r2 r2 b2 \. . / .\ ____ . ____ / . \---| |--b2--.--| |-/ Red |... | Y | ..| T |...r2...\ Servers for Users |--r1------|____|--r1-----|____|---r1----| Red users Figure 2. Testbed implementation of Scenario B. Blue users transmit over path b1 and b2. Red users use path r1, but can upgrade to MPTCP by establishing a second connection through path r2. +-------------------------+-------------------------+ |Red users are single-path| Red users are multipath | |-------------------------+-------------------------+ | Blue users use | Blue and Red users use | | MPTCP |optimal algorithm| MPTCP |optimal algorithm| | |with p. |w/out p.| |with p. |w/out p.| | | cost | cost | | cost | cost | |(meas.)|(theory)|(theory)|(meas.)|(theory)|(theory)| +-----------+-------+--------+--------+-------+--------+--------+ |Red users | 1.5 | 2.1 | 2.1 | 1.4 | 2.04 | 2.1 | +-----------+-------+--------+--------+-------+--------+--------+ |Blue users | 2.5 | 2.1 | 2.1 | 2.0 | 2.04 | 2.1 | +-----------+-------+--------+--------+-------+--------+--------+ meas.=measurements, p.=probing, w/out=without, Values are in Mbps. Table 2: Throughput received by users before and after upgrading Red users to MPTCP. We have 15 Red and 15 Blue users. By upgrading Red users to MPTCP, the aggregate throughput of users decreases by 13% with no benefit for Red users. We observe that when Red users only connect to ISP Y, the aggregate throughput of users is close to the cut-set bound, 63 Mbps. However, Blue users get a higher share of the network bandwidth. Now, let's consider that Red users upgrade to MPTCP by establishing a second Khalili, et al. Expires January 5, 2015 [Page 9] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 connection through X (showed by pointed-line in Figure 2). Our results in Table 1 show that Red users do not receive any higher throughput. However, the average rate of Blue users drops by 20%, which results in a drop of 13% in aggregate throughput. In [12 Section 3.3], we also provide a mathematical analysis of MPTCP. Our mathematical results predict that by upgrading the Red user to MPTCP the rate of Blue users will be reduced by 21%. This results in 14% decrease in the aggregate throughput. Hence, our mathematical results confirm our observations from the measurement. Similar behavior is predicted for other values of CX and CT [12 Figure 4a]. Using an optimal algorithm without probing cost, Red users transmit only over path r1 and Blue users split their traffic over paths b1 and b2 to equalize the rate of blue and red users. Upgrading Red users to multipath does not change the allocation. Hence, we observe no decrease in the aggregate throughput and the rate of each user. By using an optimal algorithm with probing cost, the rate of Blue and Red users decreases by 3% when we upgrade the Red users to multipath users since red users are forced to send 1 MSS per RTT over path r2. This decrease is much less than what we observe using MPTCP with LIA. The performance of our proposed alternative to LIA is shown in Section 7, Table 5. Similarly to Scenario A, the problem can be attributed to the excessive amount of traffic sent over the congested paths. This illustrates that MPTCP fails to balance the congestion in the network. 6 Scenario C: MPTCP is excessively aggressive towards TCP users Consider a scenario with N1 multipath users, N2 single-path users, and two APs with capacities N1C1 and N2C2 Mbps. Multipath users connect to both APs and they share AP2 with single-path users. The users download their contents from the Internet. This scenario is implemented in a testbed similar to Figure 3. If the allocation of rates is proportionally fair, multipath users will use AP2 only if C1C2, a fair multipath user will not transmit over AP2. However, using MPTCP with LIA, multpath users receive a disproportionately larger share of bandwidth. We implement the scenario in our testbed and measure the performance of MPTCP with LIA. We report the throughput received by single-path and multipath users in Table 3. We present the results for N2=10 and two values of N1=10 and 30, where C1=C2=1 Mbps. RTTs are around 150 Khalili, et al. Expires January 5, 2015 [Page 10] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 ms (including queuing delay). We also present the performance of optimal (proportionally fair) algorithms. _____ N1 | | /-- Servers multipath -------------|N1.C1|---------|---|--- For multipath users ----\ |_____| /--| \-- Users \ router R1 / \ / \ _____ / N2 \--| |--/ single-path |N2.C2| /-- Servers users --------|_____|---------|--- For single-path router R2 \-- Users Figure 3: Testbed implementation of Scenario C: routers R1 and R2 implement AP1 and AP2 with capacities N1C1 and N2C2 Mbps. +---------------+--------------------------+ |multipath users| multipath users use | | use | optimal algorithm | | MPTCP |with p. cost|w/out p. cost| | (measurement) | (theory) | (theory) | +-----------------+---------------+------------+-------------+ N1=10 |multipath users | 1.3 | 1.04 | 1 | +-----------------+---------------+------------+-------------+ N2=10 |single-path users| 0.68 | 0.94 | 1 | +-----+-----------------+---------------+------------+-------------+ N1=30 |multipath users | 1.19 | 1.04 | 1 | +-----------------+---------------+------------+-------------+ N2=10 |single-path users| 0.38 | 0.8 | 1 | +-----------------+---------------+------------+-------------+ p.=probing, w/out=without, Values are in Mbps. Table3: Throughput obtained by single-path and multipath users in Scenario C: MPTCP is excessively aggressive toward TCP users and performs far from how an optimal algorithm would perform. As C1=C2, for any fairness criterion, multipath users should not use AP2. Our results show that, MPTCP users are disproportionately aggressive and exhibit problem (P2). Hence, single-path users receive a much smaller share than they should. For N1=N2, single-path users see a decrease of about 30% in their received throughput compared to a fair allocation. When N1=3N2, this decrease is around 55%. These measurements are confirmed by our mathematical analysis as shown in [12 Section 3.4]. The predicted rate of type1 users is 1.3 Khalili, et al. Expires January 5, 2015 [Page 11] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 for N1=N2=10 and is 1.17 when N1=30 and N2=10. For type2 users, the predicted rate is 0.7 when N1=N2=10 and 0.48 when N1=30 and N2=10. An optimal algorithm with probing cost provide a proportional fairness among the users. By using an optimal algorithm with probing cost, single-path users receive a rate less than what a proportionally fair algorithm will provide them. However, as we observe, the problem is much less critical compared to the case we use MPTCP. The performance of our proposed alternative to LIA is shown in Section 7, Table 6. These results clearly show that MPTCP suffers from fairness issues. The problem occurs because LIA fails to fully satisfy goal 3. As in Scenarios A and B, MPTCP sends an excessive amount of traffic over the congested paths. 7 Can the suboptimality of MPTCP with LIA be fixed? We have shown in Section 4, 5, and 6 that MPTCP with LIA performs far behind an optimal algorithm. The question is, "is it possible to modify the congestion control algorithm of MPTCP to perform closer to the optimum". To answer this question, we implement a new congestion control algorithm for MPTCP, called Opportunistic "Linked Increases" Algorithm (OLIA). OLIA is described in [13] and its performance is analyzed in [12]. In this section, we show that in Scenarios A, B and C OLIA performs close to an optimal algorithm with probing cost. Moreover, as shown in [12, Sections 4.3 and 6.2], OLIA keeps the same non-flappiness and responsiveness as LIA. Contrary to LIA, OLIA's design is not based on a trade-off between responsiveness and optimal resource pooling. OLIA couples the additive increases and uses unmodified TCP behavior in the case of a loss. The difference between LIA and OLIA is in the increase part. OLIA's increase part two has terms: * The first term is an adaptation of the increase term of the optimal algorithm in [7]. This term is essential to provide congestion balancing and fairness. * The second term guarantees responsiveness and non-flappiness of OLIA. By measuring the number of transmitted bytes since the last loss, it reacts to events within the current window and adapts to changes faster than the first term. Because OLIA is rooted in the optimal algorithm of [7], it can provide fairness and congestion balancing. Because of the second term, it is responsive and non-flappy. We implemented OLIA by modifying the congestion control part of the MPTCP implementation based on the Linux Kernel 3.0.0. For conciseness, we do not describe OLIA in this paper and refer to [12] Khalili, et al. Expires January 5, 2015 [Page 12] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 for details about the algorithm and its implementation. +-------------+----------------------------------------+ | Type1 users | Type1 users are multipath | | are |-------------+--------------------------| | single path |MPTCP w. OLIA| optimal algorithm | | | [with LIA] |with p. cost|w/out p. cost| |(measurement)|(measurement)| (theory) | (theory) | +------+-------------+-------------+------------+-------------+ N1=10 |type1 | 0.98 |0.98 [0.96] | 1 | 1 | +------+-------------+-------------+------------+-------------+ N2=10 |type2 | 0.98 |0.86 [0.70] | 0.94 | 1 | ------+------+-------------+-------------+------------+-------------+ N1=30 |type1 | 0.98 |0.98 [0.98] | 1 | 1 | +------+-------------+-------------+------------+-------------+ N2=10 |type2 | 0.98 |0.75 [0.44] | 0.8 | 1 | +------+-------------+-------------+------------+-------------+ p.=probing, w.=with, w/out=without, Values are in Mbps. Table 4. Performance of MPTCP with OLIA compared to MPTCP with LIA in scenario A. We show the throughput obtained by users before and after upgrading type1 users to MPTCP. The values in brackets are the values for MPTCP with LIA (taken from table 1). +----------------------------+----------------------------+ | Red users are single-path | Red users are multipath | |----------------------------+----------------------------+ | Blue users use | Blue and Red users use | | MPTCP |optimal algorithm| MPTCP |optimal algorithm| |with OLIA |with p. |w/out p.|with OLIA |with p. |w/out p.| |[with LIA]| cost | cost |[with LIA]| cost | cost | | (meas.) |(theory)|(theory)| (meas.) |(theory)|(theory)| +-----------+----------+--------+--------+----------+--------+--------+ |Red users |1.8 [1.5]| 2.1 | 2.1 |1.7 [1.4]| 2.04 | 2.1 | +-----------+----------+--------+-- -----+----------+--------+--------+ |Blue users |2.2 [2.5]| 2.1 | 2.1 |2.2 [2.0]| 2.04 | 2.1 | +-----------+----------+--------+--------+----------+--------+--------+ meas.=measurements, p.=probing, w/out=without, Values are in Mbps. Table 5. Performance of MPTCP with OLIA compared to MPTCP with LIA in scenario B. We show the throughput received by users before and after upgrading Red users to MPTCP. The values in brackets are the values for MPTCP with LIA (taken from Table 2). Khalili, et al. Expires January 5, 2015 [Page 13] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 +---------------+--------------------------+ |multipath users| multipath users use | | use | optimal algorithm | |MPTCP with OLIA|with probing|w/out probing| | [with LIA] | cost | cost | |(measurement) | (theory) | (theory) | +-----------------+---------------+------------+-------------+ N1=10 |multipath users | 1.11 [1.30] | 1.04 | 1 | +-----------------+---------------+------------+-------------+ N2=10 |single-path users| 0.88 [0.68] | 0.94 | 1 | ------+-----------------+---------------+------------+-------------+ N1=10 |multipath users | 1.1 [1.19] | 1.04 | 1 | +-----------------+---------------+------------+-------------+ N2=10 |single-path users| 0.72 [0.38] | 0.8 | 1 | +-----------------+---------------+------------+-------------+ meas.=measurements, w/out=without, Values are in Mbps. Table 6. Performance of MPTCP with OLIA compared to MPTCP with LIA in scenario C. We show the throughput obtained by single-path and multipath users. The values in brackets are the values for MPTCP with LIA (taken from Table 3). We study the performance of MPTCP with OLIA through measurements in Scenarios A, B, and C. The results are reported in Tables 4, 5 and 6. We compare the performance of our algorithm with MPTCP with LIA and with optimal algorithms. We observe that in all cases, MPTCP with OLIA provide a significant improvement over MPTCP with LIA. Moreover, it performs close to an optimal algorithm with probing cost. The results show that it is possible to perform close to an optimal algorithm with probing cost by using a TCP-like algorithm. Moreover, we show in [12, Section 4.3 and Section 6.2] that MPTCP with OLIA is as responsive and non-flappy as MPTCP with LIA. This shows that it is possible to build a practical multi-path congestion control that works close to an optimal algorithm with probing cost. In [17], Chen et al. study how MPTCP with LIA and OLIA performs in the wild with a common wireless environment, namely using both WiFi and Cellular simultaneously. Their results show that MPTCP with OLIA is very responsive to the changes in the environment and always outperforms MPTCP with LIA. Furthermore, using Experimental Design, Paasch et al. [8] show that MPTCP with OLIA satisfy the design goal of MPTCP in a very wide range of scenarios and always outperform MPTCP with LIA. Khalili, et al. Expires January 5, 2015 [Page 14] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 8 Conclusion We have shown that MPTCP with LIA suffers from important performance issues. Moreover, it is possible to build an alternative to LIA that performs close to an optimal algorithm with probing cost while being as responsive and non-flappy as LIA. Hence, we believe that mptcp working group should revisit the congestion control part of MPTCP and that an alternative algorithm, such as OLIA [12], should be considered. 9 References 9.1 Normative References [2] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. [3] Ford, A., Raiciu, C., Greenhalgh, A., and M. Handley, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. 9.2 Informative References [4] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011. [5] F.P. Kelly. Mathematical modelling of the internet. Mathematics unlimited-2001 and beyond. [6] F.P. Kelly, A.K. Maulloo, and D.K.H. Tan. Rate control for communication networks: shadow prices, proportional fairness and stability. Journal of the Operational Research society, 49, 1998. [7] Kelly, F. and T. Voice, "Stability of end-to-end algorithms for joint routing and rate control", ACM SIGCOMM CCR vol. 35 num. 2, pp. 5-12, 2005. [8] H. Han, S. Shakkottai, CV Hollot, R. Srikant, and D. Towsley. "Multi-path tcp: a joint congestion control and routing scheme to exploit path diversity in the internet", Trans. on Net., 14, 2006. [9] D. Wischik, M. Handly, and C. Raiciu. "Control of multipath tcp and optimization of multipath routing in the internet", NetCOOP, 2009. Khalili, et al. Expires January 5, 2015 [Page 15] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 [10] D. Wischik, C. Raiciu, A. Greenhalgh, and M. Handly. "Design, implementation and evaluation of congestion control for multipath tcp", Usenix NSDI, 2011. [11] C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D. Wischik, and M. Handly. "Improving datacenter performance and robustness with multipath tcp", ACM Sigcomm, 2011. [12] R. Khalili, N. Gast, M. Popovic, U. Upadhyay, and J.-Y. Le Boudec. "MPTCP is not Pareto-optimality: Performance issues and a possible solution", ACM CoNEXT 2012 (The extended version is published at IEEE/ACM Transaction of Networking, volume 5, issue 25, October 2013). [13] M. Handly, D. Wischik, C. Raiciu, "Coupled Congestion Control for MPTCP", presented at 77th IETF meeting, Anaheim, California. . [14] B. Chen J. Jannotti E. Kohler, R. Morris and M. F. Kaashoek. "The click modular router", Trans. Comput. Syst., 18, August 2000. [15] S. Floyd and V. Jacobson. "Random early detection gateways for congestion avoidance", Trans. on Net., 1, August, 1993. [16] R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec, "Opportunistic Linked-Increases Congestion Control Algorithm for MPTCP", draft-khalili-mptcp-congestion- control-05. [17] Chen Y.-C, Y.-S. Lim, R. J. Gibbens, E. M. Nahum, R. Khalili, and D. Towsley, "A Measurement-based Study of Multipath TCP Performance over Wireless Networks." ACM IMC 2013. [18] C. Paasch, R. Khalili, and O. Bonaventure, "On the Benefits of Applying Experimental Design to Improve Multipath TCP." ACM CoNEXT 2013. Khalili, et al. Expires January 5, 2015 [Page 16] INTERNET DRAFT Performance Issues with MPTCP July 4, 2014 Authors' Addresses Ramin Khalili T-Labs/TU-Berlin TEL 18, Ernst-Reuter-Platz 7 10587 Berlin Germany Phone: +49 16 0972 28074 EMail: ramin@net.t-labs.tu-berlin.de Nicolas Gast EPFL IC ISC LCA2 Station 14 CH-1015 Lausanne Switzerland Phone: +41 21 693 1254 EMail: nicolas.gast@epfl.ch Miroslav Popovic EPFL IC ISC LCA2 Station 14 CH-1015 Lausanne Switzerland Phone: +41 21 693 6466 EMail: miroslav.popovic@epfl.ch Jean-Yves Le Boudec EPFL IC ISC LCA2 Station 14 CH-1015 Lausanne Switzerland Phone: +41 21 693 6631 EMail: jean-yves.leboudec@epfl.ch Khalili, et al. Expires January 5, 2015 [Page 17]