Summary

  • Multipath TCP gives an application one reliable, ordered byte stream while the endpoints can carry it over one or more ordinary TCP subflows.
  • MP_CAPABLE negotiates the connection, MP_JOIN authenticates an additional subflow, and connection-level sequence numbers let data be retransmitted on a different path after failure.
  • Two interfaces are not proof of resilience. Paths may share a bottleneck, a middlebox may strip the necessary options, and endpoint policy decides whether a second subflow is active, backup or absent.

One socket at the station door

The visible event is mundane. A device walks out of Wi-Fi coverage while an upload, call-control exchange or long response is still in progress. At the IP layer, an address may disappear and another may become usable. At the application layer, however, the useful object is not an address: it is the ordered stream of bytes already exchanged with a peer.

RFC 8684 separates those objects. An MPTCP connection maps one-to-one to an application socket, but it may contain several subflows. Each subflow looks like a TCP flow on one path and can start or end much like ordinary TCP. The connection sits above them and preserves the service the application expects. A path can therefore cease to be useful without necessarily defining the end of the connection.

The qualification matters. MPTCP does not keep a connection alive by declaration. Both endpoints must negotiate it, at least one usable subflow must remain or be established, and the connection state must still be intact. The protocol creates the machinery for continuity; it does not certify the network conditions in which that machinery will operate.

Admission belongs to the endpoints

The first subflow carries an MP_CAPABLE exchange. It tells each side that the other supports MPTCP and exchanges the key material used for the connection. If either host lacks support, or if an intervening device prevents the options from surviving, the design can fall back to ordinary TCP.

An additional path is not simply attached because another address exists. A new TCP handshake carries MP_JOIN. A connection token identifies the connection being joined; nonces and an HMAC derived from the original keys allow each endpoint to verify that the joining subflow belongs to the same peers. Local policy may still prohibit it. This is an admission decision, not automatic route discovery.

Addresses can also change during the life of a connection. ADD_ADDR lets one endpoint advertise another address, while REMOVE_ADDR withdraws one. Address identifiers help the signalling survive address rewriting by a NAT. But an advertised address says only that an endpoint has offered a candidate. It does not prove that the resulting path is reachable, independent, cheap or better.

This is the first operational boundary. Network operators provide reachability and may influence the physical paths. The endpoints decide whether MPTCP was negotiated, which candidates become subflows and whether a subflow is permitted. An application that is unaware of MPTCP may see only a normal socket, so the most consequential path choice can occur below its interface.

One ledger above several TCP flows

Each subflow retains ordinary TCP sequence numbers. That is necessary for the subflow to behave like TCP along its own path. MPTCP adds a second ledger: a 64-bit Data Sequence Number for the connection as a whole. The Data Sequence Signal maps bytes in a subflow's sequence space into that connection-level space and can acknowledge progress at the connection level.

That extra ledger is the mechanism behind resilience. If data sent on one subflow is not delivered, the same connection-level bytes can be retransmitted on another subflow with a new mapping. The receiving application still gets one reliable, ordered stream. It does not have to reconcile two independent TCP connections or decide which copy belongs next.

It is also the source of a less flattering truth. A slow path can hold up useful delivery even while a fast path is working, because the application still expects ordered bytes. Packet scheduling, reinjection and congestion control determine whether multiple paths improve the experience or merely add delay and state. RFC 8041 records that this is an operational problem, not a detail solved by counting interfaces.

A second link can be active, backup or useless

RFC 8684 lets a host mark a subflow as regular or backup. A backup is intended for use when no regular path is available, and MP_PRIO can request a change during the connection. That apparently small flag exposes the commercial decision inside multipath transport. A cellular path may be resilient but metered. A satellite path may be reachable but slow. A second fixed access may look diverse while sharing the same duct or upstream bottleneck.

RFC 6182 is explicit that address combinations need not yield disjoint paths. Its architecture aims for throughput no worse than the best constituent path and resilience no worse than ordinary TCP, while avoiding unfair pressure on other users at shared bottlenecks. Those are design goals, not a measurement report for any particular deployment.

The right unit of evidence is therefore not “interfaces available”. It is the negotiated connection and its observed subflows: which ones were established, which were designated backup, whether they traversed distinct failure domains, how connection-level delivery behaved, and whether data had to be sent again elsewhere. Without that evidence, a multipath badge can describe potential rather than service.

Fallback is part of the result

Middleboxes shaped MPTCP's design. A device on the path may remove TCP options, rewrite addresses or ports, or alter payload in ways that make the multipath signalling invalid. RFC 8684 defines safe reactions: the initial connection may fall back to ordinary TCP; a defective additional subflow may be reset and removed; a subflow that loses valid mappings during operation should be treated as broken.

Fallback is therefore not merely an installation failure. It is one possible negotiated outcome. A service can appear healthy because ordinary TCP still works while the redundancy that justified the design is absent. Monitoring that records only application success will miss the difference between “the connection survived through another subflow” and “MPTCP never operated here”.

Multipath TCP moves the boundary of a connection above one route, but it does not abolish routes. It gives endpoints a way to pool them, authenticate additions and preserve one byte stream across failures. The durable question is who controls the endpoint policy and whether the paths underneath it are genuinely different. Continuity is earned in those decisions, not in the number of radio icons on a screen.

Sources