Introduction
Multipath TCP or MPTCP is an extension to the standard TCP and is described in RFC 8684. It allows a device to make use of multiple interfaces at once to send and receive TCP packets over a single MPTCP connection. MPTCP can aggregate the bandwidth of multiple interfaces or prefer the one with the lowest latency. It also allows a fail-over if one path is down, and the traffic is seamlessly reinjected on other paths.
graph TD; subgraph MPTCP direction LR C_1(
Multiple paths (subflows)
at the same time" ==> S_1 C_2 x-. "5G" .-x S_2 C_2 <== "Wi-Fi
One path at a time" ==> S_2 linkStyle 0 stroke:green; linkStyle 1 stroke:green; linkStyle 2 stroke:red; linkStyle 3 stroke:green; Use cases Thanks to MPTCP, being able to use multiple paths in parallel or simultaneously brings new use-cases, compared to TCP: Seamless handovers: switching from one path to another while preserving established connections, e.g. Apple is using Multipath TCP on smartphones mainly for this reason since 2013. Best network selection: using the “best” available path depending on some conditions, e.g. latency, losses, cost, bandwidth, etc. Network aggregation: using multiple paths at the same time to have a higher throughput, e.g. to combine fixed and mobile networks to send files faster. Concepts Technically, when a new socket is created with the IPPROTO_MPTCP protocol (Linux-specific), a subflow (or path) is created. This subflow consists of a regular TCP connection that is used to transmit data through one interface. Additional subflows can be negotiated later between the hosts. For the remote host to be able to detect the use of MPTCP, a new field is added to the TCP option field of the underlying TCP subflow. This field contains, amongst other things, a MP_CAPABLE option that tells the other host to use MPTCP if it is supported. If the remote host or any middlebox in between does not support it, the returned SYN+ACK packet will not contain MPTCP options in the TCP option field. In that case, the connection will be “downgraded” to plain TCP, and it will continue with a single path. This behavior is made possible by two internal components: the path manager, and the packet scheduler. Path Manager The Path Manager is in charge of subflows, from creation to deletion, and also address announcements. Typically, it is the client side that initiates subflows, and the server side that announces additional addresses via the ADD_ADDR and REMOVE_ADDR options. graph LR; C_1(
Scheduler} I_21(subflow 1) I_22(subflow 2) A_2 == "
fa:fa-mobile
) S_1((fa:fa-cloud
)) end subgraph TCP direction LR C_2(fa:fa-mobile
) S_2((fa:fa-cloud
)) end C_1 <== "5G" ==> S_1 C_1 <== "Wi-FiMultiple paths (subflows)
at the same time" ==> S_1 C_2 x-. "5G" .-x S_2 C_2 <== "Wi-Fi
One path at a time" ==> S_2 linkStyle 0 stroke:green; linkStyle 1 stroke:green; linkStyle 2 stroke:red; linkStyle 3 stroke:green; Use cases Thanks to MPTCP, being able to use multiple paths in parallel or simultaneously brings new use-cases, compared to TCP: Seamless handovers: switching from one path to another while preserving established connections, e.g. Apple is using Multipath TCP on smartphones mainly for this reason since 2013. Best network selection: using the “best” available path depending on some conditions, e.g. latency, losses, cost, bandwidth, etc. Network aggregation: using multiple paths at the same time to have a higher throughput, e.g. to combine fixed and mobile networks to send files faster. Concepts Technically, when a new socket is created with the IPPROTO_MPTCP protocol (Linux-specific), a subflow (or path) is created. This subflow consists of a regular TCP connection that is used to transmit data through one interface. Additional subflows can be negotiated later between the hosts. For the remote host to be able to detect the use of MPTCP, a new field is added to the TCP option field of the underlying TCP subflow. This field contains, amongst other things, a MP_CAPABLE option that tells the other host to use MPTCP if it is supported. If the remote host or any middlebox in between does not support it, the returned SYN+ACK packet will not contain MPTCP options in the TCP option field. In that case, the connection will be “downgraded” to plain TCP, and it will continue with a single path. This behavior is made possible by two internal components: the path manager, and the packet scheduler. Path Manager The Path Manager is in charge of subflows, from creation to deletion, and also address announcements. Typically, it is the client side that initiates subflows, and the server side that announces additional addresses via the ADD_ADDR and REMOVE_ADDR options. graph LR; C_1(
fa:fa-mobile
) S_1((fa:fa-cloud
)) C_1 -. "Potential subflow" -.- S_1 C_1 <== "Initial subflow" ==> S_1 C_1 ~~~|"Subflows creation"| C_1 S_1 ~~~|"Addresses announcement"| S_1 linkStyle 0 stroke:orange; linkStyle 1 stroke:green;
As of Linux v5.19, there are two path managers, controlled by the net.mptcp.pm_type sysctl knob: the in-kernel one (type 0 ) where the same rules are applied for all the connections (see: ip mptcp ) ; and the userspace one (type 1 ), controlled by a userspace daemon (i.e. mptcpd ) where different rules can be applied for each connection.
Packet Scheduler
The Packet Scheduler is in charge of selecting which available subflow(s) to use to send the next data packet. It can decide to maximize the use of the available bandwidth, only to pick the path with the lower latency, or any other policy depending on the configuration.
graph LR; A_2(fa:fa-user
) PS{PacketScheduler} I_21(subflow 1) I_22(subflow 2) A_2 == "
fa:fa-box fa:fa-box fa:fa-box
" ==> PS PS -- "fa:fa-box fa:fa-box
" --> I_21 PS -- "fa:fa-box
" --> I_22 PS ~~~|"Packets distribution between subflows"| PS
As of Linux v6.8, there is only one packet scheduler, controlled by sysctl knobs in net.mptcp .
Features
As of Linux v6.10, major features of MPTCP include:
Support of the IPPROTO_MPTCP protocol in socket() system calls.
protocol in system calls. Fallback from MPTCP to TCP if the peer or a middlebox do not support MPTCP.
Path management using either an in-kernel or userspace path manager.
Socket options that are commonly used with TCP sockets.
Debug features including MIB counters, diag support (used by the ss command), and tracepoints.
See the ChangeLog for more details.
Communication
Mailing List: [email protected] ( plain text only ): Archives Info Subscribe by sending an empty email in plain text to [email protected], and by replying to the challenge email.
): IRC: #mptcp on libera.chat
Online Meetings
Blog
Fediverse
Projects
Kernel Development