Discrete-Event Simulation of Network Systems Using Distributed Object Computing

Transcription

1 Dscrete-Evet Smulato of Network Systems Usg Dstrbuted Object Computg Welog Hu Arzoa Ceter for Itegratve M&S Computer Scece & Egeerg Dept. Fulto School of Egeerg Arzoa State Uversty, Tempe, Arzoa, Emal: Abstract: A modelg ad smulato evromet supportg scalable etwork system aalyss ad desg s descrbed. The evromet, called DEVS/DOC, eables smulato modelg of etwork systems where hardware ad software layers of the system are modeled separately ad combed based o the cocept of quatum Dstrbuted Object Computg. The key beeft of ths reegeered smulato evromet s support for scalablty. Of partcular terest s the ablty to evaluate alteratve etwork cofguratos where may software ad hardware compoets of a system ca be accouted for ad aalyzed smultaeously. A seres of smulatos are developed to show the capabltes of dstrbuted object computg modelg ad ts realzato usg the DEVSJAVA modelg ad smulato evromet. Keywords: computer etworks, dscrete-evet system specfcato, dstrbuted object computg, HW/SW, performace aalyss, scaleable smulato, quatum modelg. 1 INTRODUCTION Numerous smulato modelg frameworks, methodologes, ad techques have bee proposed for desgg software or hardware aspects of etwork systems. Some of these smply provde add-o capabltes to hadle smulato modelg sce each geerally s devsed for modelg hardware or software layers of a etworked system [1][2][3]. I cotrast to usg ad-hoc meas to support combed software ad hardware smulato modelg of etworked system, t s mportat to have a methodology that heretly supports hardware/software codesg. Such a methodology, smlar to co-desg for embedded systems, ca have overcome heret challeges accoutg for tradeoffs etwork system desg. Dstrbuted object computg (DOC) [4] provdes a approach to modelg ad smulatg dstrbuted object computg systems as a set of software compoets mapped oto a set of etworked processg odes. Dstrbuted object computg was exteded ad mplemeted usg the Hessam S. Sarjougha * Arzoa Ceter for Itegratve M&S Computer Scece & Egeerg Dept. Fulto School of Egeerg Arzoa State Uversty, Tempe, Arzoa, Emal: sarjougha@asu.edu dscrete evet system specfcato [5] ad DEVSJAVA evromet [6]. It s teded for co-desg of etworked systems. Dstrbuted object computg provdes three abstractos to model ad smulate a system s software ad hardware layers ad ther teractos [7][8][9]. The software layer s captured as a dstrbuted cooperatve object (DCO) model to preset teractg software objects, both local, to a hardware ode or a set of dstrbuted hardware odes. The hardware layer represets a loosely coupled etwork (LCN) model of processg odes, etwork gates, ad tercoectg commucatos. The dstrbuted DCO software assged to LCN hardware forms a object system mappg (OSM). The smulato models of DCO, LCN, ad OSM compoet structures ad behavor dyamcs were formally characterzed usg the DEVS formalsm [8][9]. As a modelg ad smulato framework DEVS/DOC, ad partcular DOC 1.0, was bult o top of DEVSJAVA DOC 1.0 supports modelg of dstrbuted etwork systems such as formato systems ad supply cha etworks (e.g., see [10][11]). It provdes mportat features whch ca help users buld ther ow smulato models usg the prcple of compoet-based modelg. It also offers a user fredly evromet for smulato expermets. The vsualzato ad cotrolled mapulato features of smulato executo provde a varety of smple to powerful features (e.g., cocurret evet hadlg ad processg) for extesve smulato studes. Recet advaces software desg, programmg laguages, ad developmet evromets led to DEVSJAVA 2.7, a redesg of DEVSJAVA The ew DEVSJAVA evromet offers capabltes such as realtme smulato ad powerful data structures, whch are key for modelg complex structural ad behavoral aspects of software ad hardware etwork compoets [6]. These capabltes tur offer mportat features to be corporated to DOC. For example, oe of the ma dffereces betwee DEVSJAVA 2.63 ad DEVSJAVA 2.7 s the use of the Java Collecto API. The use of DEVSJAVA 2.7, therefore, ecesstated redevelopg DOC 1.0. * To whom all correspodeces should be drected to.

2 I the remader of the paper, we wll descrbe DOC ad ts applcato to aalyss of a clet/server etwork system. I Secto 2, we revew the basc dstrbuted object computg cocepts ad some aspects of the DEVSJAVA 2.7 modelg ad smulato evromet. I Secto 3 we hghlght the core elemets of the DOC 2.0 smulato model compoets. To demostrate DEVS/DOC 2.0 capablty terms of scalablty, we preset a example of a smple etwork cosstg of a few to several hudred software ad hardware compoets Secto 4. I Secto 5, we dscuss future work ad preset some future research drectos. (partal class herarchy of DEVS/DOC 1.0 s show Fgure 2). Smlarly, a processor model s defed as a coupled model cosstg of trasport, router, ad cpu atomc models. Atomc ad dgraph are elemetary DEVS models. 2 BACKGROUND 2.1 Dstrbuted Object Computg Approach Dstrbuted Object Computg (DOC) s a coceptual framework for modelg hardware ad software compoets of etworked systems. DEVS/DOC s a realzato of DOC usg the DEVSJAVA modelg ad smulato evromet. Ths evromet supports smulato of combed software ad hardware for structural ad behavoral etworked systems. A DOC model cossts of a Loosely Coupled Network (LCN), Dstrbuted Cooperatve Object (DCO), ad Object System Mappg (OSM) models. A LCN model represets the hardware structure (topology) ad behavor (teracto) of tercoectg hardware ettes. A DCO model specfes software compoets ad structures. It defes how the DCO software compoets teract both terally ad exterally (.e., whe executed o the dstrbuted LCN hardware compoets). A OSM model specfes precsely how DCO compoets are to be mapped oto LCN hardware compoets. The separato ad tegrato of DCO ad LCN are mportat eablg modelers (aalysts ad desgers) to study () alteratve software desgs gve some hardware archtecture, () alteratve hardware desgs gve a collecto of teractg software compoets, () or combatos thereof. Fgure 1 presets a abstract vew of the dstrbuted object computg framework [8][9]. The DOC modelg approach called DEVS/DOC 1.0 was frst developed usg the DEVS framework ad fally realzed usg the Java techology. The DEVS framework eables modular, parallel model executo ad thus t offers a systematc bass for hadlg multple, cocurret evets as well as capabltes to orgaze a collecto of ettes ad ther mapulatos [6]. The capabltes offered by DEVS/DOC 1.0 template smulato models exted the geeral purpose (core) DEVS atomc ad coupled models. As show Fgure 1, software ad hardware objects belogg to the DCO ad LCN layers are sytheszed va OSM. For example, the swobject model supports hadlg put/output ports ad messages offered by atomc models Fgure 1. Dstrbuted Object Computg Approach swobject atomc trasport etty devs processor DEVSJAVA 2.63 dgraph dgraphdoc Fgure 2. DEVS/DOC 1.0 Partal Class Herarchy 2.2 DEVSJAVA 2.7 Smulato Evromet May mplemetatos of the DEVS framework have bee developed popular programmg laguages cludg Java. The DEVSJAVA 2.7 evromet s a ew geerato of DEVS-based modelg ad smulato evromets that separates the modelg ad smulato eges ad the user terface. Ths evromet offers ew capabltes ot foud DEVSJAVA 2.63 such as model type dscovery ad ru-tme executo usg logcal clock or wallclock (see [12]). DEVSJAVA 2.7 offers strog separato betwee modelg ad smulato eges, whch s mportat for supportg dstrbuted smulato usg

3 alteratve techologes such as CORBA [13] ad HLA [14]. Oe of the key DEVSJAVA APIs s GeCol [15]. Based o SDK 1.4 [16], t cossts of a set of cotaers ad utlty classes ecessary for all other modules. Ths API cotas the base class etty, whch serves as the root class for the modelg (gedevs.modelg), smulato (gedevs.smulato), ad vsualzato (smvew) modules [15]. I DEVSJAVA 2.7, the modelg module provdes basc modelg elemets cludg atomc ad coupled models such as devs ad atomc. The devs class exteds class etty wth methods to add put ad output ports so that a model ca sed ad receve messages.e., t supports dstrbuted commucato. Extedg from devs, the atomc class provdes state assgmet ad fuctos to process exteral ad teral evets. Wth DEVSJAVA 2.7, all atomc models ca ru as a separate compoet wth vewableatomc ad all coupled models ca be executed as a separate system wth vewabledgraph (see Fgure 3). The other basc modelg elemets the modelg module are ports ad coupled, whch allow couplg of atomc ad coupled models. dgraph vewabledgraph etty devs atomc vewableatomc Fgure 3. vewableatomc ad vewabledgraph Classes DEVSJAVA 2.7 Smlar to the modelg package, the smulato package cotas classes that execute the atomc ad coupled models ad thus trasmt messages. The classes the smulato package are realzatos of the DEVS parallel abstract smulator [6]. The atomcsmulator ad coupledsmulator are two of the key classes for hadlg the tmg of atomc ad coupled models ad ther exchage of output ad put evets. The other ma package s the SmVew, whch provdes GUI servces for vsualzg atomc ad coupled models (vewableatomc ad vewablecoupled), cofgurg smulato models, ad executg ad vewg the smulato dyamcs. A example of a atomc LCN model s called hub. The executo speed of the hub ca be cotrolled va the real tme factor. A model compoet ca receve put messages o oe or all of ts put ports (e.g., Lk1) ad cocurretly produce output messages o ts output ports (e.g., outlk2). The states of the hub atomc model (e.g., executo phase (passve) ad the durato whch the hub stays phase passve ( )) ca be vewed at ru tme. 3 DISTRIBUTED OBJECT COMPUING ENVIRONMENT I ths secto, we descrbe the ew DEVS/DOC modelg ad smulato evromet wth partcular emphass o the detals of atomc ad coupled DEVSJAVA model specfcatos for software ad hardware. We show the ew DOC model compoets ad ther role supportg smulato of relatvely large-scale etwork systems (a few thousad hardware ad software model compoets) usg DEVSJAVA DOC 2.0 Software ad Hardware Layers ad Ther Mappg The Dstrbuted Object Computg part of DOC 2.0 s desgated for modelg software objects ad teracto arcs. These software objects form a computatoal doma. A software object cotas both attrbutes (data members) ad methods (fucto). The sze of a software object s defed by the collectve memory requremets of these attrbutes ad methods. Whe a software object s voked, the sze parameter loads the supportg LCN processor memory. Message arcs ad vocato arcs are defed as software-object teractos. A message arc represets peerto-peer exchages betwee objects, whle the vocato arc represets clet-server type teractos betwee two software objects. The LCN compoets model the hardware aspect of a etwork. As metoed above, Object System Mappg plays a key role modelg the behavor or performace of dstrbuted object computg systems. It maps the DCO software objects oto the LCN odes so that the abstract behavor dyamcs of the software archtecture are costraed by the capacty of resources such as processor speed, memory sze, ad badwdth. Ths dstrbuted archtecture glued by OSM provdes flexblty ad eables users to aalyze ad desg dfferet software o the same hardware or dfferet hardware for the same software. 3.2 New DOC Specfcato The packages of DEVSJAVA 2.7 provde the basc capabltes that are used DOC 2.0. As metoed earler, sce DEVSJAVA 2.7 was completely redesged, a ew desg for DOC 2.0 became ecessary. The atomc models DOC 2.0 are exteded from vewableatomc, whch supports greater GUI ad executo capabltes compared to DOC 1.0. Smlar to atomc models, coupled models are exteded from dgraphdoc. Coupled models DOC 2.0

4 exted vewabledgraph, whch supports system level vsualzato of the smulato models. Also ulke DOC 1.0, whe users apply DOC 2.0 to set up ther ow modelg ad smulato system, there s o eed to resort to lowlevel (customzed) programmg to vsualze smulato executos. That s, as log as the applcato model exteds from the dgraphdoc class, the smulato ege smvew hadles the etre executo of the smulato. Fgure 4. Applcato Doma Modelg Usg DEVS/DOC The LCN ad DCO atomc models DOC 2.0 exted from vewableatomc. These models therefore allow vsualzato of hardware ad software models. DOC 2.0 supports coupled models at the hardware ad software levels, ad ther mappg at the OSM level. A smple example of a coupled model DOC 2.0 s the processor model. It cotas cpu, router, ad trasport atomc model compoets. 3.3 Applcato Layer DOC 2.0 provdes users wth flexble facltes ad methods to set up ther ow modelg ad smulato applcatos. Fgure 4 shows the relatoshps betwee DOC 2.0, DEVSJAVA 2.7 ad user defed applcatos. I the applcato layer, hardware or software compoets ca be defed as descedets of vewableatomc (va) ad coupled models ca be defed as descedets of vewabledgraph (vd). A system whch cotas several coupled models ca be defed as dgraphdoc (see Table 1). As a modelg ad smulato system, DOC 2.0 provdes a mechasm to cotrol ad motor the smulato process ad to collect ad aalyze output data from the smulato process usg the cocept of expermetal frame [4]. Tradtoally, a expermetal frame cludes three compoets: geerator, acceptor, ad trasducer. The geerator stmulates the system uder vestgato, the acceptor motors a expermet to see the desred codtos are met, ad the trasducer observes ad aalyzes the system outputs. Wth the help of vewableatomc DEVSJAVA 2.7, DOC 2.0 sets up the expermetal frame wth two classes, acceptor ad trasducer. The acceptor ca also stmulate the system by sedg fre messages. For a atomc or a smple coupled model, oe ca defe a trasducer to observe smulatos. However, for large smulato models, multple trasducers are eeded to hadle dfferet parts of smulatos separately. DOC 2.0 provdes the trasd_tuples class to collect ad aalyze the data from other trasducers (see Table 1). 4 A NETWORK SYSTEM EXAMPLE As a layered, dstrbuted framework, DOC 2.0 supports study of hardware/software co-desg. As alluded to earler, ths evromet s partcularly useful for aalyss ad desg of cocurret hardware ad software behavors. DOC 2.0 exteds the cocept of co-desg system developmet from the executo of oe or more processes o a sgle devce (embedded system) to the terdepedet executo of may processes rug o multple, dstrbuted, ad etworked heterogeeous devces (system of systems). The LCN, DCO, ad OSM buldg blocks equp the DOC 2.0 evromet wth mportat flexblty whe used as a toolkt for studyg dstrbuted systems. Next, we llustrate the key role of separato of software ad hardware layer modelg usg two clet/server system cofguratos. 4.1 Smulato Expermet Set-up As we dscussed above, ths paper's goal s to show the scalablty of DEVS/DOC 2.0. Ths evromet supports developmet of large-scale smulato expermets for studyg clet/server etwork protocols. A clet/server applcato executg over a etwork requres a server software compoet recevg requests from oe or may clet software compoets for processg executos over a set of hardware compoets. A model of a sgle-clet/server etwork cossts of three hardware compoets (two processors ad oe lk) ad two software compoets. A two-clet/server etwork model has a addtoal par of processor ad software smulato model compoets (see Table 1 ad Fgure 5). A N-clet/server model ca be geeralzed a model eeds to have addtoal processors, software objects, ad lks (see Table 2 for the LCN, DCO, ad OSM smulato model compoets). Each clet executes ts methods, seds requests (messages) to the server, ad receves processed requests (messages) after some tme perod. Partal specfcatos for the hub etheret, processor, software, ad acceptor smulato models are gve Table 3.

5 Table 1. Two-Clet/Server Network Compoets 1 server 2 clets 1 lk 3 etwork 3 processors 9 trasducers 1 acceptor Applcato objects terfaces DOC class swobject lk_etheret hub_lk processor trasducer acceptor package DCO LCN Expermet Compoets DEVS class va vd va package smvew Table 2. DOC Smulato Model Compoets the N-Clet/Server Network System LCN Layer DCO Layer OSM N processors (Proc-1,, 1 lk (Lk) N-clet (Clet-1,, Clet-) 1 server (server) each software object s Proc-) assged to a processor Fgure 5. System Decomposto of a Two-Clet/Server Network It should be oted that for a gve etwork topology, multple lks betwee the clets ad server may be used. However, gve our choce of the MAC (meda access cotrol) protocol ad the purpose of these expermets, we have used oe lk as a abstracto of multple lks. To study behavor of a etwork system va smulato, t s mportat to desg expermets. For example, as show Fgure 5, there are two trasducers where oe motors a lk ad aother motors a processor. Smlarly, there are trasducers to motor the software objects ad ther message exchages (see Fgure 5). To cotrol the executo of the model, a acceptor s defed whch part defes the start ad termato of a smulato scearo. The smulato scearo cosders each clet to have three tasks to perform, two of whch ca be processed by the clet tself (.e., usg ts ow desgated processor) ad oe set to the server (.e., processor assged to the server) va the lk. Oce the server receves a task from a clet, the server processor begs to process the task ad seds the completed task back to the requestg clet through the lk.

6 4.2 Performace Aalyss The model ad teracto descrbed above are straghtforward for a smple etwork (.e., oe that has a small umber of hardware ad software compoets ad teractos). However, as the umber of compoets creases, the dyamcs of the model quckly become dffcult to predct va drect extrapolato from small-scale smulato models. The clet/server models brefly descrbed above ca be studed terms of ther compoets. For example, we ca collect data (e.g., collso umber, successful trasmssos, ad badwdth utlzato) for the lk. Each expermet has a observato tme durg whch data ca be collected. Usg the DEVS/DOC terface, users ca chage the executo speed va the smulator s real-tme factor the smulato speed up or slow dow rate ca be adjusted terms of the smulator s real-tme clock. The observato tme eeds to be carefully selected. The smulato observato tme eeds to be greater tha the tme requred for the smulato models to satsfy some crtera. For example, a sutable crtero s to have the observato tme be greater tha the tme t takes for all the software objects (clets ad the server) to complete ther actvtes. Table 3. Selected Hardware, Software, ad Expermetato Compoets Hub Etheret Processor Software Acceptor Attrbute Value Ut etheret speed 10 6 bt/sec processor teral badwdth fty bt/sec buffer sze fty bt Attrbute Value Ut cpu speed 10 8 operatos/sec cpu memory sze 64*10 6 bytes/sec maxmum packet sze 31*10 3 bt processor teral fty bts/sec badwdth processor etwork 2*10 9 bts/sec terface speed buffer sze fty bt packet header sze 20 byte Attrbute Value Ut sze 2*10 6 byte self-startg duty cycle fty sec thread mode oe/method Attrbute Value Ut tme for dscoverg LCN topology 1 sec umber of tmes to 1 NA voke task The performace of the etwork system s affected by may factors. I ths paper, the trasmsso back off tme s selected to demostrate the role of DOC ad performace aalyss of etwork systems. As dscussed above, both clets ad server eed to sed packets (messages) to lk through the hub etheret model. These clets ad server ca be vewed as odes the etwork system. The umber of the (clet ad server) odes s always greater tha oe order to study dfferet back off schemes the presece of packet collsos the lk (e.g., oe clet ad the server smultaeously sed messages to the lk). Usually, after the frst collso, each ode wats ether 0 or 1 tme uts before tryg aga. If two odes collde ad each ode pcks the same radom wat tme, they wll collde aga. After the secod collso, each ode pcks 0, 1, 2, or 3 at radom ad wats that umber of tme uts before sedg ts packet to the lk. If a thrd collso occurs wth 0.25 probablty, the the umber of tme uts for a ode to wat s chose at radom from the terval 0 to I geeral, after m collsos, a radom umber betwee 0 ad 2 m - 1 s selected. Fgure 6(a) shows the growth umber of collsos gve the radom back off scheme [17] for 2 to 1000 odes. Ths s expected sce wth more ad more odes, the chace of collso creases expoetally. The results show Fgure 6 are average values from 10 smulatos rus. Gve the flexblty to mapulate software ad hardware layers of a etwork system, we use a dfferet hub etheret model, whch ca be easly composed wth the software compoets from the prevous expermet. Oe of the mportat attrbutes of the hub etheret model s the back off tme, whch ca be calculated usg the tradtoal scheme dscussed above, or ca be fxed to a seres of costats. For example, f there are four odes the etwork, after the frst collso, ther back off tme ca be 1, 2, 3, or 4 tme uts where each of the clet ad server odes selects oe of them to reschedule ts packet retrasmsso. We call ths oe by oe back off scheme. It s atural to suppose ths oe by oe back off scheme wll reduce the umber of collsos or elmate them altogether. However, as show Fgure 6(a), the oe by oe back off scheme leads to more collsos. The mportat pot here s the relatoshp betwee the Server Processg Tme (SPT) ad oe back off tme ut (BTU). BTU s the dfferece betwee retrasmsso tmes of two clets. The reaso the oe by oe back off tme seems coutertutve s that the SPT s bgger tha BTU so the server s put to the lk terrupts the clets scheduled back off sequeces whch results more collsos. Before we dscuss the detals of aalyss, we defe two types of oe by oe back off schemes, oe called A ad the other B. Type A assumes SPT s less tha BTU ad Type B assumes the verse.

7 Referrg to Fgure 7, at tme t, 5 clets are trasmttg ther packets to the lk that s, fve evets are geerated cocurretly at tme t (see Fgure 7(d)). Because all of these packets go to the lk, ths results collsos at the lk. After the collso at tme t, the retrasmsso of clets umber 1, 2, 3, 4, ad 5 are scheduled at t +1, t +2, t +3, t +4, t +5 tmes as show Fgure 7(a). The server eeds Δt tme (oe SPT) to process ad sed the processed packet back. Here, we defe Δt = 1.5 * (t +1 - t ) such that SPT s bgger tha BTU (Fgure 7 (b)) ths s Type B gve above. Fgure 7(c) shows that after t +2, two packets are trasmtted va the lk, whch results vokg two tasks the server. (c). scale ad smulato executo tme Fgure 6. Performace Aalyss for Back Off Schemes (a). scale ad o. of collsos (b). scale ad badwdth utlzato At tme t +1 + Δt, the frst task the server s completed ad s set to the lk. The, clet 3 seds ts packet to the server ad there are two tasks the server aga, (see Fgure 7(c)). Sce Δt s defed as 1.5 BTU, the task for clet 2 the server s completed ad set back at tme t +4. At the same tme, clet 4 s also retrasmttg ts packet followed by the secod collso at t +4. Ths forces both the server ad clet 4 to back off. The server wll back off oethrd of Δt, ad clet 4 stll eeds to back off 4 BTU. Ths results clet 4 schedulg retrasmsso at tme t +8. We defe the server s back off tme to be fxed.e., oe-thrd of the server processg tme, Δt/3. So, at tme of t +4 + Δt/3, the server makes ts retrasmsso ad the packet for clet 2 s set back. At t +5, clet 5 makes ts retrasmsso ad aga there are two tasks the server. These two tasks wll be completed ad set back at tmes t +6, ad t +7. As stated above, clet 4 wll try retrasmsso at tme t +8. At ths tme, there are o tasks the server so the task for clet 4 wll be completed ad set back at t +8 + Δt. I the above scearo, there are two collsos cludg oe caused by the terrupto from the server to the clets that occurred at t +4. However, ths does ot mea that costat back off tme wll always lead to more collsos. The relatoshp betwee SPT ad BTU determes whether or ot the costat back off sequece wll be terrupted or ot. As show Fgure 8, f the Δt (SPT) s smaller tha BTU, the before the ext retrasmsso happes, the server has already set the packet back to the clet.e., there wll be o collso due to terrupto from server to the clet.

8 the oe by oe back off scheme A. Ths explas why the radom back off badwdth utlzato s always the best amog the three back off schemes (see Fgure 6(b)). Smlarly, the smulato tme for radom back off s always the shortest (see Fgure 6(c)). Fgure 7. Type A Oe by Oe Back Off Scheme I our expermets, the SPT s set to 4*10-4 secods. I the oe by oe back off scheme A, the BTU s set to 1*10-4 secods, ad the oe by oe back off scheme B, BTU s 1*10-2 secods. I our mplemetato of the radom back off, the cotuous collso umber (the umber of collsos that happe betwee two successful trasmssos) s less tha 10 ad the BTU s chose by the algorthm descrbed above, usually wth some costat adjustmet (.e., betwee 1*10-6 secods ad 1*10-5 secods). That s, before the server s able to complete ad sed the frst task t has receved, more tasks are set to the server. Also, after the frst collso happes, the terval for the retrasmsso s smaller. Therefore, the chace for the collso becomes smaller ad also rases the badwdth utlzato (the badwdth usage the ut tme) as show Fgure 6(b). However, order to cotrol expoetal growth of the radom back off scheme watg tme, the adjustmet perod wll be kept costat (.e., the watg tme remas betwee 1*10-4 ad 9*10-4 secods) oce the umber of cotuous collsos s greater tha 10 [7]. Ths techque makes the radom back off BTU close to the SPT. The result s creased umber of collsos whch s also smlar to the oe by oe back off scheme A (see Fgure 6(a)). Oe addtoal observato to be made s o the relatoshp betwee the umber of collsos ad badwdth utlzato. Wth the umber of collsos the radom back off greater tha 10, the total watg tme betwee two successful trasmssos s stll shorter tha Fgure 8. Type B Oe by Oe Back Off Scheme (See Leged Fgure 7) Watg tmes betwee two successful trasmssos ca be descrbed terms of RTWT (radom back off total watg tme), ATWT (oe by oe back off scheme A watg tme), rwt (radom back off sgle collso back off watg tme), ad awt (oe by oe back off scheme A sgle collso back off watg tme). Gve as the umber of collsos, we ca derve the followg relatoshps whch state that the watg tme for radom back off s less tha the watg tme for the oe by oe back off scheme A. Gve: RTWT ATWT 9 = rwt = = awt = 0 0 rwt awt rwt + awt rwt awt

9 9 9 rwt < awt 0 0, we have RTWT < ATWT. We chose sx model cofguratos based o the umber of odes (.e., 3, 200, 400, 600, 800, ad 1000 ode etwork models). These cofguratos allow us to study how software ad hardware aspects of a etwork system affect oe aother. For example, for a cofgurato wth 3 odes, the oe by oe back off scheme A has oly oe collso. More geerally, the key propertes (collsos, badwdth utlzato, total smulato tme) of oe by oe back off schemes A ad B ad the radom back off ca be studes systematcally uder dfferet hardware ad software settgs as descrbed above. I partcular, we ca determe that the oe by oe back off scheme B has a smaller umber of collsos because SPT s less tha BTU. Smlarly, we ca exame why the Etheret busy tme ad smulato tme are always loger for radom back off tme scheme B as compared wth radom back off tme scheme A ad radom back off. 5 RELATED WORK There are a varety of smulato evromets that support modelg of computer etworks. Well-kow evromets for smulato specalzed for computer etworks clude NS-2 (Network Smulator [2][18]), GloMoSm (Global Moble Iformato Systems Smulato [19]), ad TeD (Telecommucatos Descrpto Laguage [20]). A early modelg evromet that preceded these s called REAL [2]. Ths was a popular computer etwork smulator provdg aroud 30 modules (wrtte C) capturg detals of several well-kow flow cotrol protocols (e.g., TCP) ad other schedulg dscples (e.g., Far Queug ad Herarchcal Roud Rob). Sce REAL was developed solely for tradtoal wred etworks, the Defese Advaced Research Projects Agecy sposored developmet of NS-2 to hadle more complex etwork systems [2]. Wth support for customzg exstg models (e.g., ucast routg, multcast routg, moble etworkg, ad satellte etworkg), NS-2 has become popular ad to some extet s beg used for defg customzed etwork models. However, sce there s strog depedecy amog some of the NS modules, t ca be challegg to model ew protocols or to make chages to exstg protocol models. That s, gve ts complexty ad low-level detaled models, t s ecessary to have -depth kowledge of NS-2 for serous smulato [2]. Furthermore, NS-2 s ot teded for dscpled tegrato of software ad hardware smulato modelg. It prmarly supports smulatg software commucato protocols for etwork devces stead of smulatg a set of software applcatos dstrbuted across processors ad etwork devces. DEVS/DOC s smlar to other evromets such as NS-2 ad provdes modelers wth ready to use hardware modules such as cpu, router, ad lk. However, ulke NS- 2 ad others such as OpNet, t provdes greater flexblty ad smplcty for creatg customzed hardware modules as well as software modules ad composg them wth a well-defed smulato modelg framework. That s, ulke DEVS/DOC, the NS-2 evromet does ot support dstct software ad hardware modelg as layers or ther composto. Istead, NS-2 supports very detaled, fe gra modelg of protocols rather tha quatum level modelg. From a usablty aspect, NS-2, whch s a Ux-based evromet, does ot offer a user fredly smulato evromet. Cosequetly, the use of NS-2 ca requre addtoal tme ad effort for developg models that are ot already avalable. For example, drect ru-tme cotrol of smulato offers mportat ad to modelers coductg detaled aalyss of smulato executo rather tha relyg solely o data (smulato logs). The comparso of NS-2 ad DEVS/DOC dcates the latter to be more sutable for system-level etwork smulatos ad expermetatos wth user fredly terfaces ad popular tegrated objectoreted developmet evromets. 6 FUTURE WORK The dstrbuted object computg approach s mportat for characterzg etwork systems separately terms of software ad hardware layers. The ew DEVS/DOC s a evromet that supports expermetg wth system specfcatos where alteratve software ad hardware desgs ca be vared ad tegrated a well-defed fasho. Gve the geerc dstrbuted object computg framework ad dscrete-evet system specfcato, DEVS/DOC offers a bass for modelg etwork-based systems where t s mportat to aalyze ad desg a system s coceptual archtecture ot separately from software or hardware pots of vew, but stead by accoutg for total software ad hardware smultaeously. Therefore, DEVS/DOC offers a soud framework for mportat domas cludg sesor etworks, msso trag systems, ad supply-cha etworks. Applcatos of terest mght clude eterprse systems where t s ecessary to develop archtectural desgs across may hudreds of (hardware ad software) computatoal odes. Aother area of terest s to use DEVS/DOC smulato models wth physcal systems. Ths ca lead to mportat capabltes where a porto of a etwork system executg o a physcal computer etwork ca be embedded sde a large-scale smulato model. That s, the

10 evromet ca support physcal hardware wth smulated software or vce versa where software tools are executed o smulated hardware. Ths capablty eables mxed logcal ad real-tme executo of smulated ad physcal software ad hardware compoets. For example, the coceptual ad system-level desg of a etwork of may satelltes orbtg the earth ca be smulated wth a few actual satelltes, wth the remag oes beg smulated. Fally, large-scale, complex applcato of DEVS/DOC requres executo of DEVS/DOC a dstrbuted settg such as a servceoreted archtecture. Ackowledgmet Ths research was partally supported by NSF DMI grat. REFERENCES [1] Keshav, S., REAL 5.0 Overvew, Corell Uversty, [2] Iformato Sceces Isttute (ISI), The Network Smulator - s-2, Uversty of Souther Calfora, [3] OpNet Modeler, [4] Butler, J. M. 1995, Quatum Modelg of Dstrbuted Object Computg, Smulato Dgest, Vol. 24, No. 2, pp [5] Zegler, B. P., T. G. Km, ad H. Praehofer, 2000, Theory of Modelg ad Smulato, 2d Ed., New York: Academc. [6] DEVSJAVA, ACIMS, /SOFTWARE/software.shtml, [7] Hld, D. R., Dscrete Evet System Specfcato (DEVS)/Dstrbuted Object Computg (DOC) Modelg ad Smulato, Ph.D Dssertato, March 2000, Electrcal ad Computer Egeerg Dept., Uversty of Arzoa, Tucso, Arzoa. [8] Sarjougha, H. S., D. R. Hld, ad B. P. Zegler, 2000 Egeerg Dstrbuted Systems: Smulato-Based Co-Desg, IEEE Computer, Vol. 33, No. 3, pp [9] Hld, D. R., H. S. Sarjougha, B. P. Zegler, Jauary 2002, DEVS-DOC: A Modelg ad Smulato Evromet Eablg Dstrbuted Codesg, IEEE SMC Trasactos, Vol. 32, No. 1, pp [10] Goddg, G., H. S. Sarjougha, K. E. Kempf, Dec., 2003, Semcoductor Supply Network Smulato, Wter Smulato Coferece, pp , New Orleas. [11] Sarjougha, H. S., X. Hu, B. Str, D. Hld, 2001, Smulato-based HW/SW Archtectural Desg Cofguratos for Dstrbuted Msso Trag Systems, Smulato, Vol. 77, No. 1-2, pp [12] Cho, Y., B. P. Zegler, H. Cho, H. S. Sarjougha, ad S. Se, March 2000, Desg Cosderatos for Dstrbuted Real-Tme DEVS, AIS 2000, pp , Tucso, AZ. [13] CORBA Bascs, Object Maagemet Group, /corbafaq.htm, [14] IEEE Stadard for Modelg ad Smulato (M&S) Hgh Level Archtecture (HLA) - Framework ad rules, IEEE Std , [15] Park, S., B. P. Zegler, H. S. Sarjougha, Oct. 2001, Iterface for Scalable DEVS ad Dstrbuted Cotaer Object Specfcatos, IEEE Sys. Ma. Cyber. Cof., Tucso, pp [16] Java TM 2 Platform, Stadard Edto, v API Specfcato, dex.html, [17] Taebaum, A. S., 1988, Computer Networks, 2d Edto, Pretce Hall, pp [18] Fall, K., V. Kaa, The s Maual, March, 13, [19] Gerla, M., R. Bagroda, L. Zhag, K. Tag, ad L. Wag, 1999, TCP over Wreless Multhop Protocols: Smulato ad Expermets, Proceedgs of IEEE ICC. [20] Perumalla, K. S., R. M. Fujmoto, 1998, Effcet Large-scale Process-oreted Parallel Smulatos, Wter Smulato Coferece, pp , Washgto D.C..