Levin, D

Merz, R

Schioeberg, H

Sengul, C

Oxford Brookes University: RADAR

TCPSpeaker: Clean and Dirty Sides of the Same SlateDan Levin Harald Schioeberg Ruben Merz Cigdem SengulDeutsche Telekom Laboratories, Germany{dan,harald}@net.t-labs.tu-berlin.de {ruben.merz,cigdem.sengul}@telekom.deABSTRACTAs new approaches toward clean-slate network transportcontinue to emerge in the wireless domain and beyond, sogrows the difficulty of conducting reproducible, head-to-headevaluation and comparison of such protocols against one an-other. The challenge alone of clean-slate transport proto-col deployment onto end-user systems makes evaluation onexisting networks with real user traffic impractical. To ad-dress these challenges, we present TCPSpeaker, a transport-protocol translator designed to enable clean-slate transportto run and be evaluated in today’s networks. Built onthe Click Modular Router, TCPSpeaker is a tool to enableclean-slate transport approaches and evaluation in apples-to-apples fashion, on existing networks with live, real end-user generated traffic. We present the design and implemen-tation of our tool, highlighting an initial use case along witha performance evaluation.1. MOTIVATION AND RELATED WORKThe performance and fairness problems of TCP in wirelessmesh networks (WMNs) are well known [1, 2]. Approachesto solve them fall roughly into two classes: (i) those whichmaintain legacy TCP compatibility, and (ii) clean-slate pro-tocols which redefine WMN transport, breaking TCP com-patibility. Clean-slate approaches such as block-switchedand cross-layer transport protocols [3, 4] break the end-to-end principle, using intermediate WMN nodes for intelligentcaching and pacing and show significant throughput andflow fairness improvements. Clean-slate approaches how-ever, exclude TCP-speaking clients from the network and assuch, their practical impact as well as live-network evalua-tion potential is severely limited.We believe that the strengths of these two approaches maybe exploited by uniting them. We propose TCPSpeaker,a transport-protocol translator to “bridge” TCP flows en-tering and leaving the WMN at its edges. TCPSpeakerdiffers from other split-TCP approaches [2], as it does notmerely “split” TCP flows into multiple segments, but rather,enables the removal of TCP entirely from the WMN. Tothe WMN users, TCPSpeaker presents a transparent, fullyTCP-compliant interface. Inside the WMN, TCPSpeakerintroduces the freedom to swap in and out, entirely newtransport protocol more suited to the WMNs, furthermore,enabling the direct apples-to-apples evaluation and compar-ison of such approaches.Although originally motivated by problems encounteredin the wireless domain, we believe TCPSpeaker will proveuseful well beyond the scope of WMNs, allowing any clean-Figure 1: Use Case: TCPSpeaker-to-L4 pairs at theedges of a WMN translating intercepted TCP flows.slate transport to interact with legacy TCP end-hosts. Wehave released our TCPSpeaker implementation1 under a freelicense as a fully-functional Click element [5]. We next placeTCPSpeaker into context of related work, followed by dis-cussion of the uniqueness of our design and implementation.We present evaluate its performance and behavior as an in-terface to TCP, and close by identifying open questions anddirections for further work.2. UNIQUENESS OF APPROACHThe primary design goal of TCPSpeaker is to act as aninterface between TCP and a semantically equivalent intra-WMN transport protocol, which we will call L4. L4 is se-mantically equivalent to TCP if it is: bi-directional, connection-oriented, in-order, reliable bytestream with multiplexing,and flow-control. TCPSpeaker operates together with L4,with which it is paired back-to-back on the same node.Two separate back-to-back pairs operate at each edge ofthe WMN where TCP traffic enters/exits. Figure 1 depictsTCP traffic entering the WMN, where it is intercepted bya TCPSpeaker (1) and then passed to an L4 translator (2).The traffic then moves through the WMN until it is inter-cepted at the gateway, where it is converted from L4 (3)back into TCP (4), at which point it leaves the WMN. Forevaluation and development purposes, TCPSpeaker may bepaired back-to-back with another TCPSpeaker, effectivelytranslating from TCP to TCP in the fashion of a split-TCPproxy.2.1 Flow Dispatching and HandlingTCPSpeaker handles TCP traffic on a per-flow basis, wherea flow is made up of TCP segments of a bi-directional TCP1git clone git://bowl.net.t-labs.tu-berlin.de/click.gitFigure 2: Above: The full TCPSpeaker component-level architecture. Below: higher-level layers oftwo back-to-back TCPSpeakers, paired on the samehost.connection sharing the same entry and exit nodes of thewireless network. This is crucial for preserving the connection-oriented nature of TCP on both edges of the WMN. Toachieve per-flow handling, TCPSpeaker features a layeredarchitecture given in Figure 2. As a TCP flow is inter-cepted by one of the paired TCPSpeakers, it is dispatchedto its appropriate flow-handler. The flow-handler translatesthe incoming stateful TCP flow to a stateless intermediatebytestream, which is fed directly to the paired L4 (or TCPS-peaker) protocol translator where its respective intra-WMNstate is kept. This stateful-to-stateless-to-stateful transitionis implemented via a zero-copy, intra-process communica-tion, safeguarding the stateless bytestream in all but themost extreme scenarios of total node failure.For per-flow TCP-to-L4 semantics (i.e, flow-control) TCP-Speaker provides an interface for throttling the data rate toits paired L4 neighbor and vice-versa. The throttling is re-alized by inspection of the free space in its neighbor’s OUTqueue. A TCPSpeaker will only push data to its neighborwhen its neighbor is able to send that data itself, whichallows a flow-control mechanism similar to backpressure.2.2 Preserving Macroscopic BehaviorTo preserve outward TCP compatibility, the TCPSpeakerpreserves the macroscopic behavior of TCP with end-to-endflow control and outward in-order, reliable transport robustagainst packet loss and reordering. TCPSpeaker also en-sures throughput fairness across multiple flows under itscontrol. In the event of total node failure, a curious sce-nario arises, as some data which has been ACKed to thesender may fail to reach its destination. However, in prac-tice, this limitation should prove to be manageable since thebackpressure mechanism limits the amount of data whichcould be lost to the bandwidth-delay product of the WMN.Additionally, an ACK only means that the segment was re-ceived by TCP and does not guarantee processing by theFigure 3: Click Element class heirarchyapplication. Nevertheless, the delivery guarantee issue ofthe TCPSpeaker under this condition merits future investi-gation.2.3 TCPSpeaker as a Click ElementWe implemented TCPSpeaker as a Click element, whoseclass structure is given by 3. Our implementation allowsus to run the same code-base on any system running Linux(among other platforms), in either user-space, kernel-space,or even within ns-2, with no code-level modifications. Withonly minor modifications to ensure memory position-independentcode, we run and evaluate TCPSpeaker on the GateworksAvila (an ARM architecture embedded device capable ofrunning Linux), the chosen wireless hardware platform ofthe BOWL testbed [6].3. RESULTS AND CONTRIBUTIONTo prove that TCPSpeaker implementation is usable in itsintended role, we show that its performance and macroscopicbehavior closely match those of the native system TCP im-plementation. The metrics of our evaluation are throughputand RTT under conditions of packet loss and reordering, andflow-fairness [7] under simultaneous multiple flows.3.1 Experimental DesignWe design a series of experiments based on the topologygiven in Figure 4. All experiments use the same traffic gen-erator, traffic sink, and traffic shaper for packet loss andreordering. These roles are filled by servers Loadgen 1, 2and 3, respectively. Servers Loadgen 1 and 2 run the Linux2.6.18-6 kernel on a VIA Nehemiah x86-compatible proces-sor running at 1 GHz with 512 Mbytes of RAM. Loadgen 3runs a slightly newer 2.6.28-17 kernel. As our system un-der test running the Click TCPSpeaker, we use the Gate-works Avila GW 2348-4 network platforms. Each Avila runsthe Linux 2.6.26.8 kernel on an Intel IXP425 XScale CPUrunning at 533MHz with 64Mbytes of addressable SDRAM.This system is the host Avila 2 in the figure. As two TCP-Speakers run back-to-back on Avila 2, our measurement re-sults reflect two separate TCP connections, measured fromside A and B in Figure 4.In our preliminary experiments, we establish TCP con-nections and transfer 20 MBytes of data from Loadgen 1 toLoadgen 2 between which, a pair of TCPSpeakers interceptand translate each TCP connection from TCP to TCP (ef-fectively operating as a split-TCP proxy). We subject theflows to varying conditions of packet loss and reordering viaour shaper. We also establish varying numbers of simultane-ous concurrent flows, and measure the per-flow throughputand RTT characteristics on both sides of the TCPSpeakers.Figure 4: Preliminary experimental setup.Table 1: Median throughput normalized to 0%Packet Loss Case vs. % Packet Loss.% Loss TCPS A TCPS B Kernel0.1 96.9 96.9 1021 77.4 78.0 69.75 5.97 5.95 6.3We then compare our measurements to those with the Linuxkernel TCP Reno.3.2 Preliminary ResultsOur results show that TCPSpeaker macroscopic behav-ior is comparable to the Linux Kernel TCP implementationand within acceptable and practically usable bounds. TCP-Speaker responds resiliently on both sides of the split con-nection to both packet loss (see Table 1) and reordering. Forinstance, under 10% packet reordering, TCPSpeaker Side Aexhibits a median 92.5% of in-order throughput while sideB exhibits median 52.5%. This reflects the need for buffergaps introduced by out-of-order packets to be filled fromside A before the data can be passed to side B. By compar-ison, the Linux kernel TCP Reno implementation exhibitsroughly 24% median throughput under the same 10% packetreordering conditions.Our measurements show that TCPSpeaker contributespositively to per-flow fairness since the flow-scheduling andbackpressure mechanisms of the paired TCPSpeakers resultin a more equal distribution of network bandwidth capacityto flows. This can be seen as a reduction in unfairness asflows pass from side A to side B of our network (see Figure5).In summary, our measurements show that TCPSpeaker (i)exhibits operational correctness and macroscopic behavior ofLinux Kernel TCP (ii) is performant and robust to loss andreordering and (iii) is fair.3.3 OutlookTCPSpeaker enables clean-slate transport protocols to sup-port use and evaluation with legacy TCP end-hosts. Despitea rigorous development process, areas of implementation re-main for further optimization and refinement. An appealingfeature for future inclusion in the TCPSpeaker is supportfor the selective ACK option. Recent efforts on Click withunpatched Linux kernel may also offer crucial performancegains, bringing the TCPSpeaker head-to-head with the per-formance of the kernel TCP implementation. TCPSpeakeralso raises significant questions at a protocol-design level. It5 Flows A  B  15 Flows A  B  25 Flows A  B0.000.020.040.060.08UnfairnessTCPSpeaker5 Flows  15 Flows  25Flows0.000.020.040.060.080.10UnfairnessKernel TCPFigure 5: TCPSpeaker (top) vs. Kernel TCPRENO (bottom): Unfairness with varying numberof flows. TCPSpeaker improves fairness of its trans-lated flows.remains to be seen to what extent we impact upper-layerprotocols which may receive ACKs for data that is neverdelivered.4. REFERENCES[1] P. Z. Z. Fu, H. Luo, “The impact of multihop wirelesschannel on TCP performance,” IEEE Trans. MobileComput., vol. 4, no. 2, 2005.[2] S. Kopparty, S. Krishnamurthy, M. Faloutsos, andS. Tripathi, “Split TCP for mobile ad hoc networks,””UC Riverside”, Tech. Rep., 2002.[3] M. Li, D. Agrawal, D. Ganesan, and A. Venkataramani,“Block-switched networks: a new paradigm for wirelesstransport,” in NSDI, 2009, pp. 423–436.[4] K. Sundaresan, V. Anantharaman, H.-Y. Hsieh, andR. Sivakumar, “ATP: a reliable transport protocol forad-hoc networks,” in MobiHoc, 2003, pp. 64–75.[5] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F.Kaashoek, “The click modular router,” ACM Trans.Comput. Syst., vol. 18, no. 3, pp. 263–297, 2000.[6] R. Merz, H. Schiberg, and C. Sengul, “Design of aconfigurable wireless network testbed with live traffic,”in TridentCom, May 2010.[7] R. Jain, The Art of Computer Systems PerformanceAnalysis. John Wiley and Sons, 1991.

TCP-Speaker: Clean and Dirty Side of the Same Slate

https://radar.brookes.ac.uk/radar/file/122a2cbb-636b-e6ee-a79a-b983f358072b/1/TCPSpeaker.pdf

TCP-Speaker: Clean and Dirty Side of the Same Slate

Abstract

Similar works

Full text

Available Versions

Oxford Brookes University: RADAR