A model-driven emulation approach to large-scale

A model-driven emulation approach to large-scale TCP performance evaluation Miguel A. Erazo* and Jason Liu School of Computer and Information Sciences Florida International University, Miami, FL 33199 Miami, Florida 33199, USA Emails: {meraz001, liux}@cis.fiu.edu ∗ Corresponding author

Abstract: Small-scale experiments are insufficient for a comprehensive study of congestion control protocols. Similarly, results obtained from pure simulation platforms without exercising real protocols and applications lack realism. Motivated by these reasons, we developed SVEET, a TCP performance evaluation testbed where real implementations of TCP variants can be accurately evaluated under diverse network configurations and workloads from real applications in large-scale network settings. It is our purpose to provide the research community a standard environment through which quantitative assessment regarding TCP behavior can be drawn from large-scale experiments. In order to accomplish our goal, we adopted a novel model-driven emulation approach combining real-time simulation, machine and time virtualization techniques. We validate the testbed via extensive experiments to assess its potentials and limitations. Additionally, we performed case studies involving real web, streaming, and peer-to-peer applications. Our results indicate that SVEET can accurately model the behavior of the TCP variants and support large-scale network scenarios. Keywords: TCP performance; network simulation; emulation; machine virtualization; time dilation Reference to this paper should be made as follows: Erazo, M. A., and Liu, J. ‘A model-driven emulation approach to large-scale TCP performance evaluation’, Int. J. of Communication Networks and Distributed Systems (IJCNDS), Vol. x, No. x, pp. xxx. This article is an extended version of earlier work published in the Proceedings of the 5th International Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities (TRIDENTCOM 2009) Biographical notes: Miguel A. Erazo is a Ph.D. candidate of Computer Science at Florida International University. He received a B.A. in Electronics Engineering from Major University of Saint Andrews, Bolivia in 2003, and an M.S. in Computer Engineering from University of Puerto Rico at Mayag¨ uez in 2006. His research interests include network simulation, wireless networks, and network congestion control. Jason Liu is an Assistant Professor in the School of Computing and Information Sciences, Florida International University. His research focuses on parallel discrete-event simulation, high-performance modeling and simulation of computer systems and networks. He received a B.A. in Computer Science from Beijing University of Technology in China in 1993, an M.S. in Computer Science from College of William and Mary in 2000, and a Ph.D. in Computer Science from Dartmouth College in 2003.

1

INTRODUCTION

TCP from reaching high data throughput over high-speed long-latency links. Consequently, quite a number of TCP variants, including H-TCP (Leith and Shorten, 2004), Scalable TCP (Kelly, 2003), FAST (Wei et al., 2006), BIC (Xu

Although TCP has contributed to the tremendous success of the Internet, it has been widely documented that the traditional TCP congestion control algorithms (such as TCP Reno and TCP SACK) have serious problems preventing

c 200x Inderscience Enterprises Ltd. Copyright

1

apply real-time immersive network simulation techniques, which allow the simulated network to interact with real implementations of network applications, protocols, and services (Liu, 2008). We extend the real-time simulation capabilities of our network simulator such that the simulation time can be made to advance either in real time or proportional to real time. We use machine virtualization technologies to provide an accurate execution environment of the target system. These virtual machines are connected to the network simulator, which applies proper traffic delays and losses according to simulated conditions of the virtual network. Our approach combines the advantages of both simulation and emulation: we can achieve highlevel controllability, repeatability, and flexibility from simulation, as well as the capabilities to execute real protocols and applications from emulation. To enable network experiments with large traffic volume, we apply the time dilation technique on virtual machines (Gupta et al., 2006). Time dilation can change a virtual machine’s notion of how time progresses: in a timedilated system, the machine time may progress slower than real time; correspondingly, the machine is seen to be able to achieve higher network performance. Combining with the simulator’s capability of throttling the simulation time, the system is able to emulate high-capacity networks, albeit at the cost of increased experiment time. We designed and implemented SVEET based on our real-time network simulator, PRIME, which supports parallel and distributed simulation of large-scale networks (Liu, 2009). PRIME provides a scalable emulation infrastructure that allows automatic and seamless interactions between multiple virtual machines and the simulator (Liu et al., 2007). We ported several TCP congestion control algorithms from the ns-2 simulator consisting of thirteen TCP variants originally implemented for Linux (Wei and Cao, 2006). In doing so we are able to conduct large-scale experiments using simulated traffic generated by these TCP variants. We also customized the Linux kernel on the virtual machines to include these TCP variants so that we can test them using real applications running on the virtual machines to communicate via the TCP/IP stack. The rest of the paper is organized as follows. In Section 2, we review related work. Section 3 describes the details about the design and implementation of SVEET. We conducted extensive experiments to validate our testbed; the results are shown in Section 4. The capacity limitations of our platform running in a single box are explored in Section 5. Section 6 provides some interesting case studies enabled by our testbed involving web, streaming, and P2P traffic. Finally, we conclude this paper and outline our future work in Section 7.

et al., 2004), and CUBIC (Rhee and Xu, 2005)—just to mention a few—have been proposed to directly tackle these problems. Compared with the traditional methods, these TCP variants typically adopt more aggressive congestion control methods to avoid under-utilization over networks with a large bandwidth-delay product. In recent years, a significant amount of effort has been invested to evaluate these TCP variants (e.g., Ha et al., 2006, 2007; Li et al., 2007). However, no comprehensive study on the performance of these TCP variants exists beyond small-scale experimentation. This problem is exacerbated by the lack of standard performance metrics and convincing network scenarios to benchmark the existing algorithms. More recently, several test suites have been developed in an effort to standardize network configurations, workloads, and metrics for testing and benchmarking these TCP variants (e.g., Andrew et al., 2008; Wei et al., 2005). These test suites, however, support only small-scale simplified network scenarios. The community urgently needs a standard evaluation environment for an objective comparison of the TCP variants under a wide spectrum of networking conditions in large network scenarios. Three principal methods can be used to test the TCP performance: live experiments, simulation, and emulation. Live experiments on existing research testbeds, such as PlanetLab (Peterson et al., 2002) and VINI (Bavier et al., 2006), provide protocol designers with realistic distributed environments and traffic conditions that resemble the target system on which the protocols are deployed. These testbeds, however, do not provide the level of reproducibility, controllability, and flexibility necessary for testing and benchmarking the TCP variants under diverse network conditions. In contrast, network simulators, such as ns2 (Breslau et al., 2000), SSFNet (Cowie et al., 1999), and GTNetS (Riley, 2003), offer complete control over the testing environment. In simulation, the network topologies and workloads are easy to configure, and events can be readily generated to test the protocols under various circumstances. Nevertheless, simulation lacks realism. In addition, protocols are not easily implemented in simulation without significant effort; above all, simulation models must be subjected to rigorous verification and validation tests. Alternatively, emulation testbeds, such as EmuLab (White et al., 2002) and ModelNet (Vahdat et al., 2002), allow flexible network experiments that directly involve real protocol implementations. However, the cost of setting up a large-scale network emulation environment for testing and benchmarking the TCP variants can be substantially higher than that of simulation. Our goal is to provide researchers with a flexible, easyto-use, and easy-to-maintain testbed where real implementations of the TCP variants can be accurately evaluated with diverse network configurations and workloads in large-scale network settings. We present the Scalable Virtualized Evaluation Environment for TCP (SVEET), which adopts a novel model-driven emulation approach that combines advanced network simulation, emulation, as well as machine and time virtualization techniques. We

2

RELATED WORK

There have been significant efforts in the performance evaluation of different TCP congestion control algorithms. Li

2

chine virtualization, such as Xen (Barham et al., 2003) and Linux VServer (2009), to virtualized network stacks, such as OpenVZ (2009). Recently, Caini et al. (2008) designed and developed a virtual integrated TCP testbed called VITT. The main idea is to exploit advanced virtualization technologies to realize real network components within a single physical machine in order to support highfidelity TCP performance evaluation with high-level timing accuracy. However, since all network components must be emulated on the same physical host, the scalability of VITT is questionable. Virtual time management has been the central theme of parallel discrete-event simulation (Fujimoto, 1990). However, the concept is relatively new for network emulation. SVEET is developed based on the time dilation technique proposed by Gupta et al. (2006). Bergstrom et al. (2006) proposed a different virtual time management mechanism enabled by a binary executable modification scheme, which includes the ability to dynamically dilate or contract time to improve resource utilization. Grau et al. (2008) proposed a low-overhead conservative synchronization mechanism to regulate time dilation across virtual machines. All methods above have been applied only to network emulation; SVEET needs to coordinate time dilation across the entire system, including both virtual machines and the network simulator.

et al. (2007) presented experimental results of several major TCP congestion control algorithms. This study mainly focused on long-lived flows (with realistic round-trip time distributions) over a single bottleneck link. Ha et al. (2006) identified several important elements in constructing realistic test scenarios for TCP performance evaluation. In a later study, Ha et al. (2007) provided a systematic study on the impact of background traffic on the performance of high-speed TCP variants. They extended the traditional network scenarios to include as many as five types of background traffic. There has been a genuine push since the beginning from the research community for a standard evaluation environment for prototyping, testing, and benchmarking TCP algorithms. For example, Wei et al. (2005) proposed a benchmark suite that consists of a set of network configurations, workloads, and standard metrics. Similarly, Shimonishi et al. (2007) proposed a TCP evaluation suite for TCP simulation studies using ns-2. Their goal was to promote comparable studies of different congestion control schemes. Separately, Andrew et al. (2008) proposed a specification of an evaluation suite for TCP congestion algorithms, which considers different traffic scenarios and different network configurations, and defines a set of performance metrics and scenarios of common interest. SVEET is inspired by these studies and aims to provide researchers with an accurate, scalable, and flexible testbed to evaluate TCP variants with realistic network configurations and workloads. Most of the aforementioned studies were based on either simulation or emulation, but not both. For example, the testbed used by Ha et al. (2007) to evaluate TCP performance with background traffic was developed upon FreeBSD Dummynet (Rizzo, 1997). There are several prominent emulation testbeds well received by the research community for conducting network experiments in general. They include, for example, EmuLab and ModelNet. EmuLab (White et al., 2002) is an experimentation facility that consists of a large number of networked computers that can be configured to present a virtual network environment. ModelNet (Vahdat et al., 2002) is an emulation environment that supports large-scale network experiments. ModelNet runs real network applications at the peripheral of the system called “edge nodes” and directs traffic through the emulation core consisting of parallel computers. These emulation testbeds are general-purpose environments for conducting experiments for network and distributed applications, while SVEET focuses on TCP performance evaluation and benchmarking. SVEET also adopted a different design philosophy: one of the main goals of SVEET is to support commodity execution environments, rather than promoting resource sharing, in order to increase the accessibility of network testbeds by researchers at large. Researchers have proposed using machine virtualization to build network emulation testbeds (e.g., Bavier et al., 2006; Bhatia et al., 2008). Virtual machine solutions come in variations, ranging from full-scale machine virtualization, such as VMWare Workstation (VMWare, Inc., 2009) and User-Mode Linux (Dike, 2000), to light-weight ma-

3

THE SVEET APPROACH

SVEET aims to be a standard TCP evaluation testbed for the community. Such a testbed must satisfy the following requirements: 1. It must be able to generate reproducible results. Reproducibility is essential to protocol development; the users should be able to use the testbed and follow a set procedure for regression testing, documenting, and benchmarking existing TCP variants. 2. It must be able to accommodate a diverse set of networking scenarios, ranging from small-scale topologies to large-scale configurations. Not only should one be able to use the testbed for inspecting the details of the protocol behavior in small, tightly controlled, choreographic conditions, but also be able to perform studies to assess large-scale impact—e.g., how much a TCP variant can affect and be affected by other network traffic in realistic large-scale network settings. 3. It must be able to incorporate existing protocol implementations in real systems rather than develop its own version simply for testing purposes. The protocol development process is complicated and error-prone: maintaining a separate code base would have to include costly procedures for verification and validation. Fig. 1 provides a schematic view of the SVEET architecture. Distributed applications are executed directly on

3

PRIME Network Simulator

VM2

VM1

ProtocolSession

TCP/IP Stack

Applications

LinuxTcpSimpleSocket

PRIME

Applications

LinuxTcpMaster

Virtual NICs

TCP/IP Stack

PRIME Emulation Infrastructure

ns-linux-util

Figure 1: The SVEET architecture. end-hosts configured as separate virtual machines (e.g., VM1 and VM2 ) with their own network stacks implemented with the TCP variants under investigation. We call these end-hosts emulated hosts. Traffic generated by the applications on these emulated hosts is captured by the virtual network interfaces (NICs), which forward the packets to the PRIME network simulator via the emulation infrastructure provided by PRIME. Once inside the network simulator these packets are represented simply as simulation events. PRIME simulates packet forwarding according to the virtual network condition regardless whether the packets are simulated or emulated packets. If the packets reach a destination node that has been emulated, they are exported to the corresponding emulated host, again via PRIME’s emulation infrastructure. The packets arrive at the virtual network interfaces of the emulated host as if received from a real network. In the following subsections, we present more details on the components of SVEET. 3.1

SinkTcpAgent

LinuxTcpAgent

Virtual NICs

HS-TCP

CUBIC

H-TCP

HYBLA

NewReno

TCP-LP

BIC

STCP

Vegas

C-TCP

Veno

FAST

Westwood Illinois

Linux TCP

Figure 2: Implementing Linux TCP in PRIME. To allow simulation to include all the TCP variants, we followed the same design principle by Wei and Cao (2006) directly porting Linux TCP variants to PRIME. Fig. 2 shows the code structure. In PRIME, protocols on each virtual node are organized as a list of protocol sessions, each represented as a ProtocolSession object. We created a protocol session, LinuxTcpMaster, to manage all active Linux TCP connections, and another protocol session, LinuxTcpSimpleSocket, to support a simple interface for applications to send or receive data over Linux TCP. Consequently, both are derived from the ProtocolSession class. A TCP connection was structured in the same fashion as in ns-2: we used LinuxTcpAgent to represent the TCP sender-side logic and SinkTcpAgent to represent the receiver-side logic. In this way we achieved maximal reuse of the existing code from the Linux TCP implementation in ns-2. Specifically, the congestion control mechanisms of the TCP variants were transplanted directly from the Linux TCP implementation. ns-linux-util is a set of facilities created in ns-2 as an interface between the Linux TCP functions and the ns-2 simulator. We refurbished these facilities for them to run instead in PRIME.

PRIME Network Simulator

PRIME stands for Parallel Real-Time Immersive network Modeling Environment (Liu, 2009). PRIME features a parallel discrete-event simulation engine based on the Scalable Simulation Framework (SSF), which provides a standard programming interface for parallel large-scale simulation (Cowie et al., 1999). PRIME can run on most parallel platforms, including shared-memory multiprocessors (as a multi-threaded program), distributed-memory machines (via the message-passing interface), or a combination of both. Supporting parallel and distributed simulation allows PRIME to run extremely large network simulations. PRIME also supports real-time simulation, in which case unmodified implementations of real applications can run along with the network simulator that operates in real time (i.e., the simulation time advances at the same speed as the wall-clock time). Traffic between the real applications (e.g., running on virtual machines) is captured and forwarded automatically to PRIME so that it can be “carried” on the virtual network. Note that, in the case of realtime simulation, the network simulator must process events at a rate no slower than the wall-clock time to guarantee real-time performance. PRIME allows the simulation time advancement to be proportional to the wall-clock time. In particular, one can slow down the simulator if the simulation cannot keep up with real time.

3.2

Xen Virtual Machines

We chose Xen (Barham et al., 2003) for the virtual machines in our implementation. Xen is a high-performance open-source virtual machine solution. On most machines, Xen uses a technique called “para-virtualization” to achieve high performance by modifying the guest operating systems to obtain certain architectural features not provided by the host machines to support virtualization. SVEET currently supports Linux (a.k.a. XenoLinux under Xen) as the guest operating system. Specifically, SVEET was developed on Xen 3.0.4 and Linux kernel 2.6.16.33. This Linux kernel comes with all the TCP variants which we would like to include in our experiments. We also equipped the Linux kernel with Web100 (Mathis et al., 2003), so that researchers can easily monitor and change

4

3.3

User Kernel

VM1

TCP variables during the experiments. In order to fully test all TCP congestion control algorithms in various environments, plentiful bandwidths must be supported in the test network topology. There are two issues that could limit SVEET’s capabilities of conducting experiments involving high-throughput network connections. First, high-bandwidth links can transmit more packets per unit of time than slower links, which means more simulation events need to be processed in the network simulator and thus require more execution time. Second, high-capability links may cause more traffic to go through the emulation infrastructure situated between the virtual machines that generate the traffic and the network simulator that carries the traffic. The available bandwidth depends on the underlying network fabric, which could be substantially smaller than the bandwidth used in the test scenarios. In both cases, one must be able to slow down the progression of time both in the network simulator and the virtual machines in order to satisfy the computation and communication demands of the test scenarios. We adopt the time dilation technique developed for Xen by Gupta et al. (2006), which can uniformly slow the passage of time from the perspective of the guest operating system (XenoLinux). Time dilation can scale up the perceived I/O rate as well as the perceived processing power on the virtual machines. In the current SVEET implementation, we set the time dilation factor (TDF), which is the slowdown rate with respect to the wall-clock time, to be the same for all virtual machines and the network simulator at the start of the experiment in accordance with the maximum projected simulation event processing rate and emulation throughput.

Web Server

TCP/IP Stack

tun0 Web Client

Kernel

Reader Thread

PRIME Network Simulator

eth0 OpenVPN Client

VM2

User

OpenVPN Client

Emulation Gateway

Writer Thread

TCP/IP Stack

tun0

eth0

Figure 3: PRIME emulation infrastructure.

down the TCP/IP stack and then given to the OpenVPN client. Upon receiving the packets, the emulation gateway forwards the packets via a dedicated connection to the simulator. The reader thread at the simulator receives the packets from the emulation gateway and then generates simulation events representing the packets being sent from the corresponding end-hosts on the virtual network. PRIME simulates packet forwarding on the virtual network. Upon reaching their destinations, the packets are exported from the simulator and the writer thread sends the packets to the emulation gateway. The OpenVPN server at the emulation gateway subsequently forwards the packets to the corresponding emulated hosts via the VPN connections. The OpenVPN client at the target virtual machine receives the packets and then writes them out to tun0. In this case, applications, such as the web client, will receive these packets as if directly from a physical network. We measured the overhead of the emulation infrastructure through a simple experiment. We set up the Xen machine on a Dell OptiplexTM 745 workstation with an Intel Core 2 Duo 2.4 GHz processor and 2 GB of memory. We created two user domains each containing an emulated host, where we used iperf to set up a TCP connection and generate traffic between the two emulated hosts, and used ping to measure the round-trip times. We set up the simulation gateway and the network simulator on another machine, which is a Dell PowerEdgeTM 1900 configured with an Intel Quad Core 2.0 GHz processor and 8 GB of memory. The two physical machines were connected through a gigabit switch. The network model contains only the two emulated hosts connected through a link with a zero delay and a large bandwidth, so that we could measure the data throughput and latency imposed by the emulation infrastructure and the physical hardware. Fig. 4 shows the distributions of throughput and endto-end delay between the clients. For the throughput experiment, we selected four TCP variants: Scalable TCP, BIC, CUBIC, and TCP Reno. We collected the throughput measurements of 30 trials for each TCP variant and plotted its cumulative distribution. The majority of the measured throughput fell between 40 and 46 Mbps, although TCP Reno seemed to have a larger variance com-

PRIME Emulation Infrastructure

SVEET uses the PRIME emulation infrastructure to capture packets generated by the emulated hosts. The emulation infrastructure forwards the packets to PRIME to be simulated. From the simulator’s point view, these packets seem to have been generated directly by the corresponding end-hosts on the virtual network. The particular emulation infrastructure we used for the experiments is built upon OpenVPN, which has been customized to tunnel traffic between the virtual machines and the network simulator (Liu et al., 2007). Fig. 3 illustrates an example of the emulation infrastructure connecting the PRIME network simulator with two virtual machines. To set up the experiment, the two virtual machines first establish separate VPN connections with the designated VPN server, which we call the emulation gateway. The OpenVPN client on each virtual machine creates a virtual network interface (tun0), which is assigned with the same IP address as that of the corresponding end-host on the virtual network. The forwarding table of each virtual machine is automatically configured to forward traffic destined to the virtual network’s IP space via the VPN connection. In this case, data generated by applications, such as the web server, will be sent to tun0

5

100%

100%

During each experiment, we directed one TCP flow from one end-host to the other and measured the changes in the TCP congestion window size over time. For ns-2 and PRIME, we developed a script to analyze the trace output from the simulators; for SVEET, we used Web100 to keep track of the congestion window size at the virtual machines. Fig. 6 shows the results. The congestion window trajectories from ns-2 and Figure 4: Measured throughput and delay of the emulation PRIME match very well, with only small differences attributed to minor differences between the two simulators infrastructure. in the calculation of transmission time. SVEET produced results similar to those from the simulators; the differences are typically more pronounced at the beginning of the data transfer causing a slight phase shift in the congestion window trajectory onward. One reason for the small difference is the initial RTT, which is slightly different because of the emulation setup. However small, this difference causes VEGAS to behave differently on each trial, as its congesFigure 5: A simple network scenario. tion avoidance mechanism depends very much on the initial RTTs. In Fig. 6, we show 10 separate congestion window pared to others. For the round-trip time, we varied the size trajectories for VEGAS predicted by SVEET and compare of the ICMP packets: 56 bytes (the default), 512 bytes, and them against the results from PRIME and ns-2. In sum1 KB. We collected 100 ping responses for each payload size mary, the results from these tests show conclusively that and plotted its cumulative distribution. The delays ranged SVEET (without time dilation) can accurately represent from 0.6 ms to 0.75 ms in most cases; larger payload re- the behavior of the TCP variants. sulted in larger delays but not by a large margin. From the results, we can conclude that the emulation infrastructure is able to sustain close to 40 Mbps throughput and 4.2 Throughput versus Packet Loss introduce only sub-millisecond delays. We use the second set of experiments to study the accuracy of using the time dilation technique in SVEET for evaluating TCP performance. In these experiments, we used 4 TESTBED VALIDATION the same network scenario as in the previous experiments, but applied random packet drops according to a specified In this section we describe in detail the three sets of ex- probability. We varied the packet drop probability between periments we use to evaluate the SVEET testbed. 10−6 and 10−1 , and measured the aggregate throughput of downloading a large data file over TCP. Each of the experiments lasted for 100 seconds. Fig. 7 shows the results 4.1 TCP Congestion Window Trajectories from PRIME and SVEET for three TCP variants: TCP Our first set of experiments aim to provide the baseline Reno, CUBIC, and Scalable TCP, which were selected for comparison without using time dilation between PRIME their drastically different congestion control behaviors. In (pure simulation), ns-2 (whose TCP implementation has all cases, SVEET without time dilation (i.e., TDF being 1) already been validated using a Dummynet testbed by Wei produced very similar results to those from the simulation. and Cao, 2006), and SVEET (including PRIME, the timeIn separate experiments, we increased the bandwidth of dilated Xen VMs, and the OpenVPN emulation infrastruc- the bottleneck link from 10 Mbps to 100 Mbps, adjusted ture). We use a simple network with two end-hosts con- the NIC’s buffer size from 66 KB to 298 KB, changed the nected by two routers. The network is shown in Fig. 5, experiment time to 500 seconds, and collected results for 15 and is similar to the one used in the previous study (Wei independent trials. In Fig. 8, we show the average throughand Cao, 2006). The connection between the two routers put (with 95% confidence intervals) from PRIME, from forms a bottleneck link, configured with 10 Mbps band- SVEET with TDF of 10 (i.e., with a slowdown factor of width and 64 ms delay. The network interfaces at both 10), and from SVEET with TDF of 1. The results from ends of the bottleneck link each has a drop-tail queue with SVEET with TDF of 10 and PRIME are mostly indistina buffer size of 66 KB. The links connecting the routers guishable, indicating that SVEET (with time dilation) corand the end-hosts all have 1 Gbps bandwidth and zero rectly models TCP behavior. In comparison, SVEET with delay. For SVEET, both end-hosts were emulated in sep- TDF of 1 achieved significantly lower throughput, particarate Xen domains located on the same physical machine; ularly prominent in areas where emulated traffic exceeded PRIME and the simulation gateway were run on separate the maximum capacity supported by the underlying emulation infrastructure. machines connected through a gigabit switch. Scalable TCP TCP BIC TCP CUBIC TCP Reno

90%

90% 80%

Cumulative Fraction

Cumulative Fraction

80% 70% 60% 50% 40% 30%

70% 60% 50% 40% 30%

20%

20%

10%

10%

0%

0%

34

36

38

40 42 44 46 Throughput (Mb/s)

48

50

52

56 bytes 512 bytes 1K bytes

0.6

0.65

0.7 0.75 0.8 Round-Trip Time (ms)

0.85

0.9

6

SCALABLE

BIC

100

50 ns-2 PRIME SVEET 0

10

20

30 40 Time (seconds)

200

150

100

50 ns-2 PRIME SVEET

0

50

60

0

10

20

HTCP

50

100

50 ns-2 PRIME SVEET

0 10

20

0

30

40

150

100

50 ns-2 PRIME SVEET

50

60

0

10

20

30

40

50

50 ns-2 PRIME SVEET

0 30

40

0

10

20

100

50 ns-2 PRIME SVEET 0

10

20

YEAH

30

40

50

60

ns-2 PRIME SVEET (10 trials) 0

10

20

0 30 40 Time (seconds)

50

40

50

60

VENO 200

200

150

100

50

ns-2 PRIME SVEET

0 60

30 Time (seconds)

Congestion Window Size (packets)

Congestion Window Size (packets)

ns-2 PRIME SVEET

60

50

ILLINOIS

50

50

100

0

250

100

40

150

Time (seconds)

150

30

VEGAS

150

60

200

20

ns-2 PRIME SVEET

200

Time (seconds)

10

50

Time (seconds)

0

50

60

100

60

Congestion Window Size (packets)

Congestion Window Size (packets)

100

50

150

HIGHSPEED

150

30 40 Time (seconds)

0

200

0

20

Time (seconds)

RENO

20

10

HYBLA

0

200

10

ns-2 PRIME SVEET

200

Time (seconds)

0

50

60

Congestion Window Size (packets)

150

0

100

0

200 Congestion Window Size (packets)

Congestion Window Size (packets)

30 40 Time (seconds)

150

WESTWOOD

200

Congestion Window Size (packets)

Congestion Window Size (packets)

150

0

Congestion Window Size (packets)

CUBIC

200 Congestion Window Size (packets)

Congestion Window Size (packets)

200

0

10

20

30 40 Time (seconds)

50

150

100

50 ns-2 PRIME SVEET

0 60

0

10

20

30 40 Time (seconds)

50

60

Figure 6: Congestion window trajectories of Linux TCP variants.

RENO

CUBIC 1e+08

1e+07

1e+06

SCALABLE 1e+08

PRIME SVEET (TDF=1)

1e+07

Throughput

PRIME SVEET (TDF=1)

Throughput

Throughput

1e+08

1e+06

100000 1e-06

1e-05

0.0001 0.001 Drop Probability

0.01

0.1

100000 1e-06

PRIME SVEET (TDF=1)

1e+07

1e+06

1e-05

0.0001 0.001 Drop Probability

0.01

0.1

100000 1e-06

1e-05

0.0001 0.001 Drop Probability

Figure 7: Throughput achieved under random packet loss (10 Mbps bottleneck link bandwidth).

7

0.01

0.1

RENO

CUBIC 1e+08

1e+07

1e+06

SCALABLE 1e+08

PRIME SVEET (TDF=10) SVEET (TDF=1)

1e+07

Throughput

PRIME SVEET (TDF=10) SVEET (TDF=1)

Throughput

Throughput

1e+08

1e+06

100000 1e-06

1e-05

0.0001 0.001 Drop Probability

0.01

1e+07

1e+06

100000 1e-06

0.1

PRIME SVEET (TDF=10) SVEET (TDF=1)

1e-05

0.0001 0.001 Drop Probability

0.01

100000 1e-06

0.1

1e-05

0.0001 0.001 Drop Probability

0.01

0.1

Figure 8: Throughput achieved under random packet loss (100 Mbps bottleneck link bandwidth). RENO

CUBIC 1400

1200 1000 800 600 400 200 0

SCALABLE 1400

SVEET TCP flow 1 PRIME TCP flow 1 SVEET TCP flow 2 PRIME TCP flow 2

1200

Congestion Window Size (packets)

SVEET TCP flow 1 PRIME TCP flow 1 SVEET TCP flow 2 PRIME TCP flow 2

Congestion Window Size (packets)

Congestion Window Size (packets)

1400

1000 800 600 400 200 0

0

20

40

60

80

100

120

Time (seconds)

140

160

SVEET TCP flow 1 PRIME TCP flow 1 SVEET TCP flow 2 PRIME TCP flow 2

1200 1000 800 600 400 200 0

0

20

40

60

80

100

120

140

160

0

20

Time (seconds)

40

60

80

100

120

140

160

Time (seconds)

Figure 9: Congestion window sizes of two competing TCP flows. 4.3

5

Intra-Protocol Fairness

EVALUATION OF SVEET CAPACITY

In this section we evaluate SVEET’s ability to deal with real traffic when running on a single physical machine. We chose the simple dumbbell network topology with a oneto-one mapping between the servers on the left side of the dumbbell and the clients on the right side. The servers and clients were either simulated or emulated. We fixed the ratio of emulated server-client pairs to simulated pairs to be 1:20. The clients and servers were connected through two routers in the middle that were both simulated. In this case, the emulated and simulated traffic was multiplexed at the bottleneck link. We designated each emulated server to send a file to the corresponding emulated client using iperf. Likewise, we set each simulated server to transmit a file to the corresponding simulated client via FTP. We varied the number of servers and clients for different traffic demands. We recorded the traffic intensity supported by the emulation infrastructure while the system were still able to produce accurate results. The experiments were conducted on a Dell OptiplexTM 745 workstation with Intel Core 2 Duo 2.4 GHz processors and 2 GB of memory. The dumbbell network was designed in such a way that the maximum achievable traffic through the bottleneck link would be limited solely by the emulation infrastructure (which was achieved by setting a large bandwidth for the bottleneck link). More specifically, we set the latency and the bandwidth of the bottleneck link delay to be 50 ms and 1 Gbps. The branch links (between each router and the end hosts attached to the router) were set to be 1 ms and 1 Gbps. We set the TCP maximum congestion window size

The third set of experiments examine fairness between TCP flows using the same TCP variant to further establish the accuracy of SVEET under time dilation. We created a dumbbell topology similar to the one used in a recent TCP performance study by Li et al. (2007). Another pair of end-hosts were added and attached separately to the two routers in our simple network model used in the previous experiments. We set the bandwidth of the bottleneck link to be 100 Mbps and the delay to be 50 ms. At the start of each run, we selected one end-host on the left to send data over TCP to one end-host on the right. After 50 seconds, the other end-host on the left established a second TCP session to the other end-host on the right. In SVEET, all end-hosts were emulated and the TDFs of the virtual machines and the simulator were both set to be 10. We measured the changes of the congestion window size over time at the senders.

Fig. 9 compares the results, again for TCP Reno, CUBIC, and Scalable TCP. In all cases, the emulation results match well with simulation. The slow convergence of Scalable TCP indicates that this protocol does not score well in intra-protocol fairness. This is mainly due to its aggressive congestion control mechanism, which is based on an multiplicative-increase and multiplicative-decrease (MIMD) algorithm.

8

9e+08

TDF=10 TDF=5 TDF=1

Aggregate throughput (bps)

8e+08 7e+08 6e+08 5e+08 4e+08 3e+08 2e+08 1e+08

Figure 12: Single bottleneck topology.

0 0

100

200 300 400 500 600 Number of simulated nodes

700

800

and Kohler (2003) have been strongly advocating the use of better models for network research, including background traffic models, through careful examination of unrealistic assumptions in modeling and simulation studies. Ha et al. (2007) conducted a systematic study of high-speed TCP protocols and demonstrated conclusively that the stability, fairness, and convergence speed of several TCP variants are clearly affected by the intensity and variability of background traffic. Recently, Vishwanath and Vahdat (2008) investigated the impact of background traffic on distributed systems. They concluded that even small differences in the burstiness of background traffic can lead to drastic changes in the overall application behavior. In this section, we describe a set of case studies we performed to assess the global effect of background traffic generated by the TCP variants on real applications.

Figure 10: Aggregate throughput.

Per-flow throughput (bps)

2.5e+06

2e+06

1.5e+06

1e+06

500000 TDF=10 TDF=5 TDF=1

0 0

100

200

300

400

500

600

700

800

Number of simulated nodes

Figure 11: Average per-flow throughput. to be 30 packets and the TCP maximum segment size to be 960 bytes. Figures 10 and 11 depict the aggregate and per-flow throughput on the bottleneck link as a function of the number of simulated nodes. We performed 10 runs for each configuration and plotted the throughput with 95% confidence intervals resultant from 100 seconds of experimentation. As the traffic demand increased, the aggregate throughput increased linearly up to a certain limit. Beyond that limit, the emulation infrastructure could no longer sustain the traffic demand; TCP was scaled back leading to a reduced throughput. Fig. 10 clearly shows the achievable limits when run on a single machine with different TDFs. Fig. 11 shows that the average throughput per flows remained constant before degrading progressively as the traffic increased. We observe that the variance of the throughput measurement was more pronounced when the maximum throughput was achieved. Also, we observe that, although the throughput increased with higher TDFs, it was not linear. The maximum aggregate throughput was approximately 160, 480, and 670 Mbps, corresponding to TDFs of 1, 5, and 10. In fact, as we increased TDF, a smaller gain was obtained in terms of the achievable throughput.

6.1

Single Bottleneck

The experiments described in this section again used the dumbbell topology (as shown in Fig. 12). Emulated traffic from real applications using a particular TCP variant was the subject of this study. Emulated traffic competes for bandwidth with simulated background traffic, which was generated by 100 simulated nodes using the same TCP variant as the emulated traffic from real applications. A systematic study of the impact of background traffic on the performance of real applications, conducted by Vishwanath and Vahdat (2008), was used as our guideline to configure the background traffic. Their study suggests that simple traffic models, such as constant bit rate (CBR) and Poisson arrival, cannot capture the complexity of real Internet traffic. Background traffic should be bidirectional and a good background traffic model is needed to capture traffic burstiness in a range of time scales. To represent the aggregate traffic behavior, we decided to use the Poisson Pareto Burst Process (PPBP), described by Zukerman et al. (2003). PPBP is a process based on multiple overlapping bursts with Poisson arrivals and burst lengths following a heavy-tail distribution. The major parameters of PPBP include the mean arrival rate (µ), the mean session duration (d), and the Hurst parameter (H). For self-similar traffic that exhibits long6 CASE STUDIES range dependencies (LRD), 0.5 < H < 1. We configured the background traffic corresponding to a light traffic load Background traffic is known to have a significant impact on scenario (with µ = 1) and a heavy traffic load scenario the behavior of network applications and protocols. Floyd (with µ = 100). We set H = 0.8 and d = 1 second.

9

1

net 0

net 1

0.8

Apache web server

CDF

0.6

0.4

0.2

0 1e-06

CUBIC RENO SCALABLE 1e-05

0.0001

0.001 0.01 Jitter (sec)

0.1

net 3

1

LAN with 42 hosts

net 2

Figure 14: Jitter from video streaming. httperf 1 0.9

Figure 16: A campus network model.

0.8 0.7 CDF

0.6

distributing a large data file. We used SVEET to evaluate the performance of BitTorrent. The test scenario consisted of one tracker and one seed, both running on the same emulated machine, and three peers, each on a different emulated host located on either side of the dumbbell. The peer-to-peer network was used to distribute a data file of 20 MB in size. We considered only the heavy traffic load condition for this experiment. The results, as shown in Fig. 15, clearly indicate that CUBIC outperforms Reno and Scalable TCP.

0.5 0.4 0.3 0.2 CUBIC RENO SCALABLE

0.1 0 1

10

100

1000

Response Time (sec)

Figure 15: BitTorrent download time.

We placed the servers on either side of the dumbbell topology shown in Fig. 12 to create the bidirectional background traffic. For foreground traffic, we selected three applications: web downloading, multimedia streaming, and peer-to-peer applications. For web downloading, we used httperf to measure the response time of downloading web objects of different size across the bottleneck link from the Apache server, subject to both light and heavy background traffic conditions. We varied the size of the web objects to be 10 KB, 100 KB, and 1 MB. Fig. 13 depicts the empirical cumulative distribution function of the response time, defined as the time between the client’s sending the request and finally receiving the entire object. We ran 30 independent trials for each TCP variant. The results show that, although the response time for small objects is almost indistinguishable among the TCP variants, with larger object sizes, certain TCP variants perform better than others. For multimedia streaming, we measured jitter—the difference in transit time between successive packets—as an indication of the perceived quality of a video stream. We used VLC from VideoLAN as the client playing an MPEG4 movie streamed from an Apache server over the dumbbell network. To compute jitter, we captured packets at both server and client sides. We computed jitter from 100 seconds of video streaming for 15 independent trials for each TCP variant. Fig. 14 depicts the empirical cumulative distribution of jitter. CUBIC exhibits the best performance among the three TCP variants. For peer-to-peer applications, we measured the time for

10

6.2

Synthetic Topology

In order to show SVEET’s capability of dealing with larger and more complex network scenarios, we conducted another experiment using a synthetic network topology, called the campus network. The network, consisting of 508 end-hosts and 30 routers, is a scaled-down version of the baseline network model that has been used for large-scale simulation studies. The network is shown in Fig. 16. It contains four subnets; within net2 and net3, there are 12 local area networks (LANs), each configured with a gateway router and 42 end-hosts. The LANs are 10 Mbps networks. For links connecting routers within net1 and net2, we set the bandwidth to be 100 Mbps and the link delay to be 10 ms. For other links connecting the routers, we set the bandwidth to be 1 Gbps and the link delay to be 10 ms. In this experiment, each end-host acted as an on-off traffic source: the node stayed idle for a period of time, which is exponentially distributed with a mean of one second, before sending data using TCP to a randomly selected end-host in net1 for a duration, sampled from a Pareto distribution with the mean of one second. We enabled time dilation and set TDF=10 for both simulation and the virtual machines. We placed an Apache web server at one of the emulated end-host in net1 and selected another end-host in net2 as an emulated host running httperf to fetch objects from the web server. We used the same TCP variants for both simulated background traffic and emulated foreground web

Object Size=10k

Object Size=100k 1

0.9

0.9

0.9

0.8

0.8

0.8

0.7

0.7

0.6

0.6

CDF

CDF

0.6 0.5

CDF

1

0.7

0.5 0.4

0.4

0.1 0.2

0.22

0.24 0.26 0.28 Response Time (sec)

0.3

0.2

CUBIC SCALABLE RENO

0.2

0 0.73

0.32

0.2

CUBIC SCALABLE RENO

0.1

0.3

0.5 0.4

0.3

0.3

0.735

Object Size=10k

0.74 0.745 Response Time (sec)

0

0.75

0.755

4.9

0.9

0.9

0.8

0.8

0.8

0.7

0.7

0.7

0.6

0.6

0.6

0.5

0.5

0.4

0.4

0.3

0.3

0.4

0.6

0.8 1 1.2 Response Time (sec)

1.4

0 1.8

5

5.02

5.04

0.5

0.3 0.2

CUBIC SCALABLE RENO

0.1 1.6

4.96 4.98 Response Time (sec)

0.4

0.2

CUBIC SCALABLE RENO 0.2

CDF

0.9

0

4.94

Object Size=1000k 1

0.1

4.92

Object Size=100k 1

0.2

CUBIC SCALABLE RENO

0.1

1

CDF

CDF

Object Size=1000k

1

0.5

1

1.5

2 2.5 3 Response Time (sec)

3.5

CUBIC SCALABLE RENO

0.1 0 4

4.5

6

8

10

12 14 16 Response Time (sec)

18

20

22

Figure 13: Response time under light (top figures) and heavy (bottom figures) traffic conditions. new techniques to reduce the overhead of the emulation infrastructure. For example, we are currently investigating more efficient inter-VM communication schemes to facilitate high-performance and scalable interaction between the simulator and a large number of virtual machines running network-intensive applications. We would also like to improve the interoperability between the simulated TCP variants and those implemented on the virtual machines, so that real applications can directly communicate with simulated entities over TCP. In the future, we expect SVEET to be a highly flexible and highly efficient testbed with builtin capabilities to generate and run standardized TCP tests with minimal human intervention.

traffic. We measured the time to download objects of 10 KB, 100 KB, and 1 MB in size. We collected measurements of 30 independent trials. Fig. 17 shows the empirical cumulative distributions of the response time. Results show that different TCP variants produced drastically different results. TCP Reno achieved the best response time among the three TCP variants. We speculate this is due to the protocol’s better performance in terms of intra-protocol fairness; in this case, the foreground traffic could retain a larger share of the link bandwidths for downloading the objects. Surprisingly, SCALABLE seemed to perform better than CUBIC. The results suggest that we need to further investigate the details of the background traffic used in this experiment, as well as its impact on the link utilization. Here we only use this example to show that SVEET can now enable us to begin studying large-scale TCP behaviors in fairly complex network settings.

7

REFERENCES

Lachlan Andrew, Cesar Marcondes, Sally Floyd, Lawrence Dunn, Romeric Guillier, Wang Gang, Lars Eggert, Sangtae Ha, and Injong Rhee. Towards a common TCP evauation suite. In Proceedings of International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), 2008.

CONCLUSIONS

SVEET is a scalable, flexible, and accurate testbed for evaluating real TCP implementations in diverse network scenarios. We accomplish our goal through real-time simulation, emulation, machine and time virtualization tech- Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and niques. The testbed’s accuracy is tested extensively by Andrew Warfield. Xen and the art of virtualization. In comparing the performance of the TCP variants in terms Proceedings of the 19th ACM Symposium on Operating of congestion window trajectory, throughput, and response Systems Principles (SOSP’03), 2003. function against what has been projected by pure simulation. Results confirm that SVEET can capture the ex- Andy Bavier, Nick Feamster, Mark Huang, Larry Peterson, pected TCP behavior. and Jennifer Rexford. In VINI veritas: realistic and conIn the near future, we plan to test the TCP perfortrolled network experimentation. In SIGCOMM, pages mance using more realistic network topologies and traf3–14, 2006. fic in much larger network. We will also investigate and implement adaptive TDF schemes as a way to minimize re- Craig Bergstrom, Srinidhi Varadarajan, and Godmar source under-utilization. Additionally, we will investigate Back. The distributed open network emulator: Us-

11

90%

90% 80% Cumulative Fraction

80% Cumulative Fraction

Object Size = 100 KB 100%

SCALABLE CUBIC RENO

70% 60% 50% 40% 30%

Object Size = 1 MB 100%

SCALABLE CUBIC RENO

90% 80% Cumulative Fraction

Object Size = 10 KB 100%

70% 60% 50% 40% 30%

70% 60% 50% 40% 30%

20%

20%

20%

10%

10%

10%

0% 350

400

450 500 550 600 650 700 Response Time Per Download (msecs)

750

0% 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 Response Time Per Download (msecs)

SCALABLE CUBIC RENO

0% 10000 10500 11000 11500 12000 12500 13000 13500 14000 Response Time Per Download (msecs)

Figure 17: Response time under synthetic network model. ing relativistic time for distributed scalable simulation. Diwaker Gupta, Kenneth Yocum, Marvin McNett, Alex In Proceedings of the 20th Workshop on Principles of Snoeren, Amin Vahdat, and Geoffrey Voelker. To infinity and beyond: time-warped network emulation. In ProAdvanced and Distributed Simulation (PADS’06), pages ceedings of the 3rd USENIX Symposium on Networked 19–28, 2006. Systems Design and Implementation (NSDI’06), 2006. Sapan Bhatia, Murtaza Motiwala, Wolfgang Muhlbauer, Vytautas Valancius, Andy Bavier, Nick Feamster, Larry Sangtae Ha, Yusung Kim, Long Le, Injong Rhee, and Lisong Xu. A step toward realistic performance evaluaPeterson, and Jennifer Rexford. Hosting virtual nettion of high-speed TCP variants. In Proceedings of Interworks on commodity hardware. Technical Report GTnational Workshop on Protocols for Fast Long-Distance CS-07-10, Georgia Tech, 2008. Networks (PFLDnet), 2006. Lee Breslau, Deborah Estrin, Kevin Fall, Sally Floyd, John Sangtae Ha, Long Le, Injong Rhee, and Lisong Xu. Impact Heidemann, Ahmed Helmy, Polly Huang, Steven Mcof background traffic on performance of high-speed TCP Canne, Kannan Varadhan, Ya Xu, and Haobo Yu. Advariant protocols. Computer Networks, 51(7):1748–1762, vances in network simulation. IEEE Computer, 33(5): 2007. 59–67, 2000. Tom Kelly. Scalable TCP: improving performance on highspeed wide area networks. ACM SIGCOMM Computer Carlo Caini, Rosario Firrincieli, Renzo Davoli, and Daniele Communication Review, 2003. Lacamera. Virtual integrated TCP testbed (VITT). In Proceedings of the 4th International Conference Douglas Leith and Robert Shorten. H-TCP protocol for on Testbeds and Research Infrastructures for the Dehigh-speed long distance networks. In Proceedings of velopment of Networks & Communities (TRIDENTInternational Workshop on Protocols for Fast LongCOM’08), pages 1–6, 2008. Distance Networks (PFLDnet), 2004. Yee-Ting Li, Douglas Leith, and Robert N. Shorten. Experimental evaluation of TCP protocols for high-speed networks. IEEE/ACM Transactions on Networking, 15 (5):1109–1122, 2007.

James Cowie, David Nicol, and Andy Ogielski. Modeling the global Internet. Computing in Science and Engineering, 1(1):42–50, January 1999.

Jeff Dike. A user-mode port of the Linux kernel. In Proceedings of the 4th Annual Linux Showcase & Confer- Linux VServer. http://linux-vserver.org/, 2009. ence, 2000. Jason Liu. The PRIME research, 2009. http://www.cis. fiu.edu/prime/. Sally Floyd and Eddie Kohler. Internet research needs better models. Computer Communication Review, 33 Jason Liu. A primer for real-time simulation of large-scale networks. In Proceedings of the 41st Annual Simulation (1):29–34, 2003. Symposium (ANSS), pages 85–94, 2008. Richard M. Fujimoto. Parallel discrete event simulation. Jason Liu, Scott Mann, Nathanael Van Vorst, and Keith Communications of the ACM, 33(10):30–53, October Hellman. An open and scalable emulation infrastruc1990. ture for large-scale real-time network simulations. In Proceedings of IEEE INFOCOM MiniSymposium, pages Andreas Grau, Steffen Maier, Klaus Herrmann, and Kurt 2476–2480, 2007. Rothermel. Time jails: A hybrid approach to scalable network emulation. In Proceedings of the 22nd Workshop M. Mathis, J. Heffner, and R. Reddy. Web100: Extended TCP instrumentation for research, education and diagon Principles of Advanced and Distributed Simulation nosis. ACM Comput. Commun., 33(3):69–79, 2003. (PADS’08), pages 7–14, 2008.

12

Design and Implementation (OSDI’02), pages 255–270, 2002.

OpenVZ. http://openvz.org/, 2009.

Larry Peterson, Tom Anderson, David Culler, and Timothy Roscoe. A blueprint for introducing disruptive tech- Lisong Xu, K. Harfoush, and Injong Rhee. Binary increase congestion control (BIC) for fast long-distance networks. nology into the Internet. In Proceedings of the 1st WorkIn Proceedings of IEEE INFOCOM, volume 4, pages shop on Hot Topics in Networking (HotNets-I), 2002. 2514–2524, 2004. Injong Rhee and Lisong Xu. CUBIC: A new TCP-friendly high-speed TCP variant. In Proceedings of International Moshe Zukerman, Timothy D. Neame, and Ronald G. Addie. Internet traffic modeling and future technology imWorkshop on Protocols for Fast Long-Distance Networks plications. INFOCOM, 2003. (PFLDnet), 2005. George F. Riley. The Georgia Tech network simulator. In Proceedings of the ACM SIGCOMM Workshop on Models, Methods and Tools for Reproducible Network Research (MoMeTools’03), pages 5–12, 2003. Luigi Rizzo. Dummynet: a simple approach to the evaulation of network protocols. ACM SIGCOMM Computer Communication Review, 27(1):31–41, 1997. Hideyuki Shimonishi, Medy Sanadidi, and Tutomu Murase. Assessing interactions among legacy and highspeed TCP protocols. In Proceedings of International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), pages 91–96, 2007. Amin Vahdat, Ken Yocum, Kevin Walsh, Priya Mahadevan, Dejan Kostic, Jeff Chase, and David Becker. Scalability and accuracy in a large scale network emulator. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI’02), pages 271–284, 2002. Kashi Venkatesh Vishwanath and Amin Vahdat. Evaluating distributed systems: Does background traffic matter? In Proceedings of the 2008 USENIX Technical Conference, pages 227–240, 2008. VMWare, Inc. VMWare Workstation. http://www. vmware.com/products/desktop/workstation.html, 2009. David X. Wei and Pei Cao. NS-2 TCP-Linux: An NS-2 TCP implementation with congestion control algorithms from Linux. In Proceedings of the 2nd International Workshop on NS-2 (WNS2), 2006. David X. Wei, Pei Cao, and Steven H. Low. Time for a TCP benchmark suite? Technical report, CalTech, 2005. David X. Wei, Cheng Jin, Steven H. Low, and Sanjay Hegde. FAST TCP: motivation, architecture, algorithms, performance. IEEE/ACM Transactions on Networking, 14(6):1246–1259, 2006. Brian White, Jay Lepreau, Leigh Stoller, Robert Ricci, Shashi Guruprasad, Mac Newbold, Mike Hibler, Chad Barb, and Abhijeet Joglekar. An integrated experimental environment for distributed systems and networks. In Proceedings of the 5th Symposium on Operating Systems

13