MultiPath TCP (MPTCP) [rfc6824] is a set of TCP extensions that enable reliable data transfer over multiple end-to-end paths between source and destination nodes. Two benefits are forthwith achieved [rfc6824]: it improves end-to-end throughput, while allowing greater tolerance to communication failures. As a general-purpose protocol, MPTCP has a broad range of potential uses. Enabling efficient and resilient mobile communications [Paasch.et.al:2012, rfc6182], and improving performance improvement of datacenter networks (DCN) [Raiciu.et.al:2011, rfc6182] are two impactful applications of MPTCP. While MPTCP is now supported by independent implementations in different operating systems (e.g., Linux, Apple iOS, Citrix, FreeBSD, Oracle Solaris), currently its largest deployment is on mobile devices, likely on hundreds of millions of enabled devices [rfc8041].
A MPTCP connection consists of a set of one or more subflows
. Each subflow provides an alternative path to reach a remote end-system. A subflow starts and terminates as a regular single-path TCP (SPTCP) connection, with its own congestion window, which measures and estimates its state variables, such as RTT. MPTCP packet fields are carried as option into TCP header. Thus, subflow packets are handled as regular TCP packets in the network, which avoids misinterpret and drop of MPTCP packets by middleboxes. This makes easy the deployment of MPTCP on the existing Internet.
Network paths between multihomed relay/end systems have different characteristics (delay, loss, and capacity), in which MPTCP has to deal with. The reality is that there is a diversity of data traffic and transmission technology in the access networks, i.e., there are several different (heterogeneous) network paths on the Internet. Thus, it is a challenge to improve the performance of multipath transfers to allow a higher bandwidth aggregation benefit. While different algorithms have been proposed to improve multipath performance in different network scenarios and applications in the last years, the research effort has been centered around solutions in the scopes of packet scheduling [Yang.et.al:2013, Arzani.et.al:2014, Paasch.et.al:2014, Oh.and.Lee:2015, Kimura.et.al:2017], and coupled congestion controls [lia:2011, olia:2014, Wischik.et.al:2011, balia:2016, wVegas:2014].
In this report, we focus on coupled congestion controls and provide a summay of the existing algorithms deployed in the MPTCP Linux kernel implementation. Simply using standard TCP congestion control on each subflow would give an unfair resource sharing, since the subflows in an connection would dispute bottleneck links with regular SPTCP connections leading them to starvation [lia:2011]. In addition, the multipath connection undergoes the bottleneck conditions of similar and dissimilar path characteristics. To deal with those concerns, a MPTCP congestion control has to couple and adjust the sending operation of all subflows. In doing so, various objectives are taking into account [Xu.et.al:2016]:
Friendliness when sharing network resources with non-MPTCP flows;
Responsiveness to react to network changes;
Throughput improvement from multipath aggregation bandwidth;
Congestion balance among existing multipaths between two end-systems.
At present, four coupled congestion controls are deployed in the MPTCP implementation [Paasch.et.al-mptcp:2017]: LIA [lia:2011], OLIA [olia:2014], BALIA [balia:2016], and wVegas [wVegas:2014]. Such congestion controls are mostly carried out in the congestion avoidance phase as there are different strategies for additive-increase/multiplicative-decrease (AIMD), so that the other algorithms (slow start, fast retransmission, and fast recovery) occur as in standard TCP [rfc5681]. Table I summarizes the strategies of the existing multipath congestion avoidance. We provide details of each coupled congestion control in the next sections.