Realistic and Responsive Network Traffic Generation

1
Realistic and ResponsiveNetwork Traffic
Generation

• K. Vankatesh and A. Vahdat
• ACM SIGCOMM06 / 2006
• Presented by Luis Ortiz

2
Purpose

• Swing
• a network-responsive traffic generator that
  accurately captures the packet interactions of a
  range of applications using a simple structural
  model

3
Introduction

• The Idea
• From observed traffic at single point in the
  network
• Extract distributions for
• user
• application
• network behavior
• Generate live traffic

4
Contribution

• Perhaps, the first TG able to reproduce
  burstiness in traffic across a range of
  timescales using a model applicable to a variety
  of network settings

5
The Goal

• Design a framework capable of generating live
  network traffic representative of a wide range of
  both current and future scenarios
• Such framework would be valuable in a variety of
  settings that include
• capacity planning
• high-speed router design
• queue management studies
• bandwidth measurements tools
• network emulation
• worm propagation models

6
How to Define Traffic?

• Traffic generation to result in a time-stamped
  series of packets arriving at and departing from
  a particular network interface with realistic
  values for at least layer 3 (IP) and layer 4
  (TCP/UDP) headers
• This traffic should accurately reflect arrival
  rates and variances across a range of time scales

7
Challenges

• An underlying model
• simple
• semantically meaningful parameters that fully
  specify the characteristics of a given trace
• Techniques to populate the model from existing
  packet traces to validate its efficacy in
  capturing trace conditions
• should reproduce the essential characteristics of
  the original trace

8
Burstiness

• Swing matches burstiness for
• both bytes and packets
• both directions of a network interface
• a variety of individual applications within a
  trace
• HTTP, P2P, SNMP, NNTP, etc.
• original traces at a range of speeds and taken
  from a variety of locations

9
The Swing Approach

• Requirements
• Metrics for success
• Realism
• generate realistic traces for a range of usage
  scenarios
• Responsiveness
• flexibly and accurately adjust trace
  characteristics
• Maximally random
• able to generate a family of traces constrained
  only by the target characteristics of the
  original trace and not the particular pattern of
  communication in the trace

10
Structural Model

• Users
• Determine the communication characteristics of a
  variety of applications
• how often users become active
• the distribution of remote sites visited
• think time between individual requests
• Sessions
• Individual session characteristics
• does an activity correspond to downloading
  multiple images in parallel from the same server
• different chunks of the same file from different
  servers
• number and target of individual connections
  within a session

11
Structural Model (cont.)

• Connections
• Determine the characteristics of connections
  within a session
• such as their destination
• the number of request/response pairs
• the size of the request and corresponding
  response
• wait time before generation a response
• spacing between requests
• Network characteristics
• Flow characterization
• extract link loss-rates, capacities, and
  latencies for connecting paths

12
Applications Signature

• Using these observations, it is developed a
  parameterizations of individual application
  sessions. A set of values of these parameters
  constitutes an applications signature
• To successfully reproduce packet traces, it is
  necessary to extract appropriate distributions
  from the original trace to populate each of the
  parameters

13
Architecture

• Parameterization Methodology
• Assign packets and flows in a trace to
  appropriate application classes (based on
  destination ports numbers)
• Group packets into flows and calculate the size
  of data objects flowing in each direction of the
  connection (using TCP flags, sequence number and
  acknowledgment number advancements)
• Given per-flow, per-application information,
  apply a series of rules to extract values for the
  target parameters

14
Architecture (cont.)

• Extracting network characteristics
• For each host (unique IP address) communicating
  across the target link, it is required to measure
  the delays, capacities, and loss rates of the set
  of links connecting the host to the target link

15
Architecture (cont.)

• Link Capacities
• Extract consecutive data packets not separated by
  a corresponding ACK from the other side. The time
  difference between these packet-pairs gives an
  estimate of the time for the packets to traverse
  the bottleneck link from the host to the target
  link
• Packet Size Link Capacity Time Difference

16
Architecture (cont.)

• Loss Rates
• Measure loss rates using retransmissions and a
  basic algorithm
• The algorithm starts by arranging TCP sequence
  numbers corresponding to packets of a flow, based
  on time-stamps, then if there is a missing
  sequence number in the sequence, it usually means
  that the corresponding packet was lost en-route
  to the target link. This loss event (hole) is
  used for estimating p1

17
Architecture (cont.)

• Generating Swing packet traces
• Given application and network models, it is
  possible to generate the actual trace based on
  these characteristics
• The strategy is
• generate live communication among endpoints
  exchanging packets across an emulated network
  topology.
• The output trace is simply a tcpdump of all
  packets traversing the target during the duration
  of a Swing experiment

18
Architecture (cont.)

• For each application in the original trace,
  generate a list of sessions and session start
  times according to the distribution of
  inter-session times measured in the original
  trace
• Randomly assign individual sessions to generators
  to seed the corresponding configuration file

19
Architecture (cont.)

• At startup, each generator reads a configuration
  file that specifies
• its IP address
• time-stamps
• number of RRE for each session
• destination address and communication pattern for
  each connection within an RRE
• packet size distribution for each connection

20
Validation

• Results for three representative applications
  taken from
• KAZAA from CAIDA
• SQUID from Auck
• HTTP from Mawi

21
Validation (cont.)
22
Validation (cont.)