Discrete Event Simulation 2 The Current Simulators Discrete

Discrete Event Simulation - 2 • The Current Simulator(s)

Discrete Event Simulation - 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;

Discrete Event Simulation - 2 • 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

Discrete Event Simulation - 2 • The distances from the sources to the switches are assumed "small" (≤ 1 km = 4µs). • The switches are assumed "far apart" (≥ 1000 km = 4 ms). • 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.

Discrete Event Simulation - 2 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? . . .

Discrete Event Simulation - 2 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? . . .

Discrete Event Simulation - 2 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. . .

Discrete Event Simulation - 2 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? …

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 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?

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 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?

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 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 1 km long fiber of a 1 MH network you may find at most 5 bits - the light or EM pulses that correspond to a "bit signal". In long and fast networks (5000 km Fiber at 20 TH), the number of bits can be on the order of (20*1012)*(5*103*4*10 -6) = 4*1011 Which may correspond to about 4*1010 characters (on the order of 109 ATM packets), or, at 4000 characters per (Encyclopaedia) page, 10, 000 pages. . .

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 • 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).

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 struct sim. Cell { int type; // type of event - one five double time; // event clock time - float double svclock; // Last time RM cell is seen double gen. Time; // Time at which the cell was generated double round. Trip; // The network round trip : NO delay long cell. Num; // Cell number int src_id; // source id int channel. ID; // ID of channel used by source int switch. ID; // ID of switch at which cell is now int set. Up; // 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 ramp. Up; // Available Bandwidth at Switch int nrm; // counter for Nrm : 0 to 32 double prop; // propagation delay double acr; // allowed cell rate long heap. Index; // The index in the heap array };

Discrete Event Simulation - 2 What are the fields that should be common to every event? Possibly just type time heap. Index 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).

Discrete Event Simulation - 2 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(log 2(n)) is the HEAP (Priority Queue): if n ~ 106, O(log 2(n)) ~ 20, And this latter function increases BY 1 whenever the size of the event set DOUBLES. The heap. Index field is used to keep track of the index of a particular event in the appropriate event. Heap.

Discrete Event Simulation - 2 What are the types of events we need to represent? // Event types for the scheduler #define Ses. Cell. Gen 1 // Packet generated by source #define Ses. RMArr 2 // RM Packet returns to source #define Node. Cell. Arr 3 // Packet arrives at a switch #define Node. Cell. Dep 4 // Packet leaves the switch #define Bwd. RMProc 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.

Discrete Event Simulation - 2 The event types reappear in the main function of the scheduler: void Do. Event(struct sim. Cell *eptr, double clock) { switch (eptr->type) { case Ses. Cell. Gen: // Cell generation by source // Code for this case. . . break; case Ses. RMArr: // RM Cell completes round trip. //. . . break; case Node. Cell. Arr: // Node receives a FORWARD cell //. . . break; case Node. Cell. Dep: // Packet about to depart switch //. . . break; case Bwd. RMProc: // Packet on return path //. . . } }

Discrete Event Simulation - 2 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 event. Heap); D) the insertion of the source into its own event. Heap (or a general event. Heap).

Discrete Event Simulation - 2 case Ses. Cell. Gen: // Cell generation by source free = Heap. Size(event. Heap) + 1; // Next Packet? if (free > MAXBUF) { // No more Packets to get eptr->time=clock+(double)(CELLBITS/eptr->acr/MEGA); Insert. Into. Heap(source. Heap, eptr); // Put source back } else {// Set up packet, to be sent to network eptr->cell. Num = eptr->cell. Num + 1; ptr = event. Heap[free]; // get a free cell if (eptr->nrm) { // a REGULAR Packet Set. Up. Pay. Load. Cell(eptr, clock); eptr->nrm = eptr->nrm - 1; // decrement counter } else { // an RM Packet Set. Up. RMCell(eptr, clock); eptr->nrm = Nrm; // reset counter } ptr->type = Node. Cell. Arr; // a cell going forward ptr->time = clock + eptr->prop; // at first switch Insert. Into. Heap(event. Heap, ptr); // on its way. . . eptr->time=clock+(double)(CELLBITS/eptr->acr/MEGA); if (eptr->set. Up!=2) Insert. Into. Heap(source. Heap, eptr); } break;

Discrete Event Simulation - 2 case Node. Cell. Arr: // Switch receives a FORWARD cell curr. Switch = &switch. Array[eptr->switch. ID]; slot =(long)floor((clock/curr. Switch->curr. Cell. Time)); slot++; // The next "time slot" at switch eptr->type = Node. Cell. Dep; // Depart next. // how long in queue eptr->time = (double)((slot + curr. Switch->que. Length) *curr. Switch->curr. Cell. Time); eptr->prop = 0. 0; if (eptr->RMcell) // Resource Management Cell Update. Forward. Switch(eptr, curr. Switch); // Trace call. . Omitted Insert. Into. Heap(event. Heap, eptr); // update the switch queue curr. Switch->que. Length = curr. Switch->que. Length + 1; break;

Discrete Event Simulation - 2 Do. Event is called within a loop in Schedule: while (clock <= max. Time) { // more time to go //get earliest: Source or Packet event ? if (Heap. Size(event. Heap) > 0) { if (source. Heap[1]->time > event. Heap[1]->time) eptr = Remove. From. Heap(event. Heap); else eptr = Remove. From. Heap(source. Heap); } else eptr = Remove. From. Heap(source. Heap); clock = eptr->time; // Update simulation clock // Trace it. . . if ((clock + run. Time) > trace_clock) trace(eptr); // NOW DO IT Do. Event(eptr, clock); } /* while */

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 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.

Discrete Event Simulation - 2 Possible PARTIAL problem: Redesign the sim. Cell 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). . .

Discrete Event Simulation - 2 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 32 nd 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.

Discrete Event Simulation - 2 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 Header. Error. Checking 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.