Multipath TCP : the Maastricht consensus
The work on Multipath TCP started in 2008 and quickly its designers approached the IETF to create a new working group. This process starts with a BOF that was held in July 2009 in Stockholm. The discussion at the MPTCP BOF was both open and constructive reading again the meeting minutes and the MPTCP working group was quickly approved.
Its initial charter was pretty ambitious:
Mar 2010 Established WG consensus on the Architecture
Aug 2010 Submit to IESG architectural guidelines and security threat analysis as informational RFC(s)
Mar 2011 Submit to IESG basic coupled congestion control as an experimental RFC
Mar 2011 Submit to IESG protocol specification for MPTCP extensions as an experimental RFC
Mar 2011 Submit to IESG an extended API for MPTCP as an or part of an experimental or informational RFC
Mar 2011 Submit to IESG application considerations as an informational RFC
Mar 2011 Recharter or close WG
All the design was supposed to be finished in less than two years. The congestion control problem that was considered as the most important one was almost solved and the protocol design did not seem too difficult.
Shortly after the creation of the working group, Alan Ford asked an interesting question on the multipathtcp mailing list : Given that endhosts will need to signal information through a TCP connection, should they use TCP options or the payload with a TLV format to encode this information ?
This was a very important design decision. On one hand, encoding control information in TCP options is the standard way of extending TCP. An important benefit of using TCP options is that there is a clear separation between the control information and the user payload. However, the extended TCP header has a limited size and it is difficult to exchange a lot of control information inside TCP option. Another issue is that TCP options are not exchanged reliably since they are not acked. On the other hand, placing control information inside the packet payload required the utilisation of a Type/Length/Value format in the packet payload to distinguish between user data and control information.
The debate over this key design question lasted for almost a year. Michael Scharf was convinced by the idea of placing control information inside the payload and proposed a detailed design in Multi-Connection TCP (MCTCP) Transport. An important advantage of using the payload to carry control information was that MCTCP could be implemented as a library that intercepts system calls without requiring modifications to the kernel TCP implementation. Michael Scharf provided additional information in a subsequent paper [SB11]. However, using the payload to carry control information has several drawbacks. First, it is difficult to implement flow control at the Multipath TCP level since it depends on the flow control of the underlying TCP connection. Second, the TLV format imposes a specific format to the packets that are exchanged by Multipath TCP hosts. This format might interfere with middleboxes such as firewalls. For example, consider a firewall that is configure to verify that all connections on port 80 only carry valid HTTP requests and responses. With MCTCP, this firewall will observe a traffic pattern that is not exactly HTTP.
The figure below (source Multi-Connection TCP (MCTCP) Transport) describes the architecture of MCTCP.
The payload/options debate lasted for almost a year and the progress of the working group was slow. There was a risk that these two designs could evolve in parallel for a long period of time. In July 2010, the working group met in Maastricht and one of the main objectives of this meeting was to reach a consensus on this important design decision. Costin Raiciu explained the arguments that were in favor of using TCP options while Michael Scharf was in favor of using TLVs in the payload. In this end, the working group agreed to focus its energy on developing a Multipath TCP protocol that uses TCP options
References
| [SB11] | M. Scharf and T. Banniza. Mctcp: a multipath transport shim layer. In 2011 IEEE Global Telecommunications Conference - GLOBECOM 2011, volume, 1–5. Dec 2011. doi:10.1109/GLOCOM.2011.6134021. |