--- title: "How Multipath TCP Reassembles One Byte Stream from Several Subflows" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/mptcp-subflow-mapping-single-byte-stream" last-updated: "2026-10-20" --- # How Multipath TCP Reassembles One Byte Stream from Several Subflows Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. Multipath TCP can carry one application's reliable byte stream over several TCP subflows. The receiver places each subflow's payload into the connection's byte order using Data Sequence Mapping. To assess an MPTCP claim, establish the negotiated connection and count distinct mapped connection bytes before interpreting traffic totals as useful transfer progress. ## Establish which connection actually negotiated MPTCP For a dataset transfer feeding a GPU environment, a proposal showing two network interfaces leaves the transport behavior unresolved. RFC 8684, published in March 2020, specifies MPTCP version 1. A successful MP_CAPABLE exchange negotiates multipath capability on the initial subflow; MP_JOIN associates and authenticates an additional subflow with that connection. An unsuccessful initial negotiation can leave the exchange operating as ordinary TCP. Ask the supplier to identify the actual endpoint implementations, software releases and application connection covered by its claim. RFC 6897's March 2013 application guidance distinguishes stack support and enabling policy from actual use. Its compatibility discussion is useful context, rather than evidence of support in a current product. A generic statement that an operating system supports MPTCP does not identify what this transfer negotiated. Keep address discovery separate from subflow establishment. An advertised additional address is a candidate for another subflow. It does not establish that the subflow joined successfully or carried data. References: [M1](https://www.rfc-editor.org/rfc/rfc8684.html), [M3](https://www.rfc-editor.org/rfc/rfc6897.html) ## Use the mapping to recover one connection order MPTCP maintains a sequence space for the connection and a separate TCP sequence space for each subflow. RFC 6182's March 2011 architecture explains why both levels exist: the receiver needs a common order while each subflow retains its own TCP progression. A Data Sequence Mapping relates a starting subflow position to a starting connection position for a stated byte length. Think of it as a placement instruction: a range arriving here belongs at that position in the overall stream. Different subflows can therefore contribute different portions of the same ordered result. RFC 8684 carries this mapping in Data Sequence Signal, or DSS, options. A known mapping can cover several packets; it need not be repeated in every packet. The relevant accounting unit is the mapped byte range. Counting mappings, packets or TCP subflows cannot establish how many distinct connection bytes they cover. References: [M1](https://www.rfc-editor.org/rfc/rfc8684.html), [M2](https://www.rfc-editor.org/rfc/rfc6182.html) ## Work 12,288 transmitted bytes against 8,192 unique bytes Consider an original hypothetical transfer in one sending direction of an established MPTCPv1 connection with subflows A and B. The illustrated payload window is [0,8192), following any earlier connection data already accepted in order. Zero is the start of this window. These are relative payload offsets: [0,4096) contains bytes 0 through 4095. They are not actual initialized Data Sequence Numbers or TCP header sequence numbers. Stipulate valid mappings, identical contents for repeated connection positions, successful receipt and acceptance of all illustrated data, sufficient receiver space, and no other payload transmissions within this accounting window. No connection-opening or closing sequence positions, headers or acknowledgment traffic are included. A carries the 4,096 payload bytes belonging to connection range [0,4096). B carries the 4,096 bytes belonging to [4096,8192), plus another transmission of the first range [0,4096). B therefore carries 8,192 payload bytes in its own sequence space, of which 4,096 repeat connection data also carried by A. Adding the transmitted payload gives 4,096 + 4,096 + 4,096 = 12,288 bytes. Taking the union of the mapped connection ranges gives [0,8192), or 8,192 unique bytes. The additional copy occupies subflow payload space without creating another 4,096 bytes in the application's stream. RFC 8684 permits the same connection data to travel over different subflows; the mapped position preserves its identity. A report can truthfully count all 12,288 transmitted payload bytes and still overstate useful progress if it labels that figure unique stream data. This is a byte-accounting example. It supplies no elapsed time, rate, retransmission trigger or measured outcome. References: [M1](https://www.rfc-editor.org/rfc/rfc8684.html), [M2](https://www.rfc-editor.org/rfc/rfc6182.html) ## Read each ACK at the sequence space it acknowledges A TCP ACK on B describes progress in B's subflow sequence space. The connection Data ACK is cumulative across the mapped stream and identifies the next expected Data Sequence Number. RFC 8684 treats these as separate signals; subflow acknowledgment alone cannot establish connection-level acceptance. Change only the arrival order in the worked example. Suppose B's [4096,8192) connection range arrives before either copy of [0,4096). That later range can be received and acknowledged on B while the connection still waits for the window's first 4,096 payload bytes. The shared ordered stream has a gap at the start of this window. Once the first range is accepted and the later range remains retained, the connection has contiguous coverage through relative payload offset 8192. A subsequent duplicate of the first range adds no unique coverage. That offset describes the example's frontier; a real Data ACK uses the connection's actual sequence numbers. Even contiguous acknowledged reception leaves the receiving application's consumption unresolved. RFC 9293, the August 2022 TCP specification, explicitly distinguishes acknowledged data from data consumed by the user process. A claim that the dataset was processed or committed to durable storage needs evidence at that later boundary. References: [M1](https://www.rfc-editor.org/rfc/rfc8684.html), [T1](https://www.rfc-editor.org/rfc/rfc9293.html) ## Distinguish subflow reassembly from LACP and QUIC migration In the flow-hashed aggregation example covered by the related Ethernet article, matching flow inputs select one member link. Cisco's November 2023 Catalyst 6500/6000 explanation supplies that deterministic-hash mechanism. A logical bundle does not itself split one ordinary TCP stream into MPTCP subflows. MPTCP subflows are separate TCP flows, and the member assignments in any underlying aggregation still depend on its actual distribution policy. The related QUIC article examines a connection continuing through a supported path change while its endpoint state remains available. RFC 9000's May 2021 QUICv1 specification describes one path at a time for non-probing traffic in its migration model. That example does not establish simultaneous multipath capacity. MPTCP supplies a different mechanism: several TCP subflows can contribute mapped data to one connection. Identifying that mechanism still leaves the actual use and contribution of each subflow to be demonstrated. References: [C1](https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html), [Q1](https://www.rfc-editor.org/rfc/rfc9000.html), [M2](https://www.rfc-editor.org/rfc/rfc6182.html) ## Ask what each subflow contributed to the requirement For a proposal claiming that one transfer used several subflows, request evidence tied to that same connection and observation interval: its negotiated protocol version, joined subflows, their mapped connection ranges and the connection's cumulative progress. If the claim includes simultaneous use, the evidence must establish overlap in time. The byte totals in the worked example cannot establish that overlap. Preserve whether the supplied counters include repeated payload, protocol overhead or unrelated connections. In the example, B carries 8,192 payload bytes while adding only 4,096 unique connection bytes beyond A's coverage. Without the mappings, the two totals do not explain that difference. If the requirement includes independent routes, request the topology evidence separately. RFC 6182 explicitly allows address-derived paths to share bottlenecks; two addresses or NICs cannot establish disjoint physical routes. For an application-capacity requirement, ask for unique useful data over the stated interval and the required application outcome. A negotiated protocol and several traffic counters leave that result open. These questions let a buyer distinguish demonstrated multipath transfer from an available feature, and unique byte coverage from repeated carriage. They provide no basis for adding interface rates or promising a recovery deadline. References: [M2](https://www.rfc-editor.org/rfc/rfc6182.html), [M3](https://www.rfc-editor.org/rfc/rfc6897.html) ## Carry any separate physical connection work into its own scope If the selected arrangement also requires installed fiber or copper connections, Leviathan's Structured Cabling & Fiber Installation service can discuss approved assemblies, routes, endpoint labels and agreed connection records using customer-furnished or separately sourced materials. Use the related service and project inquiry to share a nonconfidential outline of that physical package. Identify the endpoints, patch points, pathways, materials responsibilities and required handoff records. MPTCP implementation, network configuration and assessment of application behavior remain with the appointed platform and network owners. The protocol explanation is educational; the physical work proceeds against its separately agreed scope. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [M1 — RFC 8684: TCP Extensions for Multipath Operation with Multiple Addresses](https://www.rfc-editor.org/rfc/rfc8684.html). Checked 2026-10-20. March 2020, MPTCPv1. Sections 2.1–2.4, 3.1 and 3.3.1–3.3.2 cover negotiation, mapping and Data ACKs; section 3.3.6 covers repeated data across subflows. Defines protocol semantics, rather than support or performance of a selected implementation. - [M2 — RFC 6182: Architectural Guidelines for Multipath TCP Development](https://www.rfc-editor.org/rfc/rfc6182.html). Checked 2026-10-20. March 2011 informational architecture. Explains the two sequence levels, range mapping and potentially overlapping paths. Used for architectural rationale; RFC 8684 supplies the version 1 wire-protocol rules. - [M3 — RFC 6897: Multipath TCP (MPTCP) Application Interface Considerations](https://www.rfc-editor.org/rfc/rfc6897.html). Checked 2026-10-20. March 2013 informational application guidance, especially sections 4.1, 4.5 and 7. Distinguishes application interfaces, policy and actual use; no historical API proposal is presented as a current operating-system interface. - [T1 — RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293.html). Checked 2026-10-20. August 2022. Section 3.8.6.2.2 describes received and acknowledged data that the user process has not consumed. Used for the reception-versus-consumption boundary. - [C1 — Cisco: Understand EtherChannel Load Balance and Redundancy on Catalyst Switches](https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html). Checked 2026-10-20. Updated November 30, 2023. The Catalyst 6500/6000 deterministic-hash explanation bounds the comparison; it does not specify every aggregation implementation or the equipment for a proposed deployment. - [Q1 — RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https://www.rfc-editor.org/rfc/rfc9000.html). Checked 2026-10-20. May 2021, QUIC version 1. Sections 9 and 21.1.3 distinguish migration from simultaneous application-data multipath use. No inference about later QUIC extensions or a selected product. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical fiber and copper installation, agreed routes, endpoint labels and connection records with customer-furnished or separately sourced materials. Relevant when the wider project includes actual physical connection work. ## Related Leviathan resources - [Ethernet breakout and flow-hashed link aggregation](/articles/ethernet-breakout-versus-link-aggregation) - [QUIC connection identity and path migration](/articles/quic-connection-id-path-migration-state) - [TCP cumulative ACK, SACK and received-byte gaps](/articles/tcp-cumulative-ack-sack-received-byte-gaps) - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Discuss a separate physical cabling project](/contact?service=structured-cabling&from=%2Farticles%2Fmptcp-subflow-mapping-single-byte-stream) ## Does the project include physical connection work? Share the approved endpoints, assemblies, routes, materials responsibilities and required connection records to discuss the physical scope, requirements and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/mptcp-subflow-mapping-single-byte-stream)