The “Experimental” status of Multipath TCP

Multipath TCP is defined in RFC 6824 and I recently heard feedback from someone working for industry who mentioned that Multipath TCP should not be considered for deployment given its Experimental status. I was surprised by this comment and I think that it would be useful to clarify some facts about the maturity of Multipath TCP.

First, from a administrative viewpoint, the Experimental status of Multipath TCP was decided at the creation of the IETF MPTCP working group. At that time, it was unclear whether it would be even possible to specify a protocol like Multipath TCP and the IESG wanted to encourage experiments with the new protocol. By selecting this option , the IESG prepared a future standardisation of the protocol and this is happening right now with the definition of a standards-track version of Multipath TCP in RFC6824bis . According to the milestones of the IETF MPTCP working group, this revision should be ready in 2017.

Second, from a technical viewpoint, the maturity of a protocol cannot be inferred from the status of its specification. The best way to measure this maturity is to observe the interoperable implementations and the deployment of the protocol. From these two viewpoints, Multipath TCP is a clear success. There are endhost implementations on Linux, FreeBSD, Apple iOS, MacOS and Oracle Solaris. Multipath TCP is also supported on various middleboxes including Citrix Netscaler, F5 BIG-IP LTM and Ericsson.

From a deployment viewpoint, Multipath TCP is also a huge success. Hundreds of millions of users of Apple devices (iPhone, iPad, laptops) use Multipath TCP every time they use the Siri voice recognition application. In Korea, a dozen of models of high-end smartphones from Samsung and LG include a port of the reference implementation of Multipath TCP in the Linux kernel and use SOCKS proxies to bond WiFi and fast LTE. Several network operators provide those proxies as a commercial service. Other companies such as Swisscom or OVH also rely on SOCKS proxies to bond different types of links together. Another emerging use case are hybrid access networks. In various countries, network operators are require to provide fast broadband services, even in rural areas where deploying fiber is too expensive. Many of these operators want to combine their xDSL and LTE networks in order to improve the bandwidth to their customers. Tessares has already deployed a pilot hybrid access network solution that leverages Multipath TCP in Belgium.

Multipath TCP projects during the IETF97 Hackathon

The IETF organised a hackathon during the weekend before the IETF‘97 meeting in Seoul. There are already several large scale deployments of Multipath TCP. However, these deployments focus on very specific utilisations of Multipath TCP for special applications or through various forms of proxies.

Recently, Benjamin Hesmans has released an enhanced socket API for Multipath TCP . This API has the potential of enabling new use cases for Multipath TCP by allowing application developpers to control the establishment and the utilisation of the Multipath TCP subflows. To understand how this new API could be used, we organised a remote hackathon at Ecole Polytechnique de Louvain. We had two teams working on Multipath TCP during the IETF‘97 Hackathon. In Seoul, 5 IETFers, including three PhD students from the IP Networking Lab worked in Seoul and 25 students worked in Louvain-la-Neuve on this new socket API.

../../../_images/hackathon.png

These two teams received the best overall award from the organisers of the IETF‘97 Hackathon in Seoul for their effort.

The Seoul team, composed of Benjamin Hesmans, Fabien Duchene, Olivier Tilmans, SungHoon Seo and François Serman worked on developing a library that can be pre-loaded before launching an unmodified application to use the new socket API to control how this application uses the underlying Multipath TCP subflows. This is described in these slides

In Louvain-la-Neuve, eight teams worked on different use cases.

Two groups of students worked on porting the Multipath TCP socket API to other langages than C. They have created prototype code for Java and Ruby. The other teams worked on curl, lighttpd, Openssh, ipef3 and nc.

Grégory Vander Schueren, Raphaël Bauduin and Thibault Gérondal worked on modifying Ruby to support the new Multipath TCP socket API. They obtained running code to support some of the new socket operations directly from ruby. Their work is summarised in these slides

../../../_images/ruby.jpg

Guillaume Demaude and Pierre Ortegat have analysed the problem of supporting the new Multipath TCP socket API in Java. It turned out that the Socket class in Java had not been designed to be extended. They have thus written static methods that implement the new socket API. Their results are in summarised in these slides and their code is available from https://github.com/reirep/matcp-java.git

../../../_images/java.jpg

Hoang Tran Viet, Remi Chauvenne and Thibault Libioulle have worked on iperf3, a throughput measurement tool. They have added the support for Multipath TCP inside iperf3 and modified the application to exchange the addresses of the client and of the server that are used to perform the tests. Their results are summarised in these slides

../../../_images/iperf3.jpg

Charles-Henry Bertrand and Sylvain Dassier have explored how to modify the netcat testing tool to support Multipath TCP. Their results are summarised in these slides

../../../_images/nc.jpg

Maxime Beugom, Antoine Denauw, Alexandre Dubray, Julien Gomez and Julian Roussieau have worked on Openssh. Their prototype controls changes the underlying subflows after the transmission of a number of bytes or after some time. This prototype demonstrates that by influencing the underlying subflows a security application can select different paths and thus counter on-path attacks. Their results are summarised in these slides Their code is posted on https://github.com/Derwaan/openssh-portable

../../../_images/ssh.jpg

Arnaud Dethise and Jacob Eliat-Eliat have modified curl to only create Multipath TCP subflows on connections that carry a sufficient number of bytes or last a sufficient time. Experiments have shown that Multipath TCP does not bring benefits for very short flows and this demonstrates how an application can defer the establishment of subflows. Their results are summarised in these slides and their prototype code is available from https://github.com/adethise/curl/tree/mptcp

../../../_images/curl.jpg

Maxime Andries, Pablo Gonzalez Alvarez and Antoine Lambot have explored the possibility of creating subflows from the server. For this, they started from the lighttpd server and have modified it to create subflows when the web object returned by the server is large enough. Their results are summarised in these slides

../../../_images/lighttpd.jpg

Alexis Clarembeau has explored the possibility of developing a higher-level API for Multipath TCP that exposes a more abstract interface to the application. His results are summarised in these slides

../../../_images/alexis.jpg

MPTCP in Wireshark

Wireshark is a widely used network analyzer that can capture network traffic, save the captured packets (*.pcap) for later analysis and most importantly helps with analyzing such packet traces. Wireshark supports many protocols, which means it is able to assign meaning to bytes (dissect in the wireshark nomenclature) and display it accordingly. In some cases as in the TCP dissector, Wireshark even builds some state to provide expert information, for instance to identify TCP retransmissions. So far, Wireshark supported stateless dissection of MPTCP, i.e., it could dissect MPTCP options correctly, without being able to identify Multipath TCP connections.

Since November 2015 and the following patch (i.e., starting from Wireshark >= 2.1), Wireshark now considers MPTCP as a separate protocol, and builds states for MPTCP as well, thus mimicking TCP dissection.

../../../_images/dissection.png

This means Wireshark is now able to (providing the matching features are enabled):

  • map TCP subflows (tcp.stream) to MPTCP connections (mptcp.stream, see also mptcp.analysis.subflows).
  • List MPTCP connections
../../../_images/conversations.png
  • identify the master subflows (*mptcp.master == 1*)
  • check for mistmatched key/tokens and key/initial sequence data number (ISN)
  • etc... start filtering packets with *mptcp.* and wireshark autocompletion should show the different possibilities

Full MPTCP dissection can be quite CPU-consuming, thus some options are disabled by default and can be enabled through the menu Edit -> Preferences -> Protocols -> MPTCP.

../../../_images/options.png
  • Display relative MPTCP sequence numbers substracts the ISN to Data Sequence Numbers. This works only if the initial packets with the keys (3 way handshake) are captured and the wireshark option tcp relative sequence numbers is enabled.
  • In depth analysis of data sequence signal (DSS) mappings tells wireshark to look for the packets which sent the DSS mappings that cover the current packet; wireshark then displays a clickable item that brings you to the packet. This feature enables the creation of interval trees (introduced especially for this feature), which should consume quite a bit of memory/CPU so use with care !
  • Check for data duplication across subflows is a feature that was intended to help detect opportunistic reinjections or redundant schedulers but this is mostly experimental so use with care.

Matthieu Coudron

Multipath TCP News : January 2016

Multipath TCP continues to attract interest from both academic researchers who write papers that use or improve the protocol as well as engineers from industry who are deploying new innovative services on top of this new TCP extension. In this newsletter that we’ll try to post every month on the Multipath TCP blog, we’ll summarise the main information about Multipath TCP that we have collected during the previous month. Feel free to contact Olivier Bonaventure if you would like to publish something in this newsletter.

Implementation news

The MPTCP-DEV mailing list has been pretty active during the last month. Three patches have been announced :

Three bug fixes pushed by Christoph Paasch :

A first implementation of the ADD_ADDR2 option by Fabrizio Demaria. This option was proposed in RFC6824bis and includes a HMAC to authenticate the advertised address.

Alexander Frommgen has announced a new website that can be used to verify that Multipath TCP works end-to-end : http://amiusingmptcp.de

This new website goes beyond the original http://amiusingmptcp.com that is not available anymore.

Another useful tool is an improved AndroidTracebox by Raffaele Zullo. It can be used on smartphones to detect middlebox interference in cellular and WiFi networks.

Scientific publications

December 2015 has been a busy month for scientific publications on Multipath TCP. Almost an entire session was devoted to Multipath TCP at Conext’2015 in Heidelberg with three papers :

Other papers have been posted.

IETF

The IETF mailing list has been rather quite during the last month. One relevant draft has been updated :

This draft addresses the Hybrid Access Networks, i.e. access networks that combine two different link layer technologies, typically DSL and LTE. The Broadband Forum is developing solutions to enable network operators to efficiently use two heterogeneous networks together and some of the proposed solutions rely on Multipath TCP. This draft proposes a TCP option similar to the one proposed in Multipath in the Middle(Box) and discusses how such a solution could be used to support UDP.