# An Analysis of MPTCP Congestion Control
## 2 Multi-Path Transport Control Protocol--An Overview  
The Internet is made up of billions of connected devices world-wide. Until recently, end-hosts connected to the Internet were typically single-homed. As an example, connected via a single WiFi interface. More recently computing devices such as laptops and mobile phones are more likely to be equipped with several network interfaces, for example WiFi and cellular, while average Internet speeds have gradually increased over the years, the transport protocols used for transferring data between devices have evolved more slowly. The Transmission Control Protocol (TCP) [10] first originated in the 1970s to provide reliable delivery between networks. Today, TCP remains the Internet's default transport protocol with few extensions [1, 2].  
Protocols established for single-homed devices are unable to realise the potential network throughput performance that multi-homed devices are theoretically able to achieve. For example, TCP can only use a single path between end-hosts per session, and the connection has to be terminated and re-established when shifting from one interface to another. As such, end-hosts cannot take advantage of redundant paths and additional capacity that exists over multiple links [1, 2].  
To enable multi-homing at end-hosts, the Internet Engineering Task Force (IETF) designed the TCP extension called Multi-path TCP (MPTCP) [3]. When multiple links are concurrently available, MPTCP transfers traffic utilising all of the available paths (subflows). This increases the potential for higher overall throughput and resiliency. MPTCP is compatible with TCP-based applications and is already deployed on the Internet [3].  
Each MPTCP connection needs to coordinate data transmission across its subflows. Current implementations use a scheduler and congestion control (CC) to manage how the end-hosts transfer data over the available paths. The role of the scheduler is to decide which links to utilise (best path) based on path availability and specific criteria (e.g., RTT, congestion window size). Once paths are selected, the MPTCP scheduler distributes the data among the selected links. The scheduler must rely on the CC algorithm to make a decision on the length of data to allocate to the subflows [1, 3].  
In a single-homed device, it is the task of CC to optimise performance while simultaneously not congesting the path. Traditionally, CC is applied to a single path between two end-hosts. TCP CC dynamically modifies the sending rate of the path to ensure full utilisation while reducing the sending rate in the case of a congestion event. Depending on the CC algorithm, congestion events may have different responses. The CC algorithm modifies the sending rate by setting the congestion window size of a TCP connection. The window defines how much data is allowed onto the path [4].  
Multi-path CC operates at either the connection-level or at the individual subflow level. Two CC approaches in MPTCP are uncoupled and coupled CC. When using uncoupled CC, each subflow manages its congestion window independently of the other subflows or overall connection information. With coupled CC, the window of the entire connection is shared between subflows. Each path congestion window is modified after considering the current state of the overall connection [1, 3].