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 con-gestion 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 im-plementations of TCP variants can be accurately evaluated under diverse network con-figurations 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 exper-iments. 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 limi-tations. 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
Engi-neering 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 Sci-ences, Florida International University. His research focuses on parallel discrete-event simulation, high-performance modeling and simulation of computer systems and net-works. 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
Although TCP has contributed to the tremendous success of the Internet, it has been widely documented that the tra-ditional TCP congestion control algorithms (such as TCP Reno and TCP SACK) have serious problems preventing
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), Scal-able TCP (Kelly, 2003), FAST (Wei et al., 2006), BIC (Xu
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 be-yond small-scale experimentation. This problem is exac-erbated by the lack of standard performance metrics and convincing network scenarios to benchmark the existing al-gorithms. More recently, several test suites have been de-veloped 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 sim-plified network scenarios. The community urgently needs a standard evaluation environment for an objective com-parison of the TCP variants under a wide spectrum of net-working 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 tar-get system on which the protocols are deployed. These testbeds, however, do not provide the level of reproducibil-ity, controllabilreproducibil-ity, and flexibility necessary for testing and benchmarking the TCP variants under diverse network conditions. In contrast, network simulators, such as ns-2 (Breslau et al., ns-2000), SSFNet (Cowie et al., 1999), and GTNetS (Riley, 2003), offer complete control over the test-ing environment. In simulation, the network topologies and workloads are easy to configure, and events can be readily generated to test the protocols under various cir-cumstances. Nevertheless, simulation lacks realism. In addition, protocols are not easily implemented in simula-tion without significant effort; above all, simulasimula-tion mod-els must be subjected to rigorous verification and valida-tion tests. Alternatively, emulavalida-tion testbeds, such as Em-uLab (White et al., 2002) and ModelNet (Vahdat et al., 2002), allow flexible network experiments that directly in-volve real protocol implementations. However, the cost of setting up a large-scale network emulation environment for testing and benchmarking the TCP variants can be sub-stantially higher than that of simulation.
Our goal is to provide researchers with a flexible, easy-to-use, and easy-to-maintain testbed where real imple-mentations of the TCP variants can be accurately eval-uated 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
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 simu-lation 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 de-lays and losses according to simulated conditions of the virtual network. Our approach combines the advantages of both simulation and emulation: we can achieve high-level controllability, repeatability, and flexibility from sim-ulation, as well as the capabilities to execute real protocols and applications from emulation.
To enable network experiments with large traffic vol-ume, we apply the time dilation technique on virtual ma-chines (Gupta et al., 2006). Time dilation can change a virtual machine’s notion of how time progresses: in a time-dilated 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, al-beit 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 net-works (Liu, 2009). PRIME provides a scalable emulation infrastructure that allows automatic and seamless inter-actions between multiple virtual machines and the sim-ulator (Liu et al., 2007). We ported several TCP gestion control algorithms from the ns-2 simulator con-sisting 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 Sec-tion 2, we review related work. SecSec-tion 3 describes the de-tails about the design and implementation of SVEET. We conducted extensive experiments to validate our testbed; the results are shown in Section 4. The capacity limita-tions of our platform running in a single box are explored in Section 5. Section 6 provides some interesting case stud-ies enabled by our testbed involving web, streaming, and P2P traffic. Finally, we conclude this paper and outline our future work in Section 7.
2 RELATED WORK
There have been significant efforts in the performance eval-uation of different TCP congestion control algorithms. Li
et al. (2007) presented experimental results of several ma-jor 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 real-istic 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 back-ground traffic.
There has been a genuine push since the beginning from the research community for a standard evaluation environ-ment for prototyping, testing, and benchmarking TCP al-gorithms. For example, Wei et al. (2005) proposed a bench-mark 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 ac-curate, scalable, and flexible testbed to evaluate TCP vari-ants with realistic network configurations and workloads.
Most of the aforementioned studies were based on ei-ther simulation or emulation, but not both. For exam-ple, 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. Emu-Lab (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 environ-ment that supports large-scale network experienviron-ments. Mod-elNet 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 appli-cations, while SVEET focuses on TCP performance evalu-ation 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 acces-sibility 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 virtualiza-tion, such as VMWare Workstation (VMWare, Inc., 2009) and User-Mode Linux (Dike, 2000), to light-weight
ma-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) de-signed and developed a virtual integrated TCP testbed called VITT. The main idea is to exploit advanced virtu-alization technologies to realize real network components within a single physical machine in order to support high-fidelity TCP performance evaluation with high-level tim-ing 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). How-ever, 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) pro-posed a low-overhead conservative synchronization mech-anism to regulate time dilation across virtual machines. All methods above have been applied only to network em-ulation; SVEET needs to coordinate time dilation across the entire system, including both virtual machines and the network simulator.
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. Re-producibility 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 net-working 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, choreo-graphic 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
im-plementations 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 in-clude costly procedures for verification and validation. Fig. 1 provides a schematic view of the SVEET archi-tecture. Distributed applications are executed directly on
PRIME Emulation Infrastructure
PRIME Network Simulator
Applications TCP/IP Stack Virtual NICs VM1 Applications TCP/IP Stack Virtual NICs VM2
Figure 1: The SVEET architecture.
end-hosts configured as separate virtual machines (e.g., VM1and VM2) with their own network stacks implemented
with the TCP variants under investigation. We call these end-hosts emulated hosts. Traffic generated by the appli-cations on these emulated hosts is captured by the vir-tual network interfaces (NICs), which forward the packets to the PRIME network simulator via the emulation in-frastructure provided by PRIME. Once inside the network simulator these packets are represented simply as simula-tion events. PRIME simulates packet forwarding accord-ing 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 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 Scal-able Simulation Framework (SSF), which provides a stan-dard programming interface for parallel large-scale simula-tion (Cowie et al., 1999). PRIME can run on most paral-lel 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 al-lows 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 applica-tions (e.g., running on virtual machines) is captured and forwarded automatically to PRIME so that it can be “car-ried” on the virtual network. Note that, in the case of real-time 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 simula-tion cannot keep up with real time.
ProtocolSession PRIME LinuxTcpMaster LinuxTcpAgent SinkTcpAgent LinuxTcpSimpleSocket ns-linux-util BIC CUBIC H-TCP STCP FAST HS-TCP
HYBLA NewReno Vegas Westwood Veno
TCP-LP C-TCP 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 cre-ated a protocol session, LinuxTcpMaster, to manage all ac-tive Linux TCP connections, and another protocol session, LinuxTcpSimpleSocket, to support a simple interface for applications to send or receive data over Linux TCP. Con-sequently, both are derived from the ProtocolSession class. A TCP connection was structured in the same fash-ion 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.
3.2 Xen Virtual Machines
We chose Xen (Barham et al., 2003) for the virtual ma-chines in our implementation. Xen is a high-performance open-source virtual machine solution. On most ma-chines, Xen uses a technique called “para-virtualization” to achieve high performance by modifying the guest oper-ating 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
TCP variables during the experiments.
In order to fully test all TCP congestion control algo-rithms in various environments, plentiful bandwidths must be supported in the test network topology. There are two issues that could limit SVEET’s capabilities of conduct-ing experiments involvconduct-ing high-throughput network con-nections. 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 sim-ulator 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 pas-sage of time from the perspective of the guest operating system (XenoLinux). Time dilation can scale up the per-ceived I/O rate as well as the perper-ceived processing power on the virtual machines. In the current SVEET implemen-tation, 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 simula-tor at the start of the experiment in accordance with the maximum projected simulation event processing rate and emulation throughput.
3.3 PRIME Emulation Infrastructure
SVEET uses the PRIME emulation infrastructure to cap-ture packets generated by the emulated hosts. The emula-tion 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 be-tween the virtual machines and the network simulator (Liu et al., 2007).
Fig. 3 illustrates an example of the emulation infras-tructure 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 emu-lation gateway. The OpenVPN client on each virtual ma-chine creates a virtual network interface (tun0), which is assigned with the same IP address as that of the corre-sponding 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
PRIME Network Simulator Reader Thread Writer Thread Emulation Gateway OpenVPN Client Web Server TCP/IP Stack User Kernel tun0 eth0 VM1 OpenVPN Client Web Client TCP/IP Stack User Kernel tun0 eth0 VM2
Figure 3: PRIME emulation infrastructure.
down the TCP/IP stack and then given to the OpenVPN client. Upon receiving the packets, the emulation gate-way 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 simula-tion 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 em-ulation 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 pack-ets as if directly from a physical network.
We measured the overhead of the emulation infrastruc-ture 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 sim-ulation gateway and the network simulator on another ma-chine, which is a Dell PowerEdgeTM 1900 configured with
an Intel Quad Core 2.0 GHz processor and 8 GB of mem-ory. 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 de-lay 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 end-to-end delay between the clients. For the throughput ex-periment, we selected four TCP variants: Scalable TCP, BIC, CUBIC, and TCP Reno. We collected the through-put 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, al-though TCP Reno seemed to have a larger variance
com-0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 34 36 38 40 42 44 46 48 50 52 Cumulative Fraction Throughput (Mb/s) Scalable TCP TCP BIC TCP CUBIC TCP Reno 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0.6 0.65 0.7 0.75 0.8 0.85 0.9 Cumulative Fraction Round-Trip Time (ms) 56 bytes 512 bytes 1K bytes
Figure 4: Measured throughput and delay of the emulation infrastructure.
Figure 5: A simple network scenario.
pared to others. For the round-trip time, we varied the size of the ICMP packets: 56 bytes (the default), 512 bytes, and 1 KB. We collected 100 ping responses for each payload size and plotted its cumulative distribution. The delays ranged from 0.6 ms to 0.75 ms in most cases; larger payload re-sulted in larger delays but not by a large margin. From the results, we can conclude that the emulation infrastruc-ture is able to sustain close to 40 Mbps throughput and introduce only sub-millisecond delays.
4 TESTBED VALIDATION
In this section we describe in detail the three sets of ex-periments we use to evaluate the SVEET testbed.
4.1 TCP Congestion Window Trajectories
Our first set of experiments aim to provide the baseline comparison without using time dilation between PRIME (pure simulation), ns-2 (whose TCP implementation has already been validated using a Dummynet testbed by Wei and Cao, 2006), and SVEET (including PRIME, the time-dilated Xen VMs, and the OpenVPN emulation infrastruc-ture). We use a simple network with two end-hosts con-nected by two routers. The network is shown in Fig. 5, and is similar to the one used in the previous study (Wei and Cao, 2006). The connection between the two routers forms a bottleneck link, configured with 10 Mbps band-width and 64 ms delay. The network interfaces at both ends of the bottleneck link each has a drop-tail queue with a buffer size of 66 KB. The links connecting the routers and the end-hosts all have 1 Gbps bandwidth and zero delay. For SVEET, both end-hosts were emulated in sep-arate Xen domains located on the same physical machine; PRIME and the simulation gateway were run on separate machines connected through a gigabit switch.
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 out-put 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 PRIME match very well, with only small differences at-tributed to minor differences between the two simulators 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 win-dow 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 conges-tion avoidance mechanism depends very much on the initial RTTs. In Fig. 6, we show 10 separate congestion window trajectories for VEGAS predicted by SVEET and compare them against the results from PRIME and ns-2. In sum-mary, the results from these tests show conclusively that SVEET (without time dilation) can accurately represent the behavior of the TCP variants.
4.2 Throughput versus Packet Loss
We use the second set of experiments to study the accuracy of using the time dilation technique in SVEET for evalu-ating TCP performance. In these experiments, we used the same network scenario as in the previous experiments, but applied random packet drops according to a specified probability. We varied the packet drop probability between 10−6and 10−1, and measured the aggregate throughput of downloading a large data file over TCP. Each of the exper-iments lasted for 100 seconds. Fig. 7 shows the results from PRIME and SVEET for three TCP variants: TCP Reno, CUBIC, and Scalable TCP, which were selected for their drastically different congestion control behaviors. In all cases, SVEET without time dilation (i.e., TDF being 1) produced very similar results to those from the simulation. In separate experiments, we increased the bandwidth of the bottleneck link from 10 Mbps to 100 Mbps, adjusted the NIC’s buffer size from 66 KB to 298 KB, changed the experiment time to 500 seconds, and collected results for 15 independent trials. In Fig. 8, we show the average through-put (with 95% confidence intervals) from PRIME, from SVEET with TDF of 10 (i.e., with a slowdown factor of 10), and from SVEET with TDF of 1. The results from SVEET with TDF of 10 and PRIME are mostly indistin-guishable, indicating that SVEET (with time dilation) cor-rectly models TCP behavior. In comparison, SVEET with TDF of 1 achieved significantly lower throughput, partic-ularly prominent in areas where emulated traffic exceeded the maximum capacity supported by the underlying emu-lation infrastructure.
0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) SCALABLE ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) BIC ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) CUBIC ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) HTCP ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) WESTWOOD ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) HYBLA ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) RENO ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) HIGHSPEED ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) VEGAS ns-2 PRIME SVEET (10 trials) 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) YEAH ns-2 PRIME SVEET 0 50 100 150 200 250 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) ILLINOIS ns-2 PRIME SVEET 0 50 100 150 200 0 10 20 30 40 50 60
Congestion Window Size (packets)
Time (seconds) VENO
ns-2 PRIME SVEET
Figure 6: Congestion window trajectories of Linux TCP variants.
100000 1e+06 1e+07 1e+08 1e-06 1e-05 0.0001 0.001 0.01 0.1 Throughput Drop Probability RENO PRIME SVEET (TDF=1) 100000 1e+06 1e+07 1e+08 1e-06 1e-05 0.0001 0.001 0.01 0.1 Throughput Drop Probability CUBIC PRIME SVEET (TDF=1) 100000 1e+06 1e+07 1e+08 1e-06 1e-05 0.0001 0.001 0.01 0.1 Throughput Drop Probability SCALABLE PRIME SVEET (TDF=1)
100000 1e+06 1e+07 1e+08 1e-06 1e-05 0.0001 0.001 0.01 0.1 Throughput Drop Probability RENO PRIME SVEET (TDF=10) SVEET (TDF=1) 100000 1e+06 1e+07 1e+08 1e-06 1e-05 0.0001 0.001 0.01 0.1 Throughput Drop Probability CUBIC PRIME SVEET (TDF=10) SVEET (TDF=1) 100000 1e+06 1e+07 1e+08 1e-06 1e-05 0.0001 0.001 0.01 0.1 Throughput Drop Probability SCALABLE PRIME SVEET (TDF=10) SVEET (TDF=1)
Figure 8: Throughput achieved under random packet loss (100 Mbps bottleneck link bandwidth).
0 200 400 600 800 1000 1200 1400 0 20 40 60 80 100 120 140 160
Congestion Window Size (packets)
Time (seconds) RENO SVEET TCP flow 1 PRIME TCP flow 1 SVEET TCP flow 2 PRIME TCP flow 2 0 200 400 600 800 1000 1200 1400 0 20 40 60 80 100 120 140 160
Congestion Window Size (packets)
Time (seconds) CUBIC SVEET TCP flow 1 PRIME TCP flow 1 SVEET TCP flow 2 PRIME TCP flow 2 0 200 400 600 800 1000 1200 1400 0 20 40 60 80 100 120 140 160
Congestion Window Size (packets)
Time (seconds) SCALABLE SVEET TCP flow 1 PRIME TCP flow 1 SVEET TCP flow 2 PRIME TCP flow 2
Figure 9: Congestion window sizes of two competing TCP flows.
4.3 Intra-Protocol Fairness
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, CU-BIC, and Scalable TCP. In all cases, the emulation re-sults 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.
5 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 one-to-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
0 1e+08 2e+08 3e+08 4e+08 5e+08 6e+08 7e+08 8e+08 9e+08 0 100 200 300 400 500 600 700 800 Aggregate throughput (bps)
Number of simulated nodes TDF=10
TDF=5 TDF=1
Figure 10: Aggregate throughput.
0 500000 1e+06 1.5e+06 2e+06 2.5e+06 0 100 200 300 400 500 600 700 800 Per-flow throughput (bps)
Number of simulated nodes TDF=10
TDF=5 TDF=1
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 exper-imentation. As the traffic demand increased, the aggre-gate 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 differ-ent 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 CASE STUDIES
Background traffic is known to have a significant impact on the behavior of network applications and protocols. Floyd
Figure 12: Single bottleneck topology.
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 stabil-ity, fairness, and convergence speed of several TCP vari-ants 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 dif-ferences 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 per-formed to assess the global effect of background traffic gen-erated by the TCP variants on real applications.
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 traf-fic 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 Pois-son Pareto Burst Process (PPBP), described by Zukerman et al. (2003). PPBP is a process based on multiple over-lapping bursts with Poisson arrivals and burst lengths fol-lowing 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 long-range dependencies (LRD), 0.5 < H < 1. We configured the background traffic corresponding to a light traffic load scenario (with µ = 1) and a heavy traffic load scenario (with µ = 100). We set H = 0.8 and d = 1 second.
0 0.2 0.4 0.6 0.8 1 1e-06 1e-05 0.0001 0.001 0.01 0.1 1 CDF Jitter (sec) CUBIC RENO SCALABLE
Figure 14: Jitter from video streaming.
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1 10 100 1000 CDF
Response Time (sec) CUBIC
RENO SCALABLE
Figure 15: BitTorrent download time.
We placed the servers on either side of the dumbbell topology shown in Fig. 12 to create the bidirectional back-ground traffic. For foreback-ground traffic, we selected three ap-plications: 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, sub-ject 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 dif-ference 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 MPEG-4 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 sec-onds of video streaming for 15 independent trials for each TCP variant. Fig. 14 depicts the empirical cumulative dis-tribution of jitter. CUBIC exhibits the best performance among the three TCP variants.
For peer-to-peer applications, we measured the time for
LAN with 42 hosts net 2 net 3 net 0 net 1 Apache web server httperf
Figure 16: A campus network model.
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.
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 gate-way 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 en-abled 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
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.2 0.22 0.24 0.26 0.28 0.3 0.32 CDF
Response Time (sec) Object Size=10k CUBIC SCALABLE RENO 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.73 0.735 0.74 0.745 0.75 0.755 CDF
Response Time (sec) Object Size=100k CUBIC SCALABLE RENO 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 4.9 4.92 4.94 4.96 4.98 5 5.02 5.04 CDF
Response Time (sec) Object Size=1000k CUBIC SCALABLE RENO 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 CDF
Response Time (sec) Object Size=10k CUBIC SCALABLE RENO 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.5 1 1.5 2 2.5 3 3.5 4 4.5 CDF
Response Time (sec) Object Size=100k CUBIC SCALABLE RENO 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 6 8 10 12 14 16 18 20 22 CDF
Response Time (sec) Object Size=1000k
CUBIC SCALABLE RENO
Figure 13: Response time under light (top figures) and heavy (bottom figures) traffic conditions.
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 cu-mulative 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 ob-jects. 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 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 sim-ulation, emsim-ulation, machine and time virtualization tech-niques. The testbed’s accuracy is tested extensively by comparing the performance of the TCP variants in terms of congestion window trajectory, throughput, and response function against what has been projected by pure simula-tion. Results confirm that SVEET can capture the ex-pected TCP behavior.
In the near future, we plan to test the TCP perfor-mance using more realistic network topologies and traf-fic in much larger network. We will also investigate and implement adaptive TDF schemes as a way to minimize re-source under-utilization. Additionally, we will investigate
new techniques to reduce the overhead of the emulation in-frastructure. For example, we are currently investigating more efficient inter-VM communication schemes to facil-itate high-performance and scalable interaction between the simulator and a large number of virtual machines run-ning 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 simu-lated entities over TCP. In the future, we expect SVEET to be a highly flexible and highly efficient testbed with built-in capabilities to generate and run standardized TCP tests with minimal human intervention.
REFERENCES
Lachlan Andrew, Cesar Marcondes, Sally Floyd, Lawrence Dunn, Romeric Guillier, Wang Gang, Lars Eggert, Sang-tae Ha, and Injong Rhee. Towards a common TCP evau-ation suite. In Proceedings of Internevau-ational Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), 2008.
Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP’03), 2003.
Andy Bavier, Nick Feamster, Mark Huang, Larry Peterson, and Jennifer Rexford. In VINI veritas: realistic and con-trolled network experimentation. In SIGCOMM, pages 3–14, 2006.
Craig Bergstrom, Srinidhi Varadarajan, and Godmar Back. The distributed open network emulator:
Us-0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 350 400 450 500 550 600 650 700 750 Cumulative Fraction
Response Time Per Download (msecs) Object Size = 10 KB SCALABLE CUBIC RENO 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 Cumulative Fraction
Response Time Per Download (msecs) Object Size = 100 KB SCALABLE CUBIC RENO 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10000 10500 11000 11500 12000 12500 13000 13500 14000 Cumulative Fraction
Response Time Per Download (msecs) Object Size = 1 MB SCALABLE
CUBIC RENO
Figure 17: Response time under synthetic network model.
ing relativistic time for distributed scalable simulation. In Proceedings of the 20th Workshop on Principles of Advanced and Distributed Simulation (PADS’06), pages 19–28, 2006.
Sapan Bhatia, Murtaza Motiwala, Wolfgang Muhlbauer, Vytautas Valancius, Andy Bavier, Nick Feamster, Larry Peterson, and Jennifer Rexford. Hosting virtual net-works on commodity hardware. Technical Report GT-CS-07-10, Georgia Tech, 2008.
Lee Breslau, Deborah Estrin, Kevin Fall, Sally Floyd, John Heidemann, Ahmed Helmy, Polly Huang, Steven Mc-Canne, Kannan Varadhan, Ya Xu, and Haobo Yu. Ad-vances in network simulation. IEEE Computer, 33(5): 59–67, 2000.
Carlo Caini, Rosario Firrincieli, Renzo Davoli, and Daniele Lacamera. Virtual integrated TCP testbed (VITT). In Proceedings of the 4th International Conference on Testbeds and Research Infrastructures for the De-velopment of Networks & Communities (TRIDENT-COM’08), pages 1–6, 2008.
James Cowie, David Nicol, and Andy Ogielski. Modeling the global Internet. Computing in Science and Engineer-ing, 1(1):42–50, January 1999.
Jeff Dike. A user-mode port of the Linux kernel. In Pro-ceedings of the 4th Annual Linux Showcase & Confer-ence, 2000.
Sally Floyd and Eddie Kohler. Internet research needs better models. Computer Communication Review, 33 (1):29–34, 2003.
Richard M. Fujimoto. Parallel discrete event simulation. Communications of the ACM, 33(10):30–53, October 1990.
Andreas Grau, Steffen Maier, Klaus Herrmann, and Kurt Rothermel. Time jails: A hybrid approach to scalable network emulation. In Proceedings of the 22nd Workshop on Principles of Advanced and Distributed Simulation (PADS’08), pages 7–14, 2008.
Diwaker Gupta, Kenneth Yocum, Marvin McNett, Alex Snoeren, Amin Vahdat, and Geoffrey Voelker. To infin-ity and beyond: time-warped network emulation. In Pro-ceedings of the 3rd USENIX Symposium on Networked Systems Design and Implementation (NSDI’06), 2006. Sangtae Ha, Yusung Kim, Long Le, Injong Rhee, and
Lisong Xu. A step toward realistic performance evalua-tion of high-speed TCP variants. In Proceedings of Inter-national Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), 2006.
Sangtae Ha, Long Le, Injong Rhee, and Lisong Xu. Impact of background traffic on performance of high-speed TCP variant protocols. Computer Networks, 51(7):1748–1762, 2007.
Tom Kelly. Scalable TCP: improving performance on high-speed wide area networks. ACM SIGCOMM Computer Communication Review, 2003.
Douglas Leith and Robert Shorten. H-TCP protocol for high-speed long distance networks. In Proceedings of International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), 2004.
Yee-Ting Li, Douglas Leith, and Robert N. Shorten. Ex-perimental evaluation of TCP protocols for high-speed networks. IEEE/ACM Transactions on Networking, 15 (5):1109–1122, 2007.
Linux VServer. http://linux-vserver.org/, 2009. Jason Liu. The PRIME research, 2009. http://www.cis.
fiu.edu/prime/.
Jason Liu. A primer for real-time simulation of large-scale networks. In Proceedings of the 41st Annual Simulation Symposium (ANSS), pages 85–94, 2008.
Jason Liu, Scott Mann, Nathanael Van Vorst, and Keith Hellman. An open and scalable emulation infrastruc-ture for large-scale real-time network simulations. In Proceedings of IEEE INFOCOM MiniSymposium, pages 2476–2480, 2007.
M. Mathis, J. Heffner, and R. Reddy. Web100: Extended TCP instrumentation for research, education and diag-nosis. ACM Comput. Commun., 33(3):69–79, 2003.
OpenVZ. http://openvz.org/, 2009.
Larry Peterson, Tom Anderson, David Culler, and Timo-thy Roscoe. A blueprint for introducing disruptive tech-nology into the Internet. In Proceedings of the 1st Work-shop on Hot Topics in Networking (HotNets-I), 2002. Injong Rhee and Lisong Xu. CUBIC: A new TCP-friendly
high-speed TCP variant. In Proceedings of International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet), 2005.
George F. Riley. The Georgia Tech network simulator. In Proceedings of the ACM SIGCOMM Workshop on Mod-els, Methods and Tools for Reproducible Network Re-search (MoMeTools’03), pages 5–12, 2003.
Luigi Rizzo. Dummynet: a simple approach to the evaula-tion 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 high-speed 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 Mahade-van, Dejan Kostic, Jeff Chase, and David Becker. Scala-bility 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. Evalu-ating distributed systems: Does background traffic mat-ter? In Proceedings of the 2008 USENIX Technical Con-ference, 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, algo-rithms, performance. IEEE/ACM Transactions on Net-working, 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 experimen-tal environment for distributed systems and networks. In Proceedings of the 5th Symposium on Operating Systems
Design and Implementation (OSDI’02), pages 255–270, 2002.
Lisong Xu, K. Harfoush, and Injong Rhee. Binary increase congestion control (BIC) for fast long-distance networks. In Proceedings of IEEE INFOCOM, volume 4, pages 2514–2524, 2004.
Moshe Zukerman, Timothy D. Neame, and Ronald G. Ad-die. Internet traffic modeling and future technology im-plications. INFOCOM, 2003.