|Internet protocol suite|
Multipath TCP (MPTCP) is an ongoing effort of the Internet Engineering Task Force's (IETF) Multipath TCP working group, that aims at allowing a Transmission Control Protocol (TCP) connection to use multiple paths to maximize resource usage and increase redundancy.
In January 2013, the IETF published the Multipath specification as an Experimental standard in RFC 6824.
- 1 Benefits
- 2 User interface
- 3 Implementation
- 4 Use cases
- 5 Multipath TCP options
- 6 Protocol operation
- 7 Congestion control
- 8 Alternatives
- 9 RFC
- 10 See also
- 11 References
- 12 External links
The redundancy offered by Multipath TCP enables inverse multiplexing of resources, and thus increases TCP throughput to the sum of all available link-level channels instead of using a single one as required by plain TCP. Multipath TCP is backward compatible with plain TCP.
Multipath TCP is particularly useful in the context of wireless networks - using both Wi-Fi and a mobile network is a typical use case. In addition to the gains in throughput from inverse multiplexing, links may be added or dropped as the user moves in or out of coverage without disrupting the end-to-end TCP connection. The problem of link handover is thus solved by abstraction in the transport layer, without any special mechanisms at the network or link level. Handover functionality can then be implemented at the endpoints without requiring special functionality in the subnetworks - in accordance to the Internet's end-to-end principle.
Multipath TCP also brings performance benefits in datacenter environments. In contrast to Ethernet channel bonding using 802.3ad link aggregation, Multipath TCP can balance a single TCP connection across multiple interfaces and reach very high throughput.
In order to facilitate its deployment, Multipath TCP presents the same socket interface as TCP. This implies that any standard TCP application can be used above Multipath TCP while in fact spreading data across several subflows.
Some applications could benefit from an enhanced API to control the underlying Multipath TCP stack. Two different APIs have been proposed to expose some of features of the Multipath TCP stack to applications: an API that extends Netlink on Linux  and an enhanced socket API.
The currently available implementations are:
- Linux kernel (reference implementation) from Université catholique de Louvain,
- FreeBSD (IPv4 only) from Swinburne University of Technology,
- F5 Networks BIG-IP LTM,
- Citrix Netscaler,
- Apple iOS 7, released on September 18, 2013 is the first large scale commercial deployment of Multipath TCP.. Since iOS 7, any application can use Multipath TCP.
- Apple Mac OS X 10.10, released on October 16, 2014.
- Alcatel-Lucent released MPTCP proxy version 0.9 source code on October 26, 2012.
During the MPTCP WG meeting at IETF 93, SungHoon Seo announced that KT had deployed since mid June a commercial service that allows smartphone users to reach 1 Gbit/s using a MPTCP proxy service.
Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments  leverage the ability of simultaneously using different paths.
Apple uses Multipath TCP to support the Siri application on IPhone. Siri sends voice samples over an HTTPS session to Apple servers. Those servers reply with the information requested by the users. According to Apple engineers, the main benefits of Multipath TCP with this application are :
- User-feedback (Time-to-First-Word) 20% faster in the 95th percentile
- 5x reduction of network failures
Other deployment use Multipath TCP to aggregate the bandwidth of different networks. For example, several types of smartphones, notably in Korea, use Multipath TCP to bond WiFi and 4G through SOCKS proxies. Another example are the Hybrid Broadband Access networks that are deployed by network operators willing to combine xDSL and LTE networks. In this deployment, Multipath TCP is used to efficiently balance the traffic over the xDSL and the LTE network.
Multipath TCP options
The Multipath TCP option has the Kind (30), length (variable) and the remainder of the content begins with a 4-bit subtype field, for which IANA has created and will maintain a sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. Those subtype fields are defined as follows:
|0x2||DSS||Data Sequence Signal (Data ACK and data sequence mapping)|
|0x5||MP_PRIO||Change Subflow Priority|
|0xf||(PRIVATE)||Private Use within controlled testbeds|
Values 0x8 through 0xe are currently unassigned.
The core idea of multipath TCP is to define a way to build a connection between two hosts and not between two interfaces (as standard TCP does).
For instance, Alice has a smartphone with 3G and WiFi interfaces (with IP addresses 10.11.12.13 and 10.11.12.14) and Bob has a computer with an Ethernet interface (with IP address 184.108.40.206).
In standard TCP, the connection should be established between two IP addresses. Each TCP connection is identified by a four-tuple (source and destination addresses and ports). Given this restriction, an application can only create one TCP connection through a single link. Multipath TCP allows the connection to use several paths simultaneously. For this, Multipath TCP creates one TCP connection, called subflow, over each path that needs to be used.
The purpose of the different protocol operations (defined in RFC 6824) are:
- to handle when and how to add/remove paths (for instance if there's a connection lost of some congestion control)
- to be compatible with legacy TCP hardware (such as some firewalls that can automatically reject TCP connections if the sequence number aren't successive)
- to define a fair congestion control strategy between the different links and the different hosts (especially with those that doesn't support MPTCP)
Multipath TCP adds new mechanisms to TCP transmissions:
- The subflow system, used to gather multiple standard TCP connections (the paths from one host to another). Subflows are identified during the TCP three-way handshake. After the handshake, an application can add or remove some subflows (subtypes 0x3 and 0x4).
- The MPTCP DSS option contains a data sequence number and an acknowledgement number. These allow receiving data from multiple subflows in the original order, without any corruption (message subtype 0x2)
- A modified retransmission protocol handles congestion control and reliability.
Several congestion control mechanisms have been defined for Multipath TCP. Their main difference with classical TCP congestion control schemes is that they need to react to congestion on the different paths without being unfair with single path TCP sources that could compete with them on one of the paths. Four Multipath TCP congestion control schemes are currently supported by the Multipath TCP implementation in the Linux kernel.
- The Linked Increase Algorithm defined in RFC6356
- The Opportunistic Linked Increase Algorithm
- The wVegas delay based congestion control algorithm
- The Balanced Linked Increase Algorithm 
Stream Control Transmission Protocol
Stream Control Transmission Protocol (SCTP) is a reliable in-order datagram stream transport protocol originally intended for telecommunication signaling. It supports concurrent use of multiple access links and allows the application to influence the access interface selections on a datagram stream basis. It also supports mobility via access renegotiation. Hence, SCTP is also a transport layer solution. It offers type 3 flow granularity with concurrency, but with more flow scheduling control than Multipath TCP. It also fully supports mobility in a fashion similar to Multipath TCP.
Within the IP Multimedia Subsystem (IMS) architecture, Session Initiation Protocol (SIP) can support the concurrent use of multiple contact IP addresses for the registration of one or more IMS user agents. This allows for the creation of multiple IMS signaling paths. On these signaling paths, signaling messages carry Session Description Protocol (SDP) messaging to negotiate media streams. SDP allows for the (re-)negotiation of the streams of one media session over multiple paths. In turn, this enables application layer multipath transport. From this point of view, IMS can therefore offer application layer multipath support with flow granularity and concurrent access. A multipath extension to Real-time Transport Protocol (RTP) is currently under discussion within the IETF. Multipath RTP can offer flow granularity with concurrent access and mobility (via IMS, SDP signaling or the RTP control protocol).
The IETF is currently developing the QUIC protocol that integrates the features that are traditionally found in the TCP, TLS and HTTP protocols. Thanks to the flexibility and extensibility of QUIC, it is possible to extend it to support multiple paths and address the same use cases as Multipath TCP. A first design for Multipath QUIC has been proposed, implemented and evaluated.
Other protocols and experiments
At the session layer, the Mobile Access Router project experimented in 2003 with the aggregation of multiple wireless accesses with heterogeneous technologies, transparently balancing traffic between them in response to the perceived performance of each of them.
Parallel access schemes used to accelerate transfers by taking advantage of HTTP range requests to initiate connections to multiple servers of a replicated content, are not equivalent to Multipath TCP as they involve the application layer and are limited to content of known size.
- RFC 6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
- RFC 6182 - Architectural Guidelines for Multipath TCP Development
- RFC 6356 - Coupled Congestion Control for Multipath Transport Protocols
- RFC 6824 - TCP Extensions for Multipath Operation with Multiple Addresses
- RFC 6897 - Multipath TCP (MPTCP) Application Interface Considerations
- RFC 7430 - Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
- RFC 8041 - Use Cases and Operational Experience with Multipath TCP
- Multipath TCP working group
- Paasch, Christoph; Detal, Gregory; Duchene, Fabien; Raiciu, Costin; Bonaventure, Olivier (2012). "Proceedings of the 2012 ACM SIGCOMM workshop on Cellular networks: Operations, challenges, and future design - Cell Net '12": 31. doi:10.1145/2342468.2342476. ISBN 9781450314756.
- S. Pokhrel; M. Panda; H. Vu (2017-02-24). "Analytical Modeling of Multipath TCP Over Last-Mile Wireless". IEEE/ACM Transactions on Networking.
- Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). "Improving datacenter performance and robustness with multipath TCP". Sigcomm.
- C. Paasch; G. Detal; S. Barré; F. Duchêne; O. Bonaventure. "The fastest TCP connection with Multipath TCP". Retrieved 2013-09-20.
- "The Linux kernel MultiPath TCP project". Retrieved 2014-11-28.
- Hesmans, B.; Detal, G.; Barre, S.; Bauduin, R.; Bonaventure, O. (2015). "SMAPP towards smart Multipath TCP-enabled applications": 1–7. doi:10.1145/2716281.2836113.
- "Survey of MPTCP Implementations (Internet-Draft, 2013)". Retrieved 2013-09-20.
- Barre; Paasch; Bonaventure (2011). "MultiPath TCP: From Theory to Practice". IFIP Networking.
- Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". USENIX NSDI.
- "Multipath TCP for FreeBSD v0.1". Retrieved 2013-09-23.
- "Release Note: BIG-IP LTM and TMOS 11.5.0". f5 Networks. 2014-05-30. Retrieved 2014-05-30.
- John Gudmundson (2013-05-28). "Maximize mobile user experience with NetScaler Multipath TCP". Citrix. Retrieved 2013-09-20.
- "Apple seems to also believe in Multipath TCP". Retrieved 2013-09-20.
- "MPTCP ROAMS FREE (BY DEFAULT!) – OS X YOSEMITE". Retrieved 2015-09-16.
- Georg Hampel (2012-10-26). "code release for MPTCP Proxy". Alcatel-Lucent. Retrieved 2016-12-28.
- Georg Hampel; Anil Rana (2012-10-26). "MPTCP PROXY" (PDF). Bell Labs/Alcatel-Lucent. Retrieved 2016-12-28.
- Rao, Shoaib. "Some comments on RFC 6824". Retrieved 25 June 2015.
- "KT's GiGA LTE" (PDF).
- Bonaventure, Olivier; See, SungHoon (2016). "Multipath TCP Deployments". IETF Journal.
- C. Paasch, iOS & Linux Implementation Updates, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/
- S. Seo, KT’s GiGA LTE - Mobile MPTCP Proxy Deployment, IETF-97, https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-01.pdf
- Gregory Detal, Sebastien Barre, Bart Peirens, Olivier Bonaventure, "Leveraging Multipath TCP to create Hybrid Access Networks ", SIGCOMM'17 (Industrial demo), http://conferences.sigcomm.org/sigcomm/2017/files/program-industrial-demos/sigcomm17industrialdemos-paper4.pdf
- "IANA Protocol Registry TCP Option Kind Numbers". Retrieved 2013-09-24.
- Paasch, Christoph; Bonaventure, Olivier (April 2014). "Multipath TCP". Communications of the ACM. 57 (4): 51–57. doi:10.1145/2578901.
- Raiciu, Costin; Iyengar, Janardhan; Bonaventure, Olivier (2013). Haddadi, Hamed; Bonaventure, Olivier, eds. Recent Advances in Reliable Transport Protocols. ACM SIGCOMM.
- Khalili, Ramin; Gast, Nicolas; Popovic, Miroslav; Upadhyay, Utkarsh; Le Boudec, Jean-Yves (2012). "MPTCP is not pareto-optimal". Proceedings of the 8th international conference on Emerging networking experiments and technologies - CoNEXT '12: 1. doi:10.1145/2413176.2413178. ISBN 9781450317757.
- Peng, Qiuyu; Walid, Anwar; Hwang, Jaehyun; Low, Steven H. (2013). "Multipath TCP: Analysis, Design and Implementation". arXiv: .
- P. Rodriguez; E. Biersack (2002-07-01). "Dynamic parallel access to replicated content in the Internet" (PDF). IEEE/ACM Transactions on Networking.
- Q. De Coninck; O. Bonaventure (2010-10-30). "Multipath Extension for QUIC". IETF Internet draft.
- Q. De Coninck; O. Bonaventure (2010-12-12). "Multipath QUIC: Design and Evaluation" (PDF). Proc. Conext'2017, Seoul, Korea.
- R. Chakravorty; I. Pratt; P. Rodriguez (2003-07-01). "Mobile Access Router". University of Cambridge, Microsoft Research.
|Wikiversity has learning resources about Transmission Control Protocol|