Christoph Paasch

Exploring mobile/WiFi handover with multipath TCP

Mobile Operators see an unending growth of data traffic generated by their customers on their mobile data networks. As the operators start to have a hard time carrying all this traffic over 3G or 4G networks, offloading to WiFi is being considered. Multipath TCP (MPTCP) is an evolution of TCP that allows the simultaneous use of multiple interfaces for a single connection while still presenting a standard TCP socket API to the application. The protocol specification of Multipath TCP has foreseen the different building blocks to allow transparent handover from WiFi to 3G back and forth. In this paper we experimentally prove the feasibility of using MPTCP for mobile/WiFi handover in the current Internet. Our experiments run over real WiFi/3G networks and use our Linux kernel implementation of MPTCP that we enhanced to better support handover. We analyze MPTCPs energy consumption and handover performance in various operational modes. We find that MPTCP enables smooth handovers offering reasonable performance even for very demanding applications such as VoIP. Finally, our experiments showed that lost MPTCP control signals can adversely affect handover performance; we implement and test a simple but effective solution to this issue.

MultiPath TCP: from theory to practice

The IETF is developing a new transport layer solution, MultiPath TCP (MPTCP), which allows to efficiently exploit several Internet paths between a pair of hosts, while presenting a single TCP connection to the application layer. From an implementation viewpoint, multiplexing flows at the transport layer raises several challenges. We first explain how this major TCP extension affects the Linux TCP/IP stack when considering the establishment of TCP connections and the transmission and reception of data over multiple paths. Then, based on our implementation of MultiPath TCP in the Linux kernel, we explain how such an implementation can be optimized to achieve high performance and report measurements showing the performance of receive buffer tuning and coupled congestion control.

Experimental evaluation of multipath TCP schedulers

Today many end hosts are equipped with multiple interfaces. These interfaces can be utilized simultaneously by multipath protocols to pool resources of the links in an efficient way while also providing resilience to eventual link failures. However how to schedule the data segments over multiple links is a challenging problem, and highly influences the performance of multipath protocols. In this paper, we focus on different schedulers for Multipath TCP. We first design and implement a generic modular scheduler framework that enables testing of different schedulers for Multipath TCP. We then use this framework to do an in-depth analysis of different schedulers by running emulated and real-world experiments on a testbed. We consider bulk data transfer as well as application limited traffic and identify metrics to quantify the schedulers performance. Our results shed light on how scheduling decisions can help to improve multipath transfer.

Multipath TCP

The Internet relies heavily on two protocols. In the network layer, IP (Internet Protocol) provides an unreliable datagram service and ensures that any host can exchange packets with any other host. Since its creation in the 1970s, IP has seen the addition of several features, including multicast, IPsec (IP security), and QoS (quality of service). The latest revision, IPv6 (IP version 6), supports 16-byte addresses.

Are TCP extensions middlebox-proof?

Besides the traditional routers and switches, middleboxes such as NATs, firewalls, IDS or proxies have a growing importance in many networks, notably in entreprise and wireless access networks. Many of these middleboxes modify the packets that they process. For this, they to implement (a subset of) protocols like TCP. Despite the deployment of these middleboxes, TCP continues to evolve on the endhosts and little is known about the interactions between TCP extensions and the middleboxes. In this paper, we experimentally evaluate the interference between middleboxes and the Linux TCP stack. For this, we first propose MBtest, a set of Click elements that model middlebox behavior. We use it to experimentally evaluate how three TCP extensions interact with middleboxes. We also analyzes measurements of the interference between Multipath TCP and middleboxes in fifty different networks.

Multipath in the middle(box)

Multipath TCP (MPTCP) is a major modification to TCP that enables a single transport connection to use multiple paths. Smartphones can benefit from MPTCP by using both WiFi and 3G/4G interfaces for their data-traffic, potentially improving the performance and allowing mobility through vertical handover. However, MPTCP requires a modification of the end hosts, thus suffers from the chicken-and-egg deployment problem. A global deployment of MPTCP is therefore expected to take years. To increase the incentives for clients and servers to upgrade their system, we propose MiMBox an efficient protocol converter that can translate MPTCP into TCP and vice versa to provide multipath benefits to early adopters of MPTCP. MiMBox is application agnostic and can be used transparently or explicitly. Moreover, a close attention was paid to the implementations design to achieve good forwarding performance. MiMBox is implemented entirely in the Linux kernel so that it is able to more easily circumvent the bottlenecks of a user-space implementation. Measurements show that we always outperform user-space solutions and that the performance is close to plain IP packet forwarding.

Revisiting flow-based load balancing: Stateless path selection in data center networks

Hash-based load-balancing techniques are widely used to distribute the load over multiple forwarding paths and preserve the packet sequence of transport-level flows. Forcing a long-lived, i.e., elephant, flow to follow a specific path in the network is a desired mechanism in data center networks to avoid crossing hot spots. This limits the formation of bottlenecks and so improves the network use. Unfortunately, current per-flow load-balancing methods do not allow sources to deterministically force a specific path for a flow. In this paper, we propose a deterministic approach enabling end hosts to steer their flows over any desired load-balanced path without relying on any packet header extension. By using an invertible mechanism instead of solely relying on a hash function in routers, our method allows to easily select the packets header field values in order to force the selection of a given load-balanced path without storing any state in routers. We perform various simulations and experiments to evaluate the performance and prove the feasibility of our method using a Linux kernel implementation. Furthermore, we demonstrate with simulations and lab experiments how MultiPath TCP can benefit from the combination of our solution with a flow scheduling system that efficiently distributes elephant flows in large data center networks.

Evolving the internet with connection acrobatics

The textbook Internet architecture revolves around the end-to-end principle with smart endpoints and a dumb network, while the actual Internet is far messier, with middleboxes pervasively deployed and affecting end-to-end traffic in many ways. Todays Internet is fragile as most of the communications are affected by transparent stateful middleboxes deployed along the path. In this paper we propose an evolution of the Internet architecture to make the middleboxes an explicit part of the Internet communications. We do so using the new Multipath TCP (MPTCP) protocol recently standardized at the Internet Engineering Task Force. MPTCP allows us to change the endpoints of the connection and by extension to explicitly add middleboxes in the middle of an ongoing communication. We show that the proposed solution accommodates nicely several widely used use cases including load balancing, DDoS filtering and anycast services. We implement selected use cases as a proof of concept.