# An Analysis of MPTCP Congestion Control
###### Abstract  
Many devices contain more than one network interface. There is scope for multi-path transfer to utilise these network interfaces simultaneously. Multi-path TCP (MPTCP) is designed to provide improved resilience and resource utilisation through multi-path transfer. One of the key goals of MPTCP is to preserve fair resource sharing with regular TCP at network bottlenecks. Although the coupled congestion control algorithms can achieve this goal by coupling subflow congestion windows, the algorithms always assume that the subflow paths will share a bottleneck. As a consequence, MPTCP is unable to maximise throughput over all available paths at a non-shared bottleneck. We present a survey about MPTCP and its coupled congestion control algorithms. We then show that MPTCP coupled congestion control algorithms perform poorly when paths are disjoint and/or do not have similar delay and/or bandwidth characteristics. MPTCP; congestion control; fairness; multi-homing +
Footnote †: journal:  
loss rate and stabilising the entire network. Each flow should meet certain requirements to ensure that available network resources are fairly shared amongst all users [4, 5]. Typically, CC algorithms monitor the incoming feedback signal to adjust the flow sending rate. Packet loss and packet delivery delay are two common signals used in CC algorithms. Both loss-based and delay-based CC use the Congestion Window (_cvnd_) to indicate each path's availability/capacity. TCP CC maintains a _cvnd_ for each flow which dynamically adjusts based on network conditions. The window increases when no congestion event has occurred and decreases when congestion is detected. Overall, CC aims to reduce congestion, maintain high link utilisation and provide a fair share of the available resources [5]. MPTCP CC algorithms can be divided into two groups, uncoupled and coupled CC. With uncoupled CC, each subflow deploys a separate/independent _cvnd_. The subflow _cvnd_ is not affected by loss events on other paths. Existing loss-based and delay-based CC algorithms can be used as an uncoupled CC in MPTCP [1, 3]. With coupled CC, a shared _cvnd_ is used across all the subflows in a connection. Currently deployed coupled CC algorithms include Linked Increased Algorithm (LIA) [6], Opportunistic Linked Increase Algorithm (OLIA) [7], Balanced Linked Adaption Congestion Control Algorithm (BALIA) [8] and Weighted Vegas (wVegas) [9]. LIA, OLIA and BALIA are considered loss-based while wVegas is delay-based. The notion of \"fairness\" has been an ongoing topic of research in both MPTCP and TCP. MPTCP uses multiple network paths simultaneously in order to improve overall throughput performance. One of the design goals for MPTCP CC mechanisms is to ensure fair coexistence of multi-path and single-path (sub)flows within the same network. The protocol is considered fair if it behaves like a TCP connection under shared path conditions. As such, the resources should be equally shared among all connections (TCP and MPTCP) [1, 3]. Uncoupled CC maintains a separate _cvnd_ on each subflow independently. As an example, three subflows sharing the same link occupy three times as much bandwidth as a regular TCP flow. This would not be fair to TCP connections at shared bottlenecks [6]. Coupled CC focuses on the fairness of the overall connection instead of a single subflow. All subflows share a coupled _cvnd_ which shifts traffic between different subflows to ensure the overall throughput is not more than a single TCP flow [6]. In this paper, we present a survey and analysis of MPTCP. In particular, we describe the general principles of MPTCP. We give an overview of a fairness definition from different perspectives and analyse existing MPTCP CC algorithms. In particular, the purpose of the analysis is to investigate the performance of the currently deployed MPTCP coupled CC algorithms under different scenarios. It is important to understand whether current solutions to MPTCP CC function both when the subflows share a bottleneck and when the subflows follow disjoint paths.