Discrete Event Simulation - Ch. 1

1

• The Current Simulator(s)

2

• It consists of several modules - trying to mimic
  functionalities. Some of the modules are used
  for some simulations, but not all modules are
  used for all simulations.
• What is being simulated?
• a) Sources
• b) Packets
• c) Switches
• d) Virtual Channels
• e) Fibers
• f) Packet Queues

3

• Simplest Example
• 1) A Source whose output enters
• 2) A Switch whose output is sent to
• 3) A Switch which directs the packets to
• 4) A Destination

4

• The distances from the sources to the switches
  are assumed "small" (1km 4µs).
• The switches are assumed "far apart" (1000km
  4ms).
• The bit transmission rate (in MH) is assumed
  high enough - and the packets are assumed small
  enough - so that multiple packets can be
  simultaneously in transit between switches , or
  even between a source and a switch.
• The source (or sources) can transmit packets at
  a high enough rate so that the switch must queue
  packets before retransmitting them.
• Some mechanism is thus required to manage this
  "excess traffic" this will depend on the nature
  of the traffic being managed.

5

• What is a Source?
• It is an entity that must contain information
  about
• The time when it will next need service
• The rate at which it currently sends packets
• The destination of the packets
• The kind of packet it is about to send (regular
  or management)
• The algorithm - if any - it will use to adjust
  its sending rate
• A mechanism by which it will create and send a
  packet
• Anything else?...

6

• What is a Packet?
• It is an entity that must contain information
  about
• The type of packet it is (regular or management)
• The destination it is meant for (address or
  path)
• If it is a management packet it will contain the
  information it needs to exchange with the other
  network entities
• The time when it will next need service (a real
  packet does NOT need this information)
• Anything else?...

7

• What is a Switch?
• It is an entity that must contain information
  about
• The rate at which it can process a packet
• The mechanism used to route the packet
• The mechanism used when the packet arrival rate
  is larger than the switch service rate
• The mechanism used to exchange information with
  management packets
• The information it needs to collect and maintain
  in order to exchange it
• Anything else? Much else, but...

8

• What is a Fiber?
• It is an entity that must contain information
  about
• The time it takes for light to move from one end
  to the other (proportional to length - as a first
  approximation).
• The bit rate it can support - usually higher
  than any rate at which a switch can transmit.
• Anything else?

9

• What is an Event?
• Something that needs service of some sort at a
  specific time.
• This could be the "event" of a source sending a
  packet the "event" of a switch receiving a
  packet the "event" of a switch retransmitting a
  packet the "event" of a destination receiving a
  packet etc
• Note that all of these "events" are time driven
  for each event there is a "time" when the event
  must take place. Two or more events could occur
  at the same "time". Events of different types
  could occur at the same time.

10
How many distinct objects must we associate with
events? Do Sources need to be associated with
events? Do Switches need to be associated with
events? Do Packets need to be associated with
events? Do Fibers need to be associated with
events? Do Destinations need to be associated
with events? Does anything else need to be
associated with events?
11
Which entities need to be associated with
events? That will depend on what we are trying
to simulate, and how. Fiber if a Fiber is
providing only "distance" - and therefore just a
time delay between a "departure event" and an
"arrival event", is there any reason why it
should be associated with its own events? If the
Fiber also provides "noise" errors, at some
random intervals, dependent on whatever
properties the fiber has, there may be a reason
to treat a Fiber as associated with an event - in
this case we will also need to know which packets
are in which Fiber at which time.
12
Source sources must create packets according to
some given distributions - independently of other
events in the system. The rate could be uniform
- x packets/sec - or it could be determined by
some other (more complex) probability
distribution that governs the time intervals
between packets, as well as the size of the
individual packets. Recall that ATM has packets
of uniform size (54 Bytes). It appears likely
that sources will have to be associated with
their own events. Destination Destinations
receive packets and ? Do they perform any
actions that are - in time - random and
independent of any other events in the system, or
are they likely to simply respond to a packet
arrival?
13
Switch Does a switch need events of its own, or
does it simply respond to packet arrivals and
departures? Do any of the "internal" activities
of the switch need their associated events? If
the switch is just a "packet mover" it may not
need any internal events - it simply responds to
a "packet event". If the switch is more than a
packet mover, it might well need its own events
errors, transmission rate changes due to external
conditions, changes in the mapping between
Virtual Path and Physical Path (if those cannot
be triggered by packet events), etc.
14
Packet This appears to be the structure that is
responsible for most of the events in the system
after packets are generated by a Source, they
must move along Fibers, from Switch to Switch,
until they reach a Destination. In "old" and
"short" networks, the number of packets is rather
small just remember that in a 1km long fiber of
a 1MH network you may find at most 5 bits - the
light or EM pulses that correspond to a "bit
signal". In long and fast networks (5000km Fiber
at 20TH), the number of bits can be on the order
of (201012)(5103410-6) 41011 Which may
correspond to about 41010 characters (on the
order of 109 ATM packets), or, at 4000 characters
per (Encyclopaedia) page, 10,000,000 pages...
15
Realistic simulations of geographically large
networks will require us to represent billions of
packets simultaneously in the network. This will
require large amounts of processing power and
memory, and data structures that are as
insensitive to size as possible. We now turn to
a version of a Discrete Event Simulator, and
discuss some of the design decisions and some of
the shortcomings.
16

• Q What is an EVENT?
• A A Data Structure with a run-time determinable
  Type (the type of event) and Time Stamp.
• ANSI C is (probably) the most portable language
  available today, consistent with the requirement
  that it be efficiently implemented and
  efficiently executed on all available hardware.
• ANSI C (along with all more "strongly typed"
  languages) has some difficulty representing
  heterogeneous objects in LISTS or ARRAYS.
• UNIONS are likely to use the largest amount of
  space required by any one of their individual
  constituents, and should be probably avoided (at
  least on a first pass).

17
Q What information must this data structure
contain? A a Type field, and a Time field
and We will take a good look at a mess, since
this is what usually happens to a simulator which
has been used to simulate several different
"realities" - fields get re-used, names are not
properly updated, documentation becomes outdated,
etc... The structure - in its original form - was
used to represent BOTH a Source and a Packet.
Having a single data structure represent both
means that it can be passed as a parameter in all
relevant functions. Unfortunately, the
functionality of the two types of objects needs
to be different, which means that - in the
interest of avoiding space waste - space NAMED in
a meaningful way for one object will be reused in
an obscure way for the other.
18
struct simCell int type // type of event
- one five double time // event clock time -
float double svclock // Last time RM cell
is seen double genTime // Time at which the
cell was generated double roundTrip // The
network round trip NO delay long cellNum //
Cell number int src_id // source id
int channelID // ID of channel used by
source int switchID // ID of switch at which
cell is now int setUp // Regular, First or
Last RMcell int RMcell // 1 Resource
Management - 0 no int CIbit // Congestion
indication 1 yes, 0 not double ER //
Percentage of Switch Buffer Use long
buflen // switch buffer length double
rampUp // Available Bandwidth at Switch int
nrm // counter for Nrm 0 to 32 double
prop // propagation delay double acr //
allowed cell rate long heapIndex // The index
in the heap array
19
What are the fields that should be common to
every event? Possibly just type time
heapIndex The first two are obvious - why the
third? Remember the number of packets (and
therefore of events) we must be prepared to keep
track of? Since events are ordered by TIME it
would seem natural to use an "event queue", where
the event "about to happen" is removed from the
head of the queue, while the "event just
happened" and newly time-stamped is inserted in
the correct position in the queue (NOT
necessarily at the end - why?), which requires
Ordered Insertion, and Ordered Insertion into a
list of size n has time complexity O(n).
20
If n 10, this is not bad if n 105, or
larger, life gets substantially more complicated
the number of comparisons becomes very large, and
has to be repeated FOR EVERY EVENT PROCESSED. A
data structure which allows general insertion and
removal of the highest priority item to take
place in time O(log2(n)) is the HEAP (Priority
Queue) if n 106, O(log2(n)) 20, And this
latter function increases BY 1 whenever the size
of the event set DOUBLES. The heapIndex field is
used to keep track of the index of a particular
event in the appropriate eventHeap.
21
What are the types of events we need to
represent? // Event types for the
scheduler define SesCellGen 1 // Packet
generated by source define SesRMArr 2 // RM
Packet returns to source define NodeCellArr 3 //
Packet arrives at a switch define NodeCellDep
4 // Packet leaves the switch define BwdRMProc
5 // Process backward RM Packet This makes a
number of assumptions that may not be true for
another type of network simulation sources do
not correspond to events except when they
generate a new packet. All remaining events are
packet driven events the normal packets go from
source to destination, while the Resource
Management packet must return to the source and
provide it with the information it collected
along the path.
22
The event types reappear in the main function of
the scheduler void DoEvent(struct simCell eptr,
double clock) switch (eptr-gttype)
case SesCellGen // Cell generation by source
// Code for this case ...
break case SesRMArr // RM Cell completes
round trip. //... break
case NodeCellArr // Node receives a FORWARD
cell //... break case
NodeCellDep // Packet about to depart switch
//... break case BwdRMProc
// Packet on return path //...

23
Let's take one of the cases, and look at the
details Packet generation needs to deal with A)
the availability of space in the simulation B)
the kind of packet to be generated C) the
insertion of the packet into the network (and the
eventHeap) D) the insertion of the source into
its own eventHeap (or a general eventHeap).
24
case SesCellGen // Cell generation by
source free HeapSize(eventHeap) 1 // Next
Packet? if (free gt MAXBUF) // No more
Packets to get eptr-gttimeclock(double)(CELLB
ITS/eptr-gtacr/MEGA) InsertIntoHeap(sourceHeap,
eptr) // Put source back else // Set up
packet, to be sent to network
eptr-gtcellNum eptr-gtcellNum 1 ptr
eventHeapfree // get a free cell if
(eptr-gtnrm) // a REGULAR Packet
SetUpPayLoadCell(eptr, ptr, clock)
eptr-gtnrm eptr-gtnrm - 1 // decrement counter
else // an RM Packet
SetUpRMCell(eptr, ptr, clock) eptr-gtnrm
Nrm // reset counter
ptr-gttype NodeCellArr // a cell going forward
ptr-gttime clock eptr-gtprop // at first
switch InsertIntoHeap(eventHeap,ptr) // on
its way... eptr-gttimeclock(double)(CELLBITS/
eptr-gtacr/MEGA) if (eptr-gtsetUp!2)
InsertIntoHeap(sourceHeap, eptr) break
25
case NodeCellArr // Switch receives a FORWARD
cell currSwitch switchArrayeptr-gtswitchID
slot (long)floor((clock/currSwitch-gtcurrCe
llTime)) slot // The next "time
slot" at switch eptr-gttype NodeCellDep //
Depart next. // how long in queue eptr-gttime
(double)((slot currSwitch-gtqueLength)
currSwitch-gtcurrCellTime)
eptr-gtprop 0.0 if (eptr-gtRMcell) //
Resource Management Cell UpdateForwardSwitch(e
ptr, currSwitch) // Trace call ..
Omitted InsertIntoHeap(eventHeap, eptr) //
update the switch queue currSwitch-gtqueLength
currSwitch-gtqueLength 1 break
26
DoEvent is called within a loop in
Schedule while (clock lt maxTime) // more
time to go //get earliest Source or Packet
event ? if (HeapSize(eventHeap) gt 0) if
(sourceHeap1-gttime gt eventHeap1-gttime)
eptr RemoveFromHeap(eventHeap) else
eptr RemoveFromHeap(sourceHeap)
else eptr RemoveFromHeap(sourceHeap)
clock eptr-gttime// Update simulation clock
// Trace it... if ((clock runTime) gt
trace_clock) trace(eptr) // NOW DO IT
DoEvent(eptr, clock) / while /
27
One must decide how to break time ties - they
will not happen very often, but We have decided
to break them in favor of ACTIVE processes
(Sources) rather than passive ones (packets).
The mechanism that allows this has introduced a
complication we have to manage two Priority
Queues rather than one. There may be other
reasons to keep two or more separate Priority
Queues. We will try to determine these reasons
(if any) as we go.
28
Question Can we find a better way to maintain
multiple types of events in such a way that
changes during modification of the simulator can
be kept a) to a minimum b) orthogonal to what
does NOT need to be changed? Answer The USUAL
approach involves modularization AND information
hiding. On the other hand, it seems "necessary"
to keep a certain uniformity - and time and space
efficiency - in the fundamental data structures,
so that modularization should attempt to maintain
these properties. At this point we are using the
same structure for both types of packets and for
sources, with a quite real confusion of fields.
29
Possible PARTIAL problem Redesign the simCell
data structure so that it is much more flexible
than now. Show that the flexibility did not
occur by giving up large amounts of execution and
space efficiency. Design a simulation that makes
substantial use of this flexibility. One may
explore C classes run-time tests should show
that the space and time requirements have changed
"little" - certainly less than a factor of 2 or 3
(if for the worse)...
30
An ATM packet consists of 53 Bytes, of which the
first 5 are important to the network, the
remaining 48 containing the payload. The first 28
bits contain address information. The next three
bits contain payload type (PT) information (user
or management) and indication on the congestion
status along the path. The 32nd bit contains
indication of the packet priority in case of
congestion (CLP). The next byte contains a
one-bit error correcting / multiple bit error
detecting code if the address is compromised
beyond recovery, the packet is discarded. The
rest of the REGULAR packet is important to us
only if we wish to study error recovery problems.
31
Since the general assumption is that ATM networks
will be extremely reliable, a first approximation
would assume that no header corruption will
occur, so there is no need to simulate the
HeaderErrorChecking field. The address field
can be simulated by any methods that appear
adequate in this simulator we just define a
"channel" that can be shared by any number of
sources the channel is used by sources entering
at the same switch and exiting at the same
switch. Different channels are associated with
different "bundles" of sources. Each switch has a
way of determining how a packet coming in on one
channel is to be forwarded. Since no error
recovery is attempted, there is no association of
a packet with any specific destination - beyond
the "last ATM switch" of a channel.