Multipath TCP was designed and implemented as a backward compatible replacement for TCP. For this reason, it exposes the standard socket API to the applications that cannot control the utilisation of the different paths. This is a key feature for applications that are unaware of the multipath nature of the network. On the contrary, this is a limitation for applications that could benefit from specific knowledge to use multiple paths in a way that fits their needs. As the specific knowledge of an application can not be known in advance, we propose a Multipath TCP path manager that delegates the management of the paths to the applications. This path manager enables applications to control how the different paths are used to transfer data. We implement this path manager above the Linux Multipath TCP kernel. It is composed of a kernel part that exposes events and commands to an userspace application that controls the key functions of Multipath TCP such as the creation/suppression of subflows or reactions to retransmissions. We demonstrate the benefits of this path manager on different use cases.

Smartphones are the most popular mobile multihomed devices. End-user expects that thanks to their WiFi and cellular interfaces, they are able to seamlessly use all available networks. Unfortunately, reality tells us that seamless coexistence between cellular and WiFi is not as simple as what the user expect. Several cellular/WiFi coexistence technologies have been proposed during the last years. Some of them have been deployed. Recently, Multipath TCP received a lot of attention when it was selected by Apple to support its voice recognition (Siri) application. As of this writing, Siri is the only deployed smartphone application that uses Multipath TCP. and there is no public information about the benefits of using Multipath TCP with it. Multipath TCP is a TCP extension that allows to send data from one end-to-end connection over different paths. On a smartphone, Multipath TCP allows the applications to simultaneously send and receive data over both WiFi and cellular interfaces. It achieves this objective by establishing one TCP connection, called subflow, over each interface. Once the subflows have been established, data can be sent over any of the subflows. Researchers have analyzed the performance of Multipath TCP in such hybrid networks. However, these analyses have been performed with bulk transfers between laptops and servers. As of this writing, no detailed analysis of the performance of real smartphone applications with Multipath TCP has been published. We fill this gap in this paper by proposing a framework that automates user actions on Android smartphone applications to perform network measurements. We use it to analyze how eight popular smartphone applications interact with Multipath TCP.

Multipath TCP is a new extension to TCP that enables a host to transmit the packets from a given connection by using several interfaces. We propose mptcptrace, a software that enables a detailed analysis of Multipath TCP packet traces.

Middleboxes such as firewalls, NAT, proxies, or Deep Packet Inspection play an increasingly important role in various types of IP networks, including enterprise and cellular networks. Recent studies have shed the light on their impact on real traffic and the complexity of managing them. Network operators and researchers have few tools to understand the impact of those boxes on any path. In this paper, we propose tracebox, an extension to the widely used traceroute tool, that is capable of detecting various types of middlebox interference over almost any path. tracebox sends IP packets containing TCP segments with different TTL values and analyses the packet encapsulated in the returned ICMP messages. Further, as recent routers quote, in the ICMP message, the entire IP packet that they received, tracebox is able to detect any modification performed by upstream middleboxes. In addition, tracebox can often pinpoint the network hop where the middlebox interference occurs. We evaluate tracebox with measurements performed on PlanetLab nodes. Our analysis reveals various types of middleboxes that were not expected on such an experimental testbed supposed to be connected to the Internet without any restriction.