CONGESTION

CONTROL IN MPTCP
POSITION PAPER

Candidate Number 132170

Degree Computer Science MComp

Module Topics in Computer Science

Word Count (excl. Appendices) 2,636

Due Date 12 January 2018

ABSTRACT
This position paper will briefly define TCP and MPTCP, and introduce the basic concept of congestion
control in the internet. There will then be a literature review covering congestion control and exploring the
design decisions, and performance analysis, of MPTCP.
Following the literature review will be a research proposal which will pose a hypothesis and describe
methods and experiment setup suggestions for carrying out the investigation and presenting the results.


2 of 13
TABLE OF CONTENTS

Abstract 2

1. Introduction 4

1.1 TCP 4

1.2 MPTCP 4

1.3 Congestion Control 4

2. Literature Review 5

2.1 Congestion Avoidance and Control 5

2.2 Design Decisions for Multipath TCP 5

2.3 Improving Datacenter Performance and Robustness with Multipath TCP 6

2.4 Effects of Multipath Routing on TCP Performance in Ad Hoc Networks 6

2.5 MPTCP Is Not Pareto-Optimal: Performance Issues and a Possible Solution 7

2.6 Practical Congestion Control for Multipath Transport Protocols 7

3. Research Proposal 9

3.1 Hypothesis 9

3.1.1 Scenario A: TCP User 9

3.1.2 Scenario B: MPTCP User 9

3.2 Research Methods 10

3.2.1 Deployed Testing Environment 10

3.2.2 Simulation 11

4. Conclusion 12

5. References 13

3 of 13
1. INTRODUCTION
1.1 TCP
Transmission Control Protocol (TCP) facilitates bi-directional point-to-point, reliable communication
between sender and receiver, and operates in the Transport Layer which sits above the Network Layer in
the OSI Model.
Packet losses are handled, and users of the protocol can expect an in-order stream of bytes rather than
dealing with individual packets, as is the case with User Datagram Protocol (UDP). The TCP protocol also
describes methods for flow and congestion control (discussed briefly in section 1.3).
TCP is connection-oriented, meaning an initialisation phase, where control messages are exchanged, takes
place before any data is sent.

1.2 MPTCP
Bonaventure, O., Handley, M., and Raiciu, C. discuss in their Multipath TCP overview paper1 that “today’s
networks are multipath … meanwhile, TCP is essentially a single-path protocol”. Multipath TCP (MPTCP)
has been introduced to address this ‘misalignment’.
MPTCP is an augmentation of the TCP protocol that allows data to flow over multiple paths (called sub-
flows) simultaneously through a single TCP connection, aiming to maximise throughput and increase
redundancy. These sub-flows span across different interfaces (e.g. Wi-Fi and cellular).

1.3 Congestion Control

Congestion Control is a term used to describe the mechanisms employed by TCP to avoid and handle
congestion in the network. Network congestion materialises as packets being dropped and long delays.
Congestion Control differs from Flow Control, which is a method for the receiver to throttle the sender’s
transmission rate by informing the sender of its amount of free buffer space (constantly changing). This
prevents an end-node from being overwhelmed, rather than the network.
TCP Congestion Control consists of a number of different algorithms including slow start and congestion
avoidance.


4 of 13
2. LITERATURE REVIEW
2.1 Congestion Avoidance and Control 2

This paper, released in 1988, begins by motivating the need to add congestion control to the TCP protocol.
The notion of a ‘conservation of packets’ is introduced, and by considering each case that would cause this
principle to fail, amendments to the protocol could be made.
Jacobson then goes on to describe how the Slow-start algorithm “gradually increases the amount of data
in-transit” to reach an equilibrium. Figure 1 shows startup behaviour of TCP without Slow-start, and Figure
2 shows startup behaviour of TCP with Slow-start — a much more stable and predictable transfer of
packets.

Figure 1: TCP without Slow-start Figure 2: TCP with Slow-start

Figures 1 and 2 are both from the Congestion Avoidance and Control paper

It was then noted that packets are very rarely damaged in transit and that packet loss, therefore, is almost
always a consequence of congestion in the network. TCP users can infer network congestion by detecting
packet losses (caused by timeouts). An additive-increase-multiplicative-decrease approach is applied,
where the sender’s window (amount of in-transit data) is increased additively, and upon detection of packet
loss (network congestion), the sender’s window size is halved. This algorithm is known as Congestion
Avoidance.
Slow-start and Congestion Avoidance are both in-use in today’s versions of TCP and MPTCP.
This paper falls into a class of its own because of how long ago, relative to the other papers reviewed, it
was published.

2.2 Design Decisions for Multipath TCP 3

This note, written by two of the authors from the paper discussed in section 2.3, collates the design
principles from a number of sources (including the IETF Multipath TCP working group).
Raiciu and Handley list three high-level requirements that MPTCP has been designed to meet. The first of
which concerns compatibility with existing applications that use single-path TCP connections; there should
be no change in how they interact with the API.
The second high-level requirement involves performance and says that MPTCP should be able to utilise the
available network resources at least as well as single-path TCP. In addition to this, single-path TCP
5 of 13
connections sharing a link with an MPTCP sub-flow should not experience any reduced performance when
compared with sharing with another single-path TCP connection.
The final of the three requirements states how important network compatibility is. MPTCP should be able to
replace TCP and work successfully in the face of firewalls, NATs, and other network equipment.
This note also falls into its own category as it does not introduce new ideas (like the Congestion Avoidance
and Control paper did), but rather collates, from a number of different sources, literature relating to the
topic, in this case MPTCP.

2.3 Improving Datacenter Performance and Robustness with Multipath TCP 4

The paper starts by discussing how single-path TCP falls short of supporting modern, large-scale data
centre networks as it does not utilise all the available paths optimally. This paper demonstrates how
replacing TCP with MPTCP in data centres results in improved throughput and fairness. Robustness was
also improved as link/switch failures were more quickly accounted for and worked around since MPTCP
had already set up multiple other sub-flows.
One particularly strong aspect of the experiment methodology was the diversity of factors considered,
including network topology, number of sub-flows and traffic matrix. The results analysed indicated that
MPTPC performs best when using 8 sub-flows in VL2 (FatTree) (as opposed to BCube) topologies.
Though some tests were run on a small cluster of Linux computers, and also on Amazon EC2 servers,
most of the experiments were carried out via simulation. A fairly obvious improvement to the testing
methodology here would be to use a large (~8,000 hosts) data centre. Amazon EC2 is not a perfect
substitute here because other (‘outside’) network traffic cannot be known/manipulated, and the exact
topology of the data centre is not known either. The team could monitor real network traffic over MPTCP
and regular TCP so give a less artificial set of results.
It is interesting to contrast the different approaches to investigation used here (mainly large-scale
simulation) and in the first paper from 1988 by Jacobson (practical and ‘hands-on’).

2.4 Effects of Multipath Routing on TCP Performance in Ad Hoc Networks 5

This paper by Ye, Krishnamurthy, and Tripathi investigates why not all TCP connections benefit from the
use of MPTCP when upgraded. This seems to contradict the performance design principle discussed in
section 2.2.
In particular, short (low number of hops) multipath connections suffered reduced goodput as compared with
short single-path connections. Ye, Krishnamurthy, and Tripathi argue that the currently available (as of
2004) multipath routing algorithms only provided benefits when there were route failures, and only for long
connections.

Figure 3: Goodput Ratio vs. Connection Distance

6 of 13
From Figure 3, it can be concluded that short-distance connections performed worse with multi-path routing
protocols, while longer distance connections performed better with them. The authors attribute this as being
“solely caused by [short TCP Connections] using sub-optimal paths”.
This paper is reasonably similar to the Improving Datacenter Performance and Robustness with Multipath
TCP paper as they both investigate the performance improvements/degradation caused by MPTCP
replacing other protocols.

2.5 MPTCP Is Not Pareto-Optimal: Performance Issues and a Possible Solution 6

Two key performance issues with MPTCP are described in this 2013 paper. The first one suggests that
switching TCP for MPTCP in some users can reduce throughput of other users in the network without
improving throughput for the MPTCP users. Khalili, Gast, Popovic, and Boudec attribute this to the linked-
increases algorithm (LIA) and suggest that this problem indicates MPTCP with LIA is not Pareto-optimal.
MPTCP may be described as ‘Pareto-optimal’ if and only if there is no alternate configuration/state that
would allow some users more throughput without reducing throughput for other users.
The second problem highlighted was that “MPTCP users could be excessively aggressive towards TCP
users” when competing for network resources due to excessive traffic being transmitted on congested links.
Figure 4 shows the testbed setup used to investigate these performance issues.

Figure 4: Testbed Setup

Finally, opportunistic linked-increases algorithm (OLIA), a proposed solution to this problem, is presented.
OLIA satisfied the MPTCP design requirements (discussed in section 2.2) and is Pareto-optimal, and
therefore doesn’t suffer from the two aforementioned performance issues.
This paper has a strikingly similar approach to the Jacobson paper on Congestion Avoidance and Control.
Both papers describe a problem and motivate a need for a solution which is then presented.

2.6 Practical Congestion Control for Multipath Transport Protocols 7

This paper starts by highlighting how congestion control algorithms used in multipath situations (such as
with MPTCP) are causing hosts at the end-points to load balance traffic to avoid congestion hotspots.
Fairness with current (single-path) TCP connections over shared bottleneck links (such as those shown in
Figure 5) is particularly emphasised in this paper. This fairness is exactly one of the high-level requirements
described in Design Decisions for Multipath TCP paper (section 2.2).

7 of 13
 Figure 5: Fairness with Shared Links

The authors developed a practical multipath congestion control algorithm by considering carefully the
fairness over shared links, improving throughput, and balancing congestion. The algorithm is, they claim,
suitable to be deployed with MPTCP on the internet.


8 of 13
3. RESEARCH PROPOSAL
3.1 Hypothesis
Following on from the literature review in section 2, the following hypothesis is presented:
The widespread replacement of TCP for MPTCP would result in reduced network congestion in
networks containing many mobile devices that are sporadically connecting to, and disconnecting
from, Wi-Fi and cellular networks.
To begin with, a single mobile device connected to Wi-Fi (and 3G mobile data services) streaming a video
is considered. The user leaves their home and consequentially disconnects from their home Wi-Fi network.
We will now consider two scenarios; in the first, the user’s device employs regular, single-path TCP, and in
the second, the user’s device makes use of MPTCP.

3.1.1 Scenario A: TCP User

The device’s TCP connection to the streaming server is severed. The device must establish an entirely new
connection over the 3G cellular interface through which to resume the video stream.
Depending on the error recovery behaviour of the particular app being used, the entire video may need to
be downloaded again.

3.1.2 Scenario B: MPTCP User

The MPTCP protocol in this instance will set up multiple sub-flows, with the potential of sending/receiving
some of the data over the cellular interface in addition to the Wi-Fi interface.
An additional observation here is that it is plausible that the device will achieve a higher download speed
(due to the use of multiple paths). This may result in the video being completely buffered on the device
before the Wi-Fi connection is lost. We will, however, continue under the assumption that this has not
happened.
The sub-flow(s) that operated across the Wi-Fi interface are terminated, and the download speed likely
drops significantly, momentarily. However, because the device still has a cellular connection (and sub-
flow(s) that operate over that interface), the device quickly recovers by shifting the whole data flow to the
available (cellular) interface.
The key difference here is that the same TCP connection is maintained in this second scenario and a
potentially lengthy handshake to setup a new connection (as was required in Scenario A) is not necessary.
A further benefit in this scenario is that the application is unaware that this change in primary network
interfaces has even occurred. No error recovery behaviour would need to be employed here.

————

In large institutions (e.g. University of Sussex), ‘campus-wide’ Wi-Fi networks are deployed. The signals are
strong inside buildings, but often degrade to unusable quality outside. Throughout a typically day,
thousands of students and staff roam around the campus entering and exiting buildings several times.
This research proposal aims to investigate whether, on a large scale, devices using MPTCP (rather than
single-path TCP) result in reduced network congestion in these environments.

9 of 13
3.2 Research Methods
Two rather different approaches to carrying out the investigation are described now.

3.2.1 Deployed Testing Environment

A consistent testing experience is important, and, consequently, a dummy streaming server should be
configured. This server should have more than sufficient capacity to handle requests from many users at
the same time — the performance of the campus network is being tested, not the streaming server.
In addition to the streaming server, an app for the smartphone devices will need to be developed. This app
will stream a file (e.g. video) from the dummy streaming server, and will log information like how long it
takes to buffer the whole file.
Each device must be able to select whether it uses single-path TCP or MPTCP connections. It would be
preferable if all devices were the same model, so as to eliminate any unexpected differences in their
network interfaces or other hardware components.
Following this setup, the devices should all be configured to use single-path TCP connections and
repeatedly stream the file from the streaming server whilst the devices are being moved in and out of
buildings throughout the campus. The reason for having the file be streamed repeatedly is to maintain a
threshold of congestion in the network with fewer devices.
While the streaming is proceeding, network congestion needs to be monitored. One option would be to
record the time-to-buffer that each device is logging.
Once these statistics are obtained for TCP, the experiment shall be run again, this time with MPTCP. The
average time-to-buffer logs will be compared and presented graphically (see Figure 6 for an sample
comparison graph).

TCP MPTCP

14
Time-To-Buffer (seconds)

12

10

0
0 1 2 3 4 5 6
Time Elapsed (minutes)

Figure 6: Sample TCP/MPTCP Comparison

There are two main issues with this investigation approach. Firstly, the impracticability of obtaining and
configuring hundreds/thousands of devices, and moving these devices simultaneously around the campus.
Secondly, network congestion is being inferred from the time-to-buffer property, which, while may be
affected as a consequence of congestion, is not a direct measurement of it. This difficulty in measuring
network congestion is tackled head-on in a simulation-style approach.

10 of 13
3.2.2 Simulation
The entire experiment (including all the devices and the streaming server) would be simulated by a
computer. In some respects, this approach would be similar to that used by the team in the Improving
Datacenter Performance and Robustness with Multipath TCP paper discussed in section 2.3.
There are a couple of advantages of using a simulation-based approach. Firstly, larger scale networks can
be experimented with as it is much easier to setup and configure virtual (simulated) test devices, than to do
so for real ones. In addition to this, network congestion, despite being somewhat of an artificial construct in
the simulation, can be directly measured.
The results from the simulation experiments would be plotted on a similar graph to the one shown in Figure
6.


11 of 13
4. CONCLUSION
This position paper has briefly introduced TCP, MPTCP, and the topic of congestion control. Several
relevant papers have been considered and summarised as part of the literature review.
A hypothesis regarding a comparison of network congestion with devices using TCP or MPTCP has been
presented along with two suggested approaches for carrying out this investigation.


12 of 13
5. REFERENCES
1 Bonaventure, O., Handley, M., and Raiciu, C. An Overview of Multipath TCP. 2012. [Online] Available
from: http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/9346-login1210_bonaventure.pdf [accessed 7/1/18]

2Jacobson, V. 1988. Congestion Avoidance and Control. In Proceedings of the ACM conference pp.
324-329

3Raiciu, C. and Handley, M. Design Decisions for Multipath TCP. 2010. [Online] Available from: http://
nrg.cs.ucl.ac.uk/mjh/design-decisions.pdf [accessed 8/1/18]

4Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Wischik, D., and Handley, M. 2011. Improving
datacenter performance and robustness with multipath TCP. In Proceedings of the ACM SIGCOMM
2011 conference (SIGCOMM ’11) pp. 266-277

5 Ye, Z., Krishnamurthy, S.V., and Tripathi, S.K. 2004. Effects of Multipath Routing on TCP Performance
in Ad Hoc Networks. IEEE Communication Society (Globecom 2004) pp. 4125-4131

6Khalili, R., Gast, N., Popovic, M. and Boudec, J.L. MPTCP Is Not Pareto-Optimal: Performance Issues
and a Possible Solution. 2013. IEEE/ACM Transactions On Networking. 21 (5) pp. 1651-1665

7Raiciu, C., Wischik, D., Handley, M. Practical Congestion Control for Multipath Transport Protocols.
2009. [Online] Available from: http://nrg.cs.ucl.ac.uk/mptcp/mptcp-techreport.pdf [accessed 8/1/18]

13 of 13