Traditional TCP operates on a simple principle: one path, one connection. If you're connected to a server, your data flows through a single channel. But what if you could use multiple paths at once, like your Wi-Fi and cellular data, to create a faster, more reliable connection? That's the core idea behind Multipath TCP (MPTCP).

MPTCP bundles multiple individual connections, called subflows, into a single logical connection. This allows a device to seamlessly switch between paths or even use them simultaneously without interrupting the application. This architecture, outlined in RFC 8684, fundamentally changes how we think about network resilience and performance.

An MPTCP connection begins just like a regular TCP connection, but with a special addition. During the initial three-way handshake, both the client and server include an MP_CAPABLE option in their SYN packets. This option signals their ability to use MPTCP and, more importantly, it's where they exchange cryptographic keys.

The client (Host A) sends its key, and the server (Host B) responds with its own. These keys aren't used for encrypting the data itself, but for securing the MPTCP connection moving forward. They are essential for proving ownership of the connection when adding new subflows later.

Once this initial handshake is complete, the first subflow is established. The connection now functions like a standard TCP connection, but it holds the keys needed to expand.

The real power of MPTCP is realized when a second path becomes available, for example, when a phone using Wi-Fi also enables its cellular data. To add this new path to the existing connection, the client initiates another TCP handshake over the new interface.

This time, instead of MP_CAPABLE, it uses the MP_JOIN option. This option contains two crucial pieces of information:

1. Token: A unique identifier for the existing MPTCP connection, derived from the server's key.
2. HMAC: A Hash-based Message Authentication Code. The client calculates this HMAC using both its own key and the server's key. It proves to the server that the device trying to join is the legitimate owner of the original connection.

If the server successfully validates the token and the HMAC, it accepts the new subflow, and data can now travel across both paths.

With data potentially arriving out of order over different paths with varying speeds and latency, how does MPTCP reassemble everything correctly? It uses a clever two-level sequencing system.

At the top level is the Data Sequence Number (DSN). This number tracks the byte stream for the entire MPTCP connection, just as if it were a single flow. It ensures that, no matter which path a piece of data took, the receiving application gets it in the correct order.

Beneath that, each individual subflow has its own Subflow Sequence Number (SSN). This is the standard sequence number used in any TCP connection. It's used by the TCP logic on each specific path to manage retransmissions and ordering for that path alone.

This separation is the key to MPTCP's success. It allows the protocol to leverage the proven reliability of standard TCP on each individual path while managing the complex task of orchestrating a single, coherent data stream at a higher level.

Time to test your knowledge of MPTCP's inner workings.

This elegant architecture allows MPTCP to provide a more robust and efficient connection, adapting to changing network conditions without missing a beat.