Abstract

Multipath TCP (MPTCP) extends the standard TCP protocol to allow a single connection to use multiple network paths simultaneously, distributing traffic across interfaces and improving both throughput and resilience. In mobile environments where a device may maintain concurrent Wi-Fi and cellular interfaces, and in 5G networks where multiple radio access paths are common, MPTCP offers measurable benefits for latency-sensitive applications. The Linux kernel has shipped an MPTCP implementation since version 5.6, and Apple has deployed MPTCP in Siri and general data offload since iOS 7, making the protocol far more available than its niche reputation suggests. This article covers how MPTCP establishes and manages subflows, how 5G network slicing interacts with multipath capabilities, and where deployment friction remains.

Subflow Establishment and Scheduler Behavior

An MPTCP connection begins as a standard TCP handshake on one path, with the MP_CAPABLE option in the SYN exchanged to negotiate MPTCP support. Once established, additional subflows are created on other available interfaces via a separate handshake carrying the MP_JOIN option and a token derived from the initial connection. Each subflow has its own sequence number space and congestion window, while MPTCP maintains a connection-level sequence space to reassemble data in order at the receiver.

The scheduler determines how data is distributed across subflows. The default coupled congestion control algorithm - defined in RFC 6356 and updated in RFC 8684 - aims to be no more aggressive than a single TCP flow would be on the most congested path, while shifting traffic toward less congested paths. This matters for fairness in shared networks. Alternative schedulers such as BLEST (Blocking Estimation-Based Scheduler) and round-robin are available in the Linux kernel via sysctl configuration and are used in high-throughput scenarios where the default scheduler’s conservatism limits aggregate bandwidth.

Interaction with 5G Network Slicing

5G’s network slicing model defines separate logical networks with distinct QoS profiles over the same physical infrastructure. A device connected to both a Wi-Fi access point and a 5G NR radio can create MPTCP subflows on each, with the cellular subflow routed through a specific network slice appropriate to the application’s requirements. This combination lets an application request low-latency characteristics from the 5G slice while using Wi-Fi for bulk data offload, all within the same TCP connection.

The 3GPP Multi-Access PDU Session framework, specified in Release 16, provides the anchoring mechanism. The UPF (User Plane Function) at the 5G core acts as the ATSSS (Access Traffic Steering, Switching, and Splitting) entity, and MPTCP is one of two supported steering protocols alongside MPQUIC. Operators at the IETF MPTCP working group and 3GPP SA2 have worked to align the semantics, with the result that standards-compliant implementations on iOS 15+ and Android devices with updated RIL stacks can take advantage of slice-aware multipath without application modification.

Middlebox and NAT Interference

The most persistent deployment problem for MPTCP is middlebox interference. Firewalls and NAT devices that strip or reject unknown TCP options will silently downgrade an MPTCP connection to standard TCP on the first path. RFC 8684 includes fallback mechanisms: if the server detects that the MP_CAPABLE option was stripped, both endpoints fall back to regular TCP without breaking the connection. The fallback is transparent to the application but eliminates any multipath benefit.

Network operators can detect this interference by monitoring MPTCP capability negotiation success rates from a proxy or monitoring point. The MPTCP daemon project (mptcpd), which runs in userspace on Linux and handles path management via Netlink, logs subflow creation and teardown events that make it possible to observe when fallback is occurring at scale. Eliminating middlebox stripping typically requires auditing firewall rule sets and updating stateful inspection policies to pass unknown TCP options - a change that is straightforward in software firewalls but requires firmware updates on some hardware appliances.

Current Deployment and Tooling

Apple’s MPTCP deployment remains the largest in production: iOS routes Siri, Maps, and background sync traffic over MPTCP, and macOS 13+ exposes MPTCP through the Network framework. On Linux, ip mptcp commands manage endpoint and limit configuration, and ss -M shows active MPTCP connections with subflow detail. Kernel 6.6 added improved fallback handling and improved scheduler extensibility that makes custom schedulers easier to load as kernel modules, reducing the friction of experimenting with scheduler policies in production.