Multi Path Transmission Control Protocol (MPTCP)

“Congestion Control and Issues in the successful deployment of MPTCP.”

Abhijit Sipani asipani@ncsu.edu
Department of Computer Science
North Carolina State University
NCSU ID 000994838
Abstract: Multi Path TCP (MPTCP) is a future Internet design which effectively makes use of
simultaneous multiple paths to transfer data between end nodes. Although present day protocols
like SCTP do make use of multi homing to get data across between end nodes, they have certain
limitations like usage of single paths at any given moment of time or compatibility with
middleboxes. In such circumstances MPTCP, essentially used for rate control, promises to be a
better alternative. The fact that it is not a TCP alternative but an extension to present day TCP
itself should be an added advantage. This report discusses about the congestion control algorithm
of MPTCP and a few issues that can be faced in implementing the successful deployment of
MPTCP.
Keywords: MPTCP, Congestion, Network Resources, Traffic, sub flows.
Terminology:

 MPTCP: An extension to the TCP protocol that supports usage of multiple paths between
two end points. (Where we assume that one or more end points are already multi homed
in order to facilitate use of multiple paths).
 Multi homed: A host having two or more network addresses.
 Congestion: Too many sources sending too much data too fast for network to handle.
 Network Resources: Any physical component of the network.
 Sub Flow: A flow of packets operating over a single path, and part of a larger connection.
Introduction: Flow control and Congestion control have always been a major issue in network
and protocol design. Stream Control Transmission Protocol (SCTP) is one notable protocol in the
present day which makes use of effective multi homing techniques for better flow control.
However it faces a major roadblock on the issue of being deployable with middleboxes such as
NAT, firewall etc. Even the usage of Concurrent Multipath Transfer (CMT) in SCTP does not
ensure fairness to existing TCP. In such a scenario MPTCP with its “coupled congestion control
algorithms” appears to be an effective measure for congestion control and rate control. MPTCP
which is a strict end-to-end protocol makes use of resource pooling to spread out network traffic
between two end points over multiple paths. Figure 1 shows a typical MPTCP scenario where
traffic from host 1 is transmitted to host 2 via multiple network addresses at both ends. Here we
assume that one or more of the end points in the network are multi homed.
In this report we take a look at the Congestion Control Algorithm that MPTCP uses and some of
the issues to be addressed in the future for the successful deployment of MPTCP.

Congestion control in MPTCP:

Congestion generally occurs when the source sends more traffic than the destination can
normally handle. Because destination nodes are receiving traffic faster than they can handle
either of the two things must happen:

 The network must prevent new packets from traversing the congested flow until those
already present are processed.
 The congested destination nodes can remove queued packets to make room for those that
are waiting to be served.

In either case data at some point or the other is lost and this is precisely the problem that most
congestion control algorithms in the present day seek to address. MPTCP is no different. In
MPTCP multiple paths are so organized as to achieve resource pooling for all the subflows from
one host to the other i.e. traffic is shifted away from congested paths so that the loss rate on the
now lesser congested path that is being used increases and that on the congested path decreases.
However merely running TCP’s congestion avoidance algorithm on each subflow does not help.
Rather it results in a subflow grabbing N times as much bandwidth as it should (if N subflows
share a common bottleneck). As such one design goal of congestion control algorithms for
MPTCP should be to achieve a fair allocation of resources.

The congestion control algorithm presented in MPTCP functions as follows:

1. Maintains a congestion window state wr for each subflow r.
2. For each round trip increases window wr by α*wr/wtotal. (As opposed to increasing it by 1
in regular TCP).
3. For each packet loss decreases the window wr by wr/2. (Refer to [4]).

This leads us to observe that the algorithm is implemented only for the increase in the congestion
window stages of the congestion avoidance state. The decrease phase is similar to that of normal
TCP (it uses unmodified TCP New Reno in case of a drop). The parameter “alpha” here is used
to adjust the total rate of the multipath flows to the rate that the data would get on a single path
best flow. However this does not mean that “alpha” controls resource pooling. Resource pooling
takes place in the linkage of the flows itself.
Alpha can be computed as follows:
α = wtotal * [maxr {(wr*mssr2)/rttr2}] / {∑rwr*mssr/rttr} 2 (Refer to [1]).

Subflow 1

Host A Host B

Subflow 2

Figure 2: Two subflows between the two paths having same RTT and same MSS

To illustrate the working of this algorithm let us consider the following scenario:
Say we have two subflows between two hosts and the subflows have the same MSS, RTT and
loss rate. (Where MSS= Maximum segment size and RTT=Round trip time). Hence the total
window wtotal would be 2*wr, where wr=congestion window of subflow r as defined in the
algorithm. Now considering the case where both subflows share a common bottleneck link, if a
drop occurs on a particular subflow only that particular subflow halves its window. The other
subflows remain unaffected. So effectively the aggregate window comes down to 3w/4 which is
much less aggressive than normal TCP (which would have brought down its window by 50%).
Since the decrease is less aggressive than normal TCP hence we also need to scale the increase
factor (else it would result in the subflow grabbing more bandwidth). This is where alpha which
is the aggressiveness factor helps by letting the subflow increase its window by α*wr/wtotal. In this
case the increase comes to be ¼. Hence we see that the slower increase and the lesser aggressive
decrease balance out each other thus giving the same performance as a normal TCP flow would
on a single path.
Similarly we can extend this argument when there are more than two subflows on the same link,
with each subflow getting a window of 1/N (if there are N subflows with same RTT same MSS
and same loss rate on all subflows). All the subflows will eventually experience a drop (as at one
point of time or the other they will have a higher congestion window state wr) and hence balance
out their increase and decrease respectively.

Advantages of using the congestion control algorithm of MPTCP:

There are reasons as to why MPTCP is favorable for the next generation Internet, some of which
are as follows:
1. First of all by providing the simultaneous usage of several paths between two endpoints,
the above congestion control algorithm seeks to achieve maximum throughput as would
 be available on a single flow best path TCP. In cases where links tend to fail due to
severe congestion, the algorithm seeks to provide a ready solution of shifting the traffic to
lesser congested paths.
2. Secondly by making sure that the congestion control is coordinated across all subflows
rather than concentrating on any one subflow the algorithm seeks to be “fair”, in the
sense that it does not allow the MPTCP connection to grab an unfair share of resources as
explained above.
3. MPTCP is highly reasonable to the existing day TCP. It can be implemented in modern
day TCP by making and adding only a few small extensions and without any major
changes (as opposed to SCTP which faces the ease of deployment as a major barrier).
At present it is still in the experimental phase and as such continues to operate in the user
space. Once the protocol gains sufficient momentum in the Internet it can also be
implemented as part of the network space.
4. As opposed to SCTP, MPTCP can easily work its way around with middleboxes that
might attempt to change the TCP options. It can readily fall back to single TCP or
probably in the worst case, not use the subflow containing the middlebox and instead
switch to another subflow using the congestion control algorithm as described above.

Issues with the congestion control algorithm of MPTCP in the current implementation:
As resilient as MPTCP might appear to congestion on its subflows and middleboxes that might
attempt to rewrite the TCP options, there are several questions that still remain to be answered
with the current algorithm some of which are as follows:
1. What happens when a particular subflow goes down? (say in case of a link failure)
2. What is the upper bound on the number of subflows that can be opened?
3. When do we start a new subflow?
4. What happens when we retransmit the same data but on a different subflow?
5. What is the deciding condition to stop a particular subflow?
6. Where should Path management be implemented, in the protocol specifications itself or
in the implementation of the protocol?
7. What happens when both hosts attempt to open subflows simultaneously?
There are also a few other disadvantages which need to be taken care of in the present
implementation of MPTCP:
1. MPTCP is rather inefficient when it comes to transferring small amounts of data. It only
excels in transferring a huge amount of data by spreading it out over multiple subflows.
However this can be remedied in the future by introducing some sort of identification for
the payload field to ensure that it probably switches over to normal TCP for small data.
2. Hosts using MPTCP have no initial exchange of information about each other’s state. For
example a multi homed host trying to connect to another node has no idea about whether
the other node is multi homed or not. In such cases it ends up wasting time as well as
network resources until it receives a reply from the other node.
3. MPTCP, albeit efficient, does not achieve perfect resource pooling. When the loss rates
are same all subflows get an equal share of the total congestion window as illustrated in
the example above. However when loss rate differs, the subflow with the lesser loss rate
gets the bigger share of the window in contrast to the perfect resource pooling principle.
 4. There is the cost involved of the host having to be multihomed in order to be MPTCP
capable. Unless a host is multihome it cannot create the requisite multipaths required for
transfering data over multiple subflows. However considering the fact that several large
providers are nowadays already multihomed, it might be possible with a little
reconfiuration to make efficient use of MPTCP.

Commercial importance of MPTCP:

Having looked at both the pros and cons of the MPTCP we can now highlight some of the
scenarios where MPTCP can be very useful and can also be successfully deployed. Some of the
potential end user scenarios along with their respective pros and cons, where MPTCP can play a
vital role in improving network resilience to failure and in maximizing throughput are:
1.Applications with multiple access to different Internet Service providers (ISP’s), e.g a mobile
host having physical access to both 3G and WLAN can benefit from MPTCP. Data can be sent
out parallely over both the 3G and WLAN connections to different ISP’s which can then forward
the same data to the Internt cloud. In doing so we gain the cumulative benefits of both 3G
(omnipresent connectivity) and WLAN (improved share of the network). Thus MPTCP enables
the use of two completely different access technologies for a single host. However the cost of
providing both 3G and WLAN to a single mobile terminal should be taken nto account as it
might act as a barrier for the end user.
2. Applications with single access to one ISP: In such scenarios the ISP itself can act as the
multipath operator and split the traffic coming from one end user into multiple streams or it can
allow the end user to open multiple sessions to itself. However in such case the network
performace depends hugely on the performance of the ISP. Moreover if the ISP provider does
not provide multipath operations it becomes impossible for the end user to make use of MPTCP.

Bug Report for the MPTCP implementation on Network Simulator NS2.34:

Tests were carried out on the MPTCP patch for the network simulator (version NS-2.34) as
provided by the MPTCP working group (WG) of the Internet Engineering Task Force (IETF) to
investigate “What happens in the event of a subflow failure in MPTCP?”
It was observed that as soon as the link was taken down the performance of MPTCP started
degrading. Initial results suggested the failure of the MPTCP protocol to switch to a different
subflow in the event of a link failure.
A closer look revealed the absence of any mechanism to detect link failures in the existing code.
The model unaware of any link failure keeps trying to use the failed link between nodes as if it
were up and running. This is clearly a bug in the existing model. It can easily be remedied by
adding a link failure detection mechanism (Probably by sensing a timeout on the failed subflow)
to the existing code. Once implemented the behavior of the model under link failure conditions
will be worth observing.
The bug was reported to and was acknowledged by the WG of the IETF. The link to the report
can be found at http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01229.html.
(Refer to follow up for acknowledgement). However it still remains to be seen whether the same
is true for the Linux kernel version of the MPTCP model.
Conclusion:
MPTCP by providing simultaneous usage of multiple paths between two hosts in a network will
definitely improve resource usage within the network and provide a more congestion resilient
solution to network resource failures. However concerns such as subflow failure, varying loss
rates, smart NAT, multihoming costs for the end user etc must be fully addressed in order to
make MPTCP totally deployable.

References:
1. C. Raiciu, M. Handley, and D. Wischik, “Coupled Multipath-Aware Congestion Control”,
IETF Internet-Draft, draft-raiciu-mptcp-congestion- 01, 2010. (Work in progress).
http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/

2. A. Ford, and C. Raiciu, “TCP Extensions for Multipath Operation with Multiple
Addresses”, IETF Internet-Draft, draft-ford-mptcpmultiaddressed- 03, 2010.(Work In
progress). (http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/)

3. M. Scharf, “Multi-Connection TCP (MCTCP) Transport” draft-scharf-mptcp-mctcp-01

(Work in progress). (http://datatracker.ietf.org/doc/draft-scharf-mptcp-mctcp/)

4. C. Raiciu, M. Handley, and D. Wischik, “Practical Congestion Control for Multipath

Transport Protocols.”

5. Alexandros Kostopoulos, Henna Warma, Tapio Levä, Bernd Heinrich, Alan Ford, and
Lars Eggert “Towards Multipath TCP Adoption:Challenges and Opportunities”.

6. Costin Raiciu, Christopher Plunkte, Sebastien Barre, Adam Greenhalgh, Damon Wishcik,
Mark Handley University College London, Universite Catholique de Louvain. “ Data
center Networking with Multipath TCP”.

7. Tapio Leva, Henna Warma, Alan Ford, Alexandros Kostopoulos, Bernd Heinrich, Ralf
Widera, and Philip Eardley “Business Models in a Multipath World”.