Multipath TCP: the architectural principles
When an IETF working group start, its members first need to agree on a charter and a set of principles that will guide their work. For Multipath TCP, the key architectural principles have been documented in :rfc`6182`.
The first, an very important, assumption for the design of Multipath TCP was that at least one of the two communicating hosts would have two or more IP addresses. This is captured in the figure below (source RFC 6182).
Then, it is interesting to recondiser the function goals that are listed in Section 2.1 of RFC 6182:
- Improve Throughput
- Improve Resilience
Today, given the wide deployment of Multipath TCP on Apple smartphones, it could be suprising that this document did not anticipate the need to support fast handovers, i.e. the ability to quickly switch a connection from Wi-Fi to cellular or the opposite. The resilience requirement takes into account the ability to retransmit data from one path to another.
After these functional goals, four important compatibility goals were listed in RFC 6182. The first one is that Multipath TCP should remain compatible with the existing socket API, although the document expected that another more advanced API would be developed later. Second, and this turned out to be a very difficult compatibility goal, Multipath TCP must preserve the ability to transfer data. This implies that if two hosts were able to exchange data over a given network path, they should still be able to exchange the same data once TCP has been replaced by Multipath TCP. In some network scenarios, preserving the ability to exchange data could rely on a fallback to regular TCP. The third goal is that Multipath TCP should not harm existing TCP flows from a congestion control viewpoint. Finally, the third goal is that Multipath TCP should not be less secure than regular TCP.
Section 4 of RFC 6182 provides a high level functional decomposition of Multipath TCP. One of the key elements of this decomposition is that a Multipath TCP will be composed of a set of subflows as illustrated in the figure below (source RFC 6182).
Then, Section 5 provides the key design principes that will be discussed in more details in other blog posts. Section 7 concerns the interactions with middleboxes, another important problem that will also be discussed in subsequent blog posts.