Simulation and Analysis Tools

1
Simulation and Analysis Tools

• Jennifer Hou, "Overview," 5 minutes
• Mary Baker, "The Narses Application-level
  Protocol
• Simulator," 20 minutes
• Louise Moser, "Testing and Analysis of
  Distributed
• Programs and Protocols," 10 minutes
• Jennifer Hou, "JavaSim A component-based
  network simulation/emulation environment," 20
  minutes

2
Overview
3
Narses

• Goal simulate application-level protocols in
  very large networks with very many flows over
  long periods of time.
• Problem packet-level simulators generally incur
  per-packet overhead and simulate the behavior of
  packets and flows at switches and routers in the
  interior of the network.
• Our solution a set of (currently only two)
  network models that trade off timing accuracy for
  speed of simulation. The most detailed model
  makes assumptions about the topology of the
  network to avoid simulating behavior in the
  interior of the network.

4
Testing and Analysis of Distributed Programs
Protocols

• Goal More reliable distributed programs and
  protocols, particularly for those that must be
  fault tolerant.
• Problem Distributed programs and protocols are
  difficult to test and debug, particularly because
  of the concurrency involved. Establishing the
  availability and reliability of a fault tolerant
  distributed system is also a challenge.
• Solution We will investigate and use tools that
  other researchers in the MURI have developed to
  address these topics, and will consider what new
  techniques we might develop.

5
JavaSim Large-Scale Network Simulation/Emulation

• Composability
• Allow study of different networking problems in a
  unified, coherent framework.
• Extensibility
• Allow code reuse and insertion of new codes so as
  to accommodate new architectures and services.
• Level of abstraction
• Allow simulation conducted at different levels of
  abstraction and at different granularities.
• Diagnosis and monitoring
• Allow diagnosis and monitoring to be conducted at
  the component level in a time efficient manner.

virtual

• Heterogeneity in terms of
• Physical layer characteristics
• MAC through transport layer protocols
• Mobility models
• Network connectivity models
• Real vs. virtual environments

real

• JavaSim Two-tier Solution
• Component-based, Autonomous
• software architecture that realizes the
• notion of software ICs
• Generalized modeling framework that
• can be easily extended

6
JavaSim

• Network Systems Laboratory
• Department of Computer Science
• University of Illinois at Urbana Champaign
• P.O.C Jennifer C. Hou
• http//www.javasim.org

7
JavaSim Large-Scale Network Simulation/Emulation

• Composability
• Allow study of different networking problems in a
  unified, coherent framework.
• Extensibility
• Allow code reuse and insertion of new codes so as
  to accommodate new architectures and services.
• Level of abstraction
• Allow simulation conducted at different levels of
  abstraction and at different granularities.
• Diagnosis and monitoring
• Allow diagnosis and monitoring to be conducted at
  the component level in a time efficient manner.

virtual

• Heterogeneity in terms of
• Physical layer characteristics
• MAC through transport layer protocols
• Mobility models
• Network connectivity models
• Real vs. virtual environments

real

• JavaSim Two-tier Solution
• Component-based, Autonomous
• software architecture that realizes the
• notion of software ICs
• Generalized modeling framework that
• can be easily extended

8
Autonomous Component Architecture

• Inspired by IC chip design

Signal
Pin

IC Chip
Specifications In data book
Pin 1
Pin 2
9
Autonomous Component Architecture

• Component building block of a software system
• Port the only means for a component to interface
  with outside world
• Events sending and receiving data

10
Autonomous Component Architecture

• Contract
• Specification of a component
• A component may be bound to multiple contracts
• Port contract specifies how data is
  exchangedbetween two components
• Component contract specifies the
  input-outputrelation of a component

11
Autonomous Component Architecture

• Components are loosely coupled
• A component is fully specified by its associated
  contracts
• A component interfaces with the rest of the
  system only at its ports
• Advantages
• A component can be implemented and tested
  independently
• A component can be easily extracted for reuse in
  the same context
• The hyper-spaghetti phenomenon is restrained from
  growing outside of a component

12
ACA - Independent Execution Context

• When data arrive at a port, the component
  processes it in an independent execution context
  (thread)
• A component may process different pieces of data
  at about the same time

thread 2 at comp. B
thread 1 at comp. A
thread 3 at comp. C
thread 4 at comp. B
data
data
time
13
ACA - Runtime

• New threads/execution contexts are created behind
  the scene in the runtime.

time
Runtime
A
B
Runtime
A
B
14
ACA - Information Exporting

• A component has designated ports to export
  special info/events at run time
• Error exported when some error occurs
• Garbage thrown out due to some policy or
  capacity setting in the component
• Debug exported whenever is appropriate
• Event exported whenever is appropriate
• Trace exported when any data arrives at, or
  departs from, the component
• One can enable/disable exporting of each type of
  information, from a component, at run time

15
ACA - Information Exporting

• Debugging and Monitoring
• 1. Each component has a designated Information
  port.
• 2. One can enable/disable exporting of each type
  of information at run time.
• 3. One may attach an instrument component to
  the infoport of a component to inspect its
  operation during runtime.

16
The Modeling Framework in JavaSim

• The modeling framework
• Is decomposed based on the arbitrary and complex
  protocol graphs with simple protocols concept for
  better module reuse.
• Can be used to implement different network
  protocols at different levels of abstraction.

• Implementation supported in JavaSim
• Internet with best-effort, integrated services,
  and differentiated services architectures
• Wireless ad hoc networks with detailed antenna
  propagation models and IEEE 802.11b
• Sensor networks with power management and
  topology control

17
Class Organization in JavaSim
18
Components Supported in JavaSim
19
Components Supported in JavaSim
Differentiated Services Components
Allow real applications to be ported onto JavaSim.
20
Scalability Test

• Famous single bottleneck scenario
• n TCP connections, 2n hosts, 2 routers and one
  bottleneck link with buffer 4n Kbytes
• n varied from 10 to 10,000
• Experiment setup
• Dual PentiumIII 600MHz, 256MByte RAM

21
Scalability Test

• Stress test
• Size of the event queue is at least n
• Routing table size is (n1)
• Testees
• JavaSim v1.0 with Tcl, Python, or Java as the
  glue language, and with an event-driven
  simulation engine or with a real-time
  process-driven simulation engine.
• Ns-2 v2.1b8a
• SSFNEt v1.3
• JavaSim and SSFNET are tested on two JVMs IBM
  JDK1.3 and Blackdown 1.3.1
• Metrics
• Setup time time to create the scenario
• Time to complete 100/500/1000-second simulation

22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
Current Work Fluid Based Simulation

• Packet-based simulations do not scale with the
  size of networks to be simulated.
• We are investigating use of fluid models to
  expedite simulation.
• A cluster of closely spaced packets may be
  modeled as a single fluid chunk with a constant
  fluid rate.
• A set of fluid model-based equations is derived
  and used to characterize system evolution.
• The fluid rate changes are kept track of and
  treated as events.
• Fluid simulation in JavaSim is based on the
  time-stepped discrete simulation technique.

27
Fluid-Model Based Simulation

• Areas in which fluid simulation has been applied
• Analysis on TCP congestion control and AQM
• Components for fluid simulation
• FIFO Queue
• Fluid Leaky Bucket
• FIFO Queues of GPS
• Non-work-conserving Schedulers
• FIFO Queue Scheduler
• TCP congestion control

28
Fluid-Model Based Simulation for WLAN?

• IEEE 802.11 for WLAN
• Analytical model for fluid simulation
• Characterize frame flows
• Derive throughput

29
Fluid-Model Based Simulation for WLAN?
30
Experiment Results

• of events execution time when the number of
  nodes is fixed with 500

31
Experiment Results

• of received packets relative bandwidth error

32
Experiment Results

• of events execution time when packet size is
  fixed with 250 bytes (100 slot times)

33
Experiment Results

• of received packets relative bandwidth error

34
Mixed-Mode Simulation

• Fluid-based models trade accuracy for a
  significantly lower event rate, but what if we
  would like to know the network dynamics of
  certain flows at the packet level?
• Mixed-mode simulation
• Foreground traffic is simulated as a packet-based
  flow
• Background flows are simulated with the fluid
  model (many background flows can be bundled into
  a single flow).

35
Mixed-Mode Simulation on a Single Link
Modified flowchunk list (Background traffic)
Flowchunk packets
Flow 1
Flow 1
Regular foreground packets
Flow 2
Flow 2
Flow 3
Flow 3
0
h
Time
Flowchunk list (Background traffic)

Packet Buffer
Incoming packets (Foreground traffic)
Outgoing packets (Some are dropped)
36
Future Work

• Extend Javasim to include components in other
  emerging network architectures, such as wireless
  sensor networks.
• Extend JavaSim to realize network emulation.
• Transport between JavaSim virtual nodes video
  streams captured by WebCam and/or PDA messages.
• Parallelize JavaSim
• Message-passing based vs. shared memory.
• Process-driven simulation (as opposed to
  event-driven simulation).
• Conservative synchronization approaches used in
  event-driven simulation can be applied?