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