Summary

  • Infinite-mapping fallback changes how an MPTCP connection operates for the rest of its life; it is not simply a temporary reduction to one active subflow.
  • A fresh connection is necessary to seek MPTCP again after this transition, but neither a successful negotiation nor safe repetition of application work follows automatically.

A connection can survive by giving up the mechanism that was supposed to make it adaptable. That is the bargain inside one particular Multipath TCP fallback procedure. Bytes can continue along regular TCP while the ability to distribute this connection across MPTCP subflows disappears. Waiting for the network to improve does not undo that bargain.

RFC 8684 makes the boundary unusually explicit. Once an endpoint falls back using an infinite mapping, it cannot revert to MPTCP later in the same connection. A recovered interface, an available alternate address or a reassuring throughput graph is not permission to cross back. The relevant unit of irreversibility is the connection—not the device, the user account or the network as a whole.

For an operator, this creates an awkward kind of success. The immediate service need may have been met: the stream did not have to stop. Yet the capability expected to protect its remaining lifetime has changed. A continuity report that records only whether traffic still flows would miss the decision now waiting for the application owner.

The mapping is doing more than joining paths

MPTCP presents an ordered byte stream while carrying data over individual TCP subflows. Each subflow has its own sequence space. A Data Sequence Signal supplies the relationship between those local sequence numbers and the connection's data sequence numbers. This lets the receiver place bytes into the wider stream even when different subflows carry them.

The distinction also governs acknowledgments. Under the ordinary MPTCP rules, the sender cannot free buffered data merely because one TCP subflow has acknowledged it. The data must be acknowledged at the connection level and on all the subflows over which it was sent. A receiver can acknowledge a subflow segment before later discarding data held for the connection, for example under memory pressure. A subflow receipt therefore does not settle the connection-level bookkeeping.

An infinite mapping changes that arrangement. It uses a reserved data-level length of zero to map the remainder of the connection. After this fallback, the sender uses only subflow acknowledgments to clear its send buffer; the receiver should stop sending Data ACKs. The remaining communication runs as regular TCP. This is a change in the rules for retaining and releasing data, not just a scheduler choosing to use one route today.

None of these transport acknowledgments establishes that an application has completed a business operation. Their scope is the transport described in RFC 8684, sections 3.3 and 3.7. That matters when somebody later proposes closing the surviving stream and repeating its work.

A checksum failure is not a universal exit sign

The fallback mechanism exists partly because middleboxes may remove options or modify payloads. Such interference can destroy the relationship between the subflow sequence and the connection sequence. If the MPTCP checksum was negotiated, it can expose relevant data or mapping damage. This checksum is not a cryptographic guarantee and does not identify an attacker.

The response depends on the connection's state. With several subflows, a checksum failure can lead to closing the affected subflow and retransmitting its data elsewhere. Failed data is not acknowledged at the connection level. The other subflows can preserve MPTCP operation. Describing every such failure as a conversion to regular TCP would erase precisely the resilience the protocol is trying to retain.

The single-subflow case has another condition: the unacknowledged data in flight must be known to be contiguous. Only then can the infinite-mapping procedure proceed without first closing the subflow. Having one subflow does not establish that condition. It might be carrying retransmissions associated with another subflow that closed uncleanly.

MP_FAIL identifies the data-sequence position associated with the failure. In the applicable fallback exchange, the reverse direction is also brought back to regular TCP. If the data is not contiguous, the specification describes a reset and a possible new subflow that is immediately given an infinite mapping. That new subflow is still part of the old connection's fallback handling. It is not the fresh, multipath-capable connection a recovery plan might be imagining.

The specification also distinguishes early option loss from trouble after mappings are established. Some cases require abandoning a problematic subflow. They do not offer an all-purpose, lossless conversion switch for every damaged connection. If checksums were not negotiated, detecting payload alteration for this purpose requires a signal from another layer.

One path can describe two different futures

Ordinary MPTCP with one established or active subflow may still be capable of using additional subflows. After infinite-mapping fallback, only one subflow may send, the others must be terminated, and the same connection cannot return to MPTCP. Both situations can produce a count of one. Their future options are different.

This is why adding a path counter to a dashboard is not, by itself, sufficient reporting. The question is whether the connection remains MPTCP or has committed to regular TCP. A count records how many subflows are present at an observation point; it does not necessarily explain why that state exists or what transitions remain available.

Application visibility should not be assumed either. RFC 6897 describes an abstract application interface. Its basic design allows enabling MPTCP before a connection is established, querying support afterward, and obtaining the addresses of established subflows. It does not establish that today's particular operating system exposes a reliable post-fallback notification under those symbolic names. Its proposed advanced callbacks were subjects for further work.

The same document warns that a queried subflow list can become stale. Legacy address queries retain the first subflow's address information even if that subflow is no longer used. A familiar peer address is thus a particularly weak substitute for current transport-state evidence. Before relying on an operational signal, a buyer or service owner needs to establish what the actual endpoint implementation reports.

Recovery starts with a new connection, not a promise

The need for a new connection to regain MPTCP is an inference from the prohibition on same-connection reversion. It is not a guarantee that the next attempt will negotiate MPTCP, find usable alternate paths or improve the service. The conditions that caused fallback may still be present.

The narrower conclusion is enough to change a runbook. Continuing the surviving stream and trying to restore multipath are separate actions with different costs. A finite transfer might be allowed to complete before renewal. A long-lived session might warrant an application-aware renewal boundary. Neither choice should be disguised as a harmless reversal of the existing transport state.

This reading is grounded in the RFC 8684 publication record, a March 2020 Proposed Standard that superseded the earlier MPTCP version. Its verified erratum concerns a TCP Fast Open example's premature Data ACK, not the section 3.7 prohibition. The RFC 6897 record identifies that earlier API discussion as Informational; the errata lookup returned no matching entries. These are specifications and design context, not measurements of a deployed fleet.

Lu Heng's agency argument suggests asking who bears the consequences of a decision, not merely who controls the mechanism. His account of BTW's purpose favours describing structure over advocacy. Here, that means recognising both sides of fallback: it may save useful work while leaving somebody else to decide when losing multipath is no longer acceptable.