Flow-based Partitioning of Network Testbed …Flow-based Partitioning of Network Testbed Experiments...

Computer Networks 00 (2013) 1–20

ProcediaComputerScience

Flow-based Partitioning of Network Testbed Experiments

Wei-Min Yao, Sonia Fahmy

Department of Computer Science, Purdue University, West Lafayette, IN 47907–2107, USA

Abstract

Understanding the behavior of large-scale systems is challenging, but essential when designing new Internet protocols and applica-tions. It is often infeasible or undesirable to conduct experiments directly on the Internet. Thus, simulation, emulation, and testbedexperiments are important techniques for researchers to investigate large-scale systems.

In this paper, we propose a platform-independent mechanismto partition a large network experiment into a set of small exper-iments that aresequentiallyexecuted. Each of the small experiments can be conducted on agiven number of experimental nodes,e.g., the available machines on a testbed. Results from the small experiments approximate the results that would have been obtainedfrom the original large experiment. We model the original experiment using aflow dependency graph. We partition this graph, afterpruning uncongested links, to obtain a set of small experiments. We execute the small experiments iteratively. Starting with thesecond iteration, we model dependent partitions using information gathered about both the trafficand the network conditions dur-ing the previous iteration. Experimental results from several simulation and testbed experiments demonstrate that our techniquesapproximate performance characteristics, even with closed-loop traffic and congested links. We expose the fundamental tradeoffbetween the simplicity of the partitioning and experimentation process, and the loss of experimental fidelity.

c© 2012 Published by Elsevier Ltd.

Keywords: Network simulation, network emulation, network testbeds

1. Introduction

Understanding the behavior of large-scale systems iscritical when designing and validating a new Internetprotocol or application. Consider the example of study-ing the impact of a large-scale Distributed Denial ofService (DDoS) attack utilizing a massive botnet. Theattack against Estonia is a well-publicized example ofthis [1]. It is important to explore defenses against thisattack under realistic scenarios, but it is undesirable toperform security experiments on the operational Inter-net.

Since it is often infeasible to perform experimentsdirectly on the Internet or build analytical models forcomplex systems, researchers often resort to simulation,

emulation, and testbed experiments. Simulators scalethrough abstraction. For example, the popular networksimulator ns-2 [2] uses simplified models for physicallinks, host operating systems, and lower layers of thenetwork protocol stack. Researchers can easily simulatea network topology with hundreds of nodes and linkson a single physical machine. Naturally, the simplifi-cation of hardware and system properties can adverselyimpact the fidelity of experimental results [3]. In con-trast to simulators, network emulators mostly use thereal hardware and software. This allows experimentersto run their unmodified applications. While emulationcan provide higher fidelity, scalability is a challenge.Emulation testbeds such as Emulab [4] and the popularcyber-range DETER [5] include a limited set of physicalmachines that are shared among several users. For fi-delity reasons, many testbeds allocate resources conser-vatively; for example, using a one-to-one mapping be-

1

W. Yao and S. Fahmy / Computer Networks 00 (2013) 1–20 2

tween hosts in an experimental topology and machinesin the testbed. This implies that if the number of experi-mental nodes exceeds the number of machines currentlyavailable in the emulation testbed, the experiment can-not be executed.

Scalability of network simulation and emulation hasbeen extensively studied in the literature. Ideas fromparallel computing [6] and resource multiplexing [7]have been adopted to increase experimental scale. Fordiscrete-event simulators [6, 8], events are distributedamong multiple machines to reduce the simulation timeand required hardware resources per machine. Addi-tional overhead for inter-machine synchronization andcommunication depends on how events are partitioned.Emulation testbeds can scale, to a certain extent, viamapping multiple virtual resources onto available phys-ical resources. For example, the Emulab testbed [7] cansupport experiments which are 20 times larger than thetestbed. This network testbed mapping problem is NP-hard [9]. The main challenge, especially with DDoSexperiments, is that the mapped experiment can over-load physical resources (e.g., CPU or memory of a phys-ical machine) and lead to inaccurate experimental re-sults [3].

In this paper, we present a more versatile solution tothe experimental scalability problem. We divide a largenetwork experiment into multiple smaller experiments,each of which is manageable on a testbed. We conductthe smaller experimentssequentiallyon the testbed. Thekey contributions of our work include (1) a novel ap-proach and tool to automatically partition a large exper-iment into sequential small experiments based onnet-work flows and the dependencies among them, (2) aniterative approach to model the interacting small exper-iments, and (3) comparisons of different approaches viaboth simulations and DETER testbed experiments.

Our proposed method,flow-based scenario partition-ing (FSP), is platform-independentbecause it does notrequire any modifications to the simulation, emulation,or physical testbed to be used. Larger experiments canbe conducted on a resource-limited experimental plat-form when partitioned by FSP. FSP can be integratedwith most existing scaling solutions. FSP can also beused to analyze dependencies and tune an experiment,even when the experiment is small enough to fit ontoa testbed. The partitioning of a large experiment viaFSP increases the experimental scalability, at the ex-pense of fidelity. FSP is most appropriate for networkexperiments that use static routing and focus on coarse-grained performance, such as the average throughput ofa data flow.

The remainder of this paper is structured as follows.

Section 2 defines our notation and assumptions. Sec-tions 3 to 6 explain our proposed method, FSP. Sec-tions 7 to 9 describe the experiments used to validateFSP and compare it to downscaling approaches. Sec-tion 10 discusses the limitations, scalability, and appli-cations of FSP. Section 11 summarizes related work. Weconclude in Section 12.

2. Background

In this paper, we focus on performance of data flows.Hence, the termnetwork experimentswill be used to re-fer to data plane experiments. A network experiment isrepresented by anetwork scenario; the smaller experi-ments generated by our method are referred to assub-scenariosor partitions. A network scenario includes thenetwork topologyand theflow information.

We model the network topology as a graphG=(V,E)with vertex setV, representing the routers and end hostsin the network, and edge setE, representing the links inthe network.|V| and|E| denote the number of verticesand number of edges in the graph, respectively. Theflow information describes all traffic in the experiment.Each flow inF includes information about the networkapplication that generated the traffic flow (e.g., FTP,HTTP), the parameters of the traffic of that applica-tion (e.g., request inter-arrival times, file sizes), and thesource, destination, route, and directionality of the flow.Traffic flowing between the same source and destina-tion nodes is grouped into the same macro-flow. Unlessotherwise specified, the termflow in this paper refers toa macro-flow. Depending on the type of network ap-plication that generates a flow, the flow can beopen-loop(e.g., unresponsive CBR UDP flow) orclosed-loop(e.g., TCP flow). The route of a flow is a sequence ofhops from its source to its destination node. Thedirec-tionality of the traffic indicates whether it is unidirec-tional or bidirectional.

We make the following assumptions to simplify theexposition. First, routes in the network are assumed notto change during the course of the experiment. Second,we assume symmetric routes for bidirectional flows,i.e., the packets in both directions traverse the sameroute. Third, flows traversing the same router butnotsharing any linkare independent. For example, a flowfrom port 1 to port 2 of a router does not interfere witha flow from port 4 to port 3. Although this is not al-ways true for low-end routers [3], the assumption holdsfor typical mid to high-end routers, and in most networksimulators, e.g., ns-2 [2]. We can easily relax these as-sumptions at the expense of higher complexity of theflow partitioning process.

2


Our approach is based on several simple but impor-tant observations. First, a large-scale network exper-iment involves many nodes and flows but not all flowsdirectly interact with each other, e.g., by sharing a phys-ical link. If we can identify the parts of the network thatare not strongly tied, we can initially examine each partindependently.

The second observation is that even though a networkscenario may contain many flows, researchers are oftenonly interested in fine-grained performance of a few ofthe flows. The rest of the flows may be used to generatenetwork workload, and are considered as backgroundtraffic. For example, when studying performance ofa web server, we can set up an experiment with sev-eral background FTP flows. Since we are interestedin the web server, we need detailed measurements forHTTP connections such as request/response time. Wemay not need to measure file transfer times for the FTPflows, and the precise arrival processes of these flowsare not important as long as they possess certain statis-tical properties (e.g., average throughput is 1 Mbps orFTP file request frequency is 1 file per second).

3. Overview of FSP

Our proposed method, which we refer to asflow-based scenario partitioning(FSP), does not partition thenetwork nodes, like partitioning approaches for paralleland distributed simulation [6] do. This is because ourgoal is to conduct experiments for each sub-scenarioin-dependentlyon a testbed. If we partition the networktopology directly as illustrated in Fig. 1(a), some flowsmay traverse two or more partitions, and we would needto concurrently execute and synchronize more than onesub-scenario experiment. Instead of partitioning thenodes in the topology, we partition theflowsin the net-work scenario as illustrated in Fig. 1(b).

Flow 1

Flow 2

Flow 1

Flow 2

Sub-scenario 1 Sub-scenario 2 Sub-scenario 2

Sub-scenario 1

(a) Partitioning the network directly (b) Flow-oriented partitioning

Figure 1. Direct network partitioning versus flow-based network par-titioning.

FSP consists of two phases. In the first phase, weautomatically split the input scenario into several sub-scenarios. We build a flow dependency graph (FDG)

to model the relationship between flows. Each con-nected component in the FDG constitutes a partition ofthe graph, which represents a sub-scenario. If any ofthe connected components is too large for the resourcesavailable for an experiment, i.e., it contains too manyhosts and routers, we apply a modified recursive bisec-tion algorithm [10] to cut these connected componentsinto partitions that meet the resource constraints. ThequantitymaxNodedenotes the upper bound on the num-ber of nodes that can be supported in each sub-scenario.Observe that in emulation testbeds such as Emulab andDETER, we need to take into account additional re-quired testbed nodes, e.g., to emulate link delays, whencomputingmaxNode. Section 4 gives the details of thisphase.

In the second phase, we conduct experiments for eachsub-scenario and collect measurements for the flows ofinterest. If sub-scenarios do notinteractwith each other,i.e., they are disjoint components in the FDG, we sim-ply conduct experiments for each sub-scenario indepen-dently. In most cases, however, there will be interac-tions among sub-scenarios, i.e., there are edges in theFDG that cross partition boundaries. To account forthese interactions, we must conduct experiments itera-tively. In the first iteration, we study each sub-scenarioindependently and collect packet traces that capture in-formation related to dependent flows in interacting sub-scenarios. In each subsequent iteration, we incorporateinformation computed fromthe traces in the previousiteration (via tools like [11, 12, 13]) into interactingsub-scenarios. In the final iteration, we collect the de-sired measurements, such as the FTP transfer comple-tion time or HTTP response time. Section 5 gives thedetails of this phase. The overall FSP approach is sum-marized in Algorithm 1.

4. Phase I: Scenario Partitioning

In the first phase of our approach, the input networkscenario is partitioned into sub-scenarios. By carefullyselecting which flows to include in each sub-scenario,flows can have as little interaction as possible with flowsin other sub-scenarios. Given a network scenario (S)which includes the network topology (G = (V,E)) andflow information (F), we divide S into sub-scenarios(S1,S2, · · · ,Sj ) such that the number of hosts and routersin each of the sub-scenario (Si) is ≤maxNode. An ex-ample of this FDG construction and partitioning (tiling)process is illustrated in Fig. 2.

3


Algorithm 1 Flow-based Scenario Partitioning (FSP)

FLOWBASED PARTITION(network, f lows,maxNode)Input: A network scenario with topology (network),

flow information (f lows), andmaxNodeOutput: Estimate of results for original scenario

// Phase 1: Partition the input network scenario1: Construct a flow-dependency graph (f dg) as de-

scribed in Sec. 4.12: Partition the f dg into multiple partitions (Parts)

where each partition contains no more thanmaxNodenetwork nodes (Sec. 4.2)// Phase 2, Iteration 1:// Collect traces in case of interaction among parti-tions.

3: for P∈ Partsdo4: Conduct experiment for sub-scenarioP5: for eachf ∈ P do6: for eachf ′ ∈ f dg.neighbors( f ) do7: if f ′ < P then8: Collect f ’s packet traces onf .path∩

f ′.path// Phase 2, Iterate for interacting partitions:// Incorporate traces collected from first iterationand acquire experimental results.

9: repeat10: for (P∈ Parts) do

// For interacting partitions only11: for eachf ′ < P do12: sharedPath← ( f ′’s path)∩ (links in P)13: if sharedPath, /0 then14: Import model (e.g., Tmix) of f ′ on

sharedPath(in P).15: Conduct experiment for sub-scenarioP16: until Interacting flows propagate their influence

(Sec. 6.2)

4.1. Flow Dependency Graph (FDG) Construction

Our first step is to identify the relationship amongflows in the network scenario. We consider two flows tobedirectly dependentif they both compete for the sameresources such as network buffers or link bandwidth. Inour current implementation, two flows directly dependon each other if they share at least one common link inthe network in the same direction during a time win-dow. We model this relationship using a flow depen-dency graph (FDG).

A flow dependency graph, FDG = (FV ,FE, f ne), is aweighted graph with vertex setFV , edge setFE, and edgeweight functionf ne. A vertex inFV represents a flow inthe given scenarioSand an edge( f1, f2) in FE denotes

(a) A network experiment scenario (with topology and flows). The end hosts (senders and receivers for all flows) are not shown in this figure.

(b) The flow dependency graph of (a).

R1

R8

R6

R4

R3

R2

R0

R9

Flow 0

Flow 3

Flow 4

Flow 5

Flow 6

Flow 7

R5

R7

Sub-scenario 1

F1

F5

F2 F0

Sub-scenario 2

F3

F6

F4 F7

Flow 1,2

Figure 2. Example of transforming a network scenario into a flowdependency graph. According to the partitioning in (b), thenet-work scenario in (a) can be divided into two sub-scenarios with fiverouters each. Sub-scenario 1 contains routers{R0,R1,R3,R6,R9}and flows {F0,F1,F2,F5}. Sub-scenario 2 contains routers{R0,R4,R7,R8,R9} and flows{F3,F4,F6,F7}.

that flowsf1 and f2 aredirectlydependent on each other.All FDG edges are bidirectional. Note that two flowsu andv may impact each other if there is a path fromu to v in the FDG. This follows from the transitivityproperty of dependence. Unless two flows belong todifferent connected components in the FDG, they mayaffect each other in the experiment. The weight of anedge f ne is set to the number of nodes shared by thetwo directly dependent flows. We evaluate this choiceexperimentally in Section 7.

When constructing an FDG, we insert all flows in sce-narioS as vertices inFV . We then insert edges into theFDG based on the routes and the directions of the flows.Recall that an edge between two vertices in the FDGindicates that the two flows will compete for resources.We need to predict the existence of such competitionwithout actually conducting the original large experi-ment. Unfortunately, such a priori prediction is chal-lenging, especially for closed-loop flows. Therefore, weresort to using flow path and direction. For example, ifthe set of flows that will traverse linkl at any time dur-ing the experimentis {a,b,c}, we insert the three edges,(a,b), (b,c), and (a,c), into the FDG. Of course, eventhough flowsa, b, andc all traverse linkl , it is possiblethat only a single flow traverses linkl at any given time.

Edge pruning. Extra FDG edges unnecessarily limitour ability to partition the experiment. Therefore, weprune edges in cases of underload. Previous work [14]

4


shows that when flows are competing for the same linkbandwidth, if the capacity of the link is large enough,i.e., there are no packet drops and only a few packets inthe buffers, each flow will utilize this link as if there areno other flows on the same link. Therefore, we identify“uncongested links” in the network and remove theselinks from the FDG. (An edge in the FDG represents aset of links in the network that are shared by two directlydependent flows, and an edge is removed from the FDGwhen it contains only uncongested links.)

Using flow path information and physical link capac-ity, we can estimate an approximate upper bound on theworkload that can appear on any single link. If the upperbound is less than the physical link capacity, we markthis link as “uncongested” and remove it from the FDG.For example, in Fig. 3, assuming that there are threeflows (from hostsa,b, andc to hostx) in the network,the aggregate throughput of the three flows on linkxcannot exceed 30 Mbps. Since the physical capacity oflink x exceeds 30 Mbps, we predict that linkx will notbe significantly congested during the experiment. Wehave implemented an automated tool to identify suchlinks and delete them from the FDG.

20 Mbps

10 Mbps 10 Mbps

20 Mbps100 Mbps

Link x

Host a

Host b Host c

Host x

Figure 3. The solid lines are (unidirectional) physical links and thelink capacity is shown next to the link. Regardless of the type offlows, the aggregate throughput on linkx cannot exceed 30 Mbps.

4.2. Partitioning the FDGThe FDG created in the previous step may have sev-

eral connected components, and one or more of thesecomponents may be too large to fit onto an experimen-tation platform. The size of a component is defined asthe number of routers and hosts used by the flows inthat component. Our next step is to divide large com-ponents such that the size of each component is smallerthan the givenmaxNodevalue. After this partitioningprocess, each flow in the original network scenario isincluded in only a single FDG partition (sub-scenario).For example, the connected component in Fig. 2(b) ispartitioned into two sub-scenarios. Ideally, we wouldlike to partition the FDG such that there is as little inter-action as possible among the sub-scenarios. Since theoptimal solution to this graph partitioning problem iscomputationally intractable, we employ an approxima-tion that repeatedly computes two-way partitions (i.e.,bisections) of the graph [15].

We leverage the greedy graph growing partitioningapproach (GGGP) [16]. GGGP is a simple approach tobisect a graph. It starts from a vertex and grows its re-gion in a greedy and breadth-first fashion. While thenumber of nodes in the region is smaller than half ofthe nodes in the graph, the algorithm will add new ver-tices into the region. In each iteration, a vertex (fromthe vertices that are adjacent to the current region) is se-lected if moving it into the current region results in thesmallest edge-cut between the two regions. Since the al-gorithm is sensitive to the choice of the initial vertex, werandomly select the initial vertex and repeat the processmultiple times. The partition with the smallest edge-cut is selected as the final output. The number of initialvertices to be selected is configurable in our implemen-tation and the default value is set to five– the defaultin [16]. We found that five initial vertices are sufficientin all our evaluation experiments, but users may select ahigher value to produce better partitions when the inputFDG is large.

5. Phase II: Sub-scenario Experiments

After determining the partitions (sub-scenarios) (S1,S2, · · · , Sj ), our goal is to obtain the desired performancemeasurements, such as the goodput of flows, from thesesub-scenarios. Without loss of generality, letS1 be asub-scenario containing the flows of interest, and letthere bem sub-scenarios thatinteractwith S1, i.e., theybelong to the same connected component in the FDG.We define ashared linkas a link in the original networktopology that is shared by flows in more than one sub-scenario. Assume that there aren shared links inS1.In order to obtain measurements for the flows of inter-est (inS1), we need to generate workloads on thesenshared links for flows in{S2, · · · ,Sm} (since these flowsare not inS1). To achieve this, we propose to conductthe experiments in multiple iterations.

5.1. First Iteration

In the first iteration, we conduct experiments inde-pendently for each sub-scenario. For interacting sub-scenarios, there will be flowsmissingon the sharedlinks, compared to the original large scenario. For ex-ample, Fig. 2 contains two sub-scenarios (S1 andS2).When we conduct the experiment forS1 in the first iter-ation, flow 4 and flow 6 will not generate any workloadon link R0-R9 since they are not included inS1, andflow 0 will also be missing fromS2. As a result, themeasurements in this iteration may be dramatically dif-ferent, compared to those in the original scenario, e.g.,

5


the throughput of flow 0 may increase since flow 0 doesnot need to compete for bandwidth with flow 4 and flow6. Therefore, we collect packet traces for these inter-acting flows, in order to later use information computedfrom these traces to generate workload that models themissing flows.

5.2. Subsequent IterationsIn subsequent iterations, we sequentially conduct

experiments for each sub-scenario that interacts withothers, but we now incorporate information computedfrom the previous iteration to model its interacting sub-scenarios. Multiple iterations may be required to prop-agate the interactions among flows. Measurements col-lected in the final iteration approximate the results of theoriginal experiment. The number of required iterationsvaries depending on the partitioning of the FDG. As wewill discuss in Section 6, in most cases, FSP requiresno more than five iterations – typically two iterationssuffice.

5.2.1. Workload and network modelingSince many flows areclosed-loop, wecannot simply

replay the collected packet traces on the shared links.We must model the workload of flows at the applica-tion level, and model theconditions experienced bythese flows in the non-shared linksin interacting sub-scenarios. This is crucial so that the missing flows areno more aggressivethan they would have been in theoriginal unpartitioned experiment. In other words, theconditions in the network, such as congestion level anddelays experienced by the missing flows during the sec-ond iteration, must mimic the original unpartitioned ex-periment, so that the transport and application layers atthe end hosts can react similar to their reaction in theoriginal experiment. This is critical when the flows arebottlenecked in another partition or their propagationdelays in another partition are high.

In our experiments in this paper, we investigate theuse of the three tools (1) Tmix [11], (2) Harpoon [13],and (3) Swing [12] to (i) process packet traces collectedduring an iteration, and (ii) model non-shared networkconditions and generate application workloads in thenext iteration. These tools capture application trafficcharacteristics (e.g.,connection vectorsrepresenting re-quests, responses, and think times), as well as networkconditions (e.g., round-trip-time (RTT) and packet loss)on the parts of the network that arenot shared amongpartitions.

Observe that additional experimental nodes may berequired to generate the workload to represent the inter-acting partitions. Depending on the testbed resources,

these additional nodes can be hosted on additionaltestbed machines or virtualized on the nodes in the sub-scenario. We can consider this when configuring themaxNodeparameter.

5.2.2. Modeling exampleConsider the simple network scenario with three

flows shown in Fig. 4. After the first phase of FSP,the scenario is partitioned into two sub-scenarios whereFlow 1 and Flow 2 belong to the first sub-scenario, andFlow 3 belongs to the second sub-scenario.

N1 N2

N3R1 R2 R3

N4

N5

Flow 1

Flow 2

Flow 3

Figure 4. An example scenario with three flows. The scenario is par-titioned into two sub-scenarios where the first sub-scenario containsFlow 1 and Flow 2 and the second sub-scenario contains Flow 3.

When conducting the first iteration of sub-scenarioone in the testbed (Fig. 5), we collect the packet traceon the shared link (R1-R2) using tcpdump. This packettrace is processed by Tmix to extract the applicationworkload model of Flow 1 and Flow 2. This applica-tion workload model includes a vector for each connec-tion representing request sizes, response sizes, and ap-plication think times. Other tools such as Swing [12]additionally capture session-level characteristics, e.g.,correlations among different TCP connections. We willcompare these tools in Sections 9 and 10.

For each flow that traverses a shared link, we alsoneed to model the network conditions experienced bythe flow in the non-shared links(i.e., the paths beforeand after the shared link). To balance the tradeoff be-tween experimental complexity and fidelity, FSP cur-rently models the network conditions via the bottlenecklink capacity, the average packet drop ratio, and the av-erage packet delay on the non-shared links.

The bottleneck link capacity can be observed directlyfrom the network topology. For example, the bottleneckcapacity for Flow 2 on path N1-R1 is 10 Mbps and onpath R2-R3-N3 is 5 Mbps from Fig. 5. The averagepacket loss and delay can be calculated from the per-flow packet loss and delay on the associated non-shared

6


links. For instance, the average packet delay on pathR2-R3-N3 is the sum of delays measured on links R2-R3 and R3-N3.

N1N2

N3R1 R2 R3

Flow 1

Flow 2

10M

100M20M

10M

5M

Figure 5. The first iteration of sub-scenario one.

In subsequent iterations, additional nodes are at-tached to the shared links to generate workload that rep-resents the interacting partitions. For example, in thesecond iteration of sub-scenario two (Fig. 6), two pairsof Tmix processes, (T1, T3) and (T2, T4), are gener-ating workload to represent Flow 1 and Flow 2 usingthe application-level model extracted from the previousiteration of sub-scenario one (Fig. 5).

Each Tmix process is connected to a “delay box” [11]before connecting to the shared link. The delay boxesare configured to reflect the network conditions that theTmix traffic should encounter. For instance, delay boxD4 is configured to have 5 Mbps link capacity and in-troduces additional loss and delay on transmitted pack-ets according to the measurements on path R2-R3-N3 inFig. 5.

Note that it may be possible to host multiple Tmixprocesses and delay boxes onto the same testbed ma-chine. For example, as illustrated in Fig. 6, T1 andT2 are two Tmix processes running on machine Tmix1.The two delay boxes, D1 and D2, can be implementedas Linux traffic shaping rules on Tmix1 and R1.

R1 R2

N4 N5

Flow 3

Tmix2Tmix1T1

D1 D2

T2

10M 10M

Tmix workload (Tmix2)(Tmix1)

T3

D3 D4

T4

100M

Figure 6. The second iteration of sub-scenario two. Two additionalmachines, Tmix 1 and Tmix 2 are used to generate the workload forFlow 1 and Flow 2.

5.2.3. Importance of modeling interacting partitionsThe key to obtaining correct results from sub-

scenarios is to utilize a modeling procedure (such as that

discussed in the previous subsection) to model the traf-fic and network conditions in missing partitions, as op-posed to simply replaying collected packet traces. Con-sider a dumbbell topology withN flows and 2N + 2nodes. Let the link between the two routers in thedumbbell be the bottleneck link (C Mbps) and each sub-scenario contains only a single flow.

Fig. 7 illustrates the average throughput of theNflows (on thex-axis) in the dumbbell topology. Asshown in the figure, since there is a single flow in eachsub-scenario, all flows are able to utilize the full linkcapacityC in experiments in the first iteration. In sub-sequent iterations, the workload of the flows fromN−1sub-scenarios is generated at the application level on topof the TCP protocol and experiences conditions of themissing partitions. Therefore, the throughtputs of flowson the bottleneck link in the second iteration are closeto C/N, for any value ofN.

0

2

4

6

8

10

2 3 4 5 6 7 8

Thr

ough

put (

Mbp

s)

Number of Flows / Sub-scenarios

OriginalIteration 1Iteration 2

Figure 7. Average/Max/Min goodput of the flows in a dumbbell topol-ogy. Each sub-scenario contains a single flow and the bottleneck linkis 10 Mbps with 10 ms delay.

5.3. Illustrative Examples

To further understand the second phase of FSP, weuse a set of simple illustrative examples. We study net-work scenarios with FTP and HTTP flows using thepopular network simulator ns-2 (Version 2.31) [2]. Weuse the topology given in Fig. 2, and set all “last-mile”links to 100 Mbps to create more interaction amongflows. The FDG for the closed-loop scenarios is givenin Fig. 2(b). For FTP, a client at the source host willsend requests to download files from an FTP server atthe destination host. Each time the client downloads a5 MB file, and the interval between requests is exponen-tially distributed with the rate parameter (λ ) set to 0.1,1, or 2. We generate HTTP flows using the PackMime-HTTP [17] traffic generator. We control the rate param-

7


eter in the traffic generator to study network scenariosunder different loads.

5.3.1. Uncongested scenariosWe first study the performance of our method in

lightly loaded network scenarios. We use 8 FTP flowsand the rate parameter (λ ) is 0.1. We measure thegoodput and packet drop rate for all 8 flows. As ex-pected, the measurements from the original scenarioand sub-scenarios (iteration 1) are almost identical (re-sults omitted for brevity), and we observe similar re-sults for lightly loaded network scenarios with 8 HTTPflows (rate = 1). This confirms the intuition that underlightly loaded scenarios, results from a single iterationsuffice to accurately approximate results of the originalscenario, which is the rationale for pruning uncongestedlinks in Section 4.

5.3.2. Congested scenariosWe now increase the load in the network to increase

interaction among flows. Table 1 lists the average re-sults for a heavily loaded network with 8 FTP flows(λ = 2), repeating each experiment 10 times.

Table 1. The goodput (Mbps) of 8 FTP flows collected from the orig-inal scenario and the second iteration of FSP.

Flow Original FSP Difference0 30.65 32.22 1.57 (5.11%)1 48.60 48.57 -0.03 (-0.06%)2 48.59 48.34 -0.25 (-0.51%)3 61.12 60.55 -0.57 (-0.93%)4 34.65 35.70 1.05 (3.03%)5 57.09 58.37 1.27 (2.23%)6 34.55 36.73 2.18 (6.30%)7 60.86 59.05 -1.81 (-2.97%)

As depicted in Fig. 2, we have 2 sub-scenarios (P1,P2)and link R0-R9 is shared among them. In the first iter-ation, we conduct an experiment forP1, and collect apacket trace on link R0-R9, which contains packets forflow 0. We collect another packet trace on link R0-R9which includes flow 4 and flow 6 when running the ex-periment forP2.

In the second iteration, the packet trace on link R0-R9 is input to the Tmix tool [11] to generate workloadsthat represent the missing flows on the link, i.e., flow 4and flow 6 forP1 and flow 0 forP2. When connectingthe Tmix workload generator to link R0-R9, we inserta delay box [11] between the link and each Tmix traf-fic generator. As discussed in Section 5.2.2, the delaybox introduces delays representing the one way portion

of the RTT of each flow, minus the delay of the sharedpath. The capacity of the delay box is configured tobe the bottleneck link capacity of a flow. We assignloss rates to the delay box to model the network con-ditions encountered in interacting partitions. For eachpath, we compute the packet loss rates and delays of thenon-shared links from the trace collected in the previ-ous iteration. For example, letn1,n2,n3, andn4 be thenodes on the path of flow 0, wheren1 andn4 are thesource and destination of the flow andn2 andn3 are thetwo end points of the shared link. The four loss rateson the non-shared parts of the flow (in both directions),i.e., (n1,n2),(n3,n4),(n4,n3), and(n2,n1), are used inthe delay box configuration. Tmix also infers detailedapplication behavior from the trace and represents it asconnection vectors [11].

The results in Table 1 demonstrate that long-termmetrics, such as the average goodput of a flow, can bereasonably predicted using our method.

5.3.3. Shared links are bottlenecksIn the previous experiment, although the network is

congested, the shared link R0-R9 is not a bottleneck inthe original network because flows 4 and 6 and flow 0are downloading files in opposite directions. We nowreverse the direction of flow 0 to make link R0-R9 thebottleneck link. The goodput of the flows is given inTable 2. We are especially interested in flows 0, 4, and6, since they are the flows on the shared link R0-R9.In the first iteration, the goodput of flows 0, 4, and 6 is21.31, 13,81, and 13.17 Mbps higher than the goodputthey obtain in the original scenario. This is due to themissing flows in each sub-scenario, e.g., flow 0 does notexist inP2.

Table 2. The goodput of 8 FTP flows (Mbps) in different iterations.

Flow Original Iteration 1 Iteration 20 30.50 51.81 27.641 48.51 48.03 51.212 48.80 49.02 45.953 61.19 49.81 59.604 34.25 48.07 36.855 57.44 44.00 61.516 35.09 48.26 38.227 60.19 49.83 58.07

After the second iteration, we are better able to pre-dict the goodput of all flows. Note that in both ex-amples, there are small variances between the resultscollected from the original scenario and from the sec-ond iteration of FSP. For example, the goodput of flow

8


0 in Table 2 is still 2.85 Mbps lower than the correctvalue. Recall that when we generate the workload forflow 4 and flow 6 intoP1, the network conditions ofP2

are modeled as the delay, link capacity, and loss on theTmix delay boxes. Ideally, the loss rates and delays ac-curately capture the impact of other flows inP2 (flow 3and flow 7). However, to reduce complexity, we do notcapture the dynamics encountered by each flow in theinteracting partition. As a result, the workload gener-ated by Tmix in the second iteration ofP1 fails to accu-rately constrain the goodput of flow 0. We are currentlyinvestigating alternative Tmix configurations that moreaccurately represent the workload of missing flows, atthe expense of space and time complexity.

5.3.4. Fine-grained and coarse-grained metrics

Fig. 8 plots the packet delay distribution of flow 1 inthe previous experiment. Table 3 lists the percentagedifference of the results between the original scenarioand the second iteration of FSP in that experiment. Weobserved that the overall statistics (coarse-grained met-rics) such as the average goodput, packet delay, and de-lay jitter as well as their cumulative distribution func-tions (CDFs) can be accurately predicted by FSP.

Since the delay and loss in the interacting partitionsare abstracted into simplified models, such as the aver-age packet loss on non-shared links, fine-grained met-rics are not preserved by FSP. For example, Fig. 9 illus-trates the one-way packet delay of the first 100 packetsin flow 1. Even though flow 1 does not directly interactwith flows in other partitions, the packet delays of indi-vidual packets are different from the original scenario.As a result, FSP does not target experiments that requirefine-grained metrics to be preserved.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5 10 15 20 25 30 35 40 45

Rat

io o

f pac

kets

Packet Delay (ms)

OriginalFSP

Figure 8. The packet delay distribution of the packets in flow1.

Table 3. Percentage difference of the results between the original sce-nario and the second iteration of FSP. The is the same experiment asTable 2.

Flow Goodput Sent Dropped Packet DelayPackets Packets Delay Jitter

0 -9.37% -9.13% -6.75% -12.38% 10.30%1 5.57% 5.35% 1.09% -1.71% -5.28%2 -5.85% -5.85% -5.82% -3.11% 6.20%3 -2.60% -1.89% 23.92% 3.53% 2.68%4 7.59% 6.42% -7.24% -5.99% -7.06%5 7.09% 7.19% 10.79% 8.00% -6.62%6 8.92% 7.93% -4.12% -4.25% -8.18%7 -3.52% -2.66% 27.62% 6.45% 3.66%

0

5

10

15

20

25

30

35

40

45

0 20 40 60 80 100

Pac

ket D

elay

(m

s)

Packet ID

OriginalFSP

Figure 9. The packet delay of the first 100 packets in flow 1.

6. Multiple Interacting Partitions

We now examine an important aspect of the tradeoffbetween experimental fidelity and complexity. As dis-cussed earlier, FSP represents the relationship betweenflows by an FDG, where each flow is a vertex in thegraph and two flows can influence each other as long asthere is a path between them. If there is no direct edgebetween two flows, the interaction among the two flowscan only be propagated transitively via other flows. Ifthe flows belong to different sub-scenarios, this propa-gation process can only take place in a subsequent it-eration. Naturally, this leads to the following question:how many iterations are required when there are multi-ple interacting sub-scenarios?

6.1. Four Interacting Sub-scenarios

Consider the network scenario shown in Fig. 10. Inthis simple scenario, all links are 10 Mbps with 5 msdelay and there are four macro-flows, each belonging toa different partition (∀1≤ x≤ 4 :Fx∈Px). Each macro-flow contains a number of concurrent TCP connectionssending traffic continuously from the source to the des-tination node for 600 seconds. In all experiments, we

9


F1 F3 F4F2

0

12

3

87

654

12119

1413 171615 1918

Flow 1

Flow 2

10

Flow 3Flow 4

Figure 10. A scenario with up to four (indirectly) interacting sub-scenarios and its flow-dependency graph.

employ Tmix togenerate the application workloadandmodel the network conditionsvia losses and delays ininteracting partitions.

Tables 4 and 5 give the goodput of the four macro-flows, each containing one connection or three TCPconnections, respectively. When the network is lightlyloaded (Table 4), two iterations are sufficient as the re-sults stabilize in later iterations. The application behav-ior extracted by Tmix for all four macro-flows, each asingle long-term TCP flow, remains unchanged in all it-erations, since we are using the same application trafficmodel. Tmix correctly infers that model from the traf-fic traces. The network conditions (delay and loss) ex-tracted from the traces vary within a small range fromthe second iteration onwards as most links have lowpacket losses and queuing delays in this lightly loadednetwork.

Note that the interactions among partitions that arenot directly connected in the FDG (e.g.,P4 andP1) arepropagated through the network conditions of interme-diate partition(s) (e.g.,P3). The similarity between thenetwork conditions measured in different iterations alsoimplies that the partitions which do not have commonshared links have little influence on each other in thisscenario. For example, flow 4 interacts with all otherflows in subsequent iterations (3rd and 4th iterations forflow 1 and flow 2). However, as seen in Table 4, thegoodputs of flow 1 and 2 remained almost unchangedafter iteration 2. Although the goodput of flow 3 be-comes more accurate in iteration 3, the improvement isinsignificant (within 5% of the link capacity).

As we increase the workload in the network, interac-tions between any two sub-scenarios are no longer dom-inated by the application workload generated by Tmix

and two iterations are insufficient to obtain accurate re-sults. As illustrated in Table 5, it takes four iterationsto obtain results with reasonable accuracy. The numberof iterations to propagate the interaction from one sub-scenario to any other sub-scenario is upper-bound by thenumber of sub-scenarios in the largest connected FDGcomponent, e.g., if the largest FDG component neededto be partitioned into four sub-scenarios, four iterationsare sufficient to propagate the interaction between anytwo interacting sub-scenarios. This maximum iterationvalue is labeledmaxChain.

Note that despite executing additional iterations, theresults from the second experiment (Table 5) are lessaccurate then those from the first experiment (Table 4).Since in both experiments the application traffic mod-els are correctly inferred by Tmix, the loss of fidelitystems from the simplified network condition modelwhich is amplified when propagated through multiplesub-scenarios.

The examples in this section highlight a fundamentaltradeoff: fidelity of the results versus the time and spacecomplexity of the experimentation process. When sim-ple aggregate measurements, e.g., average delay or lossover the entire experiment, are input to a tool like Tmixto model network conditions encountered by a flow,loss of fidelity will occur, compared to having more de-tailed representations of network conditions, e.g., a timeseries of packet loss over the entire experiment dura-tion. We are currently exploring this tradeoff in greaterdepth. The choice of which tool to use (Tmix, Harpoon,Swing) is a critical aspect of the tradeoff, and we exam-ine this via testbed experiments in Section 9.

6.2. Required Iterations

Let us return to the question posed at the begin-ning of this section. In the two previous examples,FSP requires two tomaxChainiterations. The value ofmaxChaindepends on the input scenario and the valueof maxNode. For example, Fig. 16 in Section 7.3 illus-trates themaxChainvalue calculated for a set of ran-domly generated network scenarios. We have observedthat only a few iterations are needed for all scenarioswe generated: we need four to five iterations in mostcases, based on the size of the largest set of interactingsub-scenarios.

Naturally, the examples illustrated in this section can-not represent all possible network scenarios and feweror more iterations may be required. To speed-up the ter-mination of FSP, several heuristics can be used as dis-cussed in the following subsections.

10


Table 4. The goodput of TCP flows in kbps. Each macro-flow contains one TCP connection.

Flow Original Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 51 4998 8544 4998 4998 4998 49982 4998 8544 4998 5075 5075 50753 4228 4270 3716 4214 4217 42164 5618 5695 5657 5675 5642 5610

Table 5. The goodput of TCP flows in kbps. Each macro-flow contains three TCP connections.

Flow Original Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 51 4895 9997 3161 4254 4455 43312 5098 9996 3089 3492 4247 40173 723 9992 2919 917 1045 9454 9270 9992 9373 9286 9324 9309

6.2.1. FDG edge-pruningAs mentioned in Section 4.1, uncongested links in the

network can be identified and the associated FDG edgesare removed when constructing the FDG. This reducesthe size of the connected components in the FDG andreducesmaxChainvalue.

6.2.2. Minimize interactions among partitionsIn addition to identifying uncongested links conser-

vatively (e.g., Fig. 3), one can also predict the uncon-gested links based on known traffic workload [18] orsimulation results. For example, before conducting atestbed experiment using FSP, a full-scale simulationwith simplified application workloads can be conductedto predict potential uncongested links. Although wemay not wish to prune all their associated FDG edgesduring the FSP partitioning phase as these links are notguaranteed to be uncongested, one can easily modifythe GGGP algorithm to select them as edge cuts to min-imize the interaction among partitions.

6.2.3. Early terminationAs seen in Table 4, it is often possible to obtain

accurate results beforemaxChainiterations. This oc-curs when the extracted application and network mod-els from all partitions converge to the same values intwo consecutive iterations. Note that the inputs to theworkload generation tool (e.g., Tmix) for the(n+ 1)stiteration are extracted from thenth iteration and FSP canterminate immediately without conducting the(n+1)stiteration.

6.2.4. Partial results and feedback mechanismIf FSP fails to converge within a specified number

of iterations, FSP can terminate and report only the re-sults from partitions that converged. If not all flows of

interest are covered by these partitions, the user can in-crease themaxNodevalue and repeat the FSP proce-dure. By merging interacting partitions that do not con-verge into a single partition, we are able to estimate arecommendedmaxNodevalue for the next FSP proce-dure.

7. Partitioning Experiments

In this section, we investigate the first phase of FSP.Given the size of a backbone network (the number ofrouters) and the number of flows we wish to have in anetwork scenario, we generate a set of Rocketfuel [19]topologies representing the backbone network using ourRocketfuel-to-ns tool [20]. For each flow, we insert twoend hosts as the source and the destination of this flow,and randomly attach these end hosts to the backbonenetwork. The end hosts are only attached to routers withdegree no larger than three and, to avoid trivial cases,the source and destination nodes of a flow are not at-tached to the same router.

7.1. Weights in Partitioning

We first evaluate our choice of weight function in thefirst phase of FSP. Recall that we compute the weight ofan edge cut in the FDG as the number of distinct nodes(hosts and routers in the original network topology) thatare shared by flows represented in the cut (Section 4).Since the graph partitioning algorithm in our methodaims to select partitions with low edge cut weight, thefunction we choose to calculate the weight of an edgecut should help reduce the interactions among parti-tions. In this section, we show how our weight functioncompares to a simpler function that uses the number ofFDG edges on an edge cut as the weight. Since an edge

11


in the FDG implies dependence among two flows, fewerFDG edges between partitions also implies less depen-dence among partitions.

Fig. 11 demonstrates the average number of sharedlinks between partitioned network scenarios when us-ing these two methods of computing the weight of anedge cut. In this experiment, we generate different net-work scenarios by randomly assigning 50 or 100 flowswith their end hosts onto a fixed Rocketfuel backbonewith 100 routers. We compute the average number ofshared links among partitions and the average resultsfrom 30 experiment runs are plotted. From Fig. 11,we find that using the number of distinct nodes as theweight of an edge cut can lead to fewer shared linksamong sub-scenarios than simply using the number ofdependent flows. This not only indicates that we havefewer packet traces to collect in the second phase of ourmethod, but also implies that there may be less complexinteractions among sub-scenarios.

0

20

40

60

80

100

120

140

160

180

200

10 20 30 40 50 60 70 80 90 100

Num

ber

of li

nks

shar

ed b

etw

een

part

ition

s

Maximum Number of Nodes in a Partition

Cut weight = nodes (50 flows)Cut weight = edges (50 flows)

Cut weight = nodes (100 flows)Cut weight = edges (100 flows)

Figure 11. Number of shared links among sub-scenarios with twomethods to calculate the weight of an edge cut.

7.2. Time Complexity

The time required for the second phase of FSP de-pends on the number of sub-scenarios and the tool used(e.g., Tmix vs. Harpoon) which can significantly vary(see Section 9). As seen in Algorithm 1, the time com-plexity of the first phase of FSP, i.e., partitioning a largenetwork scenarios into sub-scenarios, is dominated bythe graph partitioning algorithm. Our current imple-mentation uses the recursive bisection algorithm withcomplexityO(|FE| logk), whereFE denotes the edgesin the FDG andk denotes the number of partitions gen-erated by the algorithm [16]. The worst case time com-plexity of our complete algorithm isO(|F |4) where|F |is the number of input flows.

We computed the runtime for partitioning scenarioswith 100 to 500 flows, randomly generating 30 scenar-ios for each value of the number of flows. As illustratedin Fig. 12, the runtime is proportional to the number offlows in the network scenario. The runtime can varyfrom seconds to hours for the same number of flows de-pending on the complexity of the scenario or, in otherwords, the number of edges in the FDG. Despite thefact that FSP took up to a few hours for some scenarioswith 500 flows, partitioning will typically be invokedoffline, and hence FSP is still feasible. Moreover, thecurrent FSP prototype does not take advantage of possi-ble performance optimizations; we will develop a fasterimplementation by selecting a faster graph partitioningalgorithm, e.g., the k-way multilevel partitioning algo-rithm with O(|E|) [16], and using more sophisticatedprogram optimization techniques.

0

200

400

600

800

1000

1200

1400

1600

100 150 200 250 300 350 400 450 500 550

FS

P R

untim

e (m

in.)

Number of Flows

maxNode = 25maxNode = 50

maxNode = 100

Figure 12. The average runtime of FSP phase 1 versus the number offlows in randomly generated network scenarios.

7.3. Partition Characteristics

We now take a closer look at the partitioning re-sults. We generate sets of random network scenarios,each with 50 routers. We generate 50 to 250 unidi-rectional open-loop flows in the network, i.e., there are50+ 2× |F | total nodes (hosts and routers) in the net-work. For each set of experiments, we generate 50 ran-dom scenarios and execute the FSP partitioning phasewith differentmaxNodevalues. We investigated (i) thenumber of partitions, (ii) the value ofmaxChain(de-fined in Section 6), and (iii) the number of links androuters shared among partitions.

Fig. 13 and Fig. 14 show the number of directly de-pendent flows, and the number of links shared amongpartitions. Since the number of dependent flows islarge, and there are many links shared among partitions,we conclude that the random network scenarios we are

12


studying are complex enough to represent interestingscenarios.

Fig. 15 shows the number of partitions generated byour algorithm, and Fig. 16 shows themaxChainvaluecomputed after partitioning, which typically influencesthe required number of iterations. As expected, we findthat the larger the value ofmaxNode, the fewer the num-ber of partitions and the smaller themaxChainvalue.A flow in any of our randomly generated scenarios in-volves two end hosts and several routers on its path.Although a flow can only appear in one partition, therouters on its path can beduplicatedin multiple parti-tions. We observed that a router may appear in 10 to 20partitions. The number of duplicated routers is signifi-cantly reduced whenmaxNodeincreases.

0

100

200

300

400

500

0 10 20 30 40 50 60

Num

ber

of fl

ows

maxNode

Flows = 50Flows = 100Flows = 150Flows = 200Flows = 250

Figure 13. Average/min/max number of flows involved among parti-tions.

0

50

100

150

200

250

300

350

400

450

0 10 20 30 40 50 60

Num

ber

of li

nks

maxNode


Figure 14. Average/min/max number of links shared among parti-tions.

0

20

40

60

80

100

120

140

160

0 10 20 30 40 50 60

Num

ber

of p

artit

ions

maxNode


Figure 15. Average/min/max results of FSP partitioning under differ-ent network scenarios andmaxNodevalues.

0

2

4

6

8

10

12

0 10 20 30 40 50 60

Num

ber

of it

erat

ions

maxNode


Figure 16. ThemaxChainvalue for randomly generated network sce-narios.

8. Simulation Experiments

8.1. Botnet Experiments

Denial of Service (DoS) attacks have been launchedagainst Internet sites for decades, and distributed DoSattacks are extremely difficult to defend against. Withthe prevalence of botnets in today’s Internet, individualscan easily launch a massive DDoS attack from a rentedbotnet for just a few hundred dollars per day. In thissection, we use both phases of FSP on a scenario thatstudies the impact of a large-scale DDoS attack target-ing a busy web server at Purdue University.

To understand the availability of our web server tovisitors during the attack, we selected 200 domains assources of the legitimate users and 50 subnets as the at-tackers. The 200 (out of 14407) domains cover morethan 70% of the service providers of all visitors to ourweb server between May 2009 and May 2010, and the50 subnets are selected from the black list generated byDShield.org [21] in June 2010. We use traceroute from

13


the web server to all 200+50=250 /24 subnets to gener-ate the network topology, and find 1232 routers. Sev-eral heuristics are then applied to reduce the number ofrouters. For example, if the last 8 hops of a tracerouterecord are not used by any other flow, we aggregatethe delays between them and remove the 7 intermedi-ate hops. After reductions, there are 438 nodes and 462links in this network topology as shown in Fig. 17. Notethat the end hosts for legitimate users and attackers areaggregated. For instance, the 50 attack flows representthousands of attackers from the 50 /24 subnets. All linksare set to 100 Mbps. During the attack, 67% of the linksin the network are highly congested, including the linkdirectly linking to the web server.

Web Server

Figure 17. The network topology of the botnet experiment.

Since the size of this topology is larger than the DE-TER testbed, we use ns-2 to compare between the origi-nal and the partitioned experiments. The 200 legitimateflows are generated by the PackMime-HTTP module inns-2 with 2 requests per second using both HTTP/1.0and HTTP/1.1. For each HTTP/1.0 session, the clientrequests a 36 kB page, which is the size of the mostpopular page in our web site, and terminates the TCPconnection once it is received. For HTTP/1.1 sessions,the client first requests the same page as in HTTP/1.0,but requests up to two other pages using the same persis-tent connection. This 3-page per session is based on thefact that most of our site visitors (85.89%) view at mostthree pages during their visit. Each page contains sev-eral objects and the size and number of the objects aregenerated by PackMime-HTTP. For the attack flows, wesend UDP packet bursts to the web server at 5 Mbps andexponential on/off time with mean set to 2 seconds.

We execute FSP on this scenario withmaxNodeset

to 100 to generate sub-scenarios which can easily fitonto a testbed like DETER. The large scenario with 438nodes is partitioned by FSP into 8 sub-scenarios wherethe largest one contains 83 nodes – a reasonable size forDETER.

We use a user-perceived metric, the ratio of success-ful HTTP sessions, in both the original and the parti-tioned experiments. An HTTP session is successful ifits duration is less than 60 seconds or the delay be-tween receiving objects from the server is less than 4seconds [22]. Fig. 18 and Fig. 19 give the percentage ofsuccessful HTTP/1.0 and HTTP/1.1 sessions in the 300-second period when the server is under DoS. We alsoexamined the download time distributions for pages andobjects. Clearly, results from the first iteration are erro-neous (100% success) since attack flows and legitimateflows are mostly in separate partitions, while the resultsfrom the second iteration reasonably match the originalscenario.

0

20

40

60

80

100

0 5 10 15 20 25

Suc

cess

ful H

TT

P/1

.0 S

essi

ons

(%)

HTTP Flow ID

Origional Iteration 1Iteration 2

Figure 18. Percentage of successful HTTP/1.0 sessions. Only the first25 flows are shown due to space constraints.

0

20

40

60

80

100

0 5 10 15 20 25

Suc

cess

ful H

TT

P/1

.1 S

essi

ons

(%)

HTTP Flow ID

Origional Iteration 1Iteration 2

Figure 19. Percentage of successful HTTP/1.1 sessions. Only the first25 flows are shown due to space constraints.

A closer look at the results in Fig. 18 and Fig. 1914


reveals that, while most flows have similar results inboth experiments, a few flows (e.g., flow 9) have a sig-nificantly lower success ratio in the partitioned experi-ments. Comparing Fig. 18 and Fig. 19, the success ra-tios for HTTP/1.1 sessions are lower than the HTTP/1.0sessions, and the results from the second iteration have agreater error for HTTP/1.1. This is due to the HTTP/1.1persistent connections. The HTTP/1.1 session has moreobjects and pages in the first iteration than in the origi-nal scenario and the Tmix-injected TCP flows are thusmore aggressive. This is because when a requestedpage is dropped in the original scenario, a client willnot request the objects in that page. Since there are nodropped requests in the first iteration (the horizontal linein the figure for iteration 1), a client will request moreobjects and pages in a connection.Such changes in userbehavior are hard to capture by workload generatorsunless they have application-layer knowledge, which isavoided by Tmix because it hinders scalability and ex-tensibility to new applications. As we will discuss inSection 9, Tmix [11], Harpoon [13], and Swing [12]make different choices in terms of the user, session,connection, and network characteristics that they extractand model, and hence the fidelity of the results obtainedvaries according to which of these tools we use, and howwe configure the selected tool.As we extract and modelmore information, space and time complexity increase,but fidelity also increases. This tradeoff must be bal-anced according to the goals of the experiment to bepartitioned, and the time and space constraints.

8.2. Comparisons to DownscalingIn this section, we compare FSP with a downscal-

ing technique. We select the TranSim time-samplingapproach [23] since it is designed for arbitrary traf-fic (whereas other downscaling techniques in the liter-ature [24, 14] make assumptions about traffic models).TranSim aims to accelerate a simulation experiment byreducing the number of packet events in the simulation.While TranSim can also be applied to testbed experi-ments to reduce the hardware requirements, perhaps byrunning experiments on slower testbed machines, Tran-Sim was designed to speed up simulations [23] and it isnot entirely clear how it can reduce the number of ma-chines required on a testbed. Thus, we compare Tran-Sim and FSP via simulation experiments.

In our first experiment, we consider a scenario where50 backbone routers are generated using Rocketfuel-to-ns [20] and there are 50 pairs of end hosts randomlyattached to the backbone. The topology of our secondexperiment is a simple dumbbell as shown in Fig. 20.For each pair of hosts, a client continuously requests a

file from a server at a fixed rate. The first experiment has50 long-lived FTP flows where the requested file size is5 MB and the request rate is one per second. In the sec-ond experiment, there are 25 long-lived (class 0) HTTPflows and 25 short-lived (class 1) HTTP flows. The re-quested file sizes are 100 kB and 1 kB, and the requestrates are 2 and 50 per second, respectively. In both ex-periments, the downscaling parameterα in TranSim isset to 0.5 and 0.25. To correspond to this, themaxNodeparameter in FSP is configured so as to partition the 50flows into 2 and 4 sub-scenarios. We use ns-2 with Tmixas the modeling tool in FSP.

50 Mbps10 ms

Class 0 flows

...

......

...

Class 1 flows

Figure 20. The network topology of 25 long-lived TCP flows and25 short-lived TCP flows. Unless otherwise specified, all links are100 Mbps and 10 ms delay.

We use throughput as the metric in the first experi-ment since there are many active TCP connections whenthe simulation ends. In the second experiment, we com-pute the success ratio of HTTP requests [22]. In this ex-periment, we consider an HTTP request successful if itis completed within 10 seconds. We find that throughputCDFs for FSP and TranSim are similar for the first ex-periment in Fig. 21. In the second experiment (Fig. 22),the fidelity of FSP is significantly higher than Tran-Sim, especially compared to the 0.25 downscaling pa-rameter. These TranSim results agree with our previ-ous study [25]. TranSim loses fidelity with short-livedflows, since control packets, such as the TCP handshakepackets and HTTP request packets, cannot be sampled.The short-lived flows are thus relatively more aggres-sive.

As with FSP, TranSim is not designed to preservefine-grained metrics. When conducting a downscaledexperiment using TranSim, onlyα percentage of thepackets in a flow are transmitted. The sampling of pack-ets can significantly impact the fidelity of packet-levelmetrics such as the packet delay jitter. Table 6 givesthe differences in the delay jitter between the originaland the downscaled experiments measured in the sec-ond network topology (Fig. 20). We observe that thefidelity of packet-level metrics decreases as TranSim se-lects fewer packets to represent a flow in a downscaled

15


experiment.

Compared to TranSim, FSP requires additional traf-fic modeling processes and longer run-time to conductsub-scenario simulations in multiple iterations. The keyadvantage of FSP is that it can be directly applied to ex-perimental and emulation testbeds to reduce the numberof required machines, whereas prior work only consid-ered how to reduce simulation time [24, 14, 23].

Table 6. Percentage difference of average packet delay jitter betweenthe original and the downscaled experiments.

Short-lived TCP Long-lived TCPFSP (maxNode=60) 0.84% 3.08%FSP (maxNode=30) 1.34% 2.90%

TranSim (α=0.5) 51.06% 6.43%TranSim (α=0.25) 74.70% 39.09%

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5 10 15 20 25 30 35 40

Rat

io o

f flo

ws

Throughput (Mbps)

OriginalFSP (maxNode=100)FSP (maxNode=50)

TranSim (a=0.5)TranSim (a=0.25)

Figure 21. The throughput distribution of the 50 long-livedflows.Note that the results from TranSim are normalized (×1/α).

0.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1

Short-lived Flows Long-lived Flows

Suc

cess

ful H

TT

P R

eque

sts

(%)

Flow Type

OriginalFSP (maxNode=60)FSP (maxNode=30)

TranSim (a=0.5)TranSim (a=0.25)

Figure 22. The success ratio of long-lived and short-lived HTTPflows.

9. DETER Testbed Experiments

In this section, we discuss two sample experimentson the DETER testbed [5] that compare Harpoon [13],Swing [12], and Tmix [11]. We directly use the author-provided Harpoon implementation, but port Tmix andSwing to DETER. The network topology is the sameas in Fig. 2(a) where all links are 10 Mbps with 10 msdelay. Only 3 macro-flows, flow 0, flow 4, and flow 6,are included to simplify comparisons among the tools.

Flow 4 is an HTTP flow generated by httperf [26].The requested file size is 100 kB and the request rateis 5 per second for a total of 600 requests. The requesttimeout is set to 3 seconds to make the flow more sen-sitive to the dynamics of flow 0. Flow 6 (only used inthe second experiment) emulates a pulsing DoS attack.The idle period is 5 seconds and 40 TCP connectionsarrive during the attack period. This arrival rate and theflow size of 50 kB saturate the 10 Mbps link during theattack periods. In the first experiment, flow 0 (labeledFlow I) is also an httperf flow with the same param-eters as flow 4, but with an exponentially distributedrequest inter-arrival time (mean=0.15 seconds). In thesecond experiment, flow 0 (labeled Flow II) consists of10 clients downloading a series of files from a server.All files are 500 kB and the “think time” between con-secutive downloads is 2 seconds. In iteration 1 of thesecond phase of FSP, we collect traces for all flows onlink R9-R0, and use them to model missing flows in iter-ation 2. We repeat each experiment 5 times and averagethe results.

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Flow I Flow II

Suc

cess

ful H

TT

P R

eque

sts

(%)

Flow Type

OriginalHarpoon

SwingTmix

Figure 23. The success ratio of flow 4.

The results of the two experiments are depicted inFig. 23. In the first experiment (Flow I), results fromTmix and Swing are close to the original scenario. Al-though all three tools correctly model the traffic andnetwork conditions, Harpoon has the lowest fidelity be-cause of its use of time granularity. Unlike the other

16


two methods that inject exactly 600 TCP connections,Harpoon divides time into intervals of lengthInterval-Duration, configured to 60 seconds in this experiment,and does not aim to accurately model dynamics withinan interval. Due to this, Harpoon generates more ag-gressive flow 0 traffic, which reduces the success ratiofor flow 4. In the second experiment (Flow II), Swingyields the highest fidelity, because connections within asession are not modeled independently. Unlike Harpoonand Tmix, a connection will not start before the previ-ous one is finished, even during the attack period whenconnections take longer. The think time between down-loads is preserved, and the modeled traffic in iteration 2is no more aggressive than the original scenario.

Comparing the three methods, Harpoon has the low-est fidelity but exhibits the lowest complexity. UnlikeSwing and Tmix that require packet-level traces, a muchsmaller Netflow trace is used by Harpoon. A trace thatincludes 0.8 M packets or 12 k connections required74 MB from tcpdump but was only 1.2 MB in Netflowformat. Collecting flow-level traces takes less effortcompared to tcpdump, since Netflow is typically sup-ported by routers. Swing and Tmix have similar storagerequirements. However, while Tmix models connec-tions independently, Swing’s structural model has thehighest fidelity since correlations among connections ina session are captured. Tmix gives good results withmoderate complexity in all our experiments when con-nections arenot highly correlated. In our implementa-tions of Tmix and Swing, a 74 MB tcpdump trace canbe processed in only 35 seconds by Tmix, whereas anadditional 40 seconds are required by Swing.

Table 7. Properties captured by different traffic modeling tools.

Property Swing Tmix Harpoon

Average traffic volume Yes Yes YesConnection start time/size Yes Yes NoSession-level think time Yes No No

Packet timing/order No No No

Table 7 summarizes example properties that can beextracted using different tools. None of the three toolscan precisely capture the original packet-level behaviorsuch as the timing and order of packets or the packetdelay jitter. While Swing and Tmix are able to extractmore details from the traces, all three tools can be usedto model the average traffic volume of flows, and can beintegrated into FSP to provide results with different de-grees of fidelity according to the experimenter require-ments.

10. Discussion

10.1. Choice of Modeling Tool

The choice of the traffic modeling tool does not al-ter the FSP algorithms. The procedures to extract thenetwork conditions and the locations where traces mustbe collected are independent of the tool. Using Table 7as a guideline, we can identify the appropriate tool thatcan be used to capture the required flow and networkcharacteristics. For example, consider a one-day tracewith macro-flows that are composed of a large numberof independent TCP connections. One should use Har-poon in this scenario since it is not required to modelthe exact order of TCP connections to generate work-load that matches the traffic volume. Harpoon has thelowest complexity among the tools.

Although it is possible to integrate more sophisticatedmodeling tools in FSP for higher fidelity, current toolsfocus on transport-level and session-level characteris-tics, and require the flows to have similar application-level behavior in both the original and the partitionedscenarios. For instance, consider a video streaming ap-plication that automatically adjusts its bit rate accordingto the encountered network conditions. Compared to theoriginal scenario, the application transmits more traf-fic in a less congested sub-scenario experiment. Sincethe highly variable application behavior cannot be eas-ily extracted from the different iterations of the sub-scenario experiments using current modeling tools, re-sults from FSP may have lower fidelity.

10.2. Scalability of FSP

Given a network scenario and the available machinesin a testbed (maxNode), FSP can partition the sce-nario, regardless of the size of the network, as long asthe longest flow in the network traverses no more thanmaxNodenodes. In the extreme case, each sub-scenariowill contain only a single flow and all traffic generationnodes (e.g., Tmix nodes and delay boxes) are embeddedon the routers.

We define the scaling factor of FSP as the size of theoriginal network scenario divided bymaxNode. As oneincreases the scaling factor in an FSP experiment (i.e.,selecting a smallermaxNodevalue), the number of in-teracting sub-scenarios increase and can adversely im-pact the experimental fidelity. The optimal scaling fac-tor is often challenging to predict without conductinga series of FSP experiments. Our experience from theevaluation experiments indicates that FSP can provideacceptable accuracy when applied to a network scenariothat is one order of magnitude larger than the testbedsize.

17


10.3. Applications of FSP

FSP can be applied to both network simulationand testbed experiments. Since the partitioned sub-scenarios require fewer computational resources for asimulator or fewer testbed machines, larger experimentscan be conducted on a resource-limited experimentalplatform when partitioned by FSP.

FSP can aid parallel simulation. Unlike most parallelsimulators that require manual partitioning of the net-work topology, FSP can automatically partition a largeexperiment into sub-scenarios that can be executed inparallel.

The first phase of FSP can also be used to analyzedependencies and tune an experiment. For example,consider assigning nodes randomly in a network to gen-erate background traffic. The flow dependency graph(FDG) can be used to analyze if the nodes are assignedproperly, i.e., ensure that the background traffic inter-acts with target flows.

11. Related Work

The experimental scalability problem has been stud-ied in the context of simulation, emulation, and testbedexperiments. The proposed approaches can be broadlyclassified into two categories: (1) approaches that re-duce the size or events in a given experimental sce-nario, and (2) approaches that perform intelligent re-source allocation to map a given scenario onto availableresources.

The goal of the approaches in the first category isto generate adownscaledversion of the original net-work scenario that preserves important properties of theoriginal scenario. For example, Panet al. [24] pro-pose Small-scale Hi-fidelity Reproduction of NetworkKinetics (SHRiNK). Using SHRiNK, one can constructa downscaled network replica by sampling flows, reduc-ing link speeds, and downscaling buffer sizes and ActiveQueue Management (AQM) parameters. The intuitionbehind their approach is to reduce the traffic and the re-sources consumed by that traffic by the same factor.

Instead of sampling traffic flows, Kimet al. [23] pro-pose TranSim to slow down the simulation and sampletime intervals(also referred to astime expansion). Bymaintaining the bandwidth-delay product invariant, net-work dynamics (such as queue sizes) and TCP dynamics(such as congestion windows) remain unchanged in theprocess of network transformation.

Another noteworthy approach in the first categoryis DSCALE, proposed by Papadopouloset al. [14].DSCALE includes two methods, DSCALEd and

DSCALEs, that prune uncongested network links,based on earlier work on queuing networks [27]. Theirfollow-up work considers how to identify uncongestedlinks for pruning [18]. Petitet al. [28] investigate meth-ods similar to DSCALE, and point out that downscalingmethods are highly sensitive to network traffic, topol-ogy size, and performance measures. This is consistentwith our findings in [25].

Instead of pruning uncongested links in a path, thepath emulator proposed by Sanagaet al. [29] simplifiesa network path into a single hop. By collecting param-eters from end-to-end observations of the Internet, theemulator abstracts characteristics of the path and canemulate the path without the detailed router-level topol-ogy. Other work has also considered the downscalingproblem in specific contexts. For example, Weaveretal. [30] focus on downscaling worm attacks. Carletal. [31] study how to preserve routing paths among Au-tonomous Systems (ASes) while reducing the numberof ASes through Gaussian elimination. Krishnamurthyet al. [32] consider preserving topological characteris-tics when reducing a network graph.

Approaches in the second category map an experi-mental scenario onto available resources. These ap-proaches include the application of a range of paralleland distributed simulation techniques such as in [6, 33].For example, Walkeret al. [34] employ software vir-tualization to migrate running node images from oneswitch to another, in order to maintain the proximity ofthe nodes attached to each RF switch.

An important technique in this category is virtualiza-tion. The capacity of a testbed scales when multipleexperimental nodes are hosted as virtual machines ona single physical machine [7, 35]. Container based net-work emulators [36, 37, 38] utilize lightweight OS-levelvirtualization techniques. These tools run high fidelity,but small scale, emulation testbeds on a single machine.Real-time network simulators such as [39, 40, 41, 42]are able to interact with real network traffic and furtherimprove the capacity of existing testbeds. In contrast toFSP, approaches in this second category typically mapmultiple nodes in the original scenario to a single nodein the experiment, potentially introducing artifacts inexperiments that overload resources, especially in DoSexperiments [3, 37].

Our approach is orthogonal to techniques in both cat-egories, and can be integrated with them. For example,downscaling techniques can be applied to an experimen-tal scenario before or after FSP to simplify the originalscenario or to speed up the execution of a sub-scenario.Virtualization techniques can also be used on a sub-scenario when appropriate, allowing it to be executed

18


on a smaller number of testbed machines. FSP is a sim-ple platform-independent approach for different typesof experiments, including DoS experiments that posesignificant challenges with other approaches [3, 25, 37].

12. Conclusions and Future Work

In this paper, we have proposed a platform-independent mechanism, Flow-based Scenario Parti-tioning (FSP), to partition flows in a large network ex-periment into a set of smaller experiments that can besequentiallyexecuted. The results of the smaller exper-iments approximate the results of the original experi-ment. FSP is platform-independent since it does not re-quire any modifications to the experimentation testbed.Since the original large experiment and the partitionedsmaller experiments can be viewed as independent ex-periments, our approach can be integrated with existingscaling solutions. For example, we can use our tools tounderstand or simplify a large network experiment be-fore applying virtualization or hybrid simulation tech-niques.

Our results from simulation and DETER testbed ex-periments indicate that FSP approximates applicationperformance under different levels of congestion andopen/closed-loop traffic. Our future work plans includeoptimization of the partitioning process, and an in-depthanalysis of the granularity of modeling interacting par-titions.

We are also experimenting with FSP on a variety oftopologies and flow mixes, including large CDNs andP2P systems. The focus of these experiments is to fur-ther explore the fundamental tradeoff between experi-mental fidelity and space/time complexity of the exper-imentation process. Finally, we are examining the in-tegration of hybrid simulation, emulation, and experi-mentation techniques into FSP, in order to relax the as-sumptions we made, especially regarding dynamic routechanges and route symmetry.

Acknowledgments

This work has been sponsored in part by NorthropGrumman Information Systems, and by NSF grantCNS–0831353. Part of this work appeared in the Pro-ceedings of the IEEE International Conference on Dis-tributed Computing Systems in June 2011.

References

[1] Digital fears emerge after data siege in Estonia,http://www.nytimes.com/2007/05/29/technology/29estonia.html(2007).

[2] The network simulator,http://www.isi.edu/nsnam/ns/.[3] R. Chertov, S. Fahmy, Forwarding devices: From measurements

to simulations, ACM Transactions on Modeling and ComputerSimulation 21 (2) (2011) 12:1–12:23.

[4] Network emulation testbed,http://www.emulab.net/.[5] Cyber-defense technology experimental research laboratory

testbed,http://www.isi.edu/deter/.[6] Parallel/distributed ns, http://www.cc.gatech.edu/

computing/compass/pdns/index.html.[7] M. Hibler, R. Ricci, L. Stoller, J. Duerig, S. Guruprasad,

T. Stack, K. Webb, J. Lepreau, Large-scale virtualization in theEmulab network testbed, in: Proc. of USENIX ATC, 2008.

[8] S. Robinson, Simulation: The Practice of Model Developmentand Use, Wiley, 2004.

[9] R. Ricci, C. Alfeld, J. Lepreau, A solver for the network testbedmapping problem, in: SIGCOMM Comput. Commun. Rev.,2003.

[10] K. Schloegel, G. Karypis, V. Kumar, The sourcebook of parallelcomputing, Morgan Kaufmann Publishers Inc., 2003, Ch. Graphpartitioning for high-performance scientific simulations.

[11] M. C. Weigle, P. Adurthi, F. Hernandez-Campos, K. Jeffay, F. D.Smith, Tmix: a tool for generating realistic TCP applicationworkloads in ns-2, in: SIGCOMM Comput. Commun. Rev.,2006.

[12] K. V. Vishwanath, A. Vahdat, Realistic and responsive networktraffic generation, in: Proc. of SIGCOMM, 2006.

[13] J. Sommers, P. Barford, Self-configuring network traffic gener-ation, in: Proc. of IMC, 2004, pp. 68–81.

[14] F. Papadopoulos, K. Psounis, R. Govindan, Performancepre-serving topological downscaling of Internet-like networks,IEEE Journal on Selected Areas in Communications 24 (12)(2006) 2313–2326.

[15] M. Berger, S. Bokhari, A partitioning strategy for nonuniformproblems on multiprocessors, IEEE Transactions on Computers100 (36) (1987) 570–580.

[16] G. Karypis, V. Kumar, A fast and high quality multilevelschemefor partitioning irregular graphs, SIAM Journal on ScientificComputing 20 (1) (1998) 359–392.

[17] J. Cao, W. Cleveland, Y. Gao, K. Jeffay, F. Smith, M. Weigle,Stochastic models for generating synthetic HTTP source traffic,in: Proc. of INFOCOM, 2004.

[18] F. Papadopoulos, K. Psounis, Efficient identification of uncon-gested Internet links for topology downscaling, in: SIGCOMMComput. Commun. Rev., 2007.

[19] N. Spring, R. Mahajan, D. Wetherall, T. Anderson, MeasuringISP topologies with rocketfuel, Networking, IEEE/ACM Trans-actions on 12 (1) (2004) 2–16.

[20] Rocketfuel to ns tool suite,http://www.cs.purdue.edu/homes/fahmy/routing.html.

[21] Distributed intrusion detection system,http://www.dshield.org/.

[22] J. Mirkovic, A. Hussain, S. Fahmy, P. Reiher, R. Thomas,Accu-rately measuring denial of service in simulation and testbed ex-periments, IEEE Transactions on Dependable and Secure Com-puting 6 (2) (2009) 81–95.

[23] H. Kim, H. Lim, J. C. Hou, Accelerating simulation of large-scale IP networks: A network invariant preserving approach, in:Proc. of INFOCOM, 2006.

[24] R. Pan, B. Prabhakar, K. Psounis, D. Wischik, SHRiNK: amethod for enabling scalable performance prediction and effi-cient network simulation, IEEE/ACM Transactions on Network-ing 13 (5) (2005) 975–988.

[25] W. Yao, S. Fahmy, Downscaling network scenarios with denialof service (DoS) attacks, in: Proc. of Sarnoff Symposium, 2008.

[26] D. Mosberger, T. Jin, httperf-a tool for measuring web server

19


performance, in: SIGMETRICS Perform. Eval. Rev., 1998.[27] D. Eun, N. Shroff, Simplification of network analysis inlarge-

bandwidth systems, in: Proc. of INFOCOM, 2003.[28] B. Petit, M. Ammar, R. Fujimoto, Scenario-specific topolgy re-

duction in network simulations, in: Proc. of SPECTS, 2005.[29] P. Sanaga, J. Duerig, R. Ricci, J. Lepreau, Modeling andemula-

tion of Internet paths, in: Proc. of NSDI, 2009.[30] N. Weaver, I. Hamadeh, G. Kesidis, V. Paxson, Preliminary re-

sults using scale-down to explore worm dynamics, in: Proc. ofACM workshop on Rapid malcode, 2004.

[31] G. Carl, S. Phoha, G. Kesidis, B. B. Madan, Path preservingscale down for validation of internet inter-domain routingpro-tocols, in: Proc. of Winter Simulation Conference (WSC), 2006.

[32] V. Krishnamurthy, M. Faloutsos, M. Chrobak, L. Lao, J.-H. Cui,A. Percus, Reducing large Internet topologies for faster simula-tions, in: Proc. of IFIP Networking, 2005.

[33] D. M. Nicol, J. Liu, M. Liljenstam, G. Yan, Simulation oflarge-scale networks using SSF, in: Proc. of Winter Simulation Con-ference (WSC), 2003.

[34] B. Walker, J. Seastrom, G. Lee, K. Lin, Addressing scalabilityin a laboratory-based multihop wireless testbed, in: Mobile Net-works and Applications, 2009.

[35] K. Yocum, E. Eade, J. Degesys, D., Becker, J. Chase, A. Vahdat,Toward scaling network emulation using topology partitioning,in: Proc. of MASCOTS, 2003.

[36] B. Lantz, B. Heller, N. McKeown, A network in a laptop: Rapidprototyping for software-defined networks, in: Proc. of the9thACM SIGCOMM Workshop on Hot Topics in Networks, 2010.

[37] B. Heller, N. Handigol, V. Jeyakumar, B. Lantz, N. McKeown,Reproducible network experiments using container based emu-lation, in: Proc. of CoNEXT, 2012.

[38] J. Ahrenholz, C. Danilov, T. Henderson, J. Kim, Core: A real-time network emulator, in: Military Communications Confer-ence, 2008. MILCOM 2008. IEEE, 2008.

[39] J. Liu, Y. Li, Y. He, A large-scale real-time network simulationstudy using prime, in: Proc. of Winter Simulation Conference(WSC), 2009.

[40] ns-3,http://www.nsnam.org/.[41] S. Wang, Y. Huang, NCTUns distributed network emulator, In-

ternet Journal 4 (2) (2012) 61–94.[42] D. Gupta, K. Vishwanath, A. Vahdat, DieCast: Testing dis-

tributed systems with an accurate scale model, in: Proc. ofNSDI, 2008.

20

Flow-based Partitioning of Network Testbed …Flow-based Partitioning of Network Testbed Experiments...

Documents

Transcript of Flow-based Partitioning of Network Testbed …Flow-based Partitioning of Network Testbed Experiments...