Multipath TCP is an extension to the Transmission Control Protocol (TCP) that is used by the majority of Internet applications. MPTCP enables hosts to send the data corresponding to any TCP connection over different paths. With Multipath TCP, a smartphone can simultaneously and efficiently use both its cellular and Wi-Fi interfaces. The first specification of Multipath TCP was published in RFC6824 in 2013. Since the publication of this document several important use cases for this new standardised protocol have emerged:

• Apple uses Multipath TCP in iOS for applications such as Siri, Apple Maps, Apple Music and third party applications have also enabled Multipath TCP
• Tessares uses Multipath TCP to allow Internet Service Providers to combine their xDSL and 4G networks to provide Hybrid Access Network services 
• In Korea, several mobile operators leverage Multipath TCP to combine WiFi and 4G on smartphones
• 3GPP has selected Multipath TCP as one of the key component of the Access Traffic Steering, Switching & Splitting (ATSSS) function that enable 5G devices to efficiently combine 5G and Wi-Fi

Shortly after the publication of RFC6824 as an experimental RFC, the MPTCP working group of the IETF started to work on a standards-track version of Multipath TCP while observing the different deployments. We now have more than half a decade of experience with Multipath TCP in different use cases and the feedback from the deployment is very positive. The original specification was very solid and did not require major changes. This is likely because the development of the Multipath TCP protocol was done in parallel with the implementation of a complete implementation in the Linux kernel. This continuous implementation feedback was important to ensure that the protocol specification was realistic and could be deployed.

Version 1 of Multipath TCP has now been published as RFC8684. While current deployments use version 0 specified in RFC6824, it is expected that they will move to the new version of the protocol in the coming months and years.  

There are a several differences between RFC6824 and RFC8684: 

1. RFC8684 defines version 1 of the protocol while RFC6824 defines version 0. The version number is specified in the MP_CAPABLE option that is exchanged in the SYN packet at the beginning of the connection. This option is defined in Section 3.1 of RFC8684 as follows:

The format is similar to the original version, but there are several modifications. First, version number is set to 1 to enable servers to detect the version used by the client. Second, as described in Section 2.1, the MP_CAPABLE option sent in the first SYN packet no longer contains the connection keys. The keys are still carried in the MP_CAPABLE option, but inside the SYN+ACK and the ACK. This change leaves more space to carry other TCP options in the initial SYN packet.

A third modification is that the MP_CAPABLE defines a new flag called the C bit. This flag allows a server to indicate that clients should not attempt to establish new subflows towards the server address used to send the SYN. This small change enables load-balancers to efficiently support Multipath TCP and is important for large server cluters such as CDNs.

2. RFC6824 defines the ADD_ADDR and REMOVE_ADDR options to advertise addresses, but these options are not authenticated and not sent reliably. RFC8684 introduces two modifications. First, the new ADD_ADDR option includes a truncated HMAC to authenticate its content. Second, when a host receives such an option it must echo it to confirm to the other host that it received it. This improves the reliability of the advertisement of new addresses.

3. Multipath TCP version 1 now uses SHA-256 instead of the deprecated SHA-1 function to compute hashes.

4. Multipath TCP now includes an MPTCP-RST option to indicate why a subflow has been reset by a peer.

Tessares has contributed to the development of the proposed standard version Multipath TCP and actively contributes to its implementation in the mainline Linux kernel.

Contact us if you have specific questions or use cases that would require an efficient and standardised multipath protocol.

Author : Olivier Bonaventure