Traffic generation for network simulation Tom Kelly NS Tutorial - - PowerPoint PPT Presentation

Traffic generation for network simulation Tom Kelly NS Tutorial - Microsoft Research Cambridge 9th December 2005

Overview n Why traffic generation is important n Basics of traffic modeling n Open system models n Closed system models n Common pitfalls and concerns n Summary

Why traffic generation is important n Traffic patterns impact system design, dependency, capability, and efficiency n Want to simulate traffic to answer questions about deployment, network architecture, and basic behavior

Basic traffic modeling n Source-sink packet flow model n What rule drives when packets are sent? n How big are they? n System level flow model n When do flows arrive and depart? n What parameters do we need to simulate? n How do we classify the possible patterns to give clarity to the results? n What regimes are in and out of scope?

Source basics n Open loop flows n no feedback exerted on the flow once it begins n exists and often an effective system design choice n e.g. VoIP, games, multicast, DNS, malicious traffic n Closed loop flows n packet transmission driven by feedback based on network state n often harder to understand but makes for robust, adaptable, and scalable systems n e.g. DCCP, TCP

Packet voice modeling n Each flow uses a coding scheme and suggests a model n e.g. 8Khz, 8bit sample, 20ms frames suggests 80Kbps 200b CBR or with silence suppression exponential on/off periods 500ms n Calls arrive according to a Poisson process intensity l n Calls have random length mean t n e.g. exponential mean 200 seconds n Total load is determined by all three n e.g. CBR has 80. t.l Kbps

Something to try - voice n Construct a voice network with a single bottleneck n What jitter and loss metrics make sense for this application? n How do these metrics respond as you change the load level? n Play with the distributional assumptions, what effect do they have? n What can you conclude?

Bulk transfer problem n A backup service allows users to automatically backup their data; the operator is thinking of introducing priority queuing to offer a higher grade of service n It wants to see whether users will notice any impact as a result of this change

Bulk transfer model n Flows transfer an amount X in a single TCP connection n X ~ pareto, exponential n Flow arrivals Poisson intensity l n large number of independent users n For a bottleneck of B we should be able to handle about up to l. E[X] n not very interested in small l. E[X] n probably worth checking a couple of distributions for X and a couple of system sizes B

Something to try - bulk transfer Construct a multi-hop network with two cross paths n Try doing loading so 25% on verticals and 62.5% on horizontal n Try using priority based queuing and drop tail, crank up the CBQ n parameter to give the vertical flows Plot the backlog for runs of 30min intervals on some reasonable n sized systems When you’ve done it, you’ll be surprised n Its not an artifact n

Web traffic n A web user n asks for a page n looks at it n asks for another page n reads an article n asks for another page n What is interesting about this process?

Web traffic model n A web user n request for multiple objects of heavy tailed size n waits for these transfers to (partially) complete n request for multiple objects of heavy tailed size n waits for these transfers to (partially) complete… n Very wide range of transfer lengths n most bytes in a few long transfers n most connections a few short transfers n The arrival process is elastic n slower throughput gives fewer connection arrivals

Web traffic model (2) n What are the distributions driving this? n User think times n e.g. Pareto scale 1.0, shape 1.5 gives mean 3 n Number of concurrent requests n e.g. Pareto scale 2.4, shape 1.0 gives mean 1.7 n Size of concurrent requests n e.g. Pareto scale 800, shape 1.11 gives mean 8000 These parameters consistent with SURGE findings.

Web traffic parameter scalings n More users but transfers all same size n Same users but larger object sizes n Same users and patterns but more requests embedded in each iteration n Could imagine real systems with these scalings and each case could have different behavior

Web traffic references n Generating representative Web workloads for network and server performance evaluation. Barford and Crovella, in ACM SIGMETRICS ‘98 . n Changes in Web client access patterns: Characteristics and caching implications. Barford, Bestavros, Bradley, and Crovella, in WWW Journal Dec ‘98 , n Dynamics of IP traffic: A study of the role of variability and the impact of control. Feldmann, Gilbert, Huang, and Willinger ACM SIGCOMM 1999.

Tips for doing this in ns2 n Structure your code to allow quick assumption changes n separate flows from system process n make all the distributions plug and play n otcl or C++ n otcl quick to hack but leaks and can be slow to run n C++ slower to code but can be quicker to run n Cache flow pairs in large simulations n less object construction-destruction n keeps classifier tables lean and mean

Common pitfalls n Crazy parameters; complete overload, underload, and more mind-bending system implications n Modeling closed loop as open loop; shocking garbage n Presentation of results misleads the reader n Think about graph scales; do insets and big picture

Things that are always hard n Getting measurements and models that faithfully characterize real systems n do some measurement and modeling! n Checking your traffic model isn’t bust n try limit cases n Simulating large numbers of traffic sources n cache src-dest pairs in otcl n write C++ based connection level objects

Summary n Ultimately interested in application performance metrics n Closed loop and open loop traffic are different n Think about system level process and source-destination packet traffic n Be careful to justify your range of parameters n Measurement and model verification