MPTCP is not Pareto-Optimal: Performance Issues and a
Possible Solution
∗
Ramin Khalili
†
, Nicolas Gast, Miroslav Popovic, Utkarsh Upadhyay, Jean-Yves Le Boudec
EPFL, IC-LCA2, Switzerland
firstname.lastname@epfl.ch
ABSTRACT
MPTCP has been proposed recently as a mechanism for sup-
porting transparently multiple connections to the applica-
tion layer. It is under discussion at the IETF. We show,
however, that the current MPTCP suffers from two prob-
lems: (P1) Upgrading some TCP users to MPTCP can re-
duce the throughput of others without any benefit to the
upgraded users, which is a symptom of not being Pareto-
optimal; and (P2) MPTCP users could be excessively ag-
gressive towards TCP users. We attribute these problems to
the linked-increases algorithm (LIA) of MPTCP and, more
specifically, to an excessive amount of traffic transmitted
over congested paths.
The design of LIA forces a tradeoff between optimal re-
source pooling and responsiveness. We revisit the problem
and show that it is possible to provide these two proper-
ties simultaneously. We implement the resulting algorithm,
called opportunistic linked increases algorithm (OLIA), in
the Linux kernel, and we study its performance over our
testbed, by simulations and by theoretical analysis. We
prove that OLIA is Pareto-optimal and satisfies the design
goals of MPTCP. Hence it can avoid the problems P1 and
P2. Our measurements and simulations indicate that MPTCP
with OLIA is as responsive and non-flappy as MPTCP with
LIA, and that it solves problems P1 and P2.
Categories and Subject Descriptors
C.2 [Computer-communication Networks]: Network Pro-
tocols.; C.4 [Performance of Systems]: Design studies,
Modeling techniques.
Keywords
Multipath TCP, Congestion control algorithm, Protocol de-
sign, Performance evaluation.
∗
This research has received funding from the EU 7th Frame-
work Programme (FP7/2007-2013) under grant agreement
n. 257740 (Network of Excellence ”TREND”).
†
Ramin Khalili is currently affiliated with T-Labs/TU
Berlin, ramin@net.t-labs.tu-berlin.de.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
CoNEXT’12, December 10–13, 2012, Nice, France.
Copyright 2012 ACM 978-1-4503-1775-7/12/12 ...$15.00.
1. INTRODUCTION
The regular TCP uses a window-based congestion-control
mechanism to adjust the transmission rate of users [1]. 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 [2]. It also guarantees a fair allocation
of bandwidth among the users, but favors the connections
with lower RTT [3].
Various mechanisms were used to build a multipath trans-
port protocol compatible with the regular TCP. Authors
of [4–6] propose a family of algorithms inspired by utility
maximization frameworks. 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 [7–9]. First, they
sometimes 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 be-
tween these paths. This is not desirable, specifically, when
the achieved rate depends on RTTs, as with TCP.
MultiPath TCP (MPTCP) is a concrete proposal for mul-
tipath transport; it is under discussion at the IETF [10].
Because of the issues aforementioned, its congestion control
part does not follow the algorithms in [4–6]. Instead, it fol-
lows an ad-hoc design based on the following goals [10]: (1)
Improve throughput: a multipath TCP user should perform
at least as well as a TCP user that uses the best path avail-
able 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 [7, 9]: It can effectively
use the available bandwidth; compared to independent TCP
flows, it improves throughput and fairness in many scenar-
ios; and it solves the flappiness problem. Through analysis
and by using measurements over a testbed, we show, how-
ever, 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 ben-
efit 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”algo-
1
rithm (LIA) of MPTCP [10] and specifically to an excessive
amount of traffic transmitted over congested paths. These
problems indicate that MPTCP fails to fully satisfy its de-
sign goals, especially goal 3.
The design of LIA forces a tradeoff between optimal re-
source 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. We revisit the design
and show that it is possible to simultaneously provide both
properties. We introduce OLIA, the “opportunistic linked
increases algorithm”, as an alternative to LIA. Based on
utility maximization frameworks, we prove that OLIA is
Pareto-optimal. Hence it can avoid the problems P1 and
P2. Furthermore, its construction makes it as responsive
and non-flappy as LIA.
OLIA is a window-based congestion-control mechanism.
Similarly to LIA, it couples the additive increases and uses
unmodified TCP behavior in the case of a loss. OLIA’s
increase part, Equation (5), has two terms:
• The first term is an adaptation of the increase term of
Kelly and Voice’s algorithm [4]. This term is essential
to provide Pareto-optimality.
• The second term guarantees responsiveness and non-
flappiness of OLIA. By measuring the number of trans-
mitted bits since the last loss, it reacts to events within
the current window and adapts to changes faster than
the first term.
By adapting the window increases as a function of RTTs,
OLIA also compensates for different RTTs.
We implement OLIA in the Linux kernel and study its
performance over our testbed, by simulations and by the-
oretical analysis. Using a fluid model of OLIA based on
differential inclusion, we prove that OLIA is Pareto-optimal
(Theorem 3) and that it satisfies the design goals of MPTCP
(Corollary 2). Our measurements and simulations indicate
that MPTCP with OLIA is as responsive and non-flappy as
MPTCP with LIA. Moreover, it solves problems P1 and P2.
Hence, we believe that IETF should revisit the congestion
control part of MPTCP and that an alternative algorithm,
such as OLIA, should be considered.
In the next section, we briefly introduce MPTCP and re-
lated work. In Section 3, we provide a number of examples
and scenarios in which MPTCP with LIA exhibits problems
P1 and P2. In Section 4, we introduce OLIA and detail its
Linux implementation. In Section 5, we prove that OLIA
is Pareto-optimal and satisfies MPTCP’s design goals. In
Section 6, we study the performance of OLIA through mea-
surements and by simulations.
2. MPTCP AND RELATED WORK
Multipath TCP (MPTCP) is a set of extensions to the reg-
ular TCP, which allows users to spread their traffic across
potentially disjoint paths [10]. MPTCP discovers the num-
ber of paths available to a user, establishes the paths, and
distributes traffic across these paths through creation of sep-
arate subflows [11, 12].
MPTCP’s congestion control algorithm forces a tradeoff
between optimal resource pooling and responsiveness [8].
The idea behind the algorithm is to transmit over a path r at
a rate proportional to p
−1/ε
r
, where p
r
is the loss probability
over this link and ε ∈ [0, 2] is a design parameter. The choice
ε=0 corresponds to the fully coupled algorithm of [4–6]: the
traffic is sent only over the best paths, it is Pareto-optimal
but is flappy. The choice ε=2 corresponds to using uncou-
pled TCP flows on each path: it is very responsive and non-
flappy, but does not balance congestion. MPTCP’s imple-
mentation uses ε=1 to provide a compromise between opti-
mal resource pooling and responsiveness. This algorithm is
called “linked increases” algorithm (LIA) [10].
Let w
r
and rtt
r
be the window size and the estimated
round-trip time on path r ∈ R
u
. R
u
is the set of all paths
available to user u. LIA works as follows:
• For each ACK on subflow r, increase w
r
by
min
max
i∈R
u
w
i
/rtt
2
i
(
P
i∈R
u
w
i
/rtt
i
)
2
,
1
w
r
!
. (1)
• For each loss on subflow r, decrease w
r
by w
r
/2.
LIA increases by at most 1/w
r
to be at most as aggres-
sive as regular TCP on any of its paths. When the RTTs
are similar, this minimum can be neglected as the first term
(max
i
w
i
/rtt
2
i
)/(
P
i
w
i
/rtt
i
)
2
would always be less than 1/w
r
.
In this case, a fixed point analysis provides a simple loss-
throughput formula for LIA [9]: LIA allocates to a path r a
window w
r
proportional to the inverse of the loss probability
1/p
r
and such that the total rate
P
p∈R
u
w
p
/rtt
p
equals the
rate that a regular TCP user would get on the best path,
i.e. max
p∈R
u
p
2/p
p
/rtt
p
. Thus, the window size for the
flow on a path r is given by
w
r
=
1
p
r
·
max
p∈R
u
p
2/p
p
/rtt
p
P
p∈R
u
1/(rtt
p
p
p
)
. (2)
Besides MPTCP and algorithms in [4–6], a few other algo-
rithms have been proposed to implement multipath proto-
cols. In [13], an opportunistic multipath scheduler measures
the path conditions on time scales up to several seconds. [14]
uses a mechanism to detect shared bottlenecks and to avoid
the use of multiple subflows on the same bottleneck. [15]
proposes to use uncoupled TCP flows with a weight depend-
ing on the congestion level. These mechanisms are complex,
their robustness is not clear, and they need explicit informa-
tion about congestion in the network. Our proposed algo-
rithm, OLIA, differs from these works as it is implemented,
proven to be Pareto optimal, and relies only on information
that is available to regular TCP. It also differs from [4–6] as
it is not flappy and has a better responsiveness.
3. PERFORMANCE PROBLEMS OF MPTCP
In this section, we investigate the behavior of MPTCP
with LIA in three different scenarios: scenarios A, B, and
C. Using scenarios A and B, we show that upgrading some
regular TCP users to MPTCP could reduce the throughput
of other users in the network without any benefit to the
upgraded users (problem P1). In Scenario C, we discuss the
aggressiveness of MPTCP users that compete with regular
TCP users (problem P2). Our conclusions are based on
analytical results and measurements over a testbed.
3.1 Testbed Setup
To investigate the behavior of the algorithms, we cre-
ate three testbed topologies that represent our scenarios.
2
N
1
type1 users
private AP
.
.
.
N
2
type2 users
.
.
.
shared AP
N
2
C
2
Internet
Streaming
server
N
1
C
1
Other
servers
x
1
y
x
2
N
1
(x
1
+x
2
)
y
(a) Scenario A
1 2 3
0
0.2
0.4
0.6
0.8
1
type 2 users
type 1 users
type 1: analytical
results
type 2: analytical
results
type 1: optimum with
probing cost
type 2: optimum with
probing cost
N
1
/N
2
Normalized throughput
C
1
/C
2
= 0.75
C
1
/C
2
= 1.0
C
1
/C
2
= 1.5
(b) Normalized throughput of users:
(x
1
+ x
2
)/C
1
and y/C
2
.
0 1 2 3
0
0.01
0.02
0.03
0.04
0.05
0.06
N
1
/N
2
Loss probabilities
C
1
/C
2
= 0.75
C
1
/C
2
= 1.0
C
1
/C
2
= 1.5
(c) Loss prob. p
2
at the
shared AP.
Figure 1: Scenario A: type1 users are all downloading through the same streaming server and have access to
both a private high speed access point and a shared access point. Type2 users have access only to the shared
access point. The performance of MPTCP with LIA obtained by measurement (points) or numerical analysis
(lines) is shown on figures (b) and (c). We observe that it is not Pareto-optimal, penalizes type2 users, and
its performance is far from the theoretical optimum with probing cost. It also fails to balance the congestion.
Server-client PCs run MPTCP (with LIA or OLIA) en-
abled Linux kernels. In all scenarios laptop PCs are used
as routers. We install “Click Modular Router” software [16]
to emulate topologies with different characteristics. We em-
ulate links with configurable bandwidth and delay with RED
queuing (drop-tail queuing is also studied in htsim simula-
tion, see Section 6.2). Figure 2 represents the testbed con-
figuration of the scenario described in Figure 1(a).
Figure 2: Testbed implementation of scenario A:
router R
1
emulates the bottleneck at the server side
and router R
2
the shared AP bottleneck. Iperf is
used to emulate multiple connections. The red PCs
use MPTCP and the blue PCs use regular TCP.
3.2 Scenario A: MPTCP is not Pareto-optimal
and penalizes regular TCP users
Consider a network with two types of users as shown in
Figure 1(a). There are N
1
users of type1, each with a high-
speed private connection, accessing different files on a media
streaming server. The server has a network connection with
capacity limit of N
1
C
1
Mbps. These users can activate a
second connection through a shared access point (AP) by
using MPTCP. There are also N
2
type2 users that have con-
nections only through the shared AP. They download their
contents from the Internet. The shared AP has a capacity
of N
2
C
2
Mbps.
Let x
1
be the rate that a type1 user receives over its pri-
vate connection (by symmetry, every user of type1 will re-
ceive the same rate x
1
). Similarly, let x
2
(resp. y) be the
rate that a type1 (resp. type2) user receives over the shared
connection. We denote by p
1
and p
2
the loss probability at
the link connected to the streaming server and the shared
AP, respectively (the loss probabilities at the Internet back-
bone and the private APs are negligible).
When type1 users use only their own private AP, we have
x
1
=C
1
, x
2
=0, and y=C
2
. In this case the normalized through-
put for both type1 and type2 users is 1. In the other case,
assuming that all paths have RTT rtt, when all type1 users
activate their public connections and use MPTCP with LIA
to balance load between their connections, we have
(a) N
1
(x
1
+x
2
) = N
1
C
1
N
1
x
2
+ N
2
y = N
2
C
2
(b) x
1
+ x
2
=
1
rtt
q
2
p
1
x
2
=
1
2+p
2
/p
1
1
rtt
q
2
p
1
(c) y =
1
rtt
p
2/p
2
where (a) are the capacity constraints at the two bottle-
necks, (b) comes from the loss-throughput formula for LIA
(Eq.(2)), and (c) follows the TCP loss-throughput formula
[17]. This system has a unique solution (see [18], Appendix
A). Figure 1(b) depicts the normalized throughput of type1
and type2 users, i.e. (x
1
+ x
2
)/C
1
and y/C
2
. As shown
in [18], Appendix A, these values depend only on the ratios
C
1
/C
2
and N
1
/N
2
.
A theoretically optimal algorithm (as discussed in [4, 5])
will allocate a normalized throughput of 1 to both type1
and type2 users. In practice, however, the value of the
congestion windows are bounded below by 1 MSS. Hence,
with a window-based congestion-control algorithm, a mini-
mum probing traffic of 1 MSS per RTT will be sent over a
path. In this paper, we introduce a theoretical baseline for
window-based congestion-control algorithms, called theoret-
ical optimum with probing cost; it provides optimal resource
pooling in the network, given that a minimum probing traf-
fic of 1 MSS per RTT is sent over each path. It serves as a
reference to see how far from the optimum LIA is.
We measure the performance of LIA in Scenario A, by
using the testbed, as shown in Figure 2. The measurements
are taken for N
2
= 10 and three values of N
1
= 10, 20, 30.
The capacities of R1 and R2 are N
1
C
1
and N
2
C
2
Mbps,
where we set C
2
= 1Mbps and C
1
= 0.75, 1, 1.5 Mbps.
All paths have similar RTTs (link delay plus queuing delay
is around 150 ms over all paths). For each case, we took
5 measurements. The results are reported in Figure 1(b).
Note that in all cases we present confidence intervals, but
3
ISP X
ISP Y
ISP Z
ISP T
blue users
red users
Figure 3: Scenario B. Thick lines represent peer-
ing agreements. Blue users are downloading from
servers in ISP Z and Red users from servers in ISP
T . Blue users use multi-homing and have access to
ISPs X and Y . Initially, Red users have access only
to ISP Y but upgrade to MPTCP and connect to
both X and Y (by activating the dashed connection).
in many cases they are too small to be visible. The loss
probability p
1
depends only on C
1
and is 0.02, 0.009, 0.004
for C
1
= 0.75, 1, 1.5 Mbps. We also show our analytical
analysis of LIA, as well as the theoretical optimum with
probing cost as defined above.
These figures have multiple implications. First, they show
that MPTCP with LIA exhibits problem (P1) from the in-
troduction: 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 de-
creases, but the throughput of type1 users does not change
as it is limited by the capacity C
1
of the streaming server.
For N
1
=N
2
, type2 users see a decrease of about 30%. When
N
1
=3N
2
, this decrease is between 50% to 60%. This is ex-
plained by the fact that LIA does not fully balance con-
gestion, as shown in Figure 1(c). It excessively increases
congestion on the shared AP (not in compliance with goal
3). We observe that LIA performs far from how an optimal
algorithm with probing cost would perform. Furthermore,
these figures show that the fixed point analysis predicts ac-
curately the behavior of the algorithm: the two curves (theo-
retical and experimental) exhibit the same trend. As a sum-
mary for this section, we conclude that MPTCP with LIA
is not Pareto-optimal and can penalize TCP users without
any benefit for anybody.
3.3 Scenario B: MPTCP is not Pareto-optimal
and can penalize other MPTCP users.
Consider the multi-homing scenario depicted in Figure 3.
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 C
X
, C
Y
, C
Z
, and C
T
.
Z and T host different video streaming servers. There are
two types of users: N
B
Blue users download contents from a
server in Z, and N
R
Red users download from a server in ISP
T . Blue users use multi-homing and are connected to both
ISPs X and Y to increase their reliability. Red users can
connect either only to Y or to both X and Y . We assume
that only ISPs X and T are bottlenecks and denote by p
X
and p
T
the loss probabilities. We assume that all paths have
similar RTTs.
0 0.5 1 1.5
0.4
0.6
0.8
1
1.2
1.4
1.6
C
X
/C
T
Normalized throughput
Blue users when Red use MPTCP
Red users when Red use MPTCP
Blue users
Red users
(a) Performance of LIA.
0 0.5 1 1.5
0.4
0.6
0.8
1
1.2
1.4
1.6
C
X
/C
T
Normalized throughput
Blue users when Red are multipath
Red users when Red are multipath
Blue users
Red users
(b) Optimum w. probing cost
Figure 4: Scenario B: analytical results for 15 Blue,
15 Red users and C
T
=36 Mbps where C
Y
= C
Z
= 100
Mbps. We show the normalized throughput (15(x
1
+
x
2
)/C
T
and 15(y
1
+ y
2
)/C
T
) as a function of C
X
/C
T
.
Dashed curves: normalized throughput when Red
users connect only to ISP Y . Solid curves: the case
when Red users upgrade to multipath. For all values
of C
X
/C
T
, the throughput of all users decreases when
Red users upgrade to MPTCP.
We first present a theoretical analysis of the rate that each
user would achieve (to simplify the analysis, we assume sim-
ilar numbers of Blue and Red users). There are two possible
cases. When Red users connect only to Y , the analysis is the
same as the one of scenario C, given in Section 3.4. Here,
we analyze the case when Red users upgrade to MPTCP.
The loss throughput formula (Equation (2)) shows that the
throughput of the different connections are:
y
1
=
1/rtt
2 +
p
X
p
T
r
2
p
T
y
2
=
p
X
p
T
y
1
,
x
1
=
1/rtt
1 + p
X
/p
T
r
max
2
p
X
,
2
p
T
x
2
=
1/rtt
1 + p
T
/p
X
r
max
2
p
X
,
2
p
T
As shown in [18], Appendix B, this set of equations has
a unique positive solution. A numerical evaluation of these
formulas is depicted in Figure 4(a). Figure 4(b) depicts the
performance of a theoretical optimum with probing cost (see
[18], Appendix B). The results are presented for RTT=150
ms, C
Y
= C
Z
= 100 Mbps, and C
T
= 36 Mbps. We consider
15 Blue users and 15 Red users in the network. We depict
the normalized throughput (15(x
1
+ x
2
)/C
T
and 15(y
1
+
y
2
)/C
T
) as a function of C
X
/C
T
. The results show that
upgrading Red users to MPTCP with LIA decreases the
performance for everyone. As an example, when C
X
/C
T
≈
0.75, by upgrading the Red users we reduce the throughput
of the Blue users by up to 21%. This decrease is about
3% when we use an optimal algorithm with probing cost
(Fig. 4(b)).
We emulate this scenario in our testbed in a similar man-
ner as for Scenario A. The measurement results are reported
in Table 1 for a similar setting with C
X
= 27 Mbps. 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 consider that Red users upgrade
to MPTCP by establishing a second connection through X
(shown by dashed line in Figure 3). 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. This con-
firms our analytical observation and shows that MPTCP
4
Internet
N
1
multipath
AP
1
N
1
C
1
.
.
.
N
2
single-path
.
.
.
AP
2
N
2
C
2
Servers
.
.
.
x
1
y
x
2
(a) Scenario C: N
1
multipath
users and N
2
single-path users
are connected to two APs with
capacities N
1
C
1
and N
2
C
2
Mbps
0 0.5 1 1.5
0.4
0.6
0.8
1
1.2
1.4
1.6
C
1
/C
2
Normalized throughput
LIA: single−path users
LIA: multipath users
Optimum w. prob.: multipath users
Optimum w. prob.: single−path users
(b) Analytical results: nor-
malized throughput of all
users using LIA (solid) or
optimum with probing cost
(dashed) for N
1
= N
2
.
0 0.5 1 1.5 2 2.5 3 3.5
0
0.5
1
1.5
multipath
N
1
/N
2
Normalized throughput
single-path users
single-path: optimum
with probing cost
multipath: optimum
with probing cost
C
1
/C
2
= 1.0
C
1
/C
2
= 2.0
(c) Normalized throughputs
using LIA, obtained by mea-
surement (points) or analysis
(lines).
0 1 2 3
0
0.02
0.04
0.06
N
1
/N
2
Loss probabilities
C
1
/C
2
= 1.0
C
1
/C
2
= 2.0
(d) Loss prob. p
2
at AP2:
LIA fails to balance the
congestion.
Figure 5: Scenario C: MPTCP with LIA excessively penalizes TCP users (when C
1
/C
2
≥1, for any fairness
criterion, MPTCP users should not impact TCP users). We show the normalized throughputs ((x
1
+x
2
)/C
1
and y/C
2
) received by the users, as well as p
2
. The performance of LIA is far from the theoretical optimum
with probing cost.
Red users
Rate/user
Aggregate
Blue users Red users
Single-path 2.5 1.5 59.8
Multipath 2.0 1.4 52.0
Table 1: Measurement results for scenario B, show-
ing the effect of upgrading the Red users from regu-
lar TCP to MPTCP with LIA. The number of Red
and Blue users is 15 and all values are recorded in
Mbps. By upgrading Red users to MPTCP, the
throughput drops for all users and the aggregate
throughput falls by 13%.
with LIA is not Pareto-optimal and could penalize other
MPTCP users without any benefit for anybody.
3.4 Scenario C: MPTCP users could be exces-
sively aggressive towards TCP users.
We consider a scenario with N
1
multipath users, N
2
single-
path users, and two APs with capacities N
1
C
1
and N
2
C
2
Mbps (see Figure 5). Multipath users connect to both APs
and they share AP2 with single-path users.
If the allocation of rates is proportionally fair, multipath
users will use AP2 only if C
1
<C
2
and all users will receive
(N
1
C
1
+N
2
C
2
)/(N
1
+ N
2
). When C
1
> C
2
, a fair multipath
user will not transmit over AP2. This fair allocation is rep-
resented by dashed lines in Figure 5(b) when we take into
account the minimum probing cost. However, using MPTCP
with LIA, multipath users get a larger share of bandwidth
as soon as C
1
≥ C
2
/(2+N
1
/N
2
). We show this analytically.
Let p
1
and p
2
be the loss probabilities at APs, x
1
and x
2
be rates that a multipath user receives over its paths, and y
be the rate of a single-path user. Assume all RTTs are the
same. When C
1
/C
2
< 1/(2+N
1
/N
2
), we have p
1
> p
2
and
all users receive the same rate: x
1
+x
2
= y = (C
1
+C
2
)/2.
When C
1
/C
2
> 1/(2+N
1
/N
2
), we have p
1
< p
2
and the
fixed point formula of LIA gives:
x
1
=
p
2
p
1
+ p
2
1
rtt
r
2
p
1
and x
2
=
p
1
p
1
+ p
2
1
rtt
r
2
p
1
.
Moreover, both the APs are bottlenecks and we have x
1
=
C
1
and x
2
+ y = C
2
. As shown in [18], Appendix C, this
set of equations has a unique positive solution that only
depends on the ratio N
1
/N
2
and C
1
/C
2
. Figure 5(b) re-
ports a numerical evaluation of these fixed point equations
for the case N
1
= N
2
. We show the normalized throughputs
((x
1
+x
2
)/C
1
and y/C
2
) received by the users, as well as p
2
.
We observe that LIA is fair with regular TCP users, as long
as C
1
< C
2
/3. However, as C
1
exceeds C
2
/3, it takes most
of the capacity of AP2 for itself.
We emulate the scenario in our testbed and measure the
performance of MPTCP with LIA. The results are reported
in Figures 5(c) and 5(d) for C
2
=1 Mbps and C
1
=1, 2Mbps,
with N
2
=10 and N
1
=5, 10, 20, 30. As in scenario A, we
also present the theoretical optimum with probing cost in
Figure 5(c).
When C
1
/C
2
≥ 1, multipath users should not use AP2 at
all. However, our results show that, MPTCP users are dis-
proportionately aggressive and exhibit problem (P2). Fig-
ure 5(d) shows the loss probability at AP2. We observe
that LIA excessively increases congestion on AP2 and is un-
able to fully balance congestion in the network. Also, we
have p
1
=0.01 and 0.003 for C
1
=1 and 2Mbps, respectively.
These results confirm our analytical observation and show
that LIA is overly aggressive towards TCP users.
4. OLIA: THE OPPORTUNISTIC LINKED
INCREASES ALGORITHM
In this section, we introduce OLIA as an alternative for
MPTCP’s LIA. OLIA is a window-based congestion-control
algorithm that couples the increase of congestion windows
and uses unmodified TCP behavior in the case of a loss.
The increase part of OLIA has two terms. The first term is
an adaptation of Kelly and Voice’s increase term and pro-
vides the Pareto-optimality (Kelly and Voice’s algorithm is
based on scalable TCP; the first term is a TCP compatible
version of their algorithm that compensates also for different
RTTs). The second term, with α, guarantees responsiveness
and non-flappiness. We first present the algorithm and its
Linux implementation. Then, we illustrate with an example
its operation and its difference with LIA.
5
