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.lKbps

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

• perator is thinking of introducing

priority queuing to offer a higher grade

• f 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

n

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 parameter to give the vertical flows

n

Plot the backlog for runs of 30min intervals on some reasonable sized systems

n

When you’ve done it, you’ll be surprised

n

Its not an artifact

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