Emulation of IPbased Network

1
Emulation of IP-based Network

• Manqing Huang
• Advisor Professor Lionel M. Ni
• June 2000

2
Motivation

• Problems were identified with the previous
  version of the network emulator
• Demand for emulating more network features,
  including network topologies
• My interests in networks and kernel module
  development

3

• We decided to build a new network emulator based
  on the original design. The result of work is the
  IP-based network emulator

4
Part 1 Previous Work on the Network Emulator

• Overview
• Internal architecture
• Problems and limitations

5
Overview of the Previous Version of Network
Emulator

• Original design and implementation by former
  master student Kaushik K. Dam.
• A Linux kernel module intercepts and handles IP
  packets to emulate traffic behavior such as
  delay, bandwidth, and loss.
• Tcl/Tk GUI allows users to configure the emulator
  and to read statistical information.

6
Overview (Continued)

• By configuring routing tables, a senders packets
  travel to the emulator. The emulator kernel
  module is between the IP layer and the Ethernet
  driver. Packets are sent out to the the receiver
  after they have been handled by the module.

7
Internal Architecture of The Emulator Module
8
Problems and Limitations

• Problems found when the original emulator was
  used
• Limitation on emulated bandwidth
• Maximum bandwidth emulated 1.2mbps
• Not accurate in all cases
• Limitation on delay emulation
• Delay_time bandwidth lt 120(kbpssecond)
• It requires users to set up a bandwidth queue
  length, which is experience dependent
• Linux may crash if the bandwidth queue length is
  set too high

9
Problems and Limitations (Contd)

• Features not emulated
• Path MTU
• Out of order of packets
• Bit error rate in transmission
• Multiple traffics with different characteristics
  simultaneously
• Network topologies

10
Part 2 IP-based Network Emulator (My Work)

• Calibration of the original network emulator
• Improvement of the previous network emulator
• Design and implementation of the IP-based network
  emulator

11
Calibration of the Emulator

• Problems in bandwidth and delay emulation was
  found when the previous network emulator was used
• Writing sender programs and receiver programs to
  calibrate the previous network emulator

12
Improving Bandwidth Emulation

• Bandwidth is emulated by setting timers to
  postpone the transmission of each packet.
• CPU time in Linux kernel is divided into time
  slices called jiffies (1 jiffy 10 millisecond),
  A timer with positive value will not expire until
  at least next jiffy. Therefore.
• Only 100 packets are allowed to be transmitted in
  a second.
• Unless the packet size is a multiple of the data
  size allowed to be transmitted in a jiffy the
  emulation was not accurate.

13
Improving Bandwidth Emulation (Contd)

• Improvements
• Once a timer expires, send as many packets as
  allowed in a jiffy according to the bandwidth
• If the packet size is not a multiple of the size
  allowed in this jiffy (or vice versa), reimburse
  the size not used in this jiffy to next jiffy
• Result
• 97.5 accurate, up to 100 mbps

14
Computing the Bandwidth Queue Length

• A scenario in the kernel
• Jiffy 1 emulator busy sending packets, new
  coming packets backlogged
• Jiffy 2 backlogged packets coming into emulator
• Jiffy 3 other tasks
• Jiffy 4 emulator busy sending packets again
• So the queue should buffer packets allowed to be
  sent during 3 jiffies
• Experiments show that the queue should buffer 4
  jiffies of packets to guarantee no packets are
  dropped due to queue overflow, therefore
• Queue_length 4 (8 bw) / (HZ MTU)

15
Improving Delay Emulation

• Increase delay queue length
• Recode the program to avoid recursive calls that
  result in run time stack overflow

16
Overcoming System Crash

• Crashes happen when the kernel is out of memory
  (physical memory)
• To avoid using up kernel memory, memory usage
  checking code is embedded in the emulator
• When memory is low, the emulator drops incoming
  packets instead of buffering them
• Result the system is more robust and the delay
  emulation ability is only limited by the physical
  memory

17
New Features Emulated

• Out of order
• Another queue is added to selectively delay
  packet transmission to reorder the packet
  sequence
• Bit error rate
• MTU

18
Internal Architecture of the New Emulator Module
19
Loading Multiple Emulator Modules Into Kernel

• Multiple modules can emulate multiple traffic
  behaviors simultaneously
• Kernel space is shared for all kernel tasks.
  Symbols (variables, routines) are shared if they
  are global and non-static
• The original implementation of the network
  emulator does not avoid the sharing conflict
• The new implementation of the program avoids the
  sharing conflict and enables the modules to work
  together

20
Topology Emulation

• Why we need to emulate topology.
• Many companies have private WANs, whose
  topologies are known.
• Behavior of an individual part of the network is
  better understood than that of the entire
  network.
• Topology emulation help users to test their
  protocols and applications in a more natural
  manner.

21
Mapping the Topologies to Graphs

• A connection point of emulator modules are mapped
  to a vertex (node)
• An emulator module is mapped to an edge (arc)
  with weight
• A topology is mapped to a directed non-cyclic
  graph with weighted arcs

22
Topologies Emulated

• Topologies emulated should
• Consume a limited number of CPU cycles
• Be easy for users to configure
• Non-cyclic restriction
• Guarantee packets to be sent during finite hops
• Easy to implement and understand

23
Topologies Emulated(contd)

• An example of an emulated topology

24
Design of The Topology Emulation

• Multiple topologies can be emulated
  simultaneously.
• Each emulator module creates a virtual network
  interface. Each virtual network interface
  associates itself with a topology. Packets sent
  to that virtual network interface go through that
  topology.
• Multiple modules are connected arbitrarily for a
  topology.

25
Design of The Topology Emulation(contd)

• For example, if we load 16 emulator modules, then
  we have 16 virtual network interfaces, we can
  have 16 different network topologies.
• Each network interface views an individual
  topology.
• If an emulator module belongs to multiple
  topologies, traffic for different topologies
  interact with one another in that module.

26
Presentation of Topologies

• A topology is presented using a state machine. A
  packet changes its state when it goes through an
  emulator module

27
Packet Dispatch Policies

• We need algorithms to route packets across a
  network topology
• More specifically, when the output of one module
  forks into the inputs of multiple modules, a
  dispatch policy is needed

28
Packet Dispatch Policies (Contd)

• Seven dispatch policies have been implemented
• random selection
• weighted selection
• shortest queue first
• greatest free queue size first
• lowest drop rate first
• greatest adjusted free queue size first
• backward propagation on full
• flooding policy

29
Dispatcher

• Dispatching information (queue size, loss rate)
  is kept in shared memory
• The dispatcher code is distributed in every
  emulator module
• The dispatcher is invoked when a packet enters a
  new state

30
Preamble and Episode

• There are two handler pointers for each emulator
  module. They are called when a packet is entering
  a module and leaving a module respectively. The
  socket buffer of that packet is passed to these
  two handlers. This enables users to have their
  own routines that process the packets passing
  through an emulator module.

31
Experiments With the IP-based Network Emulator in
NCAT Research

• The IP-based Network Emulator has been used in
  the non-cryptographic authenticated
  transmission(NCAT) research
• The NCAT uses packets called message digests to
  cover (i.e., check sum) other packets. A message
  digest covers a number of packets including data
  packets and other message digest packets
• The IP-based network emulator helps to prove the
  effectiveness of this method in preventing or
  detecting attacks

32
IP-based Network Emulator Helps the NCAT Research

• It emulates different topologies between the
  sender and the receiver
• Each emulator module emulates a traffic with
  certain behaviors
• It allows users to attach the attacker programs
  as the preamble and episode handlers of each
  module to attack the packets
• It works in a real-time manner
• It helps protocol designers to verify the
  performance of the protocol and to choose the
  parameters that have the best combination of low
  overhead and good protection

33
IP-based Network Emulator Helps the NCAT
Research(contd)

• The experiment results show that.
• A higher digest-to-data ratio (digest rate) and a
  larger window size are likely to have better
  protection/detection result.
• In a environment with multiple transmission paths
  and the attacker does not have access to 1/3 out
  of all the paths, a digest rate of 0.2 and a
  window size 8 can protect all the transmissions.

34
Acknowledgement

• Thanks to Dr. Ni for his constant guidance and
  support
• Thanks to Dr. Mutkas instruction on the Linux
  kernel
• Thanks to Dr. Esfahanian for teaching me about
  graph theory related algorithms
• Thanks to Kaushik Dam for developing the original
  Network Emulator
• Thanks to Vasu for helping me with the Linux
  kernel and networking
• Thanks to my friends for their valuable
  discussions with me during the whole project