One connection, one path
A classic TCP connection is tied to one pair of IP addresses and ports. RFC 8684 puts it plainly: TCP/IP communication is restricted to a single path per connection, yet multiple paths often exist between peers. A phone with Wi-Fi and mobile data is the everyday example. If the Wi-Fi drops, every TCP connection that was using it breaks, and the app has to notice, reconnect over mobile data and retry.
Multipath networking removes that coupling. The general idea is simple: if there is more than one way to reach the other end, use more than one, or keep a second one ready, so losing a link does not end the session.
Multipath TCP
Multipath TCP (MPTCP) is the IETF’s extension to TCP for this. RFC 6182 sets out the vocabulary. A path is a sequence of links between a sender and a receiver, defined by a source and destination address pair. A subflow is a flow of TCP segments over one path. An MPTCP connection is a set of one or more subflows that together give the application a single reliable byte stream.
How it works, from RFC 8684 and the Linux kernel documentation:
- The first subflow starts as an ordinary TCP connection carrying an
MP_CAPABLEoption. If the other host, or a middlebox in between, does not support MPTCP, the option is not returned and the connection carries on as plain single-path TCP. - More subflows are added with
MP_JOIN, and hosts can announce or withdraw addresses withADD_ADDRandREMOVE_ADDRas interfaces come and go. - All data carries a 64-bit data sequence number mapped onto each subflow’s own sequence numbers, so data can be retransmitted on a different subflow if one fails.
- A subflow can be marked as a backup path, used only if no regular path is available.
On Linux, a path manager creates and removes subflows and a packet scheduler decides which subflow sends the next packet. The kernel documentation lists three uses: handover between paths while keeping connections open, picking the best path by latency, loss or cost, and aggregating several paths for more throughput.
RFC 6182 adds two cautions. Paths need not be fully disjoint, so two subflows can still share a bottleneck. And MPTCP must not unduly harm single-path TCP flows at a shared bottleneck; the RFC assigns fairness at shared bottlenecks to MPTCP’s congestion controller.
Multipath TCP on iPhone
Apple exposes MPTCP through URLSession. By default a URL session uses a single radio for a request, preferring Wi-Fi over cellular. With Multipath TCP enabled, Apple says the session starts the request on both radios and picks the more responsive one, still preferring Wi-Fi. The handover service type is meant for long-lived or persistent connections: the app uses only Wi-Fi while the Wi-Fi is reliable, and moves data to cellular as the Wi-Fi signal deteriorates, to preserve the connection.
There are conditions. The app needs the Multipath entitlement, set in Xcode’s Capabilities pane, and the server has to support MPTCP. When Wi-Fi Assist, a device-wide user setting, is turned on, it stops flows from using cellular data while the app is in the background and limits how much data the app can send over cellular; once the limit is reached, MPTCP is disabled.
QUIC connection migration
QUIC takes a different approach. Instead of several subflows, a QUIC connection is identified by connection IDs rather than by addresses, which, per RFC 9000, lets it survive changes to the endpoint’s IP address and port, such as moving to a new network. In this version of QUIC only clients can migrate, and the RFC describes connection migration as using one path at a time for ordinary traffic. Before moving, an endpoint can validate a new path, and it may probe several paths at once. So QUIC migration is a connection-preserving failover rather than simultaneous use of two paths.
Multipath at the application level
Both protocols work between two internet hosts. They do not help when the problem is that there is no internet path at all, for instance inside a cellular dead zone. For that, an app has to treat whole transports as its paths: a backend over the internet, a relay, or a direct radio link to a nearby device.
| Approach | Paths it uses | What survives a path failure |
|---|---|---|
| Multipath TCP | Several IP paths, at once or as backups | The TCP connection, if another subflow works |
| QUIC migration | One IP path at a time, switching on change | The QUIC connection, after the client migrates |
| Application-level path choice | Different transports, including local radios | The app’s message or workflow, if another transport reaches the peer |
The Offline Protocol SDK is one example of the last kind: its documentation says DORS scores eligible paths and applies switching controls across the transports an app has configured.
Whichever layer does it, multipath only helps if the paths fail independently. Two paths that both end in the same cloud region, or share the same backhaul, can fail together. The honest test is to turn one path off and watch whether the remaining one actually carries the work.