https://www.mptcp.dev/

Skip to main content
Multipath TCP
for Linux
[mptcp_logo]

  * MPTCP
      + Features
      + Communication
      + Projects
      + Kernel Development
  * Setup
      + Kernel version
      + Enable MPTCP
      + Force applications to use MPTCP
      + Using multiple IP addresses
  * Debugging
      + ss
      + ip mptcp
      + nstat
      + TCPDump and WireShark
  * Implementation guide (Devs)
      + MPTCP socket
      + Examples in different languages
  * MPTCP info (Devs)
      + MPTCP socket level
      + Per-subflow Information
      + Number of subflows
      + Check for TCP fallback
  * FAQ
      + Are there any security & privacy concerns?
      + Why & when should MPTCP be enabled by default?
      + Are there any performance impacts when using MPTCP?
      + Are there unsupported TCP socket options?
      + What are the supported operating systems?
      + MPTCP vs. QUIC
      + MPTCPv0 vs. MPTCPv1
      + What about middleboxes?
      + How should applications handle missing MPTCP support?
      + What build time checks are needed/recommended?
      + Why is IPPROTO_MPTCP not defined?
      + How to check if MPTCP is working?
      + How to bootstrap a kernel development environment?
      + High number of retransmissions / dropped packets at the NIX
        RX queue level?
  * Apps supporting MPTCP
      + Linux apps
      + Tools
      + MacOS apps
      + Add native MPTCP support
      + Others?
  * Implementation details (Kernel)

Jekyll theme
Improve this page
[                    ]

  * Improve this website

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 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(<div style="display: inline-block; min-width: 32px"><font size="7">fa:fa-mobile</font></div>)
        S_1((<div style="display: inline-block; min-width: 55px"><font size="7">fa:fa-cloud</font></div>))
    end

    subgraph TCP
        direction LR
        C_2(<div style="display: inline-block; min-width: 32px"><font size="7">fa:fa-mobile</font></div>)
        S_2((<div style="display: inline-block; min-width: 55px"><font size="7">fa:fa-cloud</font></div>))
    end

    C_1 <== "5G" ==> S_1
    C_1 <== "Wi-Fi<br /><br />Multiple paths (<i>subflows</i>)<br />at the same time" ==> S_1

    C_2 x-. "5G" .-x S_2
    C_2 <== "Wi-Fi<br /><br />One path at a time" ==> S_2

    linkStyle 0 stroke:green;
    linkStyle 1 stroke:green;
    linkStyle 2 stroke:red;
    linkStyle 3 stroke:green;

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:

  * Path Manager: Manages 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(<div style="display: inline-block; min-width: 35px"><font size="7">fa:fa-mobile</font></div>)
        S_1((<div style="display: inline-block; min-width: 60px"><font size="7">fa:fa-cloud</font></div>))

        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: 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(<div style="display: inline-block; min-width: 40px"><font size="7">fa:fa-user</font></div>)

        PS{Packet<br />Scheduler}

        I_21(subflow 1)
        I_22(subflow 2)

        A_2 == "<div style='display: inline-block; min-width: 50px'>fa:fa-box fa:fa-box fa:fa-box</div>" ==> PS
        PS -- "<div style='display: inline-block; min-width: 32px'>fa:fa-box fa:fa-box</div>" --> I_21
        PS -- "<div style='display: inline-block; min-width: 14px'>fa:fa-box</div>" --> 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.
  * 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: mptcp@lists.linux.dev (and archives)
  * IRC: #mptcp on libera.chat
  * Online Meetings

 Projects

  * Maintained by MPTCP community members
      + Kernel development on GitHub
      + Multipath TCP Daemon
          o The mptcpd daemon can do full userspace path management
            or control the in-kernel path manager.
          o Includes the mptcpize utility to allow legacy TCP
            binaries to use MPTCP.
      + Packetdrill with MPTCP support
  * Projects with MPTCP-related enhancements
      + iproute2 (for the ip mptcp command)
      + Network Manager: MPTCP features are included starting with
        v1.40.
      + Multipath TCP applications: A project to coordinate MPTCP
        updates for popular TCP applications.

 Kernel Development

  * Git Repository (branch descriptions)
  * Patchwork
  * Continuous Integration
  * Testing
  * Issue tracker

---------------------------------------------------------------------

mptcp@lists.linux.dev

Archives

Git Repository

Issue tracker

Wiki