MobiCom 2010 Poster: TCPSpeaker: Clean and Dirty Sides of the Same Slate Dan Levin, Harald Schioeberg Ruben Merz, Cigdem Sengul dan,harald@net.t-labs.tu-berlin.de ruben.merz,cigdem.sengul@telekom.de Deutsche Telekom Labs/TU-Berlin I. Introduction The performance and fairness problems of TCP in wireless mesh networks (WMNs) are well known [1, 2]. Approaches to solve them fall roughly into two classes: (i) those which maintain legacy TCP com- patibility, and (ii) clean-slate protocols which redefine WMN transport, breaking TCP compatibility. Clean- slate approaches such as block-switched and cross- layer transport protocols [3, 4] break the end-to-end principle, using intermediate WMN nodes for intelli- gent caching and pacing and show significant through- put and flow fairness improvements. Clean-slate approaches however, exclude TCP-speaking clients from the network and as such, their practical impact as well as live-network evaluation potential is severely limited. We believe that the strengths of these two ap- proaches may be exploited by uniting them. We pro- pose TCPSpeaker, a transport-protocol translator to “bridge” TCP flows entering and leaving the WMN at its edges. TCPSpeaker differs from other split- TCP approaches [2], as it does not merely “split” TCP flows into multiple segments, but rather, enables the removal of TCP entirely from the WMN. To the WMN users, TCPSpeaker presents a transparent, fully TCP- compliant interface. Inside the WMN, TCPSpeaker introduces the freedom to use a new transport proto- col more suited to the WMNs. TCPSpeaker may further prove useful beyond the scope of WMNs, allowing any clean-slate transport to interact with legacy TCP end-hosts. We implement TCPSpeaker as a fully-functional Click element [5] and evaluate its performance and behavior as an inter- face to TCP. We next discuss our design, implemen- tation, and evaluation, identifying open questions and directions for further work. II. Design and Implementation The primary design goal of TCPSpeaker is to act as an interface between TCP and a semantically equiv- alent intra-WMN transport protocol, which we will call L4. L4 is semantically equivalent to TCP if it Figure 1: Use Case: TCPSpeaker-to-L4 pairs at the edges of a WMN translating intercepted TCP flows. is: bi-directional, connection-oriented, in-order, reli- able bytestream with multiplexing, and flow-control. TCPSpeaker operates together with L4, with which it is paired back-to-back on the same node. Two sep- arate back-to-back pairs operate at each edge of the WMN where TCP traffic enters/exits. Figure 1 depicts TCP traffic entering the WMN, where it is intercepted by a TCPSpeaker (1) and then passed to an L4 trans- lator (2). The traffic then moves through the WMN until it is intercepted at the gateway, where it is con- verted from L4 (3) back into TCP (4), at which point it leaves the WMN. II.A. Flow Dispatching and Handling TCPSpeaker handles TCP traffic on a per-flow ba- sis, where a flow is made up of TCP segments of a bi-directional TCP connection sharing the same en- try and exit nodes of the wireless network. This is crucial for preserving the connection-oriented nature of TCP on both edges of the WMN. To achieve per- flow handling, TCPSpeaker features a layered archi- tecture given in Figure 2. As a TCP flow is intercepted by one of the paired TCPSpeakers, it is dispatched to its appropriate flow-handler. The flow-handler trans- lates the incoming stateful TCP flow to a stateless intermediate bytestream, which is fed directly to the paired L4 (or TCPSpeaker) protocol translator where its respective intra-WMN state is kept. This stateful- to-stateless-to-stateful transition is implemented via a zero-copy, intra-process communication, safeguard- ing the stateless bytestream in all but the most extreme