Multipath TCP (MPTCP)
1. Overview
A. Definition
MPTCP (Multipath TCP) is a transport-layer extension that carries a single TCP connection across multiple network paths (subflows) simultaneously, while still presenting the application with what looks like one standard TCP socket. The IETF standardized it as RFC 6824 (v0, 2013) and revised it as RFC 8684 (v1, 2020); it uses the TCP options field to bundle several interfaces (LTE, Wi-Fi, etc.) into one logical connection.
B. Background and necessity
Modern devices commonly hold more than one network interface at the same time. A smartphone has cellular (LTE/5G) and Wi-Fi, a data-center server has multiple NICs, and a laptop has both wired and wireless. Traditional TCP, however, is pinned to the 4-tuple of source/destination IP and port chosen at connection setup, so even if one path fails or becomes congested it cannot move to another interface. The classic case is a download that stalls when Wi-Fi signal weakens, even though cellular is perfectly alive. In other words, the device has spare capacity, yet TCP's rigid connection model cannot use it — a structural inefficiency.
The intuitive answer is "use several paths at once," but implementation is not simple. The Internet is full of middleboxes such as NATs, firewalls, and proxies that inspect and rewrite TCP headers, so a completely new transport protocol is easily blocked on the way. MPTCP accepts this reality and chose a design that preserves wire compatibility with ordinary TCP. Rather than using a new protocol number, it carries control information in the options field of existing TCP segments, so that to a middlebox it looks like plain TCP while only the two end hosts understand it as multipath. This "incremental deployability" is precisely why MPTCP, among many multipath transport proposals, actually reached commercial deployment.
The necessity converges on three values. First is bandwidth aggregation: combining the bandwidth of several paths for faster transfer. Second is resilience: keeping the connection alive over the remaining paths even when one path drops, delivering seamless handover. Third is load balancing: shifting traffic from a congested path to a path with headroom, raising the efficiency of the network as a whole. These three values only grow in importance as multi-connected environments — mobile, data center, IoT — become the norm.
C. Design goals and characteristics
MPTCP's design is summarized by the three goals stated in RFC 6356. (1) Improve throughput: an MPTCP connection using multiple paths should perform no worse than the single best path alone. (2) Do no harm: the total share that all of an MPTCP connection's subflows take on a shared bottleneck must not exceed what a single-path TCP connection would take on the same bottleneck. (3) Balance congestion: push traffic onto the less congested paths wherever possible, lowering congestion across the network.
These goals are in tension with one another. Chasing throughput alone hurts fairness; preserving fairness alone erases the multipath benefit. The reason MPTCP introduces the distinctive mechanism of coupled congestion control is precisely to strike this balance. That is, the technical core of MPTCP is not simply "use several paths," but use several paths while controlling them to be fair and harmless to the existing Internet ecosystem.
2. Overall MPTCP structure and protocol stack
MPTCP inserts an MPTCP layer between the application and the individual TCP subflows. The application calls send()/recv() against a single socket as usual, but underneath, the MPTCP layer splits the data across several subflows and reassembles it in order on the receive side. Each subflow is itself a complete regular TCP connection, managing its own sequence numbers, congestion window, and retransmissions independently. The diagram below shows this layered relationship and the makeup of two subflows.
flowchart TB
APP["Application (single socket API)"]
subgraph MP["MPTCP layer"]
SCH["Scheduler (which path to send on)"]
DSS["Data Sequence Mapping (DSS)"]
PM["Path manager (create/remove subflows)"]
end
subgraph SF["Subflows (each a regular TCP)"]
SF1["Subflow 1 : Wi-Fi path"]
SF2["Subflow 2 : LTE path"]
end
APP --> MP
SCH --> SF1
SCH --> SF2
DSS -. "connection-level ordering" .-> SF1
DSS -. "connection-level ordering" .-> SF2
SF1 --> NET["IP network (middlebox traversal)"]
SF2 --> NET
At the center of the structure are two sequence spaces. Each subflow keeps its own TCP sequence numbers intact in order to fool middleboxes. At the same time MPTCP maintains a separate connection-level 64-bit Data Sequence Number (DSN) that tracks where each byte belongs in the overall data stream. What ties the two together is the DSS (Data Sequence Signal) option, which carries the mapping "bytes X through Y on this subflow map to connection-level DSN Z." The receiver reassembles the fragments that arrived interleaved across subflows into the correct order per the DSS mapping before handing them to the application.
This dual-sequence design is the essence of MPTCP. Without a connection-level sequence the receiver could not know the global order of data arriving over different paths; conversely, without subflow-level sequences a middlebox might mistakenly judge that "there is a hole in the sequence" and tear down or tamper with the connection. By separating the two spaces, MPTCP achieves middlebox compatibility and path independence at once. The main components are summarized below.
| Component | Role | Note |
|---|---|---|
| Subflow | A regular TCP connection serving one path | Independent cwnd/retransmit |
| DSS mapping | Subflow ↔ connection-level sequence mapping | 64-bit DSN, reassembly basis |
| Token/key | Connection identification, subflow authentication | HMAC-based MP_JOIN check |
| Path manager | Decides subflow add/remove | full-mesh, ndiffports, etc. |
| Scheduler | Decides which path a packet goes on | minRTT (default), BLEST, RR, etc. |
3. Connection setup and subflow management procedure
An MPTCP connection starts by layering the MP_CAPABLE option onto an ordinary TCP handshake. When both sides exchange MP_CAPABLE during the SYN / SYN/ACK / ACK three-way process, they confirm that each supports MPTCP, and the keys exchanged here generate the connection's unique token and the secret used to authenticate subflows. If the peer does not understand MP_CAPABLE, or a middlebox in the middle strips the option, the connection silently falls back to plain TCP. This property — "works as ordinary TCP even on failure" — is the foundation that makes MPTCP safe to deploy.
Once the first subflow is up, additional paths join via the MP_JOIN option. When the device opens a new TCP handshake over a second interface (e.g., LTE) and carries the existing connection's token and an HMAC authentication value in MP_JOIN, the peer authenticates and confirms that it is a new path belonging to the same logical connection and accepts it. This authentication procedure prevents an attacker from arbitrarily injecting a subflow into someone else's connection. The sequence diagram below shows the flow from initial setup through joining a second subflow, data transfer, and teardown.
sequenceDiagram
participant C as Client
participant S as Server
Note over C,S: Step 1 - first subflow setup (Wi-Fi)
C->>S: SYN + MP_CAPABLE (key exchange)
S->>C: SYN/ACK + MP_CAPABLE
C->>S: ACK + MP_CAPABLE
Note over C,S: Step 2 - join second subflow (LTE)
C->>S: SYN + MP_JOIN (token + HMAC)
S->>C: SYN/ACK + MP_JOIN (HMAC verify)
C->>S: ACK
Note over C,S: Step 3 - data transfer (split/reassemble via DSS)
C->>S: data fragment A (Wi-Fi, DSS)
C->>S: data fragment B (LTE, DSS)
S->>C: connection-level ACK (DATA_ACK)
Note over C,S: Step 4 - teardown (DATA_FIN)
C->>S: DATA_FIN
S->>C: DATA_ACK
Even after setup, MPTCP manages path state dynamically. Representative signals are MP_PRIO, which marks a particular subflow to be held only as a backup and not used in normal operation, and REMOVE_ADDR, which tells the peer about a disappeared address so that subflow can be cleaned up. Teardown is also split into two levels: an individual subflow is closed with an ordinary TCP FIN, but the whole connection ends with a connection-level DATA_FIN, so the integrity of the entire data stream is preserved even if some paths close first. This bifurcation of control signals into subflow level and connection level is a hallmark of MPTCP state management.
The entity that decides on path creation and removal is the Path Manager. It manages, as policy, whether to add a subflow immediately when an interface newly activates, how many to keep, and when to tidy up dropped paths. The Linux implementation provides a modular path manager; representative ones are full-mesh, which makes subflows over every possible address pair, and ndiffports, which makes several flows over the same address pair with different ports. In addition, through the ADD_ADDR signal, in which one side advertises the extra addresses it holds, the peer is told which addresses it may open subflows toward even behind a server-side NAT. Because the path manager's policy directly governs the trade-off among throughput, battery, and cost (cellular billing), handover-oriented policies such as "Wi-Fi by default, LTE when it drops" are used in mobile, while aggregation-oriented policies such as "bundle every available path" are used in the data center.
4. Core mechanisms: scheduler and congestion control
A. Packet scheduler
The scheduler is the brain that decides at each send moment "which subflow should carry this data fragment." The default Linux scheduler is the minimum-RTT (minRTT) approach: among subflows with room in the congestion window, it prefers the path with the shortest round-trip delay. By filling the lower-delay path first and using the next path only on overflow, it suppresses unnecessary use of a slow path in single-fast-path situations.
The problem arises when the paths' performance differs greatly (heterogeneous). Using a fast Wi-Fi together with a slow LTE, fragments sent over the slow path arrive late and cause Head-of-Line Blocking in the receive buffer. Later data that already arrived on the fast path cannot be delivered to the application and waits until the earlier portion arrives over the slow path. To mitigate this, various schedulers have been proposed, such as BLEST (buffer-occupancy prediction), ECF (Earliest Completion First, completion-time prediction), RR (round robin), and redundant (sending the same data over several paths to minimize delay). For instance, for extremely delay-sensitive remote-control or voice traffic, a choice such as a redundant scheduler that guarantees shortest arrival time at the expense of bandwidth is made.
Scheduler selection is thus an optimization for application characteristics. A large file download cares about total throughput, so filling every path is better; a video conference cares about delay/jitter, so keeping a stable single path primary with a secondary as backup is better. That no single scheduler can be optimal in all situations is a core challenge of MPTCP operation, and recently reinforcement-learning-based adaptive scheduler research has been active.
Recent experimental studies on heterogeneous networks show that the combination of scheduler and congestion control governs performance. For example, minRTT/ECF/RR-family schedulers deliver better throughput than BLEST/LLHD-family ones when paired with coupled loss-based congestion control, whereas on segments with extreme delay variance, ECF — which predicts completion time — better suppresses head-of-line blocking. In the end it comes down not to "which scheduler is absolutely superior" but to the configuration question "which scheduler/congestion-control pair fits the given path combination and application needs," which makes MPTCP a matter of operational competence rather than a simple feature.
B. Coupled congestion control
If each subflow simply ran independent TCP congestion control, an MPTCP connection would behave like n ordinary TCP connections on a shared bottleneck and seize n times the bandwidth of other users — an unfairness. To prevent this, MPTCP couples the congestion-window growth of its several subflows, restraining the whole connection so that it is roughly only as aggressive as a single ordinary TCP on a shared bottleneck. At the same time it grows the window of less congested paths more, naturally shifting traffic there.
Concrete algorithms such as the original LIA (Linked Increases Algorithm, RFC 6356), OLIA (Opportunistic LIA) which improves its fairness flaw, BALIA (Balanced Linked Adaptation) aiming at a balance of responsiveness and stability, and the delay-based wVegas are implemented in the Linux kernel and selectable via sysctl. LIA is simple but has been noted as sometimes excessively aggressive toward single-path TCP, which OLIA/BALIA correct. Making "several paths but behaving as one to the network" is the essence of coupled congestion control, and it is an important legacy MPTCP handed down even to the design of successor protocols like Multipath QUIC.
C. Receive buffer and reassembly
MPTCP's perceived performance depends greatly on receive buffer size. The larger the delay difference between paths, the larger the buffer must be to hold fast-path data while waiting for the slow path. If the buffer is insufficient, head-of-line blocking worsens and multipath can backfire, becoming slower than a single path. Therefore, in practice, one sizes the receive buffer generously considering path characteristics (bandwidth/delay) and tunes the scheduler to limit how much it sends over the slow path. Because of this interaction, MPTCP performance should be treated not as "adding paths improves things linearly" but as a system optimization problem in which scheduler, congestion control, and buffer are interlocked.
An intuitive number makes it clear. As a rough sizing rule, the required receive buffer should be on the order of total bandwidth × maximum path RTT. For example, using a 100 Mbps Wi-Fi (RTT 20 ms) together with a 50 Mbps LTE (RTT 80 ms), to absorb the combined 150 Mbps over the slowest 80 ms you need a buffer of roughly 150 Mbps × 80 ms ≈ 1.5 MB. With the kernel default (a few hundred KB) it is insufficient, so transfer stalls each time the slow path arrives — and this is the real cause of the common misconception that "adding LTE made it slower." Thus, when bundling heterogeneous paths, along with raising the buffer you also need a setting that keeps a slow path with no benefit used by the scheduler only as backup.
5. Comparison with single-path TCP and Multipath QUIC
What decisively separates MPTCP from ordinary TCP is path mobility. Ordinary TCP is bound to the 4-tuple, so the connection drops when the interface changes, whereas MPTCP keeps the connection by adding and removing subflows. As a result, a video stream does not break even when you cross a Wi-Fi dead zone and switch to LTE. MPTCP does not get this benefit for free, however. It must fall back when a middlebox strips the option, and the two sequence spaces and reassembly logic raise implementation complexity and buffer cost.
Comparison with the QUIC multipath extension is an important recent exam and practice topic. QUIC runs over UDP and identifies paths by a Connection ID, so connection migration — continuing the connection without a handshake even when the IP changes — is built into the protocol. MPTCP, by contrast, has compatibility with the TCP ecosystem as its strength but is vulnerable to middlebox interference. That is, they should be understood as products of different design philosophies — "compatibility with existing infrastructure (MPTCP)" and "flexibility over encrypted UDP (QUIC)" — and the two are at once competitors and complements. The table below compares the key differences.
| Category | Single-path TCP | MPTCP | Multipath QUIC |
|---|---|---|---|
| Number of paths | fixed at 1 | multiple subflows | multiple paths |
| Interface switch | connection drops | kept via subflows | connection migration |
| Middlebox compatibility | high | falls back if option stripped | vulnerable if UDP blocked |
| Encryption | optional (TLS) | optional (TLS) | built in by default |
| Reassembly cost | low | high (dual sequence) | medium |
6. Deep dive: standards/implementation trends and real-world cases
On the standards side, MPTCP was revised from RFC 6824 (v0) to RFC 8684 (v1, 2020), tidying the option format and fallback handling, and proxy standards such as the 0-RTT TCP Converter (RFC 8803) that aid server-side deployment also appeared. Linux was long provided only as out-of-tree patches (multipath-tcp.org), but from kernel 5.6 (March 2020) it was officially integrated upstream, coming to provide a modular path manager, scheduler, and congestion control by default. This is a milestone showing that MPTCP has moved beyond the research stage to settle in as a standard feature of a general-purpose operating system.
The most widely known commercial case is Apple's Siri. Apple applied MPTCP to Siri traffic from iOS 7 in 2013, switching between Wi-Fi and cellular to reduce response latency and network failures. Notably, Apple's early application was not "bonding" to combine bandwidth but a resilience-centered switching to keep the path seamless. Apple later opened a developer API in iOS 11 and expanded MPTCP use to Maps, Music, Apple Pay, and more.
Korea's representative case is KT's GiGA LTE. Co-developed with Samsung Electronics, in June 2015 KT unveiled the world's first commercial service bundling 3-band CA LTE and GiGA Wi-Fi via MPTCP to deliver a theoretical maximum of 1.17 Gbps (the demo showed up to about 835 Mbps and an average of 600–700 Mbps). According to KT's IETF presentation, it placed LTE as the primary subflow (MP_CAPABLE) and Wi-Fi as the secondary subflow (MP_JOIN), and deployed an MPTCP proxy gateway between the device and the carrier network so that bonding worked even if the server did not know MPTCP. Unlike Apple's "switching" case, this focused on bandwidth aggregation (bonding), a good contrast showing how the same MPTCP yields different designs depending on the application goal (though some secondary sources describe a SOCKS-proxy-based setup, so the detailed architecture differs by source).
Likely exam directions include "Discuss MPTCP's three design goals and the necessity of coupled congestion control," "Compare MPTCP and Multipath QUIC from the perspectives of middlebox compatibility and migration," and "Propose MPTCP path-manager/scheduler policies suited respectively to mobile handover and data-center bonding."
7. Considerations and implications
- Application strategy (policy separation by purpose): MPTCP works best not with uniform "always bundle every path" application, but when the path manager and scheduler are separately designed as resilience (handover)-centric for mobile and throughput (bonding)-centric for the data center. Considering cellular billing and battery, a policy that uses Wi-Fi in normal times and switches to LTE when needed is realistic on mobile.
- Trade-off (performance ↔ complexity/buffer): adding paths does not speed things up linearly. When the delay variance between paths is large, head-of-line blocking and reassembly cost offset the gains, so receive-buffer sizing and slow-path suppression tuning must come first. On heterogeneous paths, reducing the number of subflows may actually be better.
- Middlebox/deployability: in firewall/NAT environments that strip or rewrite options, MPTCP falls back to plain TCP. Given the reality that end servers do not support MPTCP, an architecture that places an MPTCP proxy/converter inside the carrier network is the core pattern of commercial deployment.
- Security perspective: the HMAC authentication of MP_JOIN blocks subflow hijacking, but multipath-specific threats such as ADD_ADDR spoofing and cross-path attacks exist. Combined with per-path TLS end-to-end encryption, connection-level integrity must be secured together.
- Outlook and related technologies: the design philosophy of multipath is being inherited and extended by Multipath QUIC, and it ties closely to 5G/Wi-Fi 7 multi-connectivity, ATSSS (5G's multi-access traffic steering), and SD-WAN path bonding. Amid the trend of encrypted transport becoming standard, the division of roles between MPTCP and Multipath QUIC is a key future issue.
References
- IETF, "TCP Extensions for Multipath Operation with Multiple Addresses (RFC 8684)", https://datatracker.ietf.org/doc/html/rfc8684
- IETF, "Coupled Congestion Control for Multipath Transport Protocols (RFC 6356)", https://datatracker.ietf.org/doc/html/rfc6356
- Wikipedia, "Multipath TCP", https://en.wikipedia.org/wiki/Multipath_TCP
- multipath-tcp.org, "Configure MPTCP (Linux >= v5.6)", https://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP
- KT/IETF, "GiGA LTE Mobile MPTCP Proxy Development (IETF 97 slides)", https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-00.pdf
- Netmanias, "KT's GiGA LTE: World's First Commercial Wireless 1Gbps", https://netmanias.com/en/post/korea_ict_news/7591/kt-korea-lte-mptcp-wi-fi/kt-s-giga-lte-world-s-first-commercial-wireless-1-giga-3-band-ca-giga-wifi
In one line: MPTCP is a transport-layer extension that layers DSS mapping and MP_CAPABLE/MP_JOIN onto existing TCP options to bundle multiple paths into one logical connection, achieving throughput, resilience, and congestion balancing fairly via coupled congestion control while offsetting the limits of middlebox fallback, head-of-line blocking, and buffer cost through proxies, schedulers, and buffer tuning — carried on from Siri (switching) and KT GiGA LTE (bonding) to Multipath QUIC.