About Multipath TCP (MPTCP)
MPTCP in a nutshell
The Internet protocol suite is the computer networking model and set of communications protocols used on the Internet and similar computer networks. It is commonly known as TCP/IP, because its most important protocols, the Transmission Control Protocol (TCP) and the Internet Protocol (IP) were the first networking protocols defined in this standard.
TCP is one of the key Internet protocols. It provides a reliable bytestream service and is used by all applications that need to exchange data reliably, including web, email, file transfer, video streaming, … Statistics collected by researchers and network operators show that 90 to 95% of the total Internet traffic is driven by TCP.
MPTCP is an ongoing effort of the IETF Multipath TCP working group, that aims at allowing a TCP connection to use multiple paths to maximize resource usage and increase redundancy. In other words, MPTCP will allow one TCP session to be conveyed on several paths (several TCP subflows) over different access networks.
Each TCP subflow benefits from TCP’s Congestion Control and can thus adapt in real time to changing network conditions (bandwidth auto-scaling), which is very important when one or more of the paths uses a mobile network.
TCP was designed in the 1970s and has evolved over the years. One of its key features is its congestion control scheme that enables it to sense the available bandwidth in the network and adjust its transmission rate accordingly. This has enabled TCP to be used over a wide range of networks, from dialup modems to high speed Ethernet in data centres and wireless networks such as WiFi or 3G/4G.
However, the version of TCP that is used on our laptops, smartphones and servers suffers from one major limitation : one TCP connection can use only one of the laptop’s communications interfaces. This is because TCP is tightly coupled with IP. When a TCP connection starts over, for instance, the WiFi interface of say a smartphone, it cannot simply transition to the cellular interface when the smartphone moves away from the WiFi access point.
Multipath TCP(1) is a recently standardised extension to the TCP protocol that solves this problem by enabling a TCP connection to send data over any number of interfaces while still providing the same service to the application(9). Multipath TCP achieves this by combining several TCP connections, called subflows in the reference architecture(2) shown in the figure below.
To better understand the operation of Multipath TCP, let us consider the simple scenario of a smartphone that wants to exchange data over both its WiFi and cellular interfaces with a server in the cloud. The smartphone initiates the connection by sending a SYN segment with the MP_CAPABLE option on its WiFi interface. The MPTCP enabled server confirms the establishment of the connection with a SYN+ACK segment that also contains the MP_CAPABLE option. The smartphone replies with an ACK segment that confirms the establishment of the MPTCP connection. The first subflow, created over the WiFi interface, is now established.
At this point, data can flow over the WiFi interface in both directions. The smartphone can then create a subflow over the cellular interface to be able to use it too. This is done by sending a SYN segment with the MP_JOIN option over this interface. This option contains information that links this SYN with the original SYN sent over the first sub flow. As previously, the server replies with a SYN+ACK and the smartphone confirms with an ACK. The second subflow is now established. The two subflows can be used to send data. The different subflows that comprise a MPTCP connection have different delays and different bandwidths, of course. However, with MPTCP the smartphone can send data over any of the available subflows thanks to the utilisation of the DSS option that includes sequence numbers to enable the MPTCP receiver to reorder data received out-of-sequence on the different subflows. MPTCP also includes a congestion control scheme that continuously adjusts the transmission rate on the different subflows based on their measured performance. A more detailed introduction to MPTCP may be found in ACM Queue, “Multipath TCP”(3).
During the last few years, several MPTCP based use cases(4) have been explored by researchers and the industry. Most of these use cases build upon the MPTCP implementation in the Linux kernel that is considered to be the reference implementation of the protocol. This implementation has tracked the evolution of the protocol specification and it has enabled vendors such as Apple, Oracle or Citrix to verify the interoperability of their own implementation.
The first use case that was considered by researchers is the datacenter. Large datacenters use networks with many redundant links. Simulations and experiments have shown that thanks to Multipath TCP, datacenter operators could achieve better performance(7) by spreading the load over multiple links. Later, we demonstrated that the Multipath TCP implementation in the Linux kernel could reach throughputs of more than 50 Gbps for a single connection(6).
The second use case are the smartphones. Researchers demonstrated that Multipath TCP was a good solution for this environment(8) and shortly after Apple decided to enable Multipath TCP on all its smartphones. As of this writing, Apple only uses Multipath TCP for its own voice recognition application. The other applications do not benefit from Multipath TCP. This is partially because Multipath TCP is not yet deployed on servers.
The last use case that is interesting for network operators is hybrid access networks. A typical hybrid network is one that uses both DSL and 4G to connect its users. Each DSL router is equipped with both a DSL and a 4G interface to provide higher bandwidth to its users. With the regular TCP stack implemented on PCs, laptops and tablets, home users have difficulty in efficiently using these two interfaces whereas once a softwa
re-based TCP-MPTCP proxy(5) has been added to the DSL router this facility is automatically provided.
An alternative approach for supporting hybrid access networks uses Generic Routing Encapsulation (GRE) tunnelling. In comparison to MPTCP, GRE has a significant drawback in that it does not expose to the transport layer (TCP) the fact that different networks with different and varying qualities are being used to convey the data. TCP’s Congestion Control is therefore rendered ineffective in this mode, and this is particularly problematic when bonding with a mobile network which by its nature is subject to frequently changing network conditions. More information on the different bonding approaches is available in our White Paper “Comparing Hybrid Access Networks Solutions“.
(2) – [RFC6182] A. Ford, C. Raiciu, M. Handley, S. Barré, J. Iyengar, “Architectural Guidelines for Multipath TCP Development”, RFC6182
(3) – [CACM14] C. Paasch, O. Bonaventure, “Multipath TCP”, ACM Queue, 2014
(4) – [UseCases] O. Bonaventure, C. Paasch, G. Detal, “Use Cases and Operational Experience with Multipath TCP”, Internet draft, July 2015
(5) – [HotMiddlebox13] G. Detal, C. Paasch and O. Bonaventure. “Multipath in the Middle(Box)”. CoNEXT workshop HotMiddlebox, December 2013.
(6) – [50Gbps] C. Paasch, G. Detal, S. Barré, F. Duchêne, O. Bonaventure, “The fastest TCP connection with Multipath TCP”
(7) – [SIGCOMM11] C. Raiciu, S. Barré, C. Pluntke, A. Greenhalgh, D. Wischik, M. Handley, “Improving datacenter performance and robustness with Multipath TCP” in proceedings of ACM SIGCOMM 2011
(8) – [Cellnet12] C. Paasch, G. Detal, F. Duchene, C. Raiciu and O. Bonaventure. “Exploring Mobile/WiFi Handover with Multipath TCP”. ACM SIGCOMM workshop on Cellular Networks (Cellnet’12), 2012
(9) – [NSDI12] C. Raiciu, C. Paasch, S. Barré, A. Ford, M. Honda, F. Duchene, O. Bonaventure, M. Handley, “How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP”, USENIX NSDI’2012