Multipath TCP

Last updated
Multipath TCP (MPTCP)
Communication protocol
MPTCP logo.svg
PurposeGeneral Purpose
Developer(s) IETF
Introduction2009;15 years ago (2009)
Based on IP, normally layered with TCP
OSI layer Transport layer
RFC(s) RFC   8684

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 throughput and increase redundancy. [1]

Contents

In January 2013, the IETF published the Multipath specification as an Experimental standard in RFC   6824. It was replaced in March 2020 by the Multipath TCP v1 specification in RFC  8684.

Benefits

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 standard TCP. Multipath TCP is backward compatible with standard TCP.

Multipath TCP is particularly useful in the context of wireless networks; [2] using both Wi-Fi and a mobile network is a typical use case. [3] 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. [4]

The problem of link handover is thus solved by abstraction in the transport layer, without any special mechanisms at the network or link layers. 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. [5] 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. [6]

Multipath TCP causes a number of new issues. From a network security perspective, multipath routing causes cross-path data fragmentation that results in firewalls and malware scanners becoming inefficient when they only see one path's traffic. In addition, SSL decryption will become inefficient by way of the end-to-end encryption protocols. [7]

User interface

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. [8]

Multipath TCP in the protocol stack Multipath TCP architecture.jpg
Multipath TCP in the protocol stack

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 [9] and an enhanced socket API. [10]

Implementations

In July 2013, the MPTCP working group reported five independent implementations of Multipath TCP, [11] including the initial reference implementation [8] in the Linux kernel. [12] [13]

The currently available implementations are:

In July 2014, Oracle reported that an implementation on Solaris was being developed. In June 2015, work is in progress. [22] There is also an ongoing effort to push a new Multipath TCP implementation in the mainline Linux kernel. [23]

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. [24] Tessares uses the Linux kernel implementation to deploy Hybrid Access Networks.

Use cases

Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments [25] 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 [26] of Multipath TCP with this application are:

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. [27] Another example are the Hybrid 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. [28]

In the standardisation of converged fixed and mobile communication networks, 3GPP and BBF are interoperating to provide an ATSSS (Access Traffic Selection, Switching, Splitting) feature to support multipath sessions, e.g, by applying Multipath TCP both in the User Equipment (UE) or Residential Gateway (RG) and on the network side. [29]

Multipath TCP options

Multipath TCP uses options that are described in detail in RFC  8684. All Multipath TCP options are encoded as TCP options with Option Kind 30, as reserved by IANA. [30]

The Multipath TCP option consists of the standard Option-Kind (in this case 30) and Length values, followed by a 4-bit subtype field, for which the IANA maintains a sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. This subtype field indicates the MPTCP header type, and its values are defined as follows:

ValueSymbolName
0x0MP_CAPABLEMultipath Capable
0x1MP_JOINJoin Connection
0x2DSSData Sequence Signal (Data ACK and Data Sequence Mapping)
0x3ADD_ADDRAdd Address
0x4REMOVE_ADDRRemove Address
0x5MP_PRIOChange Subflow Priority
0x6MP_FAILFallback
0x7MP_FASTCLOSEFast Close
0x8MP_TCPRSTSubflow Reset
0xfMP_EXPERIMENTALReserved for Private Use

Values 0x9 through 0xe are currently unassigned.

Protocol operation

Simplified description

Difference between TCP and MPTCP DifferenceTCP MPTCP-en.png
Difference between TCP and MPTCP

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 20.21.22.23).

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:

Example of a full MPTCP session MPTCP-session-en.png
Example of a full MPTCP session

Multipath TCP adds new mechanisms to TCP transmissions:

Detailed specification

The detailed protocol specification is provided in RFC 8684. Several survey articles provide an introduction to the protocol. [31] [32]

Congestion control

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. [3] Four Multipath TCP congestion control schemes are currently supported by the Multipath TCP implementation in the Linux kernel.

Alternatives

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. [35]

IMS SIP

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) has been under discussion within the IETF. [36] Multipath RTP can offer flow granularity with concurrent access and mobility (via IMS, SDP signaling or the RTP control protocol). [35] Very recently in addition a proposal to extend also DCCP (Datagram Congestion Control Protocol) by a multipath feature is discussed at IETF in TSVWG (Transport Area Working Group) [37] dubbed as MP-DCCP.

Multipath QUIC

The IETF is currently developing the QUIC protocol that integrates the features that are traditionally found in the TCP, TLS and HTTP protocols. It can be extended to support the same use cases as Multipath TCP. A first design for Multipath QUIC has been proposed, [38] implemented and evaluated. [39]

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. [40]

Parallel access schemes [35] 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

See also

Related Research Articles

The Internet protocol suite, commonly known as TCP/IP, is a framework for organizing the set of communication protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP). Early versions of this networking model were known as the Department of Defense (DoD) model because the research and development were funded by the United States Department of Defense through DARPA.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

Traffic shaping is a bandwidth management technique used on computer networks which delays some or all datagrams to bring them into compliance with a desired traffic profile. Traffic shaping is used to optimize or guarantee performance, improve latency, or increase usable bandwidth for some kinds of packets by delaying other kinds. It is often confused with traffic policing, the distinct but related practice of packet dropping and packet marking.

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

Transmission Control Protocol (TCP) uses a congestion control algorithm that includes various aspects of an additive increase/multiplicative decrease (AIMD) scheme, along with other schemes including slow start and congestion window (CWND), to achieve congestion avoidance. The TCP congestion-avoidance algorithm is the primary basis for congestion control in the Internet. Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. There are several variations and versions of the algorithm implemented in protocol stacks of operating systems of computers that connect to the Internet.

A middlebox is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding. Examples of middleboxes include firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) devices.

H-TCP is another implementation of TCP with an optimized congestion control algorithm for high speed networks with high latency. It was created by researchers at the Hamilton Institute in Ireland.

iWARP is a computer networking protocol that implements remote direct memory access (RDMA) for efficient data transfer over Internet Protocol networks. Contrary to some accounts, iWARP is not an acronym.

Data center bridging (DCB) is a set of enhancements to the Ethernet local area network communication protocol for use in data center environments, in particular for use with clustering and storage area networks.

<span class="mw-page-title-main">Mark Handley (computer scientist)</span>

Mark James Handley is Professor of Networked Systems in the Department of Computer Science of University College London since 2003, where he leads the Networks Research Group.

TCP Cookie Transactions (TCPCT) is specified in RFC 6013 as an extension of Transmission Control Protocol (TCP) intended to secure it against denial-of-service attacks, such as resource exhaustion by SYN flooding and malicious connection termination by third parties. Unlike the original SYN cookies approach, TCPCT does not conflict with other TCP extensions, but requires TCPCT support in the client (initiator) as well as the server (responder) TCP stack.

Mobile data offloading is the use of complementary network technologies for delivering data originally targeted for cellular networks. Offloading reduces the amount of data being carried on the cellular bands, freeing bandwidth for other users. It is also used in situations where local cell reception may be poor, allowing the user to connect via wired services with better connectivity.

In computer networking, tcpcrypt is a transport layer communication encryption protocol. Unlike prior protocols like TLS (SSL), tcpcrypt is implemented as a TCP extension. It was designed by a team of six security and networking experts: Andrea Bittau, Mike Hamburg, Mark Handley, David Mazières, Dan Boneh and Quinn Slack. Tcpcrypt has been published as an Internet Draft. Experimental user-space implementations are available for Linux, Mac OS X, FreeBSD and Windows. There is also a Linux kernel implementation.

Bufferbloat is a cause of high latency and jitter in packet-switched networks caused by excess buffering of packets. Bufferbloat can also cause packet delay variation, as well as reduce the overall network throughput. When a router or switch is configured to use excessively large buffers, even very high-speed networks can become practically unusable for many interactive applications like voice over IP (VoIP), audio streaming, online gaming, and even ordinary web browsing.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

RDMA over Converged Ethernet (RoCE) or InfiniBand over Ethernet (IBoE) is a network protocol which allows remote direct memory access (RDMA) over an Ethernet network. It does this by encapsulating an InfiniBand (IB) transport packet over Ethernet. There are multiple RoCE versions. RoCE v1 is an Ethernet link layer protocol and hence allows communication between any two hosts in the same Ethernet broadcast domain. RoCE v2 is an internet layer protocol which means that RoCE v2 packets can be routed. Although the RoCE protocol benefits from the characteristics of a converged Ethernet network, the protocol can also be used on a traditional or non-converged Ethernet network.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge, Firefox, and Safari support it.

Hybrid Access Networks refer to a special architecture for broadband access networks where two different network technologies are combined to improve bandwidth. A frequent motivation for such Hybrid Access Networks to combine one xDSL network with a wireless network such as LTE. The technology is generic and can be applied to combine different types of access networks such as DOCSIS, WiMAX, 5G or satellite networks. The Broadband Forum has specified an architecture as a framework for the deployment of such converged networks.

Protocol ossification is the loss of flexibility, extensibility and evolvability of network protocols. This is largely due to middleboxes that are sensitive to the wire image of the protocol, and which can interrupt or interfere with messages that are valid but which the middlebox does not correctly recognise. This is a violation of the end-to-end principle. Secondary causes include inflexibility in endpoint implementations of protocols.

References

  1. ↑ Multipath TCP working group
  2. ↑ Paasch, Christoph; Detal, Gregory; Duchene, Fabien; Raiciu, Costin; Bonaventure, Olivier (2012). "Exploring mobile/WiFi handover with multipath TCP". Proceedings of the 2012 ACM SIGCOMM workshop on Cellular networks: Operations, challenges, and future design - Cell Net '12. ACM SIGCOMM workshop on Cellular Networks (Cellnet'12). p. 31. doi: 10.1145/2342468.2342476 . ISBN   9781450314756.
  3. 1 2 S. Pokhrel; M. Panda; H. Vu (2017-02-24). "Analytical Modeling of Multipath TCP Over Last-Mile Wireless". IEEE/ACM Transactions on Networking. 25 (3): 1876–1891. doi:10.1109/TNET.2017.2663524. S2CID   21518823.
  4. ↑ S. Pokhrel; M. Mandjes (2019-03-24). "Improving Multipath TCP Performance over WiFi and Cellular Networks: an Analytical Approach". IEEE Transactions on Mobile Computing. 25 (3): 1876–1891. doi:10.1109/TMC.2018.2876366. S2CID   69263415.
  5. ↑ Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). "Improving datacenter performance and robustness with multipath TCP". ACM SIGCOMM Computer Communication Review. 41 (4): 266. CiteSeerX   10.1.1.306.3863 . doi:10.1145/2043164.2018467. S2CID   61962047.
  6. ↑ C. Paasch; G. Detal; S. Barré; F. Duchêne; O. Bonaventure. "The fastest TCP connection with Multipath TCP" . Retrieved 2013-09-20.
  7. ↑ Afzal, Zeeshan (2020). Life of a Security Middlebox Challenges with Emerging Protocols and Technologies (PhD). ISBN   978-91-7867-103-8. OCLC   1139703033.
  8. 1 2 3 "The Linux kernel MultiPath TCP project" . Retrieved 2014-11-28.
  9. ↑ Hesmans, B.; Detal, G.; Barre, S.; Bauduin, R.; Bonaventure, O. (2015). "SMAPP". SMAPP towards smart Multipath TCP-enabled applications. pp. 1–7. doi:10.1145/2716281.2836113. ISBN   9781450334129. S2CID   9940025.
  10. ↑ Hesmans, Benjamin; Bonaventure, Olivier (2016). "An enhanced socket API for Multipath TCP". Proceedings of the 2016 workshop on Applied Networking Research Workshop - ANRW 16. pp. 1–6. doi:10.1145/2959424.2959433. ISBN   9781450344432. S2CID   13799560.
  11. ↑ "Survey of MPTCP Implementations (Internet-Draft, 2013)" . Retrieved 2013-09-20.
  12. ↑ Barre; Paasch; Bonaventure (2011). "MultiPath TCP: From Theory to Practice". IFIP Networking.
  13. ↑ Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". Usenix NSDI: 399–412.
  14. ↑ "Linux MPTCP Upstream Project".
  15. ↑ "Multipath TCP for FreeBSD v0.1" . Retrieved 2013-09-23.
  16. ↑ "Release Note: BIG-IP LTM and TMOS 11.5.0". f5 Networks. 2014-05-30. Retrieved 2014-05-30.
  17. ↑ John Gudmundson (2013-05-28). "Maximize mobile user experience with NetScaler Multipath TCP". Citrix. Retrieved 2013-09-20.
  18. ↑ "Apple seems to also believe in Multipath TCP" . Retrieved 2013-09-20.
  19. ↑ "MPTCP ROAMS FREE (BY DEFAULT!) – OS X YOSEMITE". 2014-10-20. Retrieved 2015-09-16.
  20. ↑ Georg Hampel (2012-10-26). "code release for MPTCP Proxy". Alcatel-Lucent. Retrieved 2016-12-28.
  21. ↑ Georg Hampel; Anil Rana (2012-10-26). "MPTCP PROXY" (PDF). Bell Labs/Alcatel-Lucent . Retrieved 2016-12-28.
  22. ↑ Rao, Shoaib. "Some comments on RFC 6824" . Retrieved 25 June 2015.
  23. ↑ "MPTCP Upstream Project". 2019-12-17. Retrieved 2020-01-10.
  24. ↑ "KT's GiGA LTE" (PDF).
  25. ↑ Bonaventure, Olivier; See, SungHoon (2016). "Multipath TCP Deployments". IETF Journal.
  26. ↑ C. Paasch, iOS & Linux Implementation Updates, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/
  27. ↑ 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
  28. ↑ 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
  29. ↑ 3GPP TR 23.793, "Study on access traffic steering, switch and splitting support in the 5G system architecture (Release 16)", https://www.3gpp.org/ftp/Specs/latest/Rel-16/23_series/23793-g00.zip
  30. ↑ "IANA Protocol Registry TCP Option Kind Numbers" . Retrieved 2013-09-24.
  31. ↑ Paasch, Christoph; Bonaventure, Olivier (April 2014). "Multipath TCP". Communications of the ACM. 57 (4): 51–57. doi:10.1145/2578901. S2CID   17581886.
  32. ↑ Raiciu, Costin; Iyengar, Janardhan; Bonaventure, Olivier (2013). Haddadi, Hamed; Bonaventure, Olivier (eds.). Recent Advances in Reliable Transport Protocols. ACM SIGCOMM.
  33. ↑ 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. pp. 1–12. doi:10.1145/2413176.2413178. ISBN   9781450317757. S2CID   14210629.
  34. ↑ Peng, Qiuyu; Walid, Anwar; Hwang, Jaehyun; Low, Steven H. (2013). "Multipath TCP: Analysis, Design and Implementation". IEEE/ACM Transactions on Networking. 24: 596–609. arXiv: 1308.3119 . Bibcode:2013arXiv1308.3119P. doi:10.1109/TNET.2014.2379698. S2CID   250322.
  35. 1 2 3 P. Rodriguez; E. Biersack (2002-07-01). "Dynamic parallel access to replicated content in the Internet" (PDF). IEEE/ACM Transactions on Networking. Archived from the original (PDF) on 2013-09-27.
  36. ↑ "Draft-ietf-avtcore-MPRTP-03".
  37. ↑ "Draft-ietf-TSVWG-multipath-DCCP-04".
  38. ↑ Q. De Coninck; O. Bonaventure (2010-10-30). "Multipath Extension for QUIC". IETF.
  39. ↑ Q. De Coninck; O. Bonaventure (2010-12-12). "Multipath QUIC: Design and Evaluation" (PDF). Proc. Conext'2017, Seoul, Korea.
  40. ↑ R. Chakravorty; I. Pratt; P. Rodriguez (2003-07-01). "Mobile Access Router". University of Cambridge, Microsoft Research.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.