The Current Simulator(s)

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 (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,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->type) { 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 > MAXBUF) { // No more Packets to get eptr->time=clock+(double)(CELLBITS/eptr->acr/MEGA); InsertIntoHeap(sourceHeap,eptr); // Put source back } else {// Set up packet, to be sent to network eptr->cellNum = eptr->cellNum + 1; ptr = eventHeap[free]; // get a free cell if (eptr->nrm) { // a REGULAR Packet SetUpPayLoadCell(eptr, ptr, clock); eptr->nrm = eptr->nrm - 1; // decrement counter } else { // an RM Packet SetUpRMCell(eptr, ptr, clock); eptr->nrm = Nrm; // reset counter } ptr->type = NodeCellArr; // a cell going forward ptr->time = clock + eptr->prop; // at first switch InsertIntoHeap(eventHeap,ptr); // on its way... eptr->time=clock+(double)(CELLBITS/eptr->acr/MEGA); if (eptr->setUp!=2) InsertIntoHeap(sourceHeap, eptr); } break;

25. case NodeCellArr: // Switch receives a FORWARD cell currSwitch = &switchArray[eptr->switchID]; slot =(long)floor((clock/currSwitch->currCellTime)); slot++; // The next "time slot" at switch eptr->type = NodeCellDep; // Depart next. // how long in queue eptr->time = (double)((slot + currSwitch->queLength) *currSwitch->currCellTime); eptr->prop = 0.0; if (eptr->RMcell) // Resource Management Cell UpdateForwardSwitch(eptr, currSwitch); // Trace call .. Omitted InsertIntoHeap(eventHeap, eptr); // update the switch queue currSwitch->queLength = currSwitch->queLength + 1; break;

26. DoEvent is called within a loop in Schedule: while (clock <= maxTime) { // more time to go //get earliest: Source or Packet event ? if (HeapSize(eventHeap) > 0) { if (sourceHeap[1]->time > eventHeap[1]->time) eptr = RemoveFromHeap(eventHeap); else eptr = RemoveFromHeap(sourceHeap); } else eptr = RemoveFromHeap(sourceHeap); clock = eptr->time;// Update simulation clock // Trace it... if ((clock + runTime) > 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.