Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
UNIVERSITY OF CALGARY
Intemet Tnffic Mode1 Toolki t
Julie Dwrksen
A THESIS
SUBMiTED TO THE FACULm OF GRADUATE STUDES
iN PARTIAL FULFILLMENT OF THE REQüiREMENTS FOR THE
DEGREE OF MASTER OF S m C E
DEPARTMENT OF COMPUTER SCIENCE
CALGARY, ALBERTA
FEBRUARY, 200 1
@ Julie Doerksen 200 1
National Library 1+1 ofCamda Bibliothèque nationale du Canada
Acquisiticins and Acquisitions et Bibliagraphic Services services bibliographiques
395 Wellington Street 395. nie WeUingtm fXawaûN K l A O W OctawaON K 1 A W CaMda CaMda
The author has granted a non- L'auteur a accordé une licence non exciusive licence aiiowing the exclusive permettant à la National Li'brary of Canada to Bibliothèque nationale du Canada de reproduce, loan, distniute or seii reproduire, prêter, dkinbuer ou copies of this thesis in microform, vendre des copies de cette thése sous paper or electronic formats. la forme de microfiche/fih, de
reproduction sur papier ou sur format électronique.
The author retains ownership ofthe L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts fiom it Ni ia thèse ni des extraits mbstantie1s may be printed or othenvise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation.
Abstract
The result of this thesis is the Internet Traffic Model Toolkit (ITMT) that was developed
as part of the Intemet Protocol Tnffic and Network (IP-TN) sirnulator [38]. The ITMT
provides a framework for the reuse and development of traffic and protocol models. The
simulation environment that the ïïMT was developed in ernploys the logicd process mod-
eIing rnethodology which supports paralle1 execution of simulation scenarios. Therefore,
the KbfT can be applied to the reuse of existing models from network simulators chat are
Iimited to sequential execution. As a result, existing traftïc and protocol rnodels cm be used
in l q e r and more complex simulated networks than they can currently be applied to. The
IP-TN simulator provides an cmulation interface between sirnulated networks and Internet
hosu. Therefore, models developed with the ITMT can potentially be applied to the testing
of red Intemet host applications.
Acknowledgments
1 would like thank Dr. Brian Unger for his continuing support throughout the course of rny
graduate degree. Due to the work in network simulation that 1 completed with Dr. Unger
as an undergraduate student. 1 found an interest in pursuing gnduate studies. Without his
support. 1 would not have pursued a graduate d e p .
1 want to express my appreciation to Rob Simmonds for sharing his knowledge of the
research area with me in such a patient manner, and for his continuous encouragement.
I owe thanks to David Wilson for dl of his constructive feedback. He assisted me
greatly during the writing stages of my thesis, and provided me with encouragement.
1 am so gnteful to my parents and my brother for their never ending love. encounge-
ment and positive influence. They have aiways believed in me. and have shown me how to
believe in myseif.
1 would like to sincerely chank James Hiner for his never ending Iove and patience.
He has always completely supported and encouraged me. When my interest in graduate
studies fint began, 1 had doubts about rny cripabilities. but he did not.
1 would dso like to sincerely ihank dl of my friends for their continuous encoungement
and support.
Dedication
1 dedicate this thesis to the memory of my pdmother, Eileen Guenin.
My grandmother h s ken a great source of strength for me. She was. and dways will be. a constant presence in my life. She showed me an unchanging and unconditional love. She was rui example of how to be a truly beautiful person.
Contents
Appmval Sheet ii
Abstract iii
Dedication v
Table of Contents vi
List of Tables x
List of Figures xi
List of Abbreviations d v
1 Introduction 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . 1 TheInternet 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Xetwork Simulation 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 T d c Modeling 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Thesis Overview 5
2 Computer Communication and the Internet 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 InternetHosts 10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Applicxiontayer 12
. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 User Applications 13
. . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Application Servers 14
. . . . . . . . . . . . . . . . . . . 2.3 Transport and Network Protocol Layers 15
. . . . . . . . . . . . . . . . . . . . . . 2.3.1 Transport Control Protocol 16
. . . . . . . . . . . . . . . . . . . . . . . 2.3.2 User Datagram Protoc01 18
. . . . . . . . . . . . . . . . . . 2.3.3 Network Layer: Intemet h-otocol 18 . . . . . . . . . . . . . . . . . 2.3.4 Interaction Between Protocol Layers 19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Sockets Interface 10
. . . . . . . . . . . . . . . . . 2.4.1 Introduction to the Sockets Interface 20
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47 TCP Sockets 12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 UDP Sockets 24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Summq 26
3 Review of Traffic Modeling 28 . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Basic Concepts of Simulation 18
3.1.1 Introduction to Simulation . . . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . . . . . . . 3.1.1 Logicril Process Description 30
. . . . . . . . . . . . . . . . . . 3.1.3 PmlIel Execution of a Simulation 33
. . . . . . . . . . . . . . . . . . . . . . . 3.1 -4 Description of Emulation 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Tnffic Modeling 37
3.3 Overview of Network Simulators . . . . . . . . . . . . . . . . . . . . . . . 38
. . . . . . . . . . . . . . . . . . . 3.3.1 Scdable Simulation Framework 39
3.3.2 'letwork Simulation Object Model . . . . . . . . . . . . . . . . . . JO
. . . . . . . . . . . . . . . . 3.3.3 Optimized Ketwork Engineering Tool 41
. . . . . . . . . . . . . . . . . . . 3.4 Overview of ParaIIelization Frameworks 42
. . . . . . . . . . . . . . . . . . . . 3.4.1 The TeD Simulation Laquage 42 . . . . . . . . . . . . . . . . . . 3-42 Parallel Cbsimulation Fmework 43
. . . . . . . . . . . . . . . . 3.4.3 A Grneric Parailelization Fmework 43
3.5 ThensSimulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.1 Developing a Transport Layer Protoc01 Mode1 . . . . . . . . . . . 36
3.5.2 Developing an Application Mode1 . . . . . . . . . . . . . . . . . . 47
. . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 The GIoMoSim Simulaior 48
vii
. . . . . . . . . . . . . . . . . . . . 3.6.i Developing a Piotocoi Mode1 49
3.6.2 Application of GloMoSim to Parailelization of ns TCP model . . . 5 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Summary 52
4 Internet T d c Model Twlkit Design 54 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Host Simulation Model 54
4.1.1 Model Components . . . . . . . . . . . . . . . . . . . . . . . . . . 55
. . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Host Logicd Process 56
4.1.3 Traffic Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.4 Protocol Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Component Interfaces 60
4.1. I Interface Between Hast LP and Traffic Cornponents . . . . . . . . 60 . . . . . . . . 4.2.2 Interface Between Tnffic and Protocol Components 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.3 Sending Packets 62
. . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Receiving Packets 63
. . . . . . . . . . . . . . . . . . . . 4.3 Modeling Intemet Host Functionality 64
. . . . . . . . . . . . . . . . . 1.3.1 Multiple User and Server Processes 64
. . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Multiple Connections 66
. . . . . . . . . . . . . . . . . . . . . . 4.4 Comparison of Mode1 Alternatives 70
. . . . . . . . . . . . . . . . . 4.4.1 Mode1 Component Implementation 70
. . . . . . . . . . . . . . . . . . . . 4-42 Initial Host Simulation Model 71
. . . . . . . . . . . . . . . . . 4.3 Host Simulation Mode1 Alternatives 75
4.3.4 Alternative Implementations for Port Lookup . . . . . . . . . . . . 78 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Summary 81
5 Incorporation of a M c Mode1 83 . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Waveict Model Description 83
. . . . . . . . . . . . . . . . 5.1.1 Basic Description of a WaveIet Mode1 84
. . . . . . . . . . . . . . . . . . 5.1 -2 MsynTrafF Toolkit WaveIet Mode1 88
. . . . . . . . . . . . . . . . . 5.7 Reuse of MsynTnff Toolkit Wavelet Model 89
5.2.1 Alternative Methods of Wavelet Mode1 Incorporation . . . . . . . . 89
5.2.2 Ovewiew of Waveiet Mode1 Incorporation . . . . . . . . . . . . . 91
5.2.3 Reduction of Memory Requirements of the Wavelet Model . . . . . 93
. . . . . . . . . . . . . . . . 5.3 Verification of Internet Tnffic Model Toolkit 96
5.3.1 Verification of Incorponted Wavelet Model . . . . . . . . . . . . . 96
. . . . . . . . . . . . . . . . 5.3.2 Verification of Host Simulation Model 98
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Summary 100
6 Incorporation of ns Modeis 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Description of ns Models 102
. . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 The ns Telnet Mode1 103 . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 ThensTCPModeI 103
. . . . . . . . . . . . . . . . . . 6.2 ReuseofnsTelnetandTahoeTCP Models 1W
. . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Encountered Issues 105
. . . . . . . . . . . . . . . . . . . . 6.2.2 Reuse of ns Tahoe TCP Mode1 106
. . . . . . . . . . . . . . . . . . . . . . 6.2.3 Reuse of ns Telnet Model 107 . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Timer Component 108
. . . . . . . . . . . . . . . . . 6.2.5 Examples of Component Intenction 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 ns Model Testing II0
. . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Simulation Scenario L I l . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Simulation Results 112
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Host Mode1 Testing 115 . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Simulation Scenario Il5
. . . . . . . . . . . . . . . . . . . . . . . . . . 6.42 Simulation Results 117 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Summary 121
7 Sumrnary of Contributions to T r a c Modeling 123
7.1 Possible Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Bibliography 126
List of Tables
. . . . . . . . . . . . . . . . . . . . . . 3.1 Methods for CloMoS'un TCP Mudel 50
. . . . . . . . . . . . . . . . . . . . . . . . 6.1 Simulation Scenano Parameters 1 13 . . . . . . . . . . . . . . . . . . . . 6.3 iP-TN Simulation Scenario Parameters 1 18
. . . . . . . . . . . . . . . . . . . . . . 6.3 ns Simulation Scenario Parameters 1 18
List of Figures
1.1 Host Connection to the Internet . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Web Browser Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
9.1 Philosopher communication Via a Protocol Stack . . . . . . . . . . . . . . . . 8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Internet Protacoi Stack 10
9.3 Representation of Internet Host . . . . . . . . . . . . . . . . . . . . . . . . . I I
2.4 Downloading a Web Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Itentive Server 15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Concumnt Web Server 15
. . . . . . . . . . . . . . . . . . . . . . . 3.7 Intenction Between Protocol Layers 19
9.8 Multiple User and Server Processes . . . . . . . . . . . . . . . . . . . . . . . 21 . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 TCP Connection Systern Cails 23
3.10 Two TCP Connections to the Same Server Process . . . . . . . . . . . . . . . . 74 7.1 1 UDP System Cdls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.12 Two UDP Sessions to the Same Server Process . . . . . . . . . . . . . . . . . . 26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Causaiity E m r E.uample 32
3.2 Zamboni Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3 Sequcntial Execution of a Simulation . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Panllel Execution of a Simulation . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Internet Game System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 iP-TNEmulator 36
5.8 Two Dimensional Arnys of Scding rind Wavetet Coefficients . . . . . . . . . . 94 5.9 Heap Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.10 Cornparison of MsynTmffand ITMT Synthetic Data Traces . . . . . . . . . . . 97
5.1 1 Cornparison of MsynTdf and iTMT Synthetic Datri Traces . . . . . . . . . . . 98
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.12 Test Scenario 99
. . . . . . . . . . . . . 5.13 Cornparison of Synthetic Dam Tmce and Host LP Output 100
. . . . . . . . . . . . . . . . 6.1 Class Structure of rn and ITMT for ns TCP Model 106
. . . . . . . . . . . . . . . 6.2 Class Structure of ns and ïiMT for ns Telnet Model IO8
. . . . . . . . . . . . . . . . . . 6.3 Encapsulation of rn Models by iTMT Objects 110
. . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 P-TN Simulation Scenario 1 1 I l
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 ns Simulation Scenrrrio 1 I l 2
. . . . . . . . . . . . . . . . . . . 6.6 Cornparison of iP-TN and ns Telnet Sources I I4
. . . . . . . . . . . . . . . . . . . . 6.7 Comparison of P-TN and ns Trinet Sinks 114
. . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 P-TN Simulation Scenario 1 I I 6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 ns Simulation Scrnrrrio 7 II7
6.10 Two Cornparisons of P-TN and ni. Telnet Sources: (a) P-RI and ns Telnet
Source with Mean 10 and Sred 1 (b.) IP-TN and ns Telnet Source with Mean 10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . andSeed 10 I I9
6.1 1 Two Comparisons of iP-TN and ns Telnet Sinks: (a) iP-TN and ns Telnet Sink
Acknowledgernents to Source with Mean 10 and Seed 1 (b.) iP-TN and ns Tdnet
Sink Acknowledgemrnts to Source with Mem 10 and Seed IO . . . . . . . . . . 120
List of Abbreviations
ANSE
API
GIoMoSim
IP
IP-TN
M N
LP
LRD
mm4
OPNET
SRD
SSF
TCP
TeD
TFrP
r n T
UDP
WAN
Active Networks Simulation Environment
Application Programmer's Interface
Global Mobile Information System Simulator
Internet Protocol
Internet Protocol Traftîc and Network
Local Area Network
Logical Process
Long Range Dependence
Multifrxtal Wavelet Model
Network Simulation Object Model
Optimized Network Engineering Tool
Short Range Dependence
Scalabie Simulation Fmework
Transport Control Protocol
Telecommunications Description Language
Trivial File Transfer Protocol
Intemet Traffic Model Toolkit
User Datagram Protocol
Wide Area Network
xiv
Introduction
As the use of the Internet bas increrised. so has its size and complexity as well as the
amounts and types of infornuion, or tnffic. tnveling over it. As a result. the development
of computer networks has become more complex. Cornputer simulation provides a tool for
the evalurition and development of many aspects of computer networks. As the core pur-
pose of a network is the transfer of infornation. an imponant aspect of network simulation
is tnffic modeling. which is the topic of this thesis.
1.1 The Internet
As an introduction to the concepts that will be discussed in this thesis, consider the follow-
ing questions. What happens when someone using a web browser requests the show times
for al1 movies playing at n local theater that evening? What is the process that allows this
information to triive1 to the user's computer? To answer these types of questions. a basic
understanding of how cornputers comrnunicate over the [nternet is required. The Interner
is the global computer network composed of many interconnected smaller networks. A
computer connected to the Intemet is an Interner hosr. Internet hosts provide a variety of
applications for users. such as web browsers, email programs. and word processing pro-
,onms. Some of these applications. such as ri web browser or an email prognm. involve the
genention of messages and requests to be sent to another Internet host. Intemet hosts can
aiso provide services to respond to such messages and requests. For example, a web server
responds to requests generated by a web browser. As shown in Figure 1.1, an Internet host
is usually part of a subnet which is a smdler IocaI network that is connected to the internet.
Subnets are connected to the internet by a mirer which is a device that contains routing
and topoiogical information that it uses to direct data towards its final destination.
- - - - - - - - - - - - - - - - - Router + Internet -: Router IF- - - * - - - - A , - - - - - - - - -
Figure 1.1: Host Connection to the Internet
To visualize the scenario of using a web browser to request rnovie show tirnes. refer to
figure L 2. and suppose the person using the web browser is using host 1. The requested
information is stored on a rernote Intemet host md is provided by a web server. For the
purpose of this example. suppose that the web server providing the movie show tirnes is
on host 4. and assume that the information is retrieved directly from host 4. The request
for the show cimes wouId be sent from host 1 to router I. from router t over the Internet
to router 2. and finally to host 4. When the request is sent over the Interner, it may be
sent through multiple routers. each of which will direct the message towards router 2. The
requested show tirnes would be sent back to the web browser in a similar fashion. To
cornrnunicate with erich other. Interner hosts use ri set of protocols. A ptvtocol is a set of
d e s and conventions that are used to conduct a conversation. The protocols of an Internet
host are used for iomatting and interpreting information thrit they send to each other.
1.2 Network Simulation
As the use of the Internet has increased the development of rnany aspects of cornputer
networks has becorne more complex. For example. consider the deveIopment process of
a web server. This process rnay incIude an evaluation of the efficiency of the web server
in responding to requests. As the responses h m a web server are sent to a web browser
- - - - - - - - Router 1 : -.--a I ' interna di Router 2 - - - - - - - - . - - - - - - - - . HOST 5
Figure 1.2: Web Browser Example
over the Internet. consideration of the other information on the Internet during the time
of the response may need to be included. However, as the use of the Internet has greatly
increased. so have the amounts and types of information, Le.. uaffic traveling over it. As a
result. it could be very difficult to determine the mounts and types of traffic on the internet
at any given time. This can pose a difficulty in the development of my intemet host service.
The main purpose of the components of a network and the protocols that it employs is to
transfer information. Therefore. a consideration of the traffic on a network is dso imponant
to the development of both network components and protocols.
Compurer simrrlution is the modeling of the behavior of a physicd system over tirne
through the use of a computer prognm. Computer simulation has k e n applied to the
modeling of computer networks and several network simufators have been developed that
cm be used to model computer networks connected to the Intemet. These include ns [2,12],
GloMoSim [Il, SSF [Kg], NetSOM 1221, and OPNET [6.21]. The simulation of networks
involves modeling the components of the network. such as routes, hubs and hosts, as well
as modeling the protocols used for communication over the network. The main purpose of a
computer network is the tnnsfer of information. therefore, an imponant aspect of modeling
a network is a representation of the traffic on the network.
The network component. protocoi, and uaffic models of a nerwork simulator are al1 entities of the computer progrm. Therefore, the exact topology of a sirnulated network,
the protocols it employs and the arnounts and types of uaftic uaveling over it cm dl be
specified. As a result, a controlled environment can be established for the evduation and
development of many aspects of computer networks, including network components, com-
munication protocols. and Intemet host services. As previously dernonsuated a consider-
ation of the amounts and types of traffic on a network can be important to the deveIopment
of al1 of these aspects of computer networks. Therefore, traff~c modeiing is an important
part of network simulation.
Traffic Modeling
Several network simulators have k e n developed that can be applied to the modeling of
computer networks connected to the Intemet including ns 12. 121, GloMoSim [I l , SSF [8.91, NetSOM [22]. and OPNET [6, 211. As a result. many Intemet tnffic and protocol
rnodels exist. Some of the simulation environments provided by these simulators. however.
are limited in certain aspects. One aspect is the simulation method used by a simulator.
Depending on the method employed. the way in which a simulation mn can be executed
rnay result in limitations to the size and complexity of the scenarios explored. Many of the
network simulators mentioned rue limited in this way. However. some of these sirnulators.
such as ns. are widely used. As a result. if the traffic and protocot models of such simula-
tors could be used in a simulation environment that was less limiting CO scenario size and
complexity. then these widely used models could be applied to the evaiuation of l q e r and
more complex scenarios.
Another aspect to consider can be demonstrated by refemng qain CO the developrnent
process of a web server. To test an Internet host service using a simutated network. an
interface is required between the service and the simulated network. Most of the network
simuiators mentioned here do not provide this type of interface. Therefore. an actud ser-
vice provided by an Intemet host cannot be tested using a simulated network. Rather. a
sirnuiation mode1 of a service could be tested. however. the mode1 woufd first have to be
developed.
The result of this thesis is the Intemet Traffic Mode1 Toolkit (KMT) which was de-
veloped as part of the Internet Protocol Traffic and Network (il?-TN) simuIator [38]. The
main goal in the development of the ITMT was to provide a framework for the reuse and
developrnent of traf%c and protocol models within a simulation environment that allows
them to be used in simulated networks that are Iess limited in size and complexity than the
sirnulated networks that they cm currently be applied to. A secondary goal was to provide
a framework that allows models to be a part of simulated networks that cm be used to test
actuai Intemet host services. The development goals of the ITMT are not stated here in
complete detail. After basic descriptions of cenain aspects of simulation have b e n given,
a more complete definition of the goals in the development of the iTMT will be provided.
1.4 Thesis Overview
As the Intemet Traffic Model Toolkit provides a fnmework for the development of models
of network traffic and protocols that computers use to communicate over a network. a basic
understanding of this communication is required to understand the design of the ITMT.
The description of computer communication that was just provided is only an introduction
and a more detailed one is required. Chnpter 1 provides basic descriptions of the necessary
aspects of computer communication.
The iTMT provides ri hmework for the development and reuse of traffic and protocol
models. There are orher network simulators that support traftic and protocol mode! de-
velopment. such as the ns [?. l?]. GloMoSim [ I l , SSF [8.9], NetSOM [22] and OPNET [6. 3 I ] simulators. However. as previously explained. the simulation environments of these
simulators are Iimited in some aspects. There are also other fmeworks that have been de-
veloped for the Ruse of existing tnffic and protocol models. [XI, [26], and [36]. However.
the methods employed by these fnmeworks for reusing a model differ from the method
of the iTMT. As previously mentioned. the deveiopment goals of the iTMT should be
more ciearly defined. however. basic understandings of simulation and the simulation en-
vironment of P-TN are first required. Chapter 3 begins with these necessary descriptions.
Following these descriptions. the development goals of the rrPvIT are cieariy defined. Also
provided in Chapter 3 is a clarification of the contributions of the ITMT through a compar-
ison to the network simulators and fmeworks mentioned here.
The tntemet Traffic Model Toolkit consists of a simulation model of an internet host
that was developed as part of the P-TN simulator. This host simulation model includes
components for the development of tnffic and protocol models. These components pro-
vide an interface for M c and protocol models to be used in simulated network xenarios
created using the IP-TN simulator. The focus of Chapter 4 is to provide a description of
the design of the ITMT. Descriptions of each of the rnodel components and how the model
components interact are provided dong with an explanation of each of the mode1 alterna-
tives that were considered.
ïhe main goal in the development of the Intemet Tnffic Model Toolkit was to provide
ri framework for the reuse and development of tnKc and protocol models. To show thar
the ïïMT can be used for this purpose, two applications of the KMT were performed. The
first application was an incorporation of an existing trafiïc model inro the P-TN simula-
tion environment. That is. the ITMT was used to create an interface between this existing
tnffic mode1 and the P-ïX simulator so that the traffic model could be used in simulation
scenarios. Chapter 5 provides a description of the traffïc model and the process of incorpo-
rating it into the P-ïX simulation environment. The second application of the iTMT was
the incorpontion of a tdfic and a protocol model from the ns simulator [2. 121. Chapter
6 provides a description of both of these models and the process of incorporriting each of
them into the IP-TN simulation environment.
The final chapter. Chapter 7. provides a summary of the development goals and contn-
butions of the tntemet Tnffic Model Toolkit as well a discussion of possible future work.
Cornputer Communication and the Internet
The Intemet Tnffic Mode1 Toolkit (ïIMTl was developed as part of the [P-TN simulator
which is used to mode1 computer networks. Therefore. to acquire an understanding of
the M design. a basic understanding of computer communication over a network is
required. The way in which cornputers achieve communicrition over a network is through
the use of a set of components. each implementing a protocol. amnged as a stack. A
protocol is a set of niles and conventions used to conduct communication. Between each
pair of components venically adjacent in a stack there is an interface for communication.
An explmation of the concept of ri protocol stack is the starting point of this chapter. An
malogy is firsr used to demonsurite how components of a protocol stack communicate. then
the genenl idea of a protocol stack is explained. An outline of the remaining sections of
this chapter is deferred until the protocol stack has been explained.
Consider the following analogy that demonstrates the type of communication used be-
tween components of a protocol stack. The scenario is based on m example from [40]
and is shown in Figure 2.1. The scenario consists of two philosophers, one who speaks
Japanese and one who speaks ûerman. The philosophers each have a translator CO assist
hem in communicrtting. The two translators have the common l a n p g e English and each
translator hris a secretary. in order for the Japanese philosopher to speak a sentence to the
German philosopher. the following sequence of events occurs. The Japanese philosopher
speaks the sentence to the Japanese uanslator. The Japanese translator then tnnslates the
sentence to English and relays it to his secretary. The secretary of the Japanese translator
then faxes the sentence to the secretary of the German translator. The secretary receiv-
1. COMPUTER COMMUNICATION AND THE INTERNET 8
ing the fax relays the sentence to the German translator who mslates it to Geman and
speaks it to the Gemm philosopher. If the German philosopher replies to the Japanese
philosopher, a similar pmcess occurs.
Figure 2.1: Philosopher Communication Via a Protoc01 Stack
Now cmfully consider how the Japanese philosopher communicates. The sentence
spoken by the Jripanese philosopher is intended for the German philosopher bur is actualIy
spoken to the Jripanese translator. The Japanese philosopher is only concemed with the
sentence thnt the Geman philosopher will receive and not with what is done CO the sentence
by the tmslator or the secretiuy or how the sentence gets to the Grrman philosopher. The
only thing the Jnpanese philosopher needs to know about the Japanese tnnslator is how to
relsy and receive sentences to and from hirn or her. Furthemore. the Japanese philosopher
does not need to know anything about the secretary. Similady. the sentence tmslated
by the lapmese translntor is intended for the Gennan tmslator but is actually relayed to
the secretq. The Japanese msiator only needs tu know how to relay sentences to and
meive sentences from the Japanese philosopher and the secretary but does not need to
know anything more about either of hem.
Now reconsider Figure 1.1. This scenario cm be viewed as two stacks of people with
three people in each stack. Each person is rit a certain Ievel or l q e r of a stack. The
philosophers are on the s m e levef as each other. the translaton are on the same level as
each other. and the secretaries are on the same level as each other- Two people that are at
the same Ievel as each other can be referred to as peers. A conversation occurs benveen
1. COMPUTER COMMUNIC.&TlON AND THE INTERNET 9
two peers. and the set of rules and conventions used to carry out the conversation is known
as the protocoi of the communication. No information is actually passed directly between
the two peers. but nther. is passed through each of the two stacks of people. The use of
the same protocol without direct communication between two pem cm be referred to as rinual commtuzication [JO] . The virtual communication is indicated by the ditshed mows
in Figure 2.1 and the actual communication is indicated by the solid arrows. The two
translators. for example. use virtual communication. Each person is only concemed with
what it is they are communicating to their peer. and the only thing that each person needs to
know about any of the other people in the same stack is how to exchange information with
the people above and below them. The process between peers cm change without effecting
the rest of the stack. For example. the two translators could rnunrally decide to use Spanish instead of English. This change would not effect the other people in the stack, nor would i t
effect the way that information is passed between people in the stack.
The communication concepts demonstnted in the philosopher example cm now be ap-
plied to the use of a protocol stack by a computer to communicate with another computer
over a network. In gened. a protocol stack refers to a set of components. each irnplement-
ing a protocol. m g e d in a vertical manner. A computer uses a set of software modules
rurruiged as a protocol stack to communicate with another computer over a network. Each
module of one cornputer virtually communicates with its peer in the protocol stack of the
other cornputer and actually communicates with the modules vertically adjacent to i t in
the protocol stack that it belongs CO. A module in a protocol stack is only concemed with
formatting information to be interpreted by its peer. and only needs to know how to pass
information to the modules vertically adjacent to it and nothing more about the other mod-
ules in the stack to which it belongs. A computer cm communicate with another computer
if they each have a protocol stack of modules that implement the same set of protocols and
each pair of peers implements the sarne protocol, The number of layers in the protocol
stack and the protocols implemented at each layer vary depending on the type of informa-
tion driving the communication.
The Interner is the global network composed of many interconnected srnaller networks.
The protocol stack that computers use to communicate over the Intemet cm be imple-
mented in different ways. The set of protocols required are shown in Figure 1.3 arranged
as a four layer protocol stack. The remaining sections of this chapter will describe the
2. COMPUTER COMMUNIC.~ON AND THE INTERNET 1 0
details of each of these Iayers thrit are essentid to the understanding of the Intemet Traf- fic Mudei Toolkit design. Section 2.2 provides a more detaited description of a computer
connected to the Internet that uses this protocol stack. The application layer provides ser-
vices to users, such as an email program, and is described in Section 2.3. The uansport
layer is designed to dlow peer entities on the source and destination hosts to c q on a
conversation [XI]. The funrtionality provided by the uanspon layer to the application layer
inchdes reliability and flow control. The transport layer is described in Section 2.4. The
main function of the network layer is to deliver data to its destination host. The network
layer is also described in Section 2.4. The prirnary rote of the physicril layer is to place data
onto the physicd medium connectint the computer to the network. The physical medium
varies depending on the network. For exampte. it could be a copper cabte or. in the case
of wireless cornmunicricion. it could be radio waves. As an understanding of the physicd
Iqe r is beyond the scope of Intemet traffic modeling. no further explmarion of this layer
is provided. FindIy. Section 1.5 describes the interface berween the application layer and
the transport layer. ...-... A * .... . ......... - -
Figure 2.2: Cnternet Protocol Stack
Recall the questions related to using a web browser that were posed in Chapter 1. It was dso
stated thrit h e abiiity to answer these types of questions is important in acquiring a basic
understanding of cornputer communication over a neiwork. To understand what happens when a user of a web browser requests movie show Urnes. a more comptece understanding
1. COMPUTER COLIYUNICATION AND THE INTERNET 1 1
of the cornputer providing the web browser is required. The main purpose of this section is
to provide a description of computers that provide services such as email and web browsers.
This section begins with a description of a representation of a computer connected to the
Intemet. Following this is an explanation of how computers are connected to the Internet.
At the end of this section. the protocols irnplemented at each layer of the protocol stack
used by computers over the Intemet are introduced. More complete descriptions of each of
these protocols are given later in the chapter.
Each computerconnected to the internet cm be referred to as an Intemet host. Consider
the representation of an Internet host shown in Figure 2.3. An Intemet host can provide
multiple tuer applicatiorts. For example. an e m d prognm, a web browser and a word pro-
cessing program are dl user applications. Some of these. such as the email program and
the web browser. generate messages and requests to be sent to a remore Intemet host and
can be referred to as clients. For example. when a web browser user requests information.
the information may be residing on another Intemet host to which a request for the infor-
mation is sent. When the Intemet host receives the request. it uses a web server to handle
the request. A prognm that handles messages or requests generated by user applications
is an upplicurion server. Just as Intemet hosts cm provide multiple user applications. they
can also provide multiple application servers. User and server applications reside at the
application layer of the protocol stack.
Figure 2.3: Representation of Internet Hast
2. COMPUTER COM~IUNICATION .AND THE INTERNET 12
An Internet host is usually part of a subner which is a smaller locd network that is
connected to the Internet. Subnets are connected by a murer which is a device that contains
routing information as well as information about the topology of the network. When data is
sent from one host to another. it may be sent through multiple routers. each of which direct
the data towruds its destination host, A router hlis a prorocol stack that contains the network
and physica1 layers. Routen employ the sarne network Iayer protocol as Internet hosts,
however. the physical Iayer of different routers may Vary depending on the physicat medium
used for data transmission. More detail on how the information trrivels is unnecessary
for the understanding of Internet trafEic modeling, therefore, the communication between
[nternet hosts wiIl be explained in this thesis using a host to host view. That is. how the
sending and receiving hosts operate to communicate will be described without details of
how information that has k e n sent by one host inveIs to the other host,
Shown in the representation of an Internet host in Figure 2.3 are the protocols imple-
mented at each of the Iayers of the protocol stack. The application layer consists of user
applications and application servers. A description of the user applications and application
servers provided by Internet hosts is given in Section 2.2. The protocols implemented at
the transport Iayer are the Transport Control Protocol (TCP) and the User Drttagnm Proto-
col (UDP). and the protocol implemented at the network layer is the [nternet Protocol (IP). Descriptions of TCP, ODP and IP are provided in Section 2.3.
2.2 Appücation Layer
The application Iayer is the top Iayer of the protoc01 stack as previously shown in Figure
2.2. Two types of programs that reside at the application Iriyer of an Internet host are user
applications and application servers. Examples of user applications are an email program.
ri web browser. rtnd ri word pmcessing program. Some user applications. such as email
pro-ms and web browsers. genemte messages or requests for information to be sent to a
rernote Internet host An application server is a computer prob- that receives messages
and handles requests genented by user applications. For example, a web server handles
requests for information generated by a web browser. These types of prognms facilitate
computer communication. therefore. to acquire a basic understanding of computer commu-
nication we need to look at exampies of these types of p r q m s . Section 2.2.1 provides
2. COMPUTER COLIMUNICATION AND THE INTERNET 13
a description of user applications while Section 2.2.2 provides a description of applica-
tion servers. These descriptions focus on the aspects of the types of programs provided by
Intemet hosts that are relevant to modeling Internet traffic.
2.2.1 User Applications
Consider the following scenario. A user of a web browser attempts to downlod a web
page. and as a result a request for some information is sent to another computer. When
the computer receives the request for the information, the request is ultimately handled by
a web server. How does the web server know how to interpret the request? How does
the web server know what format to send the requested information in so that the web
browser cm interpret it'? The web browser implements the same protocol for formatting
and interpreting information as the web semer, This means that requests generated by the
web browser and information sent in response by the web server rire in the sarne format.
The web browser and the web server expect to receive information in this format and know
how to interpret it. X user application implements the same protocol as an application
server that can receive messages and handle requests that the application genentes. For
exampie. 3 web browser and a web server that communicate with each other may use the
HyperText Transfer Protocol (E-ITT'P) [29].
An application may communicate with exactly one server. or it rnay comrnunicate with
multiple servers simultaneously. A web browser is an example of an application chat may
communicate with multiple servers. A web page could be cornposed of multiple items such
as text and images, and rach of these items could reside on sepmte cornputers. When a web
page containing multiple items is downloaded, each of the items may need to be retrieved
h m a different remote server. For exrunple. refemng to Fisure 2-4. suppose a user is downloading a web page using a web browser on host 1 of subnet 1 and two images and
some text must be retrieved to display the web page. Suppose also that one of the images
is stored on host 1 of subnet 2. the other image is stored on host 3 of subnet 2, and the text
is stored on host 3 of subnet 3. A request for each of these items is sent to the lnternet host
serving the item. as demonstrated by the dashed m w s . After a request is sent. the next
request could be sent before the response to the previous request has been received and the
web browser could be communicating with three web servers simultaneously.
1. COMPUTER COMMUNIC.&TION AND THE INTERNET
S u b m I
. .. . ..... . . . . . ..
Figure 2.4: Downloading a Web Page
Consider an individual application more closely. An ripplication can be nin multiple
tirnes sirnultaneously. For example. a user could have two running copies of a web browser
open simultaneously. Each active instance of a user application is referred to as a user
procus. Similarly each active instance of an application server is referred to as a sewcr
procrss. A server process that interacts with TCP is referred to as a TCP srrver and a server
pmcess that interacts with UDP is referred to as a UDP semer. The next section provides
a description of how TCP and UDP servers operate.
2.2.2 Application Servers
Consider again the process of a web browser sending a request to a web server. As shown
in Figure 2.5. another request couId be received by the web server while it is still semicing
the first one. If this happens. the request could be queued until the web server is ready to
service it. A server that queues incoming messages and requests and services them one at
a time in first corne first serve order is referred to as an iterative server. TCP and üDP
servers can both opente iteratively.
A server may receive a request that takes a large amount of time to service which causes
an undesinble delay for queued requests. To solve this problem, a semer process can use
multiple processes or threads to service requests. This allows the server pmcess to be
2. COMPUTER COMMUNICATION AND THE INTERNET
Figure 2.5: lterative Server
available to service incoming requests while other ones are king serviced. A semer that
opentes in this manner is referred to as a concurrent server. An example of a concurrently
openting web server is displayed in Figure 2.6. As shown, two separate processes are
used to service the requests frorn the web browsers of host I and host 2. and the web
semer process is still available for furcher incoming requests. Both TCP and UDP servers
cm operate concurrently. however. there are slight differences between the two. A more
detailed description of ecich of these types of semers is provided in Section 24.
H m : -1 L-
Figure 2.6: Concurrent Web Server
2.3 Transport and Network Protocol Layers
The core purpose of the communication between a user process and a server process is to
exchange the request and the information requested however, the communication is also
used to exchange conuol information, For example, the receiving host could indicate to the
2. COMPUTER COBIMUNICATION AND THE INTERNET 16
sending host that the information is king sent faster than it can be processed. To acquire
a basic understanding of cornputer communication, a closer look at the way cornputers
communicate during the servicing of a request is necessary. The transport and network
layers of Internet hosts control the way in which information is sent. This section describes
the main functions provided by the protocols at these layers. The transport layer protocols
used by Internet hosts are the Transport Control Protocol (TCP) and the User Datagnm
Protocol (UDP). and the network Iayer protocol used is the Internet Protocol (P). Section
2.3.1 provides a description of TCP, in Section 2.3.2 a description of UDP is given. and
Section 2.3.3 provides a description of IP. Finally, in Section 2.3.4 the interaction between
these protocols is explained.
2.3.1 Transport Control Protocol
The Transport Control Protocol (TCP) [32] is one of the transport layer protocols uscd by
Internet hosts. TCP is implemented as a software cntity that cm be referred ta as the TCP
Iayer of an Internet host. Applications and application servers pass requests and informa-
tion in the form of data buffets to the TCP Iayer. The TCP layer breaks each data buffer
into smaller pieces called segmenrs. Sorne exm data consisting of fields that are used to
provide control information to the receiving [ntemet host is added to the beginning ofeach
segment and is refened to as ri header. The fields of a header can be used by two peers
in a protocol stack to indicate things to each other about the way in which information is
k ing exchanged. For example. the TCP layer of a receiving host c m use a field in the TCP
header to indicate to the TCP layer of a sending host that information is king sent frister
than it can be processed.
TCP is connection oriented which rneans that a user process must first establish a con-
nection to a server process before sending a request. A connection used by the two TCP
layers of a sending and a receiving host is a Iogical rnapping of a user process to a semer
process and is not a reservation of bandwidth on each link from the sending host to the
receiving host. The sending TCP Iayer initiates the connection setup when it has a data
strearn to send by sending a segment with information in the TCP header indicating a re-
quest to set up a connection. If the receiving host provides the type of service required by
the requesting user process and h a sufficient resources, then a segment is returned by its
2. COMPUTER COMRIUNICATION AND THE INTERNET 17
TCP Iayer to indicate that the connection can be set up. Otherwise, a segment is rerumed
indicating that the host does not provide the required service or has insufficient resources at
the present time. More detail on how the mapping is achieved is left until Section 2.5 as an
understanding of the interface between the application and transport layers is first required.
A TCP layer provides reliability to the application layer. For each se,oment that is
sent by a TCP layer. a timer is set. If the timer expires before an acknowledgment for
the segment is received then the segment is retransmitted. Several algorithms exist for
calculating the mount of time to set the timer for based on the arnount of time that it takes
for segments to be acknowledged [JO]. In order to distinguish segments, each byte of data
is given a sequence number and these are included in each TCP header as the 6rst and last
bytes of data that the segment contains. Multiple segments of a single data stream rnay
not ail follow the sarne path over the Internet. and they may even arrive at the destination
host out of order. The sequence numbers of the se-ments üre used by TCP to re-order the
segments of a data stream before passing the data to the application layer. The data sent by
an application to a server using TCP is completely received by the server in the order that
it was sent. The same applies to the data sent from a server to an application.
In addition to reliability, ri TCP layer provides tlow control to the application Iayer.
Flow control means that the rate at which the TCP layer of the sending host is sending data
to the TCP layer of the receiving host cm be controlled. To provide fiow controt. ri TCP
Iayer uses a sliding window protocol [JO] and [32]. A TCP implementation has a certain
mount of space for storing received data When a connection is established between a user
and a server process. the TCP layers of the sending and receiving hosts indicate the size of
their stonge space to each other by using a field in the TCP header. The smallest of the
two sites is then used by each of the TCP layers as a window size, which is a number of
bytes of data that can be sent before receiving an acknowledgment. For each segment sent.
the window size of the TCP layer of the sending host is decreased. and for each segment
acknowledged the window size is increased. A basic TCP implementation decreases and
increases the window s i x by one packet size. The sliding window pmtocoi provides a
rnechmism for the TCP layer of the receiving host to control the rate of ffow of the sending
host [JO].
2. COMPUTER COAIMUNICATION AND THE INTERNET
2.3.2 User Datagram Pmtocol
Some applications do not require the functiondity provided by the transpon Iayer. An
alternative to using TCP is to use the User Datagram Protocol (UDP) [34]. UDF is dso
implemented as a software entity that can be referred to as the UDP layer of an Internet
host. Unlike TCP. UDP is a connection less protocol that does not perform connection set
up and does not provide mechanisms for reliable delivery or flow control. Rather. UDP
provides an interface between the application Iayer and the network layer for applications
that do not require transpon layer services. A UDP laper simply accepts data buffers from
applications. breaks each one into segments, and adds a UDP Iieadrr to each segment.
Multiple segments of a single data strem may noc dl follow the same path over the Intemet,
and rnay be received by the destination host out of order. Unlike TCP. UDP does not ensure
that riIl the segments will be received and does not re-order segments when they arrive,
Therefore. data that is sent by an application to a server using LJDP may not al1 be received
by the server. and may be received in a different order than sent. The same ripplies to the
data sent by ri semer to an application.
Applications that use UDP typically do not require reliable delivery and need the higher
efficiency offered by avoiding connection set up. For example. it may not be worth the
overhead of setting up a connection for an appkation that exchanges only a small amount
of data with a semer. As rinotherexmple. consider an application that sends video captures
to remote hosts. The application sen& portions of video as a single data stream. however.
the data stream is broken into segments by the ü û P layer. As the segments are received by
the destination host. the UDF layer reconstructs the segments back into a data stream for the
application layer to display. It is possible that one or more of the segments are not received
by the destination host, In this case, i t would be undesirable to retransmit a segment as by
the time it is received the data stream rnay have k e n reconstructed and displayed beyond
the point where the segment belonged.
2 3 3 Network Layer: Intemet Protocol
The Internet Protocol (IP) [30] is the network tayer protocol used by tnternet hosts. The
main purpose of the network Iayer is to deliver data to its destination. The IP layer attaches
an IP header to each segment it receives from the TCP and üûP layers to form an IP
1. COMPUTER COMMUNICATION AND THE INTERNET 19
packer. The IP header includes the IP addresses of the source and destination hosts. An IP address is a logical address unique to dl hosts and devices connected to the Internet. The IP layer is responsible for directing packets to their destination based on routing information
and information about the topology of the network. Both Intemet hosts and routers employ
the Intemet Protocol at the network Iayer. When data is sent from one host to another. it
may be sent through multiple routers, each of which direct the data towards its destination
host.
2.3.4 Interaction Between Protocoi Layers
The interaction between protocol layers will now be demonstrated through the use of rin
example. Suppose a request is generated by a web browser and is sent to a remote host
providing a web semer. as shown in Figure 2.7. The data stream representing the request
is passed to the TCP entity and broken into segments. Each segment is passed to the IP module. The order in which the IP module accepts segments from the TCP and UDP
modules is dependent on the imp1ement;ltion. Each segment is sent over the Intemet as an
iP packet to the destination host. When the destination host receives an IP packet. the IP header is stripped from the packet and the remaining sebment is passed to the TCP module.
The IP layer can determine whether to pass a received packet to the TCP or UDP module by
inspecting a field in the iP header. The TCP Iayer strips the TCP header from the segment
ruid reconstructs the request using the segments that it receives. The request is ultimately
passed to the web semer.
Figtm 2.7: interartion Beîween Rotocol Layers
2. COMPUTER COMMUNICATION AND THE INTERNET 20
Essentially. the TCP. LJDP, and iP layers are software modules in the operating sys-
tem of the Internet host. Multiple user processes can utilize the TCP and LJDP modules
simultaneously. The TCP and UDP modules multiplex data buffers from multiple user and
server processes. This means that the TCP and LJDP modules each combine the multiple
data buffers they receive from the application layer into a single sueam of segments to send
to the IP module. The TCP and UDP modules also demultiplex incoming data for a user
or semer process. This means that the segments received by each of the TCP and UDP
modules are sepmted and reconstmcted into data streams. and each data stream is passed
to the user or server process that it was intended [or. The next section describes an interface
that was developed for the communication between processes over a network chat provides
a mechanism to indicate which process a segment is intended for.
Sockets Interface
How the communication is initiaced and maintained between a user and a semer process
is the final part in understanding cornputer communication over the Internet to the extent
necessq for the understanding of rnodeling tntemet uaffic. This section provides an ex-
planation of the interface between the application layer and the transport layer that is used
to initiate and maintain such communication. In Section 2.4.1 a description of this inter-
face is given. Section 7.4.2 provides an explmation of how a user process communicating
with a TCP layer uses this interface to cornmunicate with a rernote server process while
in Section 2.4.3 a similar explanation is given for user processes that cornmunicate with a
ü û P layer.
2.4.1 Introduction to the Sockets Interface
To assist in the understanding of the sockets interface, an example to demonstrate the pur-
pose of the interface will first be given before a full description. Suppose a web browser
process generates a request for a remote web semer process. Both the host providing the
web server and the host providing the web browser could be mnning multiple user andor
server processes as shown in Figure 2.8, When the web browser process passes the request
to the TCP module. how does it indicate which server process to send it to. and how is the
1. COMPUTER COMMUNICATION AND THE INTERNET 2 1
communication between the web browser and web server processes initiated? Furthemore,
how does the web semer process indicare to the TCP module which user process to send a
response CO'?
'Du
Figure 2.8: iCIultiple User and Server Processes
The sockets interface was developed to achieve communication between two processes
over a network [39. 421. The sockets interface is an Application Programmers Interface
(AH) for applications to the transport layer protocols. That is. the sockets interface pro-
vides a set of methods that allow a user or semer process to communicate with the transport
layer to send and receive information to a remote user or semer process. To do this, the
sockets interface uses pon niimbrrs. which are numbers that are associated with user and
semer processes. Pon numbers are used by user and server processes to indicate which
process a request or a response is to be sent to. Ephemeral port numbers are dynamically
creoted and associated with user processes. A server process is usuaily associated with ri
~vell h o w n port number. which is a port number that is globally known to the entire Inter-
net and is associated with a particular service type [27]. For example. the well known port
number 80 is used to indicate that a request needs to be serviced by a web server.
As explained in Section 2.3.1. a user process that intencts with a TCP layer must first
establish a connection with a remote server process before sending requests. The connec-
tion is a logicai mapping between a user and a server process. A socker is an endpoint to
this type of connection and is identified by an iP address and port number pair [39]. The
socket can be used to identify a user or server process, howevec it is possible that more
7. COMPUTER C O ~ ~ M U N I C . ~ T I O N AND THE INTERNET 22
than one process is running on the same socket as in the case of a concurrent server. The
way in which a process is identified in this case is described in the next section. Section
2.4.2. A user process that intencts with llDP communicates with a rernote server process
without an established connection. however. a socket is associated with both the user and
server processes. Each user process rnust create a TCP or UDP socket in order to contact
a rernote server process. The sockets interface provides a set of methods for a user process
to mate a socket and use it to cornmunicate with a rernote server process. Each method
cal1 is a systern cd). A esrem cuil is a function call into the kernel of the openting system
of a computer. The kemel is a software module that provides things such as a file system.
rnemory management, CPU scheduling and device i/0 for an operating system. The set of
system crills provided for the creation and use of a TCP socket is different from the set of
system cdIs provided for the creation and use of a UDP socket. Section 2-42 provides a
description of TCP socket system cails and Section 7.4.3 provides a description of the LTIP socket system calls.
2.42 TCP Sockets
AS shown in Figure 2.9. when a user process that intencts with a TCP layer sen& a request
to ri rernote server process it uses a set of system calls. For example. it rnay use the four
system calls socker. connect. wrire and read [42]. The s o c k t system call can be used to
creatc a new TCP socket to which an ephemeral port number is assigned. The connect
system cal1 is used to connect to the remote server process. The 1 ' address of the remote
host and the porc number of the rernote server must be specified in the cd1 to the connect
method. The wnre and reod system calls are used to send and receive data
In order for a web server process to receive requests. it must have associated with it a
port number that the web browser process can use when sending requests. Figure 2.9 ais0
shows the system cdls that a server process cm use to accept requests from a remoce user
process. The socker system cd1 can be used to create a TCP socket. Once the TCP socket
is created. the bind system call is used to associate it with the port number for the service
type thrit the server provides. The socket address which consists of the iP address of the
host and the port number of the service type is a parameter that must be specified when
using the bind system call. The port number is usudly a well known port number. The
7. COMPUTER COMMUNICATION AND THE [NTER.NET
Figure 2.9: TCP Coanection System Calls
lisren system cal1 allows the kernel of the Internet hast ta accept connections for the port
numkr. The accept system cd1 establishes the connection between the server prucess and
the remote user process. The write and reud system cdls send and receive data.
Yow consider the use of multiple connections simultaneously. Suppose a web browser
is used to downtoad a web page that requires two images and both images reside on the
same Internet host. Then two requests would be genented for the sarne web server. If
the server prKess runs concurrently. then it wiIl use two processes. one to service each
of the requests. How would the two connections king used to service the requests be
distinguished? Figure 2.10 is used to answer this question, The web browser would set up
rwo separate connections by creating two TCP sockets. In this example. the first TCP socket
created by the web browser is assiped the ephemed port nurnber 1500, and the second
TCP socket is assigned the ephemed port number 1501. The frrst TCP socket is then
identified by the TP ziddress of host 1 and the port number 1500. The second TCP socket
is idencilied by the IP address of host I and the port number 1501. To set up a connection.
the web browser can use the welI known port number 80 to indica:~ that it requires service
from a web server. When the remote server process receives the connection set up request,
2. COMPUTER COMMUNICATION AND THE INTERNET 24
a separate process is then used to service the web browser request until the connection is
closed. The separate process still uses port number 80. The connection is identified using
the socket pair [(host 1 tP address, ephemeral port number 1500). (host 2 iP address, port
number 80)]. When the second request is received by the semer process. i t again uses a
sepmte process. and this process still uses the port number 80. The connection is identified
by the socket pair [(host 1 iP address. ephemeral port number 1501). thost 7 IP address.
port number go)]. The two connections are distinguished by the ephemeral port numbers
of the TCP sockets created by the web browser.
2.43 üDP Sockets
A user process that interacts with a UDP layer does not open a connection before sending a
request to a semer process. however. a üDP socket is associated each with the user pmcess
and the semer process. Figure 2.11 shows a set of system cdls provided by the sockets
interface for a user process to create a üDP socket and use it to communicate with a server
process [42]. The socket system cal1 can be used to create a UDP socket and the bind
sy stem cd1 assigns an ephemeral port number to the new socket. nie sendro and reclrfrom
system cdls are used to send and receive data
2. COMPUER COMMUNICAT~ON AND THE INTERNET
1 blocks unul
Figure 2.1 1: UDP System Cails
Figure 2.1 I dso shows the system cdls used by a server process that intencts with a
üDP Iayer to accept requests from remote user processes. The server process can use the
socket system cd1 to create a UDP socket. The bind sysiem cal1 is used to associate the
üDP socket with the port nurnber for the service type that the server process provides. The
sendto and rect'fmrn system cails are used to send and receive data. The same üDP socket
cm be used by a user process to send data to multiple server processes. Each time the
sendto system cd1 is made. the remote socket must be specified. For longer data transfers
the connect system cal1 may be used in which case the destination socket is stored. The
w i r e system caII cm then be used every time some drita is sent. and the stored destination
socket will be used.
A UDP server that opentes concumntly uses port numbers to distinguish multiple
communication sessions differently than a concurrent TCP semer. Figure 2.12 shows an
example of how aconcurrent UDP server works. Trivial File Transfer Protocol (TFïP) [33]
is an application for transferrïng files between Internet hosts. As file uansfers can be quite
short. TFTP uses UDP. Sometimes TFïP can require long file transfers, therefore, a T F P
server cm operate concurrently. A T F P user process wiI1 send a request to a remote server
2. COMPUTER COMMUNICATION AND THE INTERNET 26
process using the well bown port number 69. When the server receives the request it will
use another process to service the request so that it cm be available for other incoming
requests. Unlike a concurrent TCP semer. a new socket is created for the process semicing
the request to which an epherned port number is assigned. The user process must look at
the port number of the first reply from the server process and send al1 following segments
for the request to the indicated port.
iTERNET HOST 1
Intemet hosts use a four Iayer protocoI stack to comrnunicate which includes the application
layer. the transport Iayer. the network Iayer and the physicd layer. The application layer
includes the user applications and application servers provided by the host. Some user
processes communicate with only one server process at a time whereas others comrnunicate
with multiple server processes simuItaneously. A server prucess rnay operate itentively, or
concurrently when servicing longer requests. The transport layer protocols used by Intemet
hosts are the Transport Control Protocol (TCP) and the User Datagnm Protocol (UDP) and
the network layer protocol used by Intemet hosts is the Internet Protocol (IP). Applications
oenerate requests for remote servers in the fom of data strearns which are formatted by the -
TCP module or the ü'DP module. and are sent as iP packers to the destination host by the
IP module. The sockets interface provides a set of rnethods for user and server processes
to cornrnunicate over a network.
This chapter provided a description of the aspects of compter communication relevant
to rnodeling Internet tnI5c. Before the Internet Tnffic Mode! Toolkit is described, an
understanding of both the environment ttiac it w3s developed within and irs contributions
are required. The focus of the folIowing chapter is to provide this remaining background.
Review of Ikaffic Modeüng
The focus of this chapter is to define the development goals and contributions of the Intemet
Tnffic Mode1 Toolkit ([TMT) arid to provide an overview of other work. In order to do this.
cenain concepts rnust fint be described. As a result. this chapter consists of two parts. Ttie
focus of rhe first part is to describe the necessary concepts. and the focus of the second part
is to defrne the development goals and contributions of the ïiMT and to compare it to other
simulators and fnrneworks.
The lnternet Tnffic Mode1 Toolkic was developed for uaffic rnodeling within a particu-
1a.r type of simulation environment. Before the contributions of the ITMT cm be defined. it
is necessary to describe this environment and how it c m be used for tnffic modeling. The
first part of ihis chapter is orgmized as fo1Iows. Basic descriptions of relevant concepts of
simulation are provided in Section 3.1. and tnffic modeling is discussed in Section 3.2.
The second pan: of this chapter is oqanizedas follows. Section 3.3 provides an ove~iew
of network simulators that support uaffic modeiing. while Section 3.4 provides an overview
of fmeworks chat were developed for the reuse of t&c and protocol models. Finally,
Sections 3 5 and 3.6 provide a close Iook at two of the most widety used network simula-
tors. both of which support the developrnenr of M c and protocol modeis.
3.1 Basic Concepts of Simulation
The main purpose of the Internet Tcdiic Mode1 TooIkit is to provide a framework for trafic
modeling within a prirticular simulation environment. A definition of the contributions of
the iTMT requires a description of both simulation in the context of the ITMT. and the
pmicuIar simulation environment that it was developed in. The simulation environment
employ s the logicul p r o c m modeling methodoiogy [ 141 which supports the parallel exe-
cution of simulation models. In Section 3.1.1 a definition of simulation is provided while
Section 3 . 1 2 provides a description of the logicai process modeling rnethodology, and
Section 3.1.3 provides an explmation of plualle1 execution. A description of the emulation
capabilities of the IP-TN simulator is given in Section 3.1.4.
3.1.1 Introduction to Simulation
Comptctrrsimirlarian is the rnodeling of the behavior of aphysicui -rem over time through
the use of a computer progm. A physical systern may be an rictual system such as an
airpon. or it may be ri hypothetical systern such as a possible set up for a cornputer network.
The term simulation will be used to refer to computer simulation in the context of this
thesis.
When a simuiator is nin. it keeps tnck of a rimulurion rime. There are three notions
of time with respect to ri simulation ClJ]. Physicul rimr refers to tirne in the physicd sys-
tern. simitlurion time refers to an abstrxtion used in simulation to mode1 physicai time, and
walIclock rime refers to time during the execution of the simulation progrm. To demon-
strate these notions of tirne. the foltowing exmple taken from [IS] will be used. Consider
a sirnuirition of the transportation system in -4tlanta for the 1996 summer Olympic games.
Physicai time extends from July 19 to August 4. 1996. One way chat the physicd time
could be represented in the simulator is by using a double precision Boating point nurnber
with each unit corresponding to one day- When the simulation is executed simulation time
would advance from 0.00 to 17.00. If the simulation was mn for three hours on the after-
noon of Febmq 35. 1995. wdlclock time might extend from 3:00 PM to 6:ûû PM on chat
day.
There are different types of simulation with respect to the relaionship of the progres-
sion of simulation time to the progression of wdlclock time 1141. For example. a fiight
sirnuiritor used by pilots in training is an example of a mal-rime simularor. In this type of
simulator. simulation tirne dvmces in synchmny with wallclock time. Another type of
simulation is asfasr as possible simulation. In tfiis type of simulation, simulation tirne is
advanced as quickly as possible without any concem for maintaining a fixed relationship
between advances in simulation time and advances in wallciock time. When using this type
of simulation, ri unit of simulation time rnay advance in one second of wallclock time dur-
ing part of a simulation run but rnay take severai minutes during another part. For exarnple,
a simulator that represents a cornputer network could be developed using this type of simu-
lation. The Intemet Traffic Model Toolkit was developed within a simulation environment
that employs this type of sirnuirition, ie. as fast as possible execution.
3.1.2 Logical Process Description
There are different types of simulation and different methods of representing a physical
systern. The type and method used by a sirnulritor cm be refened to as the simulation envi-
ronment. The Intemet Traffic Model Toolkit was deveioped as part of the IP-TN simulator
that is used to simulate computer networks. The simulation environment of IP-TN uses the
logicul procrss (LP) modeling methodology for representing a physicril system.
A physicril system can be viewed as a nurnber of interacting physical pmcessrs. which
are entities of the physicai system. The choice of what constitutes such an entity is highly
dependent on the scenario. Each physicai process can be represented within a simulator as ri logical process. which is an entity of the computer program. For exarnple. an elevator
systern can be simulated using a set of Iogical processes that each represent an elevator.
Each logical process has associated with i t a set of state vuriables. A state variable
is a value that represents an aspect of a physical process. The state variables of a logicril
process are not shared with other logicd processes. The behavior of a physical process
cm be imitrited by changing the vdue of one or more state variables. For exarnple, a
logical process that modek an elevator may have a state variable to represent the floor that
the elevator is currently on. The rnoving of the elevator from one floor to another can be
rnodeled by changing the vdue of this variable.
There are multiple ways of representing the same physical system using logical pro-
cesses depending on the aspects of the system that need to be capnired. The representation
of an elevator system just given, for example. would be usefui if the purpose of the simuia-
tion was to examine the effects of changes to the way in which individual elevators operate.
If the purpose of the simulation was instead to examine how long people have to wait for
an elevator on a specific floor. then it may be unnecessary to model each elevator in detail.
In this case, the elevator systern couId be represented as a single logical process with state
variables to indicate which floors currently have an available elevaror.
Logical processes intenct with erich other to imitate the interaction mong the physical
processes that they represent. The only way that logical processes comrnunicate is rhrough
the exchange of evenrs. An erwr is an abstraction used in simulation to mode1 a change
in the state of the physical system. Each event has a time stamp associated with it that
represents the simulation time at which the change occurs. The minimum tirne required for
the exchmge of events between two Iogical processes is known as the lookuhead time. The
execution of an event refers to the use of a cornputer processor to invoke a method cal1 on
the Iogical process that received the event, and cm resutt in a change of state by the Iogical
process. The simulation methodology thac involves executing a set of evencs that occur at
certain points in simulation time is known as discrete ment simulation.
When ri simulator using discrete event simulation and the logicai process modeling
methodology is run. there are a number of events sent between logicd processes. The
events to be executed for a simulation are organized in increasing time stamp order in one
or more queues. ï h e addition of an event to a queue is referred to as schediïling the event.
The set of events executed by one logical process is a subset of the total set of events for
a simulation run. To accuntely imitate the physical system. each logical process must
execute its set of evencs in increasing time starnp order. By maintaining this order for each
LP. the increasing time starnp order of the complete set of events will dso be mrtintained.
An enor in a simulation run caused by the execution of events out of order is referred to as
a cciirsali~ ermr. To demonstrate this concept, part of a discrete event simulation using the
togicd process view is shown in Figure 3.1. Suppose there are three logical processes each
having its own time stamp ordered queue of events. Assume LP 3 hrts received an event
with a tirne s tmp of 5 from LP 1 but has not received an event from LP 2. Suppose LP 3
executed the event. then later received an event from LP 2 wirh a time starnp of 3. Then the
causality constnint woutd be broken.
To maintain the causrility constrrtint. LP 2 couId have delayed the execution of the event
from LP 1 untiI it was safe to do so. An event received by an LP is safe to execure when
it has ken ensured that no other event with a srnalIer time stamp will be received by the
LP. A method of maintaining the causdity constraint is therefore required. The methoci
Figure 3.1: Causaüîy Error Example
ernployed by the sirnu lation environment of IP-TN delays an LP from executing an event
until the LP has received at Ieasr one event frorn each of the LPs that sen& events to it. To
avoid deadlock situations. that is. to avoid a situation in which acycle of LPs are dl waiting
to receive an event. 3 specid type of event can be sent by an LP to indicate to another LP a
lower bound on the nexc tirne rit which i t will send an event [53]. This algorithm is brised
on the assumption t h dl events sent to an LP are received.
When ri logical process receives rin event, it may change one or more state variables
and send one or more events. To demonstrate this ide* the elevator system example wilI
be continued. Suppose there is an elevator system consisting of three elevators, and the
algorithm used to respond to a request for an elevator is io send the cIosest one. If an
elevator is requested on fioor 3 and there are currently elevators on fioors 4.6. and 7. then
according to the cilgorithm for response. the elevator on Roor 4 is sent. To simulate the
system. each elevator could be represented as a logical process with a state variable for
the flmr number it is currentIy on. To model the scenario just given. each logicai pmcess
couId send an event to each of the ocher two logicd processes indicriting the vdue of its
floor number state variable. L'pon receiving both events, a Iogical process could compare
the floor numbers to its own to see if it is closest to the requested floor. The logicai pmess
with the closest floor number changes the value of its state variable to the requested floor
nurnkr. This is one example of how the scenario couId be modeIed through the exchmging
of events by logicd processes.
3.1.3 Paraiiel Execution of a Simulation
As just explained, the logicd process modeling methodology represents a physical system
as a set of logical processes, each of which could have one or more time stamp ordered
queues of events. As a result. a simulation using this modeling methodology hrts the poten-
tial for execution of multiple events concurrently. Therefore, the use of the logicai process
modeling methodology dlows for the parallel execution of a simulation. To assist in the
understanding of parallel execution. the andogy shown in Figure 3.2 will first be used to
demonstrate how it works. Scenririo 1 shows ri single Zamboni cleaning a hockey rink
whereas scenario 2 shows two Zambonis simultaneously cleaning a hockey rink. If i t cakes
the single Zamboni ten minutes to clean the rink, then it could potentially trike two Sam- bonis five minutes to clean the rink. In the second scenario, the two Zambonis are working
together in paraIlel to finish the same job in less time than it would take for a single Sam-
boni to complete.
Figure 3.2: Zamboni Scenarios
The concept of working in pardIel is the key idea behind paralle1 simulation. An exarn-
ple to assist in demonstrating how the parailel execution of a simulation works is depicted
in Figure 3.3. Shown in the di%- is one computer processor and two Iogical processes.
each with a time stamp ordered queue of events. Even though both LP 1 and LP 2 have
an event to process. only one event cm be executed at a time because there is only a sin-
gle processor. The method of tunning a simulation by executing a single event at a time
is referred to as sequential execution. When using sequential execution, the events of a
simulation can be organized as a single queue.
[ e v r n t - x - ~ ] - - - * @ tirne = 6 time = 5 time = 3
1 computer ]
[ - G q s ) - @ time = 7 time = 2
Figure 33: Sequential Execution of a Simulation
[n contrast. consider Figure 3.4. Shown in the d i a g m is the same scenario but with
two cornputer processors. As both LP 1 and LP 2 have events to process and there are two
processots available. two events cm be executed concurrently. The method of running a
simulation by executing multiple events concurrently is referred to as parallel execution.
One of the main purposes of paralle1 execution is to reduce the amount of time it trikes to
mn a simulation.
Figure 3.4: Parallel Execution of a Simulation
To run a simulation, algorithrns are required for the scheduling and execution of events.
Irnplementations of these algorithrns are provided by the simulation kemel. A simuhtion
kemel is a software module that provides the functionality required by the simulation envi-
ronment to run a simulation. The functionality provided varies depending on the simulation
environment. The Internet Tnffic Model Toolkit was developed to employ discrete event
simulation and uses the logical process rnodeting methodology which dIows for the paral-
le1 execution of a simulation. Now that a basic description of this simulation environment
has been provided, the emulation capabilities that are provided by the IP-TN simulator will
be explained in the next section.
3.1.4 Description of Emulation
In addition to simulation of computer networks. the IP-TN simulator provides emrtlarion
capabilities. It is useful to acquire a basic understanding of these emulation capabilities to
understand the environment provided for mfXc modeling when using the Intemet Traffic Model Toolkit.
Consider the following scenario that will demonstrate how the iP-TN emulation cap- bilities work. Refening to Figure 3.5. suppose two people are playing a computer game
against each other over the Intemet. Plriyer 1 is using host 1 and player 2 is using host 4.
For the purpose of this example, a computer game is a user application that sends informa-
tion about one player's actions to the other player's computer. For example. suppose the
motive of s player was to shoot the opposing player. If Player 1 shot player 2. ri message
could be sent from host 1 over the Intemet to host 3 to infonn player 2.
Figure 35: Intemet Game System
A Company that sells this type of game may want to evaluate the performance of a
particular game before selling it. To evaluate its performance. certain aspects of a game
could be tested. For example. the mount of time it takes piayer 2 to be informed thal
they have been shot could be tested to see if it stays within a defined limit. To perform
this testins. two employees could play the game qainst each other over the Internet. This
method. however. may not be very productive. The reason for this is that many people
across the world could be using applicïuions chat are sending information over the Internet,
therefore, it could very difficult to determine dI of the types and arnounts of traffic on the
Intemet whiIe the game is k ing played. As a result, it codd be difficult to interpret the
reasons for the levet of performance achieved in a given trial of the game. For exmple,
suppose that the amount of time between player 2 k i n g shot and player 2 king infonned
that he had been shot was beyond a desired limit. It could be that the game of host 1 is
not sending a message to host 4 quickly enough after player 1 is shot. It could also be that
other traffic on the Internet has caused a delay in travel time for the message from host 1
to host 4. As there are multiple explanations and the amount and types of traffic traveling
over the Internet are unknown, it could be very difficult for the people testing the game
to determine the correct reason that the aspect of the giune k ing tested is not within the
defined limit. If the people performing the testing could control the types and mount of
traffic on the Intemet while they were playing the garne. then the performance of the game
could be more properly tested. However. this in an unachievable possibility.
Suppose the grime was instead played over a simulated Internet as depicted in Figure
3.6. In this example. one player is using host 1 and the other player is using host 2. Intemet
hosts can be represented within the simulator as entities of a computer program. therefore.
the amount and type of sirnulated traffic k ing sent between hosts in the simulator cm be
specitïed. As a result. n game can be played in a controlled environment that behaves like
the Interner and a pmicular test can be repeated. To do this, however. the two players
must be able to play the g m e from their cornputers over the simulated Internet. The IP-
TB simulator provides a simuIated Internet and emulation capabilities as an interface for
actual Internet hosts to send data through the simulated Internet. By using the emulator. two
players could play a game against each other over the simuiated Internet and it would appear
to them as though they were playing over the Intemet. Potentiaily. any user application
that is desipned to be used over a computer network couid be tested by using iP-TN in
conjunction with the ernulation capability.
Figure 3.6: IP-TN Emulator
The [P-TN simulation environment andernuiation capabilities have now k e n described.
A description of the concept of a trafic model is the final description rernaining that is use-
ful to the understanding of the developmenc goals of the Intemet T m c Model Tooikit. A
description is provided in the next section.
A traffic model is a representation of one or more entities that genentr network traffic. For
example. a tdfic mode1 could be a representation of a single user application, or it coutd
be a representation of several user applications. In the latter crise. the traffic model is a
representation of the multiplexed uaffic h m the multiple applications. and is referred to
as an aggrqafe traffic mode1 [19.35.201.
One way that a tmffic model cm represent network tmffic is mathernaticdly. For ex-
ample. a user application generates mounrs of data at particuhr times. 00th the mounts
of data and the tirne intervals rit which it is genented may closely t'ollow certain statisti-
cal distributions. The generated traffic c m be represented by the traffic model using these
distributions.
Displayed in Figure 3.7 is m example of a simple tnffic model deveIoped with the log-
ical process modeling methodology that could be used in a network simulator that employs
discrete event simulation. Two types of evenrs can be sent by a Iogicril process. intemal
events and externul events. An inremal ewnr is an event that is sent by an LP to itself. ruid
is usualIy used by an LP to triger itself to perform some action at 3. specific simulation
tirne. As shown in the example of a sirnpie tmRic model, a logicai process could schedule
an internd event for the simulation cime at which a data stream should be generated. If
the traffic model genentes data streams at times riccording to a statistical distribution. then
internd events cm be scheduled for rhese urnes- When an internd event is received the
LP cm execute a method to geneme a data stream. An m e m a l evenr is an event that is
sent by an LP to a different LP. As shown in the example of a simple traffic model, externai
events can be used to represent packets composing the data sueam. Earh external event
cm be sent to the LP representing the destination cornponent of the data stream,
The logicd process modeiing mettiodology uses evmr-arienred simulation. ïhat is.
changes of state in a simulation scenario over Ume depend on the ~ceiving of events.
Figure 3.7: Example of a Simple Ttamc Mode1
Another type of simulation is process-oriented simulation. In process-oriented simulation.
a simulation process models an entity and encapsulates a behavior that is defined by a
set of actions [I-t]. Process-oriented simulation can still use events. but the change of
state of simulation processes does not necessarily depend on the receiving of events. In
process-oriented simulation. a simulation process cm wait or advance a certain amount of
simulation time without the use of events. For example. using process-oriented simulation,
a simple traffic model could be implemented using a simulation process that sen& data
streams and waits for a certain amount of simulation time between each without using
intemal events.
In the following sections. the development goals and contributions of the ITMT are defined and a comparison with other work is provided.
Overview of Network Simulators
The main _goal in the development of the Intemet Traffic Mode1 Toolkit was to provide a
fmework for the reuse and development of uaffic and protocol models within a simulation
environment that dlows for panllel cxecution. To achieve this. the iTMT was developed
within a simulation environment that uses the logicai process modeling methodology- After
development. the IlMi was applied to the incorporation of two models frorn the wideiy
used ns [2. 121 simulator. which only allows for sequential execution. into the iP-TN sim-
ulation environment. As a result, the ns simulation models can now be used within simula-
tion scenarios that parrillel execution c m be applied to. The iP-RI simulation environment
dso provides an emulation interface. therefore. traffic and protocol models developed or
incorponted using the Intemet Traffic Model Toolkit cm be part of simulated networks
that cm interact directly with Intemet hosts. Both iP-TN and the Intemet Traffic Model
Toolkit were developed to be freely available to the research comrnunity.
Other network simulators have k e n developed for the modeling of computer networks
connected to the Intemet. some of which provide a fmework for &c and protocol model
developrnent. In order to define the contributions of the Intemet Tnffic Model Toolkit. it is
irnponmt to compare it to these other simulators. This section provides comparisons to SSF
[S. 91, NerSOM [22] and OPNET [6.21] in Sections 3.3.1,3.3.2 and 3.3-3 respectively. The
focus is to examine the simulation environments provided for the development of t&c and
protocol models and to compare these environments with the environment of die Intemet
Traffic Model Toolkit.
Two other simulators were examined in detail. ns [?. 121 and GIuMoSim (11. The ns
simuiator is widely used in the networking community. however. does not dlow for the
parallel execution of simulation scenarios. Therefote. the Intemet Traffic Model Toolkit
was used to create an interface between two ns models and the [P-TN simulator. As a
result, these models can now be used in P-TN simulation scenarios. A close Iook at ns.
therefore. was useful both to examine how a widely used network simulator provides a
framework for the development of tnffic and protocol models, and to assist in detemining
how an ns model could be reused by the Intemet Traffic Mode1 Toolkit. GloMoSirn has also
k e n appiied to the reuse of the same ns models incorponted into iP-TN . and GloMoSim
provides a simulation environment that allows for parailel execution. Even though this
work was encountered after the ns rnodels had dready ken incorporated into the IP-TN environment. a close look at how this was accomplished using GloMoSim was useful as a
cornparison. A description of rrs is provided in Section 3.5 and a description of GIoMoSim
is given in Section 3.6.
3.3.1 Scalable Simulation Framework
The Scaiable Simulation Fnmework (SSF) is a network modeling framework [S. 91. The
simulation environment of SSF employs discrete event simulation and paraIlel execution
cm be apptied to simulation scenarios. SSF provides a set of five base classes for construct-
ing simulation scenarios. the Entity, inlhannel. outChannel. Process and Event classes.
Models can be developed in the C++ and Java pro-garnming languages by extending these
classes or deriving new ones. Network components are defined using the process-oriented
view. The functionality of a network cornponent is defined using the Process class. and the
state is defined using the Entil class. The InChannei and OutChannel classes are used to
define the endpoints of communication channels and the Event class is used to represent
the messages passed between network components.
Another frmework. SSF-OS. was designed to be used with SSF for simulating Intemet
networks and protocols. A set of component rnodels are provided by SSEOS including net-
work elements such as routers and hosts and network protocols such as IP, TCP and UDE
An Application Pro,mmer's Interface (MD is provided for extending and developing
models usin3 these components. The APT provided by SSEOS is composed of three core
base classes. ProrocolGraph. ProrocolSession and ProrocolMessage. The ProtocolGraph
class is used to define the set of protocols that a host conratns and their relationship to one
mother. Protocol models can be developed by deriving a class from the ProtocolSession
class. The ProtocolMessage class is used to represent the data fragments passed between
protocol models. This set of classes can be used to develop both protocol and traffic models.
SSF provides a frarnework for the development of tnffic and protocol models within
ri simulation environment that ailows for parallel execution of simulation scenarios. How-
sver. it has not k e n applied to the reuse of a mode1 frorn a network simulation environment
that only allows sequential execution. Unlike the IP-TN simulator. SSF does not provide
emulation capabilities for simulated networks to intenct with Internet hosts. That is. the
SSF simulator does not provide an interface to allow actual Internet hosts to send packets
through a simulated network scenario. or for simulated packets to be sent over an actuai
network. As a result. traffic and protocol models developed with SSF cannot be used in
simulated network scenarios that are applied to h e testing of actual Internet host services.
33.2 Network Simulation Object Model
The Network Simulation Object Model (NetSOM) is a simulation toolkit that was designed
to provide a library of extendible nenkiork objects with weil defined interfaces to be used
by network engineers and academic researchers for analyzing existing implementations
and designing new ones [22]. A main goal in the developrnent of NetSOM was to pmvide
interface capabilities that allows for different programming tools and utilities to be used
for the definition of simulation scenarios, evduation of simulation results and for t d c
collection. The simulation environment of NetSOM employs discrete event simulation
simulation and simulation scenarios can be executed sequentidly. Network objects cm be
extended and developed using the MODSIM iII simulation language. MODSLM III uses
the process-oriented view of representing a physical system.
The libnry of network objects provided by NetSOM is a set of base classes including
Node. Link, Network and Traffic Source classes. These classes can be extended or ovenid-
den to develop new ones. Models of hosts and routes c m be developed with the Node class
and the Network class cm be used to group nodes together into networks. The Link class
can be used to develop models of the connections between hosts. routes. and networks.
The Traffic Source class can be used to develop trriffic models which are contained by
nodes. Provided with this set of base classes are severai protocol implementations includ-
ing TCP and IP models. The base protocol implementations provided can be extended or
ovcmdden and new classes cm be developed to implernent new protocols. in the rivailable
litenture. no funher detail is given on the interfaces of these network objects.
Liniike the IP-TN simulator. NetSOM dws not provide ernulation capabilities for in-
teraction between simulated networks and Internet hosts. NetSOM was intended to be
available CO academic researchers, however. is not currentiy k ing distributed.
3.3.3 Optimized Network Engineering Tool
The Optimized Network Engineering Tool (OPNET) is a commerciai network simulation
package for the design and study of communica~ion networks. devices. protocols and appli-
cations [6 ,2 i l . The simulation environrnent of OPNET employs discrete event simulation.
and simulation scenarios cm be executed sequentially.
A libnry of extendible models is provided which includes network. node and process
rnodels. Editors are provided for extending and developing each of these types of modets.
Node models can be used to define nenvork components, and a network rnodel cm be used
to define how network components are connected. A node model is described as a block
stnicnired data flow d iabm. The functionaiity of each block of a node model is defined
using ri process model. A process modet uses process-oriented simulation and c m be used
to specify sevenl aspects of a node such as a protocd or an application. A process model
is developed in the Proto-C languagt, which is a combination of state transition dia,ms.
kemel procedures and the C programming language. The process editor provides art en-
vironmenc for the developrnent of new process models based on a state transition diagram
approach. The progression of a pmcess in response to rvents cm be defined gnphicalty as States and tnnsitians. and a l i b r q of C hnctions is provided for specifying logic at each
state. A library of detailed protocol and application models is provided including TCP and
IP models.
Unlike the [P-ITj simulator. OPNET does not provide emutation capabilhies for in-
teraction between simulated networks and Internet hosts. OPNET is only commerciaily
available. and cornmerciail restrictions prevent public domain research into the methodoi-
ogy of extending and developing protocol and traffic models.
3.4 Ovemew of Parallelization Frarneworks
One of the main goals in the development of the [ntemei Traffic Model Tooikit wris to
provide a fmework chat supported the reuse of sequentid network simulation models in
a simulation environment that altows for parriilel execution. Other friuneworks have k e n
developed to parallelize sequential network simulation models. however. the methods used
in achieving the pmllelization differ €rom the method employed by the Internet Tnffic
Model Toolkit. A cornparison to three fmeworks is provided here. Section 3.4.1 provides
an overview of a project using the TeD simulation language [25], in Section 3.43 a parriIlel
CO-simulation framework [26] is described. and Section 3.3.3 provides a look at a generic
pimilelization fmework [36].
3.4.1 The TeD Simulation Language
A project was initiated to reuse the widety used TCP and P modeIs of the sequentiai
network simulator ns [2. 121 in a panllel simulation environment [El. The plan was to
triinsfonn m source code into the Telecommunications Description h g u a g e (TeD) [24].
TeD is a simulation language based on C u that ailows for the paralfel execution of sim-
ulation scenarios. The intention of the project was to create simulation models using the
TeD simulation language that behave identically to ns models.
The TeD Ianguage uses process-oriented simulation. An enti'y is used to represent a
network component and has a state and a behavior. The behavior of an entity is defined as
a set of functions and processes. The flow of control of an entity is defined by its processes
which can change the state of the entity and crin send and receive events. A process cm
invoke functions of an entity which cm only change the state of the entity and cannot send
and receive events. The processes of an entity cm communicate by sending events thmugh
an infernal cliannel. Different entities communicate by passing events to each other through
txternal channels.
A completely stnightforward translation of ns code into the TeD language was not
possible. The main chailenge was that. unlike the TeD language. the ns simulator uses
event-oriented simulation. Most of the ns classes could be transformed into TeD entities.
Not al1 of the ns clriss methods. however. could be transfomed into TeD functions. As TeD
processes crin send and receive events but TeD functions cm not. ns methods th3t include
an event as a panmeter had to be tnnsformed into a TeD process. Another complication
was that some ns constructs. such as event cancellation. had no immediate replacement in
the TeD language.
This method of pmllelizing ns rnodels does not appear to be very quick or simple. The current status on this project is unavailable.
3.1.2 Pardel Co-simulation Framework
A framework was developed for the panllelization of sequentid network simulators through
the use of CO-simrtlarian [26]. In the contelrt of this fiamework. CO-simulation rneans that
two simulations are run together as if they were a single simulation. The entities of both simulations communicate with each other as if they belong to the same simulation, The
use of this framework aiIows CO-simulation of sequentid network simulators with parrtllel
simulations developed using the Active Networks Simutation Environment (AISE) [26].
Currently the framework supports CO-simuiation of models developed using ANSE with models from the ns simuiator [2. 121. Basically. the ns simulator was adapted to run on the
same simulation kemel that AiYSE uses. In order to adapt ns, some of the class structure
was modified and functions were added IO some of the ns classes. The ns simulator does
not adopt the logical process modeling methodology, therefore, in order to adapt ns to be
run alone in a parailel simulation environment a substmtial amount of revision to the ns
models would be required. Instead. CO-simulation was used to run ANSE and ns simula-
tions together nther than adapting ns ro be executed in parallel done. This means that the
GYSE and ns simulation models communicate with each and are run as one simulation. To
achieve this, an interface module was written so that the components of each of the two
simulation models could communicate with each other.
Currently this panllel co-simulation framework only supports CO-simulation of models
developed using ANSE and m. The set of methods developed in parrillelizing ns may
or rnay not apply in parallelizing other sequentid simufators. Furthemore, new issues
could be encountered in doing so. For example. using this fnmework to parallelize a
sequential simulator based on the process-oriented view of simulation may dso involve the
transformation of flow of control of processes into actions performed upon the receipt of ün
event. It does not appear that the fnmework is a geneni method for panllelizing sequential
simulators but a set of methods provided as a result of parallelization of rnodels from the
ns simulator.
3.4.3 A Generic Parallelization Framework
A genetal framework has been deveioped for the pmllelization of any sequential network
simulation [36]. To panllelize a simuiation using this fnmework. the simulation is run as
a disrribitred simularion. In the context of this fmework, distributed simulation means
that a simulation is partitioned into a set of smailer simulations. and each of the smailer
simulations is mn using a different processor. When 3 simulation is partitioned each of the
smaller simulations represents a portion of the original state and maintains a sepante time
starnp ordered event queue.
To use this method of paralIeIization. seved issues must be addressed. First of ail.
routing capabilities must be provided so that the nodes of different portions of a simulation
scenaïo can send events to each other. The litenture on the framework discussed here sug-
gests some alternatives. but routinp capabilities rue not provided by the framework itself.
Secondly. as portions of a simulation scenario have their own event queue, a rnethod for
ensuring that events are only executed when it is safe to do so is required. Thirdly, a method
is required for separate sub simulations to send events to each other. The fnmework was
applied to a simulation network scenario that was developed using the ns simulator [2. 121. For this application of the framework. an existing runtime library was used to provide
methods for sending events and ensuring that events are safe to execute. The ns network
scenario was partitioned into eight subnetworks, and executed as a distributed simulation
using eight processors.
The fnmework described here was developed to be a general framework that could be used to pardlelize any sequential network simulation. The only example provided in the
literature [36], however. was the application of the framework to a single network scenario
developed using the ns simulator. The method of achieving pardlelization through the use
of distnbuted simulation rnay be successful when applied to other simulators, however.
unexpected issues may also be encountered, For example. the use of this framework to par-
dlelize a sequential network simulator thar does not employ the logical process modeling
methodology may require a partitioning of the state of a simulation scenario. It rippears
that other applications of this fnmework are required to iIlustnte its genenlity.
The ns Simulator
This section provides a detailed look rit the ns simulator. Fïrst a genenl description of ns is
given. then a detailed look at the APIS provided for protocol and traffic model development
are given in Sections 3.5.1 and 3.5.3 respective[-
The ViNT project involved the development of the multi-protocol network simulator
ns [2 . 111 based on the REAL [l8] and E S T [IO] sirnulators. One of the main goals in
the development of ns was to provide the resemh cornrnunity with a common framework
for network simulation and protocol deveiopment. The ns simulator is publicly available
and new developments submitted are either incorponted into the distributed version of ns
or made publicly rivailable. ns uses sequential discrete event simulation. The simulation
components were developed in C t t and the user interface was developed in OTcl. The net-
work animation tool nam allows for visualization of simulation runs. Emulation capability
is provided which allows the simulritor to interface to a live network. ns provides quite
an extensive library of traffic protocol rnoduIes including a web traffic model. F'ïF (File
Transfer Protocol [28]), Telnet [3 11, UDP and several TCP models. To ease the process of
testing new protocols. automated test suites and a frarnework for testing the robustness of
a protocol. STRESS [15]. are provided.
3.5.1 Developing a Transport Layer Protocol Model
The ns Agent class provides a set of methods ris an API for developing a new protocol
model. When extending the Agent clriss. sorne of these methods must be defined. some
of them have default definitions. and the remaining ones rue optional. The lisren, connect.
and close methods c m be used to simulate the opening and closing of connections, but are
not required by a protocol model. The only TCP model provided by ns that implements
these methods is the full TCP rnodel. As shown in Figure 3.8. one of the sendtnsg or sendro
methods must be implemented by ri mode! derived €rom the Agent class in order for an
application model to send packets to it. The srnd method is irnplemented by the Agent
class to send a packet and is not intended to be ovenvritten by extended classes. The recv
method is invoked when a packet is received and is intended to be overwritten by classes
derived from the Agent class. The a d method cm be defined to acknowledge received
packets.
Figure 3.8: ns API for Developing a Transport Layer Protocol Model
When implementing a transport Iayer protocoI. the TimerHandler class is provided for
irnplementing any required timers. For example. the TCP models provided by ns imple-
ment a retransmit timer that is set every time a packet is sent. If an acknowledgment is
not received for the packet before the retransmit timer expires, then the packet must be
retransmitted. When extending the TtmerHandler class. the erpire method must be defined
with the procedure for handling an expired timer. The expire method can cd1 the timeout
method of the transport Iayer protocol ic belongs to. The timeout method is a method of the
Agent class and must be implemented by an extended class when defining a transport layer
protocol that contains one or more timers.
The user interface provided by ns was developed using the OTcl scripting language,
When implementing a new protocol, the Iinkage from the new protocol class to the ûTcl
interface must be defined. The OTcl interface provides methods for creating simulation
objects and defining their state. The TciCluss OTcl class must be extended and the creare
rnethod defined so that creation of an OTcl object results in creation of a corresponding
C u object. Each Ctt. variable representing part of the state of the C-H object must be
bound to a corresponding narne in the OTcl name space for a change to an ûTcl variable
to nsult in a change to the corresponding C+.t variable. This is essential to enable users to
set the initial state of a simulation object. The delaybind-initall and deluybindllispatch
methods of the Agent class can be implemented to bind the C++ variables to OTcl variables.
Within these methods OTcl methods for binding variables can be cdled as the Agent class
is derived from the OTcI TclObject class. The command method of the Agent cliiss is
provided to ailow C u rnethods to be invoked from the ûTcl interface. This rnethod can
be implemented in a ciass extended from the Agent class to map Ct+ rnethods to method
names in the Tcl script.
3.5.2 Developing an Application Mode1
The ns Application class provides a set of rnethods as an API for developing application
models. When extending the Application class. a set of methods is provided that cm be
used to define an application model. The stan and stop methods are used to indicate to the
application to start and stop sending data. As shown in bold text in Figure 3.9. the send
method is used to invoke an application to send a number of bytes. The recv method is used
by a transport Iayer protocol to indicate to the appiication that it has received a number of
bytes and the resiime method can be used by the transport layer protocol to indicate to the application to continue sending data
Timers cm be defined for the application in the sarne rnanner as for a transport layer
protocol. and linkage to the OTcl interface is required and c m dso be defined in a similar
Figure 3.9: ns AP1 for Devefoping an Appücation Model
manner as for a transport layer protocol. The command method of the Application class
can be used to map a C u function cd1 to a method name in the Tcl script. A case for the
stm method should be included in the command method so that a user c m indicate when
an application should start sending data.
The TruflcGenerator class is extended from the Application clriss. The TdficGencr-
ator c1i.1~~ a n be used to implement a tnffic genetator other than a user application. such
as a constant bit rate source. A set of virtuai rnethods rire provided by the TrafficGenerator
class that crin be used in de fining a t&c source.
3.6 The GloMoSim Simulator
This section provides a detailed look at the GloMoSim simulator [ I l . First a general de-
scription of GIoMoSirn is given. Following is a detailed description of the API provided
for protocol development in Section 3.6.1. and an in depth look at the parallelization of one
of the ns TCP models in Section 3.6.2- GloMoSim (Global Mobile Information System Simulator) is a scalable simulation Ii-
bnry for modeling wireless networks that was developed at UCLA Il]. GloMoSim was
developed using the Parallel Simulation Environment for Complex Systems (PARSEC),
which is a C based simulation Ianguage. A GIoMoSim simulation c m be run using sequen-
tid discrete event simulation or. with a few modifications, using paralle1 discrete event
simulation. GloMoSim was designed to simulate very large wireless network models con-
sisting of thousands of nodes.
Each node in a GIoMoSim simulation represents an entire protocol stack. The protocol
layers included are the application. transport, network, data link and physicd layers. A
protocol layer is implemented as a set of method calls. Each simulation entity represents
multiple nodes residing in a particulargeographicd area. The application layer models pro-
vided include Telnet and FTP. and the transport layer models provided are TCP and UDP.
IP and mobile IP with dynamic routing support are provided for the network layer. As
GloMoSim is oriented towards modeling wireless communication. the protocol modules
provided for the data link and physicai layers implement protocols for wireless comrnuni-
cation. and mobility models are provided for nodes.
3.6.1 Developing a Protocol Mode1
To develop a protocol model CO be used within GloMoSim a set of function calls must be
implemented. A skeleton interface for implementing these functions is provided for each
protocol layer as a PARSEC file. The initialkation function is called at the beginning of a
simulation rur, and is used to define any initiahzation that is to be performed for a protocol
implementation beforc the simularion run begins. Thejhalice function is called at the end
of a simulation run and is used to define how the output of statistics is performed.
A function must also be defined to dlow a protocol to send messages to lower or upper
layer protocols. Parameters Vary depending on the sending and receiving protocol layers.
An API is provided for every pair of neighboring protocol layers to assist the protocol
developer in quickly integnting a model. For example. the network layer to transport layer
API specifies two methods. one to send a packet from the network layer to the transport
layer. and one to send a packet from the transport layer to the network layer. For each
method the required panmeters are indicated. For exarnple, when a packet is sent from
the transport layer to the network layer the puyluad and pucketSize fields of the packet
are required by the network Iayer. The implementation of certain protocol layers require
additional methods as well. For example. a TCP modet requires the methods displayed in
Table 3.1
3. REVIEW OF TRAFFIC MODELING
1 representing a server to open 1
Method
Open Listen Socket
1 a listen connection
Connection Open 1 Used by an application model
Purpose
Used by an application model
Fields
application type, local port
application type. local port.
Data Packet Send
rernote address, remote port to initiate connection set up
Used by application model pay loaci, packet size, I
/ to send a packet 1 conncction ID
Connection Close Used by an application mode1 connection ID -7
Open Result / the application layer of an / connection a) I
/ to close a connection 1
/ opened listening socket 1
Listen Socket 1 Used by s TCP mode1 to infom locd port.
Connection Open
Result
connection type. Used by a TCP mode1 to inform
the application layer of an
Data Sent Result
locai port. remote address.
1 opened connection
Used by a TCP mode1 to
indicate the number of bytes
that can be sent
remote port. connection iD
connection ID,
packet size
1 the qplication layer about 1 payload. packet size
Data Received / Used by n TCP mode1 to inforni I
connection ID.
connection type. Connection Close
Result
received dan
Used by TCP model to infonn
Table 3. L : Methuds for GloMoSim TCP Model
the application Iayer of a
connection close
connection ID
3.6.2 Application of GloMoSim to Paraiielization of ns TCP model
The mosr recent release of GloMoSim includes a TCP model from the ns simulator [2. 121.
The configuration file used to run a simulation does not support the use of this model at the
current tirne, however. a new release is intended to provide support for the use of seved
of the ns TCP models. Severai issues are encountered in incorporating a modef from one
network simulator into another. Two of the main differences between Glo~MoSim ruid ns
are the user interfaces and the simulation environments of each.
The ns simulator was developed in C u . and the user interface was developed using
OTcl. Each simulation object is mapped to an OTcl object enabling the user to specify
the state as well as methods to be invoked on the object. When a state variable of an
OTcl object is changed the corresponding value of the CU variable is also changed. To
incorponte the ns model into GloMoSim. the OTcl interface was modified so that OTcl
methods could still be calied by corresponding C u objects. The modified method ciiils do
not have any functionality, however. the reason for allowing C t t objects to still be able to
cal1 these methods is to reduce the amount of modification required to incorponte the C u
objects into GloMoSim.
An interface class. GlomoNSTCPlnte~ucer, was written to incorponte the ns TCP model into GloMoSim. The ns TCP source model is implemented by the ns TcpAgent class
and the ns TCP sink model is implemented by the ns TcpSink class. The GlomoNSTCPln-
re6lcrr clriss contains a list of TcpAgenrs and a list of TcpSinks to enable a GloMoSim
node to contain ris TCP source and sink objects. The main access point into TcpAgent
and TcpSink objects is through the recv method cd1 which is invoked when a TcpAgent or
TcpSink object receives a packet. The GloMoSim methods TcpRccrive and TcpReceiveAck
are used to invoke the recv method on the appropriate TcpAgent or TcpSink object. The ns
send method is used by a TcpAgent or TcpSink object to send a packet. The send rnethod
was replaced by the GLOMOsend method so that a packet sent by a TcpAgent or TcpSink
object is sent from the GloMoSim node to which it belongs.
Each packet sent by a TcpAgent or TcpSink is a Packet object. In order for TcpAgent
and TcpSink objects to send and receive ns Packet objects to one another, a pointer to the
Packet object is contained within the GloMoSim event that is sent from the source GIo-
MoSim node to the destination GloMoSim node. An ns packet contains multiple headers
and each header has an offset used to access i t These offsets are initiaiized at ththe k-
~inning of a simulation a n . The GloMoSim inir class was developed to perform packet - header offset initialization dong with other such initialization procedures required by the
ns models.
Other smailer issues were resolved in the integntion of the ns TCP mode[ into Glo-
MoSim. The issues described here give an idea of the main problems that must be deait
with in incorporating an ns mode1 into a parallel simulation environment.
Summary
The main goal in the development of the Intemet Traffic Model Toolkit (TrPUIT) was to
provide a inmework for the reuse and developrnent of traffic and protocol models within
a simulation environment that allows for padIel execution. The ITMT was deveioped
as part of the Intemet Protocot Traffic and Network (P-TN) simulator. The simulation
environment of IP-TT4 employ s the logical process modeling methodotogy whic h allows
for prinllel execution of simulation scenarios. The IP-ïN simulation environment dso
provides an emulation interface. therefore. traffic and protocoi models developed or incor-
ponted using the iTMT cm be included in simulated networks used to test services of
actual Intemet hosts. Both iP-TN and the ïMT were developed CO be freely available to
the reserirch community.
Other network simulators have k e n developed chat support the development of traffic
and protocol models. The ns simulator [2. 121 supports protocol development, provides
a set of widely used models. is freely available, and provides an emutation environment.
However. the ns simulator uses sequentid simulation which resuicts rnodel size due to
simulation run cimes. The Scaiable Simulation Frarnework (SSF) [S. 91 supports protocol
development in a panlie1 simulation environment. however. it does not provide a set of
rnodels as widely used as those of ru and has not achieved the reuse of such models in
the parallel simulation environment that it provides. Funfiermore, SSF does not provide
an emuIation environment for developed models. The GIobaI Mobile Information System
Simulator (GIoMoSim) [ l ] supports protocol development in a parallel simulation envi-
ronment is freely available and supports the reuse of ns models in a parallel simulation
environment. GloMoSim. however, does not provide an emulation environment for devel-
oped models. The Necwork Simulation Object Model (NetSOM) [22] and the Optimized
Network Engineering Tool (OPNET) [6, 211 ate not freely available and neirher of thern
provide paralle1 simulation environments or emulation capabilities.
Other fmeworks have k e n deveioped to parallelize sequential network simulation
models. however, the methods used in achieving the parailelization differ from the method
employed by the Internet Tnffic Model Toolkit, These fmeworks do not provide environ-
ments for protocol development. but focus on the reuse of sequential network simulation
models. One initiated project involved the rewriting of code from the ns simdator into the
TeD parallei simulation language [Z]. This is a time consuming method of pmilelizing
a sequential simulation model, and the status of this project is not currently available. A
general framework was developed for the parallelization of any sequential network simula-
tion [36], This framework uses distnbuted simulation to parallelize a sequential simulation
model which requires the model to be partitioned into a number of smaller simulation mod-
cls, and has so far only been applied to the reuse of simulation models from one sequential
network simulator. Another framework was also developed that runs a sequential simula-
tion model on a panllel simulation kemel. but in a CO-simulation environment with another
simulator [26]. This framework has only k e n applied to the teuse of models from one
sequential network simulator.
Now that the development goals and contributions of the Interner Traffic Model Toolkit
have k e n defined. its design will be described in the Chapter 4.
Internet Traffic Model Toolkit Design
The main focus of this chapter is to present the design of the Intemet Traffic Model Toolkit
(ITMT). The Internet Traffic Model Toolkit consists of a simulation model of an Internet
host. and provides an interface for the reuse and development of traffic and protocol mod-
els within the [P-IX simulation environment. Section 4. L provides an introduction to the
Internet host simulation model and a description of e x h model component. In Section
4.2 an explmation of the interfaces between each pair of cornponents that communicate is
given. while Section 4.3 provides a description of how the demultiplexing of IP packets C
and the use of sockets is represented. Finally, a cornparison of model alternatives that were
considered is given in Section 4.4.
4.1 Host Simulation Model
The Internet Tnffic Model Toolkit consists of a simulation rnodel of an Internet host that
was developed within the iP-TN simulation environment. The focus of this section is to
introduce this simulation mode1 and provide a description of its functionality. In Section
4.1.1 the host simulation model is introduced. and Sections 4.1 -2, 4.1.3 and 41.4 provide
descriptions of each of the model components.
4.1.1 Model Components
Shown in Figre 4.1 is the representation of an Intemet host previously introduced in Sec-
tion 2.1. and a simulation mode1 based on this representation that was used to implement the
Intemet Traffic Model Toolkit. An Internet host is represented in the simulation mode1 as
a logical process that encapsulates one or more Trafic Objects. Recdl that the logical pro-
cess modeling methodology was described in Section 3.1.2. A Traffic Object represents a
tnffic mode1 and encapsuIates one or more Prorocof Objects. A Protocol Object represents
one or more protocol layers. The iP packets sent between Internet hosts are represented by
events. The multiplexing and demultiptexing of iP packets provided by the transport and
network protocol layers and the use of sockets are represented by functionality within the
host logicril process.
Figure 4.1: Represeotation and Simulation Mode1 of an tnternet Rost
The remainder of this section provides a more detailed description of each of the mode1
components. A description of the host logicid process is given in Section 3.1.3 Section
1.1.3 provides a description of the Tnffic component. and a description of the Protocol
component is given in Section 41.4.
4.1.2 Host Logical Process
The main component of the simulation mode1 used to implement the Intemet Traffic Model
Toolkit is a logicrii process that represents an Internet host. The simulation environment
used employs the event based logical process modeling methodology, therefore, a simu-
lation is driven by the sending of events between logicd processes. As as result. a host
logicd process controls the function of the other mode1 components that it encapsulates.
Within the [P-TN simulation environment. a logicd process is an instance of a C u
class. This class is provided by the simulation environment and defines the basic function-
ality of a logical process. For example. this c l s s provides a method for logicd processes
to send events. The ITMT host logical process is implernented as a C-H CISS derived from
the base logical process c lss and provides a set of methods for a Traffic Object to com-
rnunicate with the host LP to which it belongs. This set of methods will be described in
Section 4.2.1. In addition to these. other methods are defined by the host logical process
class. Sorne of them are required to be implemented by the base logical process class to
Liefine the behavior of the host logical process during simulation initialization and terni-
nation and when receiving events. These will be described later in this section. Others are
required to be implemented by the fmework of iP-TN to rnable component construction
and initidizrition of component panmeters. These will not be described in detail here as
they are beyond the scope of a basic understanding of the Intemet Tdfic Model Toolkit.
Recall that two types of events cm be sent by a logicai process, e.irrerna1 evenrs and
intrmnl evenrs. An crremal ment is an event that is sent by an LP to a different LP.
Extemal events sent by a host LP represent iP packets. An interna1 event is an event that is
sent by an LP to itself. and is usuaily used by an LP to trigger itself to perfom some action
rtt a specific simulation time. A host LP uses intemal events to trigger itself to invoke other
mode1 components to perfom actions at certain simulation times. For example. a host LP
cm use an intemal event to trigger itself to invoke a T f i c Object to generate a data sueam
at a specific simulation time.
The state of a host logicd process includes two times. a currfime ruid a ne.irtsend_time.
The ctrrr~ime variable is updated every time the host LP receives an event and is used by
the host LP to prevent itself from scheduling an interna1 event with a time stamp less than
an rvent it has dready processed. An example to demonsuate this situation is depicted
in Figure 4.2. Shown is a host LP that has received and processed an event with a time
stamp of 3.0. As a result, the value held by the crtrrrime variabte of the host LP is 3.0.
Suppose the host LP then receives a request from aTnffic Object to be invoked to genente
a data stream at tirne 2.5. If an intemai event was scheduled for this requested cime. the
event wouid be received after the host LP had already received an event wich a grmer
time stamp and ri causality error would occur. To avoid this problem, the host LP only
schedules an intemal event for a time greater than or equai to the vdue held by its ctirr~ime
variable. When a host LP receives a request from a Traffic Object to be invoked at a
cenain sirnuilition time. the host LP compares the requested time to the vdue heid by its
currrime variable. If the requested time i s greater than this value then an internai event is
scheduled for the requested tirne. Otherwise. an intemal event is scheduled for the value of
the crirr~ime variable.
Figure 4.2: Scheduüng an Intemal Event
[n addition to the czwrrime variable. a host LP also keeps tnck of a nerrsend~ime
variable. The ncrr~endrime vaiabie is updated every time the host LP sends an extemal
event and is used by the host LP to prevent itself iroin sending an event to another host LP with ri smaller time stamp than a previously sent event- Each time a Tmffïc Object makes
a request to send a packet event 3t a particular simulation time. the host LP compares the
value heid in the ne.ccsend3rne variaHe to the requested time. If the requested time is
mater. then the event is sent at the requested time. Otherwise. it is sent at the time held b
by the ncrssendrime variable. Every time a packet event is sent. the vdue held by the
ne.nsendrime variable is updated to the time the event was sent plus the time it woutd take
an Intemet host to place an iP packet on a Iink connecting it to the Internet. An example
of this situation is depicted in Figure 4.3. Suppose tiiat Traffic Object 1 requested to send
a packet event at time 2.5, and that after host LP I had sent the packet event the value held
by the ne.rtsenci_time variable was 35 due to the time that it took to place the packet on
the link. Suppose that Tnffic Object I then requested to send a packet event at time 3.0. In
order for host LP 1 to ensure that it does not send another event to host LP 2 with a time
stamp less than 3.5. it will not send an extemal event with a time stamp less than the value
held by the ne-rtsund~imr variable. Therefore. the packet cvent from Tnffic Object 1 is
sent at time 3.5 plus the time it cakes to place the packer on the link.
Figure 33: Sending an Extemai Event
The base logical process class requires a class derived frorn it to define three methods.
These methods delïne the behavior of the logicd process during simulation initialization
and termination. and when the logicril process receives an event. Erich of these methods
are invoked by the simulation kerneI. The initialice method is called during initialization
before a simulation has staned. This method is defined by the host LP to initidize the state
of the LP and to invoke the initidize rnethod on each Traffic Object that it encapsulates.
This is done so that each T f i c Object cm begin generrtting data suearns. The terminare
method is invoked at the end of a simulation. The host LP defines this method to print out
statistics such as the number of packet events sent. The process method is cdled when the
LP receives an event. This method is defined by the host to pmess an event according
to its type. If the evenc is an external event representing an iP packet. then a method is executed to determine if the host LP is Ehe final destination of the packet event. if it is, then
the T d c Object to pass the event to is determined otherwise. the event is sent to its final
destination. If the event is an intemal event then it was scheduled so that the host LP would
trigger a particular Traftic Object to execute some method. In this case. the correct Traffic
Object is determined ruid the event is passed to it. The Tnffic Object cm teII by the type of
the event which method to execute.
4.1.3 T r a c Object
The traffic component of the host simulation model can be used CO implement a vrtffic
model. The traffic component is implemented as a C u class by the name of Traffic. and
a Traffic Object is an instance of this class. The Traffic class provides a set of methods
for developing new traffic models and for integrating existing modeis to be used within the
IP-TN simulator. The initialice method is cailed before a simulation begins ruid cm be used
to initialize the state of a Traffic Object. and the reminare method is cailed at the end of a
simulation and cm be used to print stritistics. Methods for communicating with the host LP
and Protocol components are also included in this set and will be descnbed in Section 4.2.2.
There are additional methods required by the fnmework of IP-TN to be implemented by
ri Traffic Object ro enable component creation and pariuneter initialization. These will not
be described here in detail as they are beyond the scope of a basic understanding of the
tntemet Tnffic Model Toolkit.
A user application of an Internet host cm send a request to any other Internet host. To
represent this functionality. aTraffic Object hris access to a list of host logical processes that
it crui send packet events to. This list cm be specified to be a pmicular set of other host
LPs. or to be dl other host LPs of a simulation. How a host LP is chosen from the list is
dependent on the implementation of the tnffic rnodel. A tnffic mode1 c m be implemented
so that a new destination host LP is chosen for each data strearn, or to simply send dl data
strems to the same destination.
4.1.4 Protocol Object
The protocol component of the host simulation model can be used to irnplement a mode1
representing one or more protocol layers. For exmple. a protocol component couId be
used to implement a TCP or a UDP model. The protocol component is implemented as
a C u class by the name of Protocol, and a Protocol Object is an instance of this class.
The Protocol class provides a set of methods for developing new protocol models and for
integating existing models to be used within the IP-TN simulator. The inirialize method
is cailed before a simulation begins and cm be used to initialize the state of a ProtocoI
Object. and the teminate method is cailed at the end of a simulation and c m be used to
print statistics. Methods for communicating with a Traffic Object are also included in this
set and will be described in Section 4.2.2. There are additional methods required by the
framework of IP-TN to be implemented by a Protocol Object to enable cornponent creation
and parameter initiaiization. These will not be described here in detail as they are beyond
the scope of a basic understanding of the Intemet Tnffic Model Toolkit.
4.2 Component Interfaces
Each component of the host simulation model rnust communicate with one or more of the
other components to send and receive events representing IP packets. This section provides
a description of the interface between each pair of components that communicate. Section
4.2.1 provides a description of how a host LP and a Traffic Object comrnunicate while
Section 4.2.7 provides a description of how a Traffic Object and a Protocol Object commu-
nicate. Some exmples to demonstnte the communication between these cornponents are
given in Sections 4.2.3 and 4.7.4.
4.2.1 Interface Between Host LP and Trafiic Components
A host LP initiates communication with a Tdfic Object when it receives lui extemal event
representing an IP packet to be processed by the Traffic Object. and when it receives an internai event that was scheduled to invoke the T&c Object to perform some action. The
Traffic class provides the pmcessnenr method that can be cdled by the host LP in both
cases. This method takes as its only panmeter the event that was received by the host LP.
The events rire distinguished by the Traffic Object according to a type field in each event,
A Traffic Object initiates communication with the host LP to indicate that it wouId like
to perform an action at a certain simulation time. The host IogicaI process class provides
the schedmvenr method for this purpose. The method takes as parameters an event to be
scheduled and a simukion time to schedule the event for. If the requested time is earlier
than the current simulation time of the host LP. then the event is scheduled to be executed
for the current simulation time. Otherwise. the event is scheduled for the requested time.
The actions chat a Tnffic Object executes are dependent on the tnffic mode1 that it
implements. The generation of data strearns is an action that is performed by al1 Traffic
Objects representing ri tdfic mode1 that is a data sveam source. The host logical process
class provides the xmir~equesr method for a Tdfic Object to indicate the simulation time
at which it wouId like to generate a data sueam.
Another cime when a Tnffic Object comrnunicates with the host LP is when it has
generated one or more events representing iP packets to be sent to another host LP. The
host logicd process class provides the sendreqitest method for a Tdfic Object to use for
this purpose. The methoâ takes two panmeters. an event representing an iP packet and the
simulation tims 3t which the event shouid be sent if possible. If the next simulation tirne
at which the host LP cm send a pricket event has not reached the requested send time. then
the host LP sen& the event at this requested tirne. Otherwise. the host LP sends the event
ris soon as possible. In either case. the time at which the event was actually sent is returned
by the method.
42.2 Interface Between Traffic and Protocol Components
A Traffic Object comrnunicates with a Protoc01 Object to pass a data Stream to the Protocol
Object. The procrsssrream method is provided by the Protocol class for this purpose. The
method takes as its only parameter the size of the data strrarn in bytes. The resulting events
are retumed to the Tmffic Object through the sendpacker method of the Tnffic class. This
rnethod takes as its only parmeter an event representing an IP packet.
A Protocol Object rnay need to communicate with another Protocol Object if one of
them represents a higher level protocol Iayer and the other represents a lower level protocol
layer. The Promcol class provides the processpacker method for this purpose. The Proto-
col Object representing the lower level protocol layer cdls the sendpacker method on the
Traffic Object for each event that it creates.
4.2.3 Sending Packets
This section provides an example to demonstrate how the interfaces between the host simu-
lation mode! cornponents are used CO geoerate and send an event represencing an IP packet.
Figure 4 -4 depicts a host LP contnining a single Traffic Object.
Figure 4.4: Model of Generating and Sending [P Packeb
The Trdfic Object represents a web browser thnt generates a request every five minutes
and contains a single Protocol Object that rnodels a TCP layer. Suppose each simulation
time unit represents one minute md the simulation is mn for sixty simulation time units
to represent one hour. The Tdfic Object genemtes a data sueam representrition every tive simulation unit5 to modei the generation of a request every five minutes by the web
browser. Therefore. the first data stream is generated by the Traffic Object at simulation
time 5.0. In order to do this. the Traffic Object calls the xmit~eqitesf method on the host
LP and passes simulation time 5.0. The host LP schedules m internai event for time 5.0.
and when it receives the event it caIIs the processavent method on the Traffic Object. The
Traffic Object senerates a data strem. then calls the processsrream method on the Protocol
Object and passes the size of the data stream. The Protoc01 Object creates a number of
events representing IP packets according to the size of the data stream. The Protocol object
passes each event to the Trriffic Object througb the sendpacke? method. and each event is
passed by the Trafiïc Object CO the host LP by using the sendrequesr method
4.2.4 Receiving Packets
This section provides an example to demonstraie how the interfaces between the host sim-
ulation model components are used to process a received event representing an IP packet.
Figure 4.5 depicts the same host LP of the previous example.
Figure 45: Mode1 of ReceiMng IP Packets
When the host LP receives an extemal event representing an IP packet. it determines
which Traffic Object the event is to be processed by. An explanation of this process is
provided in Section 4.3. Once the Traffic Object is deterrnined. the host LP calls the pro-
cuss-uvent method on the Traffic Object and passes the event. The way in which the event
is processed depends on the traffic model that the Traffic Object irnplements. If the Traffic
Object does not contain any Protocol Objects then it simply processes the packet event The
Traffic Object may. however. contain one or more Protocol Objects therefore may need to
determine which Protocol Object to pass the packet event to for processing. This process
is explained in Section 4.3.
4.3 Modeüng Internet Host Functionality
To represent multiple user applications and serves of an Intemet host, a host LP may
contain multiple Tnffic Objects. A host LP uses identification numbers to distinguish
multiple Traffic Objects. and a number used as a port number is associated with each Traffic
Object. More details on the use of Tnffic Object iris and port numbers are provided in
Section 4.3.1. A Traffic Object may contain multiple Protocol Objects to represent the
use of multiple connections between a user and a server process. A Traffic Object uses
socket pairs to distinguish multiple simulated connections. Each LP in an IP-TN simulation
scenario is assigned an address that is used as an P address. Each socket of a Traffic Object
consists of the iP address of a host LP and a number that is used as a port number. The use
of sockets by Traffic Objects is described in more detail in Section 4.3.2.
4.3.1 Multiple User and Server Processes
Recail that when a user process sends a request to a server process it tirsr creates a socket
to which a port number is assigned as shown in Figure 4.6. Also recall that before a server
process cm receive requests it crerites a socket and binds it to a port number indicating its
service type.
Figure 4.6: Distinguishing User Pmsses
To represent multiple user and semer processes of an Intemet host, a host LP may
contain multiple Traffic Objects. To distinguish among them. each host LP contains two
tables used to map numbers used as well known and ephernerai port nurnbers to Tr&c
Objects. The itdpsetverrable is used to map numbers used as UDP port numbers to T d c
Objects and the rcpsetver~able is used to map numbers used as TCP port nurnbers to
Traffic Objects. These tables are an abstraction of the demultiplexing of incoming packers
at the iP layer as well as the TCP and UDP layers of an actud Intemet host. Figure 4.7
depicts an example of a TCP server table. As shown in the diagram. each entry contains
a port number. a Traffic Object id. and a pointer to a Traffic Object. Traffic Object ids
are used to provide simple, direct mapping to Tnffic Objects rather than using a more
cornplex method when looking up a Tnffic Object in a server table. Each Trriffic Object
of a host LP rnust be registered in either the UDP or the TCP server table for it to receive
events representing IP packets. The pon number cm be specified as the port number of
the service type that the Tnffic Object models. or the port number can be assigned when
the Traffic Object is registered to represent an epherned pon number. An id is assigned to
each registered Traffic Object.
HOST LP ------------------------------------- 1
Figure 4.7: Aost LP Port Number Table
As demonsuated in Figure 4.8. when a T&c Object sends a packet event it calls a
method on a global table to find the id of the destination Traffic Object. The destination
host LP. transport layer protocol. either TCP or UDP, and destination port number are
specified as panmeters to the meihod caiI. In the example used here, the sending Traffic
Object models a web browser and uses the port number 80 in the lookup cal1 to indicate
that it needs to send packets to a Traffic Object that models a web server. The id of the
T r A c Object of the destination host LP that models the required service is renimed. The
transport layer protocol type. TCP or UDP, and the retumed id are included as fields of
the packet event. When the destination host LP receives the event, the field indicating
the transport layer protocol is exarnined. According to the indicated protocol, the Tnffic
Object id indicated in the event is used to look up the Traffic Object in either the TCP or
the ü û P server table.
Figure 4.8: Example Port Lookup
4.3.2 Multiple Connections
Recail that multiple TCP connections from a user process to the same server are distin-
guished using source socket and destination socket pairs as shown in Figure 4.9.
To model this type of scenario. a Trafiïc Object can use multiple Protocol Objects that
are distinguished by numbers used as port numbers. Each Traffic Object contains two ta-
bles. a rssrlienr~able and a rssserver~able for mapping port numbers to hotocoi Objecrs.
If the Traffic Object represents a user application, then it will use the tssrlient~able. This
Figure 4.9: MuItipIe TCP Connection Distinction
table is an abstraction of the use of ephemenl port nurnbers to distinguish multiple user
processes by an actual tntemet host. and maps numbers used as ephemeral port numbers
to Protocol objects. Each Protocol Object belonging to a Traffic Object that represents ri
user application must be registered in the client table of the Tnffic object to receive packer
events. When a Protocol object is registered, a port number is returned. This returned
number is used by the Traffic Object to register itseIf in either the TCP or üDP server table
of the host LP. The Traffic Object must be registered in the host server table once for each
Protocol Object that i t contains in order for each Protocol Object to receive packet events.
If the T&c Objtct represents a server that responds to requests. then it will use the
rssserver_rable. This table is an abstraction of the use of source and destination socket
pairs to distinguish multiple connections to the same server process by an actual Intemet
host. The table maps local Protoc01 Objects to remote host address. port nurnber pairs.
Each Protocoi Object of a TraCfic Object representing a server must be registered in the
server table of the T&c Object to respond to simulated requests. M e n a Protocol Object
is registered, the remote host address and port number fields of the table entry are left
unspecified. The registered Protocol Object represents a listening server process. The
Traffic Object must be registered once in either the UDP or the TCP server table of the host
LP. To register the Traffic Object. the port number of the service type that the Tnffic Object
models is specified.
An example representation of how the scenario shown in Figure 4.9 could be modeled
is depicted in Figure 4.10. Traffïc Object Tl of host LP 1 represents a user application that
sen& requests. Each Protocol Object that Tl contains is registered in the rss-ciient~able
of Tl . When Protocol Object Pl is registered in the client table. port number 1 is retumed
and when Protocol Object P2 is registered in the client table, port number 2 is retumed. TI
is registered in the host TCP semer table once for PI using port number 1 and once for F2
using port number 2.
?PST !-O! - - _ - - - - _ - - - - - - - - - - - - - _ - _ HOST LP 2 - - - - - - * - - - - - - - - - - - - - - * - - - * * - - * - -
Figure 4.10: Mode1 of Multiple TCP Comection Diidion
Traffic Object T2 of Host 2 represents a semer that receives requests. Each FrotocoI
Object that T2 contains is registered in the tssserver_rable of T2. When P3 and P4 are
registered. the host address and port number fields are left empty. T2 is onIy registered in
the TCP server table of Host 2 once using the port nurnber 80 to indicate that it represents
a web server.
When Tl generates a request for Host 2 using Protocol object Pl. in the IP header of
the packet event it specifies the source field as Host 1 address, the destination field as Host
2 address, and the Protocol field as TCP. In the TCP header, the source port is set to 1.
and the destination port is set as 80. As P3 and P4 are encapsulated by T2. when Host
LP 2 receives the packet event. it will first be passed to T2. T2 will then determine which
Frotocol Object to pass the packet event to. As a result. the destination Traffïc Object id
also needs to be specified in the IP header. Tl invokes a rnethod on the global pon map
table to retneve the Traffic Object id for port 80 on Host 2. In this example. id 1 would be
retumed. Tl uses the retumed id to set the destination Traffic Object id in the IP header.
As Pl and P2 are encapsulated by TI. when Host I receives a packet event in response
from Host 2. it will iïrst pass the packet event to Tl. Therefore, the source Traffic Object id
dso needs to be set in the IP header of the packet event that Host I sends to Host 2 so that
Host 2 cm use this id as the destination Tnffic Object id when it sen& a response packet
event to Host 1. Thus, the source Tnffic Object id is set to I in the IP header of the packet
event that Host 1 sends to Host 2. In the header of the first packet event sent a field is set to
indicate that this is the first packet event of the request. In the 1 s t packet event a different
field is set to indicate that this is the 1 s t packet event of the request.
When Host 2 receives the packet event. the Protocol field of the IP header is examined
CO see if LJDP or TCP service is required. In this case. TCP is required, so the destination
Tnffic Object id from the IP header is used to look up the Traffic Object in the TCP server
table. In this example T2 is retumed. md the packet event is passed to T2. In the first
packet T2 sees that the field of the TCP header that indicates a connection set up request is
set. therefore. uses the source tield of the iP header. which is Host 1 address, and the source
port from the TCP header. which is 1. to map the rernote Protocol object to a local one. To
do this. T2 invokes a cal1 on the rssserver_rable which maps the remote host address and
port number pair to the first availabIe hotocol object in the table. For the remaining packet
events of the request. Host I address and port number 1 are used by T9 to look up P3.
4.4 Cornparison of Model Alternatives
This section provides a description of some of the design issues that were encountered and
model alternatives that were considered in the design of the internet Tnffic Model Toolkit.
By enamining the design process of the ITMT an understanding of the design choices can
be gained. Section 4.4. I provides a discussion of model component implementation. Sec-
tion 4.4.2 provides a description of the initiai host simulation model that was developed
while in Section 4.4.3 a second alternative to the finai host simulation model is described.
Finally. Section 4.4.4 provides a description of two methods that were considered for de-
termining which Tnffic Object of a destination host LP to send packets to.
4.4.1 Model Component Implementation
The design process of the Internet Tnffic Model Toolkit involved the design of a simu-
lation model that could provide a fnmework for traffic and protoc01 modeling within the
P-TN simulation environment. To design this simulation model. cenain issues had to be
addressed. First of d l . the model components had to be identified. Secondly. how each
of the model components was to implemented had to be decided. As the main purpose
in the development of the Internet Traffic Model Toolkit was to provide a fnmework for
traffic and protocol modeling in a network simulation environment. and Internet hosts are
the network components that provide services that generate network t&c. the main corn-
ponent of the iTMT is a reprrisentation of an Internet host. Components were aiso required
to represent Internet host services and protocols. As the functionality of host services and
pmiocols differ. two different model components were used. Therefore. it was decided that
the simulation mode1 would consist of three components. one to represent an Intemet host.
one to represent Internet host applications. and one to represent Intemet host protocols.
Alternatives of how to irnplement each component were then considered. As the IP-TN simulation environment employs the logicai process (LP) modelins methodology. repre- senting an tnternet host in this simuIation environment involves the use of one or more
LPs. One possibility was to implement each model component as an LP. As LPs only com-
municate by sending events to each other, any communication beween mode1 componencs
would result in the sending of one or more events. For example, in order for a uaffic com-
ponent to p a s ~ a data sueam to a protocol component to be processed into packet events,
the tdfic component would have to send an event to the protocol component. A prob-
lem with representing ai1 components using LPs is that method cdls cmnot be used for
communication between components. but nther events must be used. Each event must be
scheduled and executed. therefore. sending an event involves more overhead than a method
call. This would unlikely be a problem for small network scenxios. however. large net-
work scenarios could consist of tens of thousands of nodes. As a result, a reduction in
the number of events used for communication is important to simulation execution time.
Therefore. it was decided not to represent each component as an LP. To reduce the over-
head of communication between model components ris much as possible. only one LP was
used. As previously described the Internet host was represented using an LP and the traffic
and protocot components were represented using objects. This allowed for communication
between components to be achieved using method calls. Any actions perfomed by a model
component that needed to be CO-ordinated with simulation time could be achieved by an
intrmal event scheduled by the LP.
4.4.2 Initial Host Simulation Model
This section provides a description of the initial host simulation model that was developed,
and the issues that were encountered. The final design of the host simuiation model encap-
sulates the protocol cornponent within the traffic component. The design of the initial host
model kept these components separate ris depicted in Figure 4.1 1.
Figure 4.11: Alternative Model for ' h f f i c and Protocol Compnentrs
A host LP could encapsulate multiple Traffic Objects and multiple Protocol Objects.
Using this model. a TratXc Object may communicate with one or more Protocol Objects.
or it may not communicate with any depending on the tnffic model it implements. For
example. a Traffic Object representing a netscape web browser may need to communicate
with up to four Protocol Objects each representing TCP to model the use of up to four
simultaneous connections. An aggregate M c model. on the other hand. may not require
the use of any Protocol Objects. To send ri packet event a Tnffic Object either communi-
cates directly with the host LP or with a Protoc01 Object. To demonstrate this. Figure 4-12
shows two scenarios. one with a Protocol Objecr and one without.
- HOST LP.
' w- *
Figure 4.12: Sending a Packet
As shown. when a Protocol Object is not used. a T&c Object communicates directly
with the host LP. When a Protocol Object is used the T M c Object passes the data sueam
to the Protocol Object and the ProtocoI Object communicates directly with the host LP. In
both cases. a method cal1 can be used by the component to communicate with the host LP. ïhere are seveni ways that this communica~ion can be achieved using a rnethod cail. Using
this mode], the tnffic or protocol component cdls a method on the host LP indicating rhat
it is ready to send and the host LP either renims a tespurise indicating thx the cornponent
can send. or it returns a response indica~ing tfiat the component cannot send and invokes
the component to send at a later cime. Wlen using a Prococol cornponent, the response is
directed to the Protocol component as it has processed the data strem that it received from
the Trriffic cornponent into packet events.
This mode1 could work if the host: LP only contained a single Traffic Object and ac most
one Protocol Object. however. there is a potential problem if multiple Traffic or hotocol
Objects are used. The main issue is that there is no metiiod for a traffic mode1 to indicate the
time at which packets should be sent. As a result. a t d i c mode1 cmnot maintain a tnffic
pattern. The model ne& to take into account the time at which packets should be sent.
Furthemore. to correctly multiplex packet events from multiple components according to
tirne stmp. an interna1 event should be used to trigger the sending of each packet event as
internai events are received in time stmp order.
Rectiving packet events using this model is demonstrited in Figure 4-13.
Figure 4.13: Remiving a Packet
When a host LP receives a packet event, it either passes the event to a Traffic Object or
to a Protocol Object. If the Traffic Object that the packet event was intended for does not
cornmunicae with any Protocol Objects. then the packet event would be passed directiy to
the Tnffic Object. On the other hand. if the Tnffic Object did have one or more Pmtocol
Objects to comrnunicate with. then the packet event would be passed to one of the Protocol
Objects. To determine which object to pass a received packet event to, the packet event
could contain a pointer to the object. Sevenl methods were considered to determine the
object pointer to be placed in the event. however. there were problerns with each. These
methods are described in Section 4.4.4.
An alternative would be to use identification numbers as in the final design of the host
simulation model. This could work if the Tnffic and Rotocol classes were derived from
the same base class as demonstnted in Figure 4.14. The host LP could contain an a m y of
EvenrPmcessor objects. and each could have an id. This id could be used to indicate which
object to pass an event to. The Evenr_Pmcessor class contains the method pmcess_evenr.
which can be called by the host LP to pass a received event to either a Rotocol Object or
Trafic Object for processing.
Figure 4.14 Clas Hierarchy
As demonstrated. a couple of issues were encountered during the design of this simula-
tion model. One of these issues is how to correctly multiplex packet events. Another issue is how to indicate the appropriate destination Tdfic Object when sending a packet event.
These issues cm be resolved as demonsuated. The main reason that this simulation model
was not used is that the frarnework of the IP-TN sirnuiator required the Traffic and Protocoi
classes to be separate nther than denved from the same class. The next section pmvides a
description of two host simulation models that encapsulate the prorocof component within
the M c component.
4.43 Host Simulation Model Alternatives
The final implementation of the ITMT consists of a single host simulation mode!. During
the design process. the use of two host simulation models was considered to incorporate
two types of traffic models. The first simulation model. shown in Figure 4. f 5 was design4
to incorporate a single agbmgate traffïc model and is refemd to as the simple host model.
Figure 4.15: Simple Host Mode1
The second modeI. refemd to as the standard host model. is shown in Figure 5.16.
Figure 4.16: Standard Host Model
The standard host model was desi~ned to incorporate multiple uaffic models tha~ each
cepresent a single user application or application server.
.-ln agsregate trriffc modsl is designed to generrite the tnffic pattern of sevenl multi-
pleurd data strerims. This trdffic pattern represents certain amounts of data sent at panicular
times and musc lx mriintainsd to riccur~tely model the multiplexed data streams. Therefore.
for 3 Trriftic Object to maintain ri tniffic pattern. data must k sent rit priniculrir simulation
times. The simple host mode1 only incorporrites ri srngle Triit'fic Object. .A3 a result. the
packst rvents genenitsd do not have to be rnultiplsued 1~1th packet evsnts [rom orher Trafic
Objects. The packst evènts _oener~ted by the Trriffic Objrzcr crin therctere bc sent by the host
LP at the timss requiisted. and the traffic pattern cm be maintilined.
The strinilrird host model \vas designed to incorporais multiple ttriftic mocicls thrit each
rsprcssnt a single user application or application semer. This model \vas desirnec! to send
pricket events from Trriffic Objects as soon as possible. riither than rit a requested rime.
.in IP moduk \\as developd to multiplex outgoin? packet svcnts from multiple Traftic
Objscts. .As demonstrated rn Figure 4.17. the IP modulr works b' placing Trriffc Objects
thrit are rcad: to send one or more packet c \ m s into a k t .
Figure 4.17: IP h d u l e
iVhen there is rit Ieast one Trriffic Object in the list. the host LP uses an intemal event to
tngger the IP module to remove the îïnt Trifîic Objrct trom the list. When a Traffic Object
is remo\c.d. i t is invoked to send one or more pückct svenrs. .A standard host LP ean be
iontigured to dlow ri Traffic Object to consecutively scnd ri maximum nurnber of packet
events.
There are t~bo mqor problems ~vith the standrird host model. First of all. a trriffic model
needs to maintain a traftic pattern whether it is an aggregate tnftic rnodel or a representation
of a single sntity. Therefore. the Tnffic Objects of this model must bc able to specit'y
limes at ivhich packet evrnts should be sent. and the times specitied should De taken into
considerrition by the host LP.
The second problern wifh this mode1 is thrit the IP module does not take into consid-
errition the timr starnp of a packet event when multiplexing packet evcnts from different
Trriftic Objects. Figure 4. LS provides an example ro demonstnte a possible problematic
rt'siilt. S h o w in the diagram ts a standard host LP with tivo Traffic Objects. Trriffic Object
I maks a sencl request and ris a ~ s u l t is plriccd in the rertdy to send list of the IP mod-
ule. Trriftic Object 2 later makes a send request rrnd is thsrefore placed into the ready to
?;end list aftcr Trriitic Ob~ect 1. The host LP is configureci to allow each Traific Object to
const'cutivelc send t\vo packa events. When Tnîïic Object 1 is removed from the list and
~n\oked to send. i t sends ii packet event \hith a time stamp of 5.0 and a packet t'vent \hith a
time stamp of 6.0. LVhen Tniftic ObjtXt 2 is Itiier invold to send. i t sends a packet t'vent
nith a time stamp of 1.5. It is possibk that the packet events from both Traitic Ohjects
have the same destination host LP. If the packet event IL i th a rime stamp of 5.5 was sent. ri
causality m o r could occur. Therehre. the host LP must sencl the packet etent at a time of
iit Icast 6.0. .As a result. the trdftic pattern of Traftic Object 2 ~ ~ o u l d not hci mrrintained. To
properl~ multiple^ packet ekents h m multiple Trrtffic Objects. an intcrnal cvent should be
used to tngger the iiending oirtich packet ewnt as the intemal ekents nou13 ht. rcceiccd by
the host LP in tirnc starnp ordcr.
.As a result of the problems encountered in the design of thc standard host simulation
model. the simple and standard host simultition rnodels were comhtnrd into the host simu-
lation mode1 that s a s used ro irnplement the Internet Tnffic Mode1 Toolkit. The resulting
model ;illo\vs ri host LP tu contarn multiple Tnl'tic Objects and incorporrites the spccitica-
tion of a srmulation time b- a Traific Object ar which erich packet event should be sent. The
resulting model alIo\vs a host LP to contain ri single Tr~ffic Object thereiore allowing the
capabilities of the simple host simulation model. The resulting mode1 also allows a host LP
to contain multiple T d t i c Objects therefore allowing the cripabilities of the standard host
simulation model.
Figure 4.18: IP \Iodule Ewmple
4.4.4 Alternative hnplementations for Port Lookup
When ri host LP scncis packrt events to another host LP. the Traffic Object of the recei~ in:
host LP that the packet events should be processeci hy is indicated in each packet event.
This section provides ri descnption of t~vo methods that uere considercd for determinin_o
and rndicatinp the iorrect Trdtic Ohjf2~t. The tint method is demonstrrited in Figure 4.19.
.As s;honn. LL hen a Ti-riftic Ohjcct rcpresentin_o a user application hris one or more packct
events to sencl. i t calls a glohaI mtlthod to tind the object pointer of the Trsiffic Object of
the ciesrination hvst LP thaf modcls the required type of senice. The desrination host LP
and port numkr of the senice t y are speciîied AS parsimeters. .A method is then calleci
on the clcstinrition host LP. The host LP returns the ubjecr pointer to the Trrtftic Object that
i t contains that models the required type of service. The object pointer is returned to the
requestins Trriffic Object. The retumed object pointer is then included in the packet event
so that the destination host LP knous which Traffic Object to prtss it to.
.A mqor problem \vith thrs method is thrit it does not cake into consider~tion the pos-
sihilit). that the objrct pointer ma! not point to the correct Tnffic Object by the time the
pxket event amves. The services otfered by an Intrmet host ma? change. For example.
End-port cpon al End-port-addr itimt LP a.pn a,
Figure 4.19: Object Lookup Slethod 1
ri \ieb sener provided hy an Internet host may be temporrinly unavriilable due to technical
diffculties. To model the changing senties prowded, a host LP crin dynamically create
and Jsstroy Trriftic Objects Juring a stmulation. An rxample of the type of problem that
can he criused hy this is deprcted in Figure 4.10. .As shown. host LP 1 reqiiests the Trat'tic
Objwt pointer for port SO on host L P 2. As the current simulation time of host LP 2 is 7.0.
the Tr~ftic Object pointer returned is an indication of the Traftic Object that models a \veh
wner a\riilahls rit thrit tirns. Honever. rhr rcquest is made by host LP 1 rit its currcnt time
n hich is 5.0. Thsretore. host LP L does not receive a true indication of the type of models
provided hy host LP 2 rit timr 3.0. In this example. host LP 1 prweeds to send ri packet
cvrint w t h a time stamp of 5.5 to host LP 2 usine the returned object pointer. Suppose that
the simulation time of host LP 1 teriches 5.5 the Traffic Object modeling a web sensr
hrid heen destroprd and a new Tnffic Object had k e n created to model an email semer.
It is possible that the neK Trriffic Object has the sarne pointer address that the destroyed
object had. .As ri result. the pxket ewnt received by host LP 2 at time 5.5 would be prissed
to the Trriffic Object modeling an emar l server even though i t was intended for a Trriffic
Object that models a ueb semer.
Figure 120: Sending a Pücket Event using an Incorrect Object Pointer
To ciddwss this problern. ci second rnethod wris considered. Insrsrid of inwking ri global
method d l . ri host LP \vould insterid send an svent to the destination host LP requesting
thc iihject potntrr for thc required port nurnber. This rnethod is depicted in Figure 4.11.
.As c k m s arc prwcsssd in tirne strirnp order. the request would be rcceived hy host LP
2 ;it thc rippropriatr timç. The idca ~i-ris that the object pointer returned ~ o u l d then bc
:i truc indication of the traftic mode1 provided by host LP 2 at the ttrne of the request.
Ho\se\cr. duc to thr: lookrihctid of both the host lo~tcal processes and the logical processes
rcprcscntine routrrs thrit the went would be sent through. therc could be delri? in the
time that it is scnt by one host LP and the time thrlt i t is received by the other. .As ri
resiilt. the object pointer returned ma- not rlcturilly be a tnie indication of the traftiç mode1
providd bu host LP 2 at the tirne of the rcqucst. Also. as the Traftic Object that the
objcct pomtrr indrcritss rnriy change by the tirne a pxket event reriches host LP 2. motfier
problrrn ~ ~ i t h this method is that i t dws not prevent the situation of Figure 4.10 h m
occurnng. Furthemore. ri major problern with both of these rnethods is the fact that an
LP has access to a pointer to an objert of another LP. and according to the logicd process
modelins methodolo~y. LPs do not share sttite. For a host LP to h l l y encapsulate its Triit'tic
Objects. an alternative method of indicating the component that a packet ment is intended
for is required. .As previousl y described. this wtis addressed by the use of Tr~ffic Object i&
in the hnai host simulation model thrit tvas used to implement that intemet TraffÏc Mode1
Toolkit
- /-- m m mrru
, -. .. n... ...a. ............ . . . . .
Figure 3.11: Object Lookup Xlethod 2
4.5 Summary
This chriptrr provided a description of the desiy process of the Intemet Traftic Mode1
Toolkit including an overview of mode1 alternatives that were considered. The IT?vIT wris
de\eloped as pan of the IP-ïS simularor- and consists of a simulation model of an Interner
host. The simulation model consists of three components. a logical process representing
an Internet host. a component representing a uaffic model. and a component representrng
one or more protocol lapers. interfaces rire provided for communication between compo-
nents. .As the simulation model w u developed in a simulation environment that employs
the ecent orientsd logical prwess modeling mrthodology. the host logicril process controls
the function of the trdfic and protocol components. E..ctemal svents are used to represent
IP packrts. and intemal events are used to invoke traffic components to perform actions
such ris the generrition of data streams.
The Intemet Triffic Mode1 Tootkit provides ri frameuork for the reuse and development
of trriffc and protocol models. The Trriftic ciass provides an .\Pl for the clrvelopment and
reuse of traffc models. The Protocol c l s s provides an .\PI for the development and reuse
of modrls of protwol Iriyrrs such as TCP and IF. Traffc and protocol modrls can be used
uithin the IP-TN simulation environment which provides a simulation environment for
modeling computer networks and allows for pmlIel execution of simulation scenanos.
.-\fter devrlopment. two ripplications \vue completed using the Intrmet Triffic Modd
Toolkit. One of thrse uas t h s incorporritmn of an eiristing aggrcgate trafîic model into thr
IP-TY simulation rnvironmrnt. and is described in Chapcer 5. The other application $vas
the incorportition of ri tmffic and ri protocol mode1 from the at.quentia1 nctwrk simulator
r i s [ 2 . 121 to hr used nithin thc panIIel s~mulrition snvironment of IP-T4'. This application
is dcscnticd in Chriptt-r 6.
Incorporation of a Traffic Model
One mriin purpose of the Intemet Trriffic Model Toolkit (ITbIT) is to provide ri frrimeuork
for rhe relise of existing tr~fîic models within the IP-TY simulation environment. To s h o ~
thrit the [TMT crin he useJ for this purpose. the ITMT \\\.as ripplird to thc reusc of rin
existing tmttic modci. .As the IP-TIi sirnulritor is used to reprcsent cornputer net~~orks thrit
rire connectell t r i the Intemct. ii trriftic mode1 that accuratel'; models Internet triiftic would he
use fui in IP-T?i si mulrition scenrinos. Therefore. the ITMT \\ris ripplicd to the i ncorpormon
ai ;i u tivelet mode1 from the .ClsyiTr& toolkit [3]. It bas ken sho~vn that iwvrlet rnodds
reprcsent Intsrnet trrifîic more riccurately than previous models. The rctisons for this arc as
follo~rs. Network trriffic has been shown to be long range dependent (LRD) [191. \vhich
rncans that thcrc is similrir hurstiness in the trrifiîc xross man! time scales. Thcrc are
se~crril traitic rnodels for the rcpresentation of LRD traffic [ 5 ] . Intsrnst trriftic. however. hris
becn shown to have a multi-frrictül structure [13] which merins thrit the scriling behaviors
arc diffcrent rit diffèrent ttme scriles. Thrit is, in addition to king LRD. network tr~ffic
d s u Clcm~ns[rri~es correlritions that rire close together in time. This behavior is kno~in ris
shon rmse dependrncr iSRD). Prcvious traffic models w r e d e s i p d to capture LRD and
not concerncd 1 ~ 1 t h SRD. The wrivelet technique. however. captures both the LRD
and SRD chrirxtenstics of ri si_onal. .As a result. wrivelet based rnodeling techniques have
ken devsloped to represent the chrirrictcristics of network trafic [-II.
The purposr of this chripter is to descrik the incorporation of the wrivelet mode1 tiom
the hIs>nTniff toolkit into the IP-TN simulation environment. Section 5.1 provides ri de-
scnption of the ~vrivelet rnodel. This description is a basic one thrit includes the concepts
rcquired to understand how the ITMT wris applied to the reuse of the panicular chosrn
~avele t rnodel. Funher understanding of this subject is beyond the scope of this thesis.
Section 5.2 contains an sxplanation of how the IlYvIT \vas used to incorpotrite the wavelet
model. Finally. Section 5.3 provides a description of how the incorponted ivavelet model
\vas tested.
Wavelet Mode1 Description
To show that the Internet Trriffic Mode1 Toolkit can be applied to the reuse of an tltisrin~
trafîic model. a irclidur rrio~lrl was incorporrited into the IP-TN simulation environment.
Thr prirticular wa\elet mode1 chosén was reused from an existing traffiç a n a l y s and gen-
errition tookit called .Cl.sytTr(rfl [j]. Section 5.1.1 providcs a basic description of the con-
cept of a \vaveler model and Section 5.1.2 gives a description of the Ms-nTmff toolkit 2nd
the \va\elt.t model lhat i t provides.
3.1.1 Basic Description of a Wavelet Model
.\ t~ritc1t.t rnodcl 1s a mathematical representation of a signal [7, 161. In rhe conttxt of
fhe Ms-nTraff toolkit. J signal is an tmpirictrl thrm rri1r.r that is sampled ris a ene es of
h'te counts. .An zrtiptrr~wi h r < t rntcr is a senes of recorded information about the data
transrnitttd wer a net\torL. To .;ample an ernpincal data trrice as 3 senes of byte counts.
rhe numkr of h'tes of data tr~nsrnitted per intemal of tirne is rccorded for a panicular
tntenal sire. Displa'ed in Fiyre 5.1 is an example that demonstrrites this idcti. Shown
tn the diagrrtrn is an rmpirrcal data tmce using the time interLa1 of L rns (milItsecond). .At
the end of etc- 1 ms tims intena1 the number of b!tes of data that have been transmittd
dunng the rime intena1 is recorded.
Figure S. 1 : Example of a Formûtted Empincal Dûta Trace
A avavrlet model trmsforms a signal into a wrivclet representation which consists of
piam of coefficients that capture the behriviod propenies of the signal. This represenration
can then be used to reconstruct the original signal or to grnerite a signal that resernbles
or that is statistically equivalent to the original one which will be reicrred to ris a syrirlirric
signal. .A wavelrt represrntlition of a signal can bt: conveniently stored using a conipltvt.
hirirrn trrr. .As s h o w in Figure 5.2. a c-onrplrrr hinu? rrrr is a structure consisting of a set
of nodes. The topmost node is rekrred to as the mot. Erich node can have outgoing nodes
that rire rcferred to ris ~Mcirrn. .A node thüt has children is d e m d to rts the plirrtir of the
children. In a cornpletc bina? trce. a node either has no children or i t hris two children.
Nodes that haw children are irtrrnwi riodes. and nocles thrit do not have children are 1tm.r~.
Figure 5.2: Esample of a Camplete bina^ Trce
The Iertvcs o i ri h i n e m e crin bc used to store values of a propen! of ri signal. Thc
Ms>nTniff toolhit \\a~clt.t rnodd. ft~r example. Lises the letives of ri hinap tree to store
the byte counts of ;in trnptrical data trricc. The s i p l crin thcn he trrinsformed into ri
\vavelet representation stlinins ar the Iea~es and progressing twarcts the ruot of the trct.. .-\
\vavolet representation of a signal consists of pairs of coefticients. st-rrlins. ~-o~;rJi~.icms and
wri.t.lrt c w J f i c k r i . r . that capture the behaviorril propenies of the sipal. To dernonstrrite
hou ri signal is representcd usine these coefticients. the followmg example taken from [-i I I
iviII be used. Figure 5.3 depicts a sarnple si_onal represented ris a sequence of byte counts
that will be trrinsfi~msd into a waveler representrition. In this exrimple. the Icaves of the
bina? tree store the byte counts. and the interna1 nodes will contain the scaling and wavelet
coefticients once the iransformation i s complete. In the bina- trec. j refers to the level of
the trcr and k refm ro the horizontal node of ri panicular Ievel. For example. the value 17
resides rtt the node identifid by the J value of 3 and the k vaIue of O. Ir!,x is the ssaling
coefticient and N', is the wrivrlet coefticient for position j.k in the b i n q tree. The tinest
orriin scaling coefficients. the ones 3t the Ieaves of the me. are derived directly from the +
signal usin: C r , A = 2 - ! 'CI k 1 whcre Cfkj is the byte count of Ieaf k. The tinest grriin scaling
coefficients for the values of Figure 5.3 are shown in Figure 5.4. For example. the scriling 7 - : ' ' i coefticient for value 17 is calculated by Cr>,o = - - 17 = 17/2' -.
Figure 5.3: Example Signal
Figure 5.4: Cornpuîation of Finest Grain Scaling Coefficients
The corirser grain scriling coefticients. the ones rit internai nodes of the tree. arc rccur-
sively p c r a t c d using the function C/,- 1.k = 2- ' '1 LI,.^ - Ci,,x- 1 ). The scaling cwfli-
crent rit the root of the trce represents the mean of the properp values of the sigal. The
scaling corifticients crilculated using the tinest srriin scriling coefficients of Figure 5.4 rire
sho\vn in Figure 5.5. For example. the scaling coefticient for node 1.0 is calculated b~ 7 - 1 1 . , - -.
= - (17 2' --7 I _ '" - 1 = 6 .
The coarser grain ~vavelet coefficients are recursiveiy p e n t e d using the function - 7-1 1 V , - - ( t ',lr, - 1 ). The wrivelet coefficients based on the scdinp coefficients
Figure 3.5: Computation nf Cnarser Gnin Scding Cmfticients
of Figure 5.4 rire shoivn in Fisun. 5.6. For cxrirnple. the tiavclet coefficient for nodè 2.0 is
,--IcUlatc,J t,! \v2.0 = 2 - 1 2 , 17 2.' 2 - 7 , ?; 2 \ - , 7 - 1 = 3 / - .
The exact \ alut's of ri propcrt! of a si@ can btl reconstmctr'd using the méan and the
~snèmted \ ia~t le t ~ ~ ~ f t i c ~ e n t s . Ti, p e n t e a synthetic signal. tht' ~vavslt.t coefficients crin +
be generritsd by using ;i statisttcal distribution using chanctens~ics of the original \\s\tIet
coefficients. For e.uampie. t h é Wvclst tndependent Güussitin i WIG) mode! [:O] chooses
wtiveler cwfficients froni a Griussian distribution using the rnetin and variance of the on?-
inal \vavrIct iosfficients. The 'vIultifmctal Wavelet Mode1 iMW>f) [35] uses s beta dis-
tnhution to seneme values that a i r useci to cornpute wrivelst coefficients with 3 slmitar
tanance to the original ones. By usrng strttisticd distnbutions. man! syntheric tmces san
k genermci that resemble the onginal tnce. The entire b i n e tree does not have to be
ussd tor the genention of ri synthtitic signai [3l. Instead, ri smning Iorl crin be chosrn.
':ou compurr nr i tc lcr icc~ficicnt 3t top Io-cl
Figure 5.6: Cornpuîation of Wavelet Coefficients
rind the scaling coefficients crin ht. rmcioml- genented for the startins level hascd on the
merin. For example. i f ri startins leLe1 of 2 is chosrn. then 4 scaling coefficients ~vould ht.
rrindornl~ generatd briseci on the top Ie~el scaling coefficient. The rernaining coefficients
ivould then he gsnerrited in the same manner ris before.
5.1.2 MsynTraff Tooikit Wavelet Modei
The MsynTraff toolkit is used for the analvsis of emptical network traffic traces and the
analys and generation of synthetic tnces [31. The analysis of network trriffic refers to the
entrxtion of the charactenstics of ri dita trice and the representation of thesc charxteristics
usine a trriffic model. Thc MsynTrrit'f toolkit provides this functionalit! throuzh rhe use of
a wrivelet model. The genention of network trriffic refen to the crerition of a sythetic dacri
trace. In the sontext of the bIsynTriff toolbt- a syzrlieric mce 1s rt serics of byte counts
ani ticililly genented using the wavslet representation of an smpiricril trace. The ivlsynTraff
toolkit uses the Multi frictal Wve let Mode1 I MWMi [351 for generriting synthetic data
traces. This model has k e n shown to generrite data that more closely resembles the original
data than previousiy used \vavelst bised methods [XI. This is one of the reasons thrit
the uavelet model of the hIsyTraff toolkit w s chosen to be incorporated into the IP-TN
simulator using the intemet Traftic Mode1 Toolkit.
Reuse of MsynTraff Toolkit Wavelet Model
To demonstrlite that the Intemet Trliitic \ Idel Taolkit crin be ripplied to the n-use of an
msting traftic model. thc multifrlictal ttrivelet mode1 of the MsyTraff toolkit \bas incorpu-
rated into tht. IP-TY sirnullitor. That 1s. the ITMT uris used to crcate an inrerfricc betwen
tht. ua\elt't model and the iP-TN simulator jo that the \\rivelet modt.1 could bc usecl in
simulation sccnrinos. Section 5.1-1 pro{ ides 3 dcscnption of altrrnatt. nays thlit rhis appli-
cation oi thc IThlT could 1i.n~ hecn perforrneti. Section 5.2.: provides rin oben i w o i thc
prrxsss that \ras t.mplo>sd. and Sectirin i.l.3 provides a Jescnption of ho\\ the rncrnop
requirements of the \ra\ekt mociel uere reduced to allou simulation sccnanos to contain
man' hosts that use the nli\elet mdel to _ornerate tr~flic.
5.2.1 Alternative Methods of Wavelet Model Incorporation
The MsynTraff toolkit is composed of a Tcl~Tk grriphical user interface and a set oi C l C t t
programs for the anal'sis and seneration of network data traces. One of the C i C u pro-
grams 1s used to producc rite wlivclet reprewntation of a net~vork data trace. a second
program is used to format ri \\rivelet representrttron to produce li new representrition that
oniy contains the information required to generite a synthetic trace. and a third program
is uscd to piririte ri s'nthritic data trxe based upon ri formatted wavelet representarion.
These programs implement the multitirtctril navetet model [35].
To use the Ms'-nTrnff toofkit wrivelet mode1 within the IP-TN simulator to generrite
s'nthetic diatri trrices. t i w alternatives sxist. The tint alternative is to rerid in an empincal
data trace. use the tvlivelrt mode1 to cmte the wavclet representarion. then use the wavelet
representation to genentt: ri synthetrc datri trace. This would require the incorporïtion of al1
three programs from the XlsyTraff toolkit into the IP-TN simufation environment. If this
had k e n dons, then for each ikavelet mode1 used in a simulation run. a data f le containing
Lin empincal data t rxe ijould have to k read in by the sirnulritor. -4s an empiricril data
t rxe can contriin over a miilion byte counts. the time for initialization of a simulation
couid he noticeably incrcased. Furthemore. once the empincal dsta t r i e had k e n r e d
in. riIl threr prograns would havc to be rlxecuted to produce the uavelst representrition and
genmtc a synthetic data tnce. The eirecution of al1 t h ~ r of these programs also ad& to
the initialization time for ri simulation run.
The second alternative is to only read in the fomatted iva~clet representation of an
empincal duta tracc and use rt to generrite synthetic traces. This alternative only rcquires the
s> nthetic ~enerrition progmm to ht. incorporrited into the t P - N simulator. To produce the
formatted waitlet rcpresentation used hy the hls~nTratTtoolkrt. thr wavelet representation
of an ernpincrtl data trace 1s tirst crcated. Then. for crich level of the binary trce the vanance
of the \\aiclet cwificients rs calculated. The formatteci uawlet representrition consists
of this crilculrited vaniince for cach ievel of the hina- c m . as w d l as the staning letcl
and number of remaining icvcls of the trec. Thcreforc. ri tormrittsd \\rivelet reprssentation
contains n + 2 values u h m thc ernpincal data tracc contains 1" ulues. For example. thc
tQrmattcd \t.aveler representiiticin of an empincal data trace of stze 1043576 hris only II ~alitsii. This altt'mativc is ri good choice when it talics lcss timc to _ocneratr a synthetic
tmcr than to rcad in a tiic contliming one. .As this \vas the crise for the size of data traces
that are commonly used uith the UsynTraff toolkit. this alternatiie \vas chosen. .AISO.
stonng ri \i at-elet reprrsentation l i l lo~ s for synthet~c trxes to k generated anyime during
a ~irnulLition run+
The onl) riltemative tu gencrating s>nthetic traces itithin the [P-TN simulator is to rcad
in hles containing previousl> generated traces. .A s>nthetic data trace is the same size ris the
onginal rmpiricaI data trace. therefore. simulation initialization time could still be effected.
Honeicr. once the trace is trrid in it crin lx used directlu. This alternative would be a g o d
shoice i f the size of the empirical data trace was small enough that the time required [O
grnerate a sythetic trace \vas grcater than the time rcquired to read one in. As this ivris nor
iht. ~ ' 3 5 ~ for the size of &ta trsces that are commonly used u ith the MsynTmff toolkit. this
alternative ivris not chosen.
5.22 Overview of Wavelet Mode1 Incorporation
This section provides an overview of how the Iniemet Trriffic Mode1 Toolkit wris used to
ma te lin interface bcit~veen the IP-TN simulator and the MsynTrrtff toolkit wavelst motiel.
First an oLen.iew is given. then more detailed descriptions of method impIementations are
provided.
In order for the MsynTrriff toolkit wavelet model to be used rn IP-TN simularion scr-
nanos. the nrivelet model and the simulator need to communIcate with erich other. By extending the Trriftic class of the Intemet Tnt'tic Model Toolkit and detininz ri set of meth-
od-; providsd by thia class. an interface cm be created between an existing trdtic model and
the IP-T'Y simulator. One of these methods allows a host LP to communicate with a T d f c
Objsct and can be dctined by a c l s s entended from the Trriftic clriss. Tfie host LP of the
IDIT provides rwo methods for a Trriffic Object to communicate ivith it. Thcse methods
arc aircady cletined and crin be called by a clriss entended h m the Tmffc clus.
The [TMT Trrittic class \vas ctntended to crerite a class h! the name of wrridcr. An
instiincc o i this clriss u il1 be referred to as a I.iiti.t~Itv 0bje.c.r. This ciriss uas used to encap-
wlritt. the proprrim for generriting synthctic data trxes and the state tif the tba\.sIt.t mdzl .
This p r o p m consists of a set of methods which ivere includsd as methods of the ti avelet
ilass. Onr of thcse methods. the syrrhrsisr method. is crt1lt.d to initiate rhe _oener~tion of ri
sunthetic data trricc. The other methods are riII crilled by the .svnriir.si,-L. method. To use the
~ a i c l c t modd to gcncrriie ri data trrice. the wrivelet clriss invokss the .syrlrrsisr method.
Tht set ot methods prot ided bu the Tr~t'fic clriss consist.; of the initildizr.. rcnninarr.
pro~ws-ti-c~nr. m i .s~wtlpcic%rr methods. The inirîulix methcd is requircd for set up before
a stmulatm is run and the r~~rrninc~re. method is required to pnnt out statistics at the end oia
~imulation. The ~ ~ o L . L ~ . s . F - t l i . t l t l r method allows the host LP to comrnunicatir ~i [ th the Trriffic
Object. The .srnJpuc.krr allows a protocol component to comrnuniclite with the Trriffic
Object. but uas not deti ned by the wavelet clriss ris no protocol components were required.
Recall that there rire additional methods required by the hmework of the IP-TX simulritor.
Onl? one of these methods. the inir method. will be discussed here as the others rire beyond
the seope of a basic understanding of the reuse of the wavelet model.
The t ~ o methods provided by the host LP for ri Tnmc Object to communicate with it
are the .ïrrrir..rc.qrrrsr and std-rrqrresr rnethods. The .mir_reyrtrsr methoci of the host LP
san bci used bk a c l s s denvrd from the Tnffic clriss to schedule intemal events to invoke
the Traftic componeni to genertite data strerirns. The s r n d ~ q i i r s r mcthod is uscd to pass
ctich packet evrnt to the host LP to be sent. Both oirhese methods tire used by the wavslet
cl riss.
Now thtit an o v s n i e ~ of the pmess of creating an interface hrts been given. more
cfet;iiIsJ descriptions of the mtlrhods délined for the wrtvclêt clrtss wil l bt. proviried.
Thc proryss-e.iwrt methoci allows a host LP to communicare with ri WdurIet 0b~el.t.
This methori is callcd h- a host LP when an event for ri Tnffc Objsct hris ken rccervcd.
This methd uas Jètinéd for the wrivclet class to prwess two types of evenrs. extemal
tvrnrs reprcsenting IP packers and inremal events of rype GEiVER-\TE. If ri rectliwi cvent
represents an [P pwker. then a stritistic of the number ot' packet wents wceivcd is incrrised.
.-1 receivcd intsmril cbcnt or' t y ~ G&,VER\TE represrnts ri message to tngizer the senriins
of ti barch of packet tttnts. When an svcnc of this t y p ts rcceived. the miir mrthod of ihe
iia\t'Iet class IS callcd. it h i s h sends a number of pücket svcnts rtccodin~ to the nc\t byrc
wunf of the synthctic clah trace k ing userl.
Thc iniriii1i:t- mcthod rs srtlled Mort. ri simulririon bcyns and wris cics~g~ecf to hri uscd
t i ~ inttialize the 5t;itrl ot ;I T~iftic Ohjcct and prrt'om an! nscçssrip stt up. Thé iriiriii1i:r
method of the u.aieIst clliss uris deîintld tc, initiate the senclin? of packet evrnts. This
method simply calls ancirher mrthod. the .wiir method. that nris dttined to crctite and scnd
prickets according t h t tr~tfic pattern reprcscnted by ihc wveltlr rnodel. The .mir msthd
otitains the n t x r h'ttl count h m a s y t h r t ~ c &tri trxe. cesites a nurnkr of packet c\.ents
xcording tci ri cmiigur~bk pxket site. and prisses each packet cvent to the host LP ro lx
sent.
The rrn?riri~lrc method is calkd rit the end of a simulatron run and {+as drsigned to Lie
uzrd IOr the pnntins of srlitistics. This rnethçid i v a s deîined for the uavelet c l s s to pnnt
ciut the numher of piicket tlvents sent. the number ot' pricket evcnts receivsd tiy a Mvelet
Ohjsct. and the number of prtckct events thtir could nor k sent at the rime requested in
order ro mainrriin rhc trriltic patrern represenred by a s>nthstic data trice.
The [P-TX simulatnr tramework requires ri c l a s extendrd from the Trritïic c l s s to
rrnplement the inir merhori. This methoci parsrs input pirimeters for ri Tnftic Ohject.
This method wa?; deîincif for the wawlet clriss to p m the name of the iile containine the
fomattcd wavdet repmsentrition to be used for gencr~ting synrhetic rrriffic traces. This
tilr nrirnr is prissed to the inirdutu methd which is ri method that was defined for the
\vabelet class in addition to the methods provided by the Traffic class. This method opens
the fle containing the formatted wavelet representation. reads in the formatted wavelet
representation. and calls the .syrtlie.~izr method of the wavelet model. This occurs dunng
initiaiization. therefore. the synthetic trace is generated before the simulation run begins.
Once the simulation run has staned. the Wavelet Object sends batches of prickets brised on
the senes of bytes counts of the syntheric trxe. What happens when the end of the synthetic
trace is reached is dependent on the LVavelet c l s s impiementrition. .A new synthetic trice
ciiuld he generated hy callin: the .syniltesi;u mrtthod again, however. this could causc some
dela' bet~vcen scndine data streams. To rivoid the delay. the same synthetic trace could be
used again. howver. the triflic pattern would bt. ewctly the same ris before. The size of
each synthetic trace 1s the samr the onginal empiticril trace. therefore. when using this
\vavelst mode1 only traces of tinitt. Iength c9n be generited. This could be an issue for r,
simulation scenano that is run untiI a certain state is reached. rrither than for a particular
rimount of simulation time. In thrs case. thc sue of the cmpincal tnce that should be uscd
cannot he determincd. Therefore. this rvavelet modet may not be the traffc model to use
for this type of simulation scenano.
The Internet Traftic blodel Tooikit rillowd an rntert'acr to be created for the tirivelet
rnodel to ht. used nithin IF-TY simulation scenanos. The crcatlon of the intert'rice did not
wquire alterition to the \va\elet modci.
5.2.3 Reduction of Memory Requirernents of the Wavelet Mode1
The multifrxtal ita\elet modei of the MsyTraff tooilit wrts incorporateri into the IP-TN
srmulatcir so that i t could be used dunng simulation runs to generate synthetic data tram.
.An encountered issus \ras as follo\cs. The size of the rmpincal data tnces generall- used
~ i t h the i\a\elet mde l can contaIn oier a m~llion b>re counts. therefore. the memory
requirements for generating eLen 3 single synthetic trm can be quite large. .As netuork
scenanos created n i:h the IP-T?j stmulator couId potentrrill> tnclude man? hosts that use
the ninelet mode1 to generite trriffic. the memop requirements could cause simulation
initialization to take an undes~rable amount of mm. To address this issue. the memory
requirements of the synthetic trace _oenerdtion progarn uere reduced.
The implementation of the tkakelet mode1 uses three Jifferent I dimensional rira-s to
store the ~\avelet coefficients. scaling coefficients. and the variance of the wavelet coet'ti-
cients. Figures 5.7 and 5.9 together provide an example to demonstrate this situation.
Figure 5.7: Example of Fl'avelet Representation of a Signal
Figure 5.8: Two Dimensional : \ r q s of Smling and Wavelet Coefficients
Shoun in Figure 5.7 is rt \vavoler rrpresentation of a signal that was calculated previ-
ously in this chapter. The t~vo dimensional m ~ p s that would be used hy the MsynTraff
toolkit rnultifractal wavelet model to store the wvelet and scaling coefficients are shown
in Figure S.S. For each of rhrse two sets of coefficients. a two dimensional arny of size
nr Y n 1s requirecl IL here n ts the number of uIues in the empiricd data trace and rri is the
number of levels in the bina? trer of the wriveiec reprexntrition of the empirical data trace.
E ~ e n though onl! one u.avelet and one xd ing cciefficienr are calculated for the top level
of the bina. me. the tirsr row in each of the r i r r ~ y s hris room for n values. The unused
sntnes in each ma? shown in Figure 5.8 are marked with an x. AS can be seen. only I 5
of the 32 spaces in the scaling coefficients aray are used and only 6 of the 32 spaces are
ussd in the wavelet coefficients amy. Furthenore. the m y s shown here are yuite srnrill.
An rrnpirical data trace can contiiin over a million values. therefore. the amount of unused
spxe u n be quite large. For exmple. when using the MsynTrat'f multifractal \\;~wAet
model and an rmpirical data trace of size IMS576. two mays rach of size 20 Y 10JSF76
rire required to store the tvavelet and scaling cwfficients and more than half of each of these
arrays is unused. In addition. the a r i y stonnr the variance of the wavelet coefficients nas
not ewn considered in the rxrirnple shown. Therdore. an alternative mcthod of storrige of
the wvelet iind scaline coefficients called a Iitwp [37] was implemented.
.A heap is a one dimensional arrq used to store the information contained by the nocles
of a binar) t r t x .An cxtimplt. to dernonstratt. the use of a heap is show in Figure 5.9.
Figure 5.9: Heüp Structure
In this example. the nodes of ri binrin tree are originally stored using a tuo dimen-
sional am!. and ri heap u-il1 be applied. A s shown. the lwation of each value in the t~vo
dimenstonal arcly 1s mripped to a location In a cnrresponding one dimcnsional amy using
the function 11 = 12, - k ) - 1 where Ii is the resultinz index into the one dimensional lirq
mi j.k is the index pair for the location in the two dimensionni am!. For example. the
\aluc in location 1 .O of the two dirnensional a m ? is placed in location 11 = (1' - 0 I - L = I
of the one dirnensional am!. LTsing a heap resulted in a substantial reduction rn mernory
requirements for the speçilic data traces that were used with the wavelet model within the
IP-T'; simulator.
5.3 Verification of Interne t Traffic Model Toolkit
Thé success of the application of the Intemet Tralfic Model Toolkit to the incorporation of
the 5Is>nTrifftoolkit wavelst model was tested in two ways. First of dl. the wavelet model
\kas tt'sttd within the IP-TN simulation environment to snsure that its output had not been
altered. The method employed and results obtained from this tesring rire described in Sec-
tion ï.:. 1 . Secondly. the host simulation modcl \vas tested to ensure that the traffic pattern
of a s>nthetic trace uséd in a simulation run would be maintained hy the host output. The
set of tests perhmed on the host simulation model and the rcsults obtained rire described
in Sccrion 5.3.1.
5.3.1 C'erification of Incorporated Wavelet Model
To c'nsiirt' that the application of the Intemet Traffic Model TooIkit to the incorporition
ot' thc n a \ ~ ' I ~ t model into the IP-TY simulation environment did not alter its opmalion.
the incorporatt.d \vavelet model \tas used to senerite synthetic data trrices ~ h i c h ttrre
cumparcci to synthetic traces generatt'd hy the MsynTraff toolkit. Tiko data sets that are
commonly used uith the MsynTraff toolkit \vert. used. the Ibl-tcp-3 clata set consistin_o of
2 hours iit' \vide a m TCP packets [221 and the BC-pOctS9 data set ~onsisttng of 4 million
packcr traces of L X 3 and W.AX triftic on an Ethemet [19]. Both data traces were taken
from the Intemet Traffic Archive [17].
For each empirical trace. the MsynTrat'f toolkit \vas used to senerite the wavelet rep-
rescntatron. The wavelet representation of each data trace \\as then used to generare I O
synthctic trices. 10 usine the MsynTraff toolkit and 10 using the ivavelet mode1 in the
IP-TX simulation emironmect. To compare a s> nthetic trace generited by the IvlsynTrriff
tordkit ~ i t h a synthetic trace generated hy the \vavelet model within the IP-TN simulation
enviriinment. the seed for the random numbcr generitor used b! the progriim for snerritine
synthetic traces \\as controlled. .A seed is used to set the initial value retumed by ri random
numkr senerator. If the s m e seed is used twice with the same rrindom number generator
rhen the same sequence of numbers is retumed both times. For each par of eenented s y -
thetic tmcrs. one eenerated by the MsynTratT toolkit and the other by the isaveiet model
uithin the IP-LN simulation environment. the seed was xt at a paniculnr value. The result
uas 1 sets of 10 synthetic traces based on the BC-pOctS9 data set and 2 sets of 10 synthetic
rrrices btised on the lbl-tcp-3 data set.
Each synthetic data t rxe senerated by the MsynTrdf toolkit \vas comprired with the
synthetic Jrita trace genented by the wavelet model in the IP-TY sirnukition environment
using the same empirical data t rxe and random number generator seed. To determine i f
two data traces were the same. the byte counts of sach were compxed. Exh pair of traces
compareci were identical up to O. 1 ms.
The MsytTriff toolkit provides the ability to generrite a set of grriphs for an empiricrtl
or synthctic data trace [3]. These graphs display the rneans and vanances of the wavelet
and scaling corifticients of the wavclet reprcsentation of a data trace. h set of grriphs can
dso be generiited to compare these values for two dm trdces. TWO grriphs rire s h o w
here ris c'tamples to demonstrate that the synthetic traces generated hy the rvavelet model
in the IP-TY srmulation environment iverc identical to those seneratrd by the MsynTraff
toolkit. The sraphs show ri companson of the variance of the ~tavslct coefficients of the
~varc1t.t reprcstntation of two synthetic traces. one penerated 61 the MsynTraff loolkit and
the othtr h! the \vavelst mode1 in the IP-TY simulation environment. Figure 5.10 shows a
cornpanson of sythstic traces b ~ e d on the BC-pOctS9 data sel. and Fipure F. I 1 shows a
companson of synthetic traces brised on fhc Ibl-tcp-3 data set.
Figure 5.10: Cornparison of SIsynTraff and ITMT Synthetic Data Traces
The wmparison of each pair of sythetic traces showed that the t ~ o rraces rvere the
same. theretorc. the wavelet model did not appear to be altered. This provides evidence to
support the success of the application of the Intemet Traffic Mode1 Toofkit to the reuse of
the SIs~nTrrifFtoolkit wavelet model within the IP-TS simulation environment.
Figure 5.1 1: Cornparison of 1CkynTnK and IThlT Synthetic Data Traces
5.32 Verification of Host Simulation Model
Once the MsynTraff toolkit nuvelet model wris incorpor~tcd into the IP-TY simulator, i t
\ u s uscd to test ho\\ \wll the hosr simulation mde l output maintains the traffic pattern of
ri s>nthetic tnce. To do this. ri simulation scrnano wrts set up and se\eral simulations \ rue
run iising cach of the BC-pOctS9 and Ibl-tcp-7 empincal data trrices.
The simulation scenano that was used to test the host simulation model is shown in
Figure 5.11. The scenario consists of tu.o host logical processes ris w l l ris other compo-
nents of the IP-TY simulator. two hub components and one router component. The hub
component represrnts a hub that connects a subnet tii the Intemet and the router compo-
nent represents a router that directs IP plckets over the Intemet to thrir destination. One
of thc host LPs containcd ri wavelei model that wris used to generatc spnthetic datri traces
and scnd the rcsulting byte counts to the other host LP in the form of packet évents. The
purpose of the simulation runs was tu cornpm the sythetic data trricc generated for rrich
sirnulrifiun run with the triiftic: output from the host LP.
Csing the simulation scenario s h o w in Figure 5.12.4 sets of 10 simulation runs were
perionnsd. Two sets were mn ustns the BC-pOçtS9 empincal data trace and tivo \vere run
using the Ibl-tep-2 érnprncal dam trace. For each data trace. one set of simulation mns ivere
dons using a pxket size of 15ûû bytes and the other usinp a pricket s i x of 5 12 bytes. For
riIl simulation mns. an inten-al size of IO rns wrts used for the empincal and synthetic data
traces.
For each simulation run. the syntheric data m e genented was stored and for each
Figure 5.12: Test Scennriu
packet e\ent sent b! the host LP the packet tirne srarnp ruid s i x in bytes was recorded. The
tile containin_o the time stamp and byte counr pairs \vas then formatted into a file of byte
counts indicating ho\\ man' b1tt.s had k e n sent during erich 10 rns time intenal. This
resultins tile of byte counts \vas then cornparcd to the byte counts of the synthetic data
trrice. The byte counts of each pritr of traces that were comparcd uere identical up to O. 1
ms.
.-\s prcviously mentiuncd. the MsyTrat'f toolkit provides the functionality to compare
t~vo wavcler rcprcscntations ro each uther through a cornparison of the scaling and wvelet
coet'ticients displayeJ 2s a set of grtiphs [3j. One grriph is sho~vn here as an example ro
demonstrritc the host LP output for e x h simulation run \vas identical to the 'iynthctic data
trricc used. Fig.~tr 5.13 shonl; a cornparison of the variance of the wavelet coefficients for
t ~ o trrices hased on the BC-pOctS9 data set. a synthetic trace genertited for a simulation
run and the host LP output for the same simulation run usinz a packet size 1500 bytes.
For the set of simulation runs perfomed. the host LP output matched the synthetic
traces used. This provides evtdence to support the ability of the host simulation mode1 to
maintain a traffic pattern.
The host LPs used in the set or simuiation N ~ S perfOrmed oniy contriined ri single tnftic
rnociel. 11' a host LP contained more than one tntfic model. however. then the trriffïc pattern
of each rnay not be mriintained. in this crise. the host LP would have to multiplex more than
one data strerim. If a traffic mode1 tned to send ri packet during the time that rt packrt from
Figure 5.13: Cornparison of Synthetic D a h Trace and Host LP Output
another traffic model was beine sent. then the packet rnay be sent later than desircd and
the trrit'tic pattern rnay not be maintained. .AS the wavelet mode1 of the MsynTrriff tootkit
is an aggregate traffic rnodel. it is designeci to rcpresent multiple cirita strerims multiplexed
together. Thrirefim. i t is not designeci to he used with other trriftic rncideIs. As a result. rht.
issue identitied here mriy not be a probltim. Another issue that rnay cause the trrifîic pattcrn
to be distoned is the rate of the l ink cornponent connecting the host to the network. if rhc
link r,w 1s lowr than the rrite that a ttrifiïc rnodel is sending data. then the pxkrts will not
be sent fast tnough to maintriin the trriftic pattern. This can ocsur even n hen using ri single
traffic model. and 1s something to be a~bare of.
5.4 Summary
One of the main goals in the developrnent of the intemet Trriffic b1OdrlI Toolkit was to pro-
vide a frameivork for the reuse of traftic models within the IF-TX sirnuIarion environmenr.
To show that the ITMT can be used for this purpose. it \vas applied to the reuse of the
multifrristal ivavelet rnodel from the .Cl.syTruff toolkit [31. That 1s. the [TMT \vas used
ro create rin interface between the wavelet model and the IP-TN simulator so that it could
be used in simulation scenarios created with the [P-T?J simulator. This chapter provided a
description of hotv the IniT wris applied to the reuse of this wrivelet model.
To ensure thrit the output of the ivavelet model had not k e n altered by the Internet
Trriffic Mode1 Toolkit. testing was performed on this rnodel within the IP-TN simulation
environment. This testing involved the compririson of synthettc dara tram ecncnted using
rhe wvelet model of the MsynTratT toolkit with those prnrrtired using the wavelet mode1
ivithin the IP-T-I simulation environment. The results obtained provide evidence to support
the success of the application of the Internet Traffic Mcidsl Tuolkit to the reuse of the
uaveler model. The ITMT provided ri frrtmework for the rcuse of this pürticular wttvelet
model rcithin [P-TN simulation scenarios. The wriveltit modcl was rilso used within the
IP-TY simularion environment to tesi ho^ well the host simulstion rnodel output maintains
thc trdhc pattern of ri synthetic trace. The rcsults obtained provide evidence to suppofl the
ability of the host simuIation model to maintain ri trriftic pattern.
The [TMT was also applied m the reusc of two rnodels from the ns simulrttor [ 2 . 121.
The nrxt chiper proviclrs a description of these modcls and the process of incorponilinp
[hem into the [P-TII sirnulritton cnvironmcnt.
Incorporation of ns Models
One main goal in the development of the Intemet Trriftic Model Toolkit ([ThIT) was to
provide ;L frimetvork for the reuse of trriffic and protocol models thrit were developed in
LI seqticntrai simulation environment within the IP-TN simulation tmironmenr thrit allows
(tir parriIlel c~ccution of simulation sccnririos. To show thiit the ITMT srin bc used for
this purpose, i t t u s applicd to thc incorporrition of a trriffic ancl ri prorwol mode1 of the tis
[f . 171 nettvork simulritor into the IP-TN simulation environment. Thrit is. the ITMT ivas
used to crcritt. an interface bet~vecn the n s models and the IP-TN srmulritor so thrit the ris
models could be ussd in simulation scenarios crerited tvith the [P-TY sirnulritor. The focus
of this chaptsr is ro Jcscnbe hou the IThiT wris ripplied to the reuse of these ns rnodeis and
to pro\ rde cvidencc to support the success of this applicrition. Dt.scnptions of the n s trriftic
and prorucol modcls rire y e n in Section 6.1 whilc Section 6.2 provides ri description of
the application of the ITMT to the reuse of these models. Finrilly. two sets of testins that
i t m ptxformed to provide evidence thrit this application of the IT>IT was successful and
the rt.suIts obtriined rire presented i n Sections 6.3 and 6.4
Description of ns Models
The ris simulritor is ri network simulator that provides ri set of tvidely uscd trriffic and pro-
t ~ o l models [2 . 11). Recrill that a detailed description of ns \vas eiven in Chsipter 3. The
ris simulation environment only rillows for the sequential execution of simulation scenarios
whereas the IP-TN simulation environment emptoys the logical prwess modeling method-
ology ivhich allows for par~llel exocutton of simulation scenanos. To show that the ITMT
can be successfully applied to the incorporation of r ts models into the IP-TS simulation
environment. it wris applied to the reuss of an ns tetnet rnodel and an ris TCP model. To
descnbe hoiv the ITMT \vas appiied to the reuse ot thesr modcls, it is tint necessary to
descnbe the models themsclves. Section 6.1.1 provides a descnption of the telnet model
ti hile Section 6.1.2 provides a descnption of the TCP model.
6.1.1 The ns Telnet Model
Tclnet is a user application that provides remote access to Intemet hosts [3 11. To the user
of a tclnet application it appars that he or she is actually workin~ on the remote cornputer.
Recall from the Jcscnprion of us that wtis yven in Chrtpter 3 that the ns Applic~~rriori
ilriss provides a sct drncthods for developing an application model. One of the application
modcls pro\ idcd b' 12s 1s a teInet application modél. This modtil is esscntially a reprcsentli-
tion oi thc data mcams sent b-. a telnet applicat~on. Prickct t'vents that reprcsent IP packcts
;ire y - m ~ t c d at timcs that arc r~ndomly chostin usine an tixponentiai distribution. .An n s
hmcr componcnt 1s used to schedule evcnts for these expunentially distributed times in or-
der 10 invoke the tclnct component to send packets. AS each t2.s .Application component
sends packet evcnts throueh an Agent componenr and the Asent component has a contig-
u~ihle packet siLe. the s i x of each packet sent bu the telnrt mode1 is determined by its
Agent component. The set of methoifs provided hy the Application clriss for detining an
application mode1 rncludes the . srm and srop methods. These t\io rnethods are detined in
the telnet i l t i~s to invoke and terminate the sending of packet tlents respcctively.
6.1.1 The ns TCP Model
The Transport Control Prorocol iTCP) is a conncction oriented trrinsport layer protocol that
provides reliahility and flot+ control to the applicarion Iayer. .A more detailed descnption
of TCP \\ris p e n in Chripter 2. The protoc01 models provided by the n.5 simulator include
a set of TCP models. As a telnet application reyuires the senice of a TCP entity. the ns
telnet model cornmunicrites u.ith an ris TCP rnodel. The ns telnet model uses a basic TCP
6. Isc'ORPOR.-\TION OF ris ~ I O D E L S t0-I
model provided by 11s which implernents a version of TCP knom as Tahoe TCP [ l II. In
addition to the basic functionaIity provided by al1 TCP irnpkmentations. Tahoe TCP rilso
provides mechanisrns forjiisr rrrmnsniir and conLyesrion niwidunce. Fust rerrtuianir refers
to a method of infemn? ivhen s packet has k e n los[ and retransmitting it. C*on,qrsriori
ciiwiclmce refers to ri method of rittempting to prevsnt packets from beine lost due to con-
zestion tvhich occurs \r hen prickts are belne sent over a link frister than it can handle. L
Trihoe TCP uses an rilpithm known rts slolr. srun to provide congestion avoidancs. The
sloti s t x t algorithm txponenciaIIy increases the rait. of sending whils monitoring packet
loss. I f packet loss occurs. thr srnding rue is rcduced and then incrmed again. but only
lincrirly.
.As prcviousl~ descnkd in Chaptcr 2. the ris =\ornt clriss provides a set of methcids for
devsloping ri protocol model. The r i s TCP.-\,ytw and TCPSinX- clrtsses ikerc dcnved from the
.-\grnt clriss to drvelop the r t s T~hoc TCP model. The TCPAgent clriss detines the khavior
of I TCP component that sends data strerims from an application model according tu the
Tahoe TCP slgonthms. 2nd the TCPSink class Jetines the khavior of a TCP component
that receives from a sending Tiihoe TCP model. Scvcrril ns timer components are cietincd
h> the TCPAgent class to pro~ide TCP functionality. For cxample. a tirner cornponent
is dctined to inioke the retrxtsmission of lost prickets. This tirner cornponrnt is used to
scheduls an event fur each packet sent. If the packt h a not been acknowledged when the
timer e\mt is processed. then the pricket 1s retrrinsmittsd.
6.2 Reuse of ns Telnet and Tahoe TCP NIodels
To shou rhat the Interner Trrifîic Mode1 Toolkit provtdcs a frameivork for the reuse of
trrittic and protocol models wthin the IP-TN simulation environment. it w s applied to the
incorpordtion of the ns telnet and Trihoe TCP models. Some of the main issues that \\ert.
encountered due to the clifferences betwen the srmularors are discussed in Section 6.3.1.
Sections 6.1.1 and 6.2.3 provide descriptions of hou rhe miT \vas applied to the reuse of
the ns telnet and ns Trihoc TCP models respectively.
6.3.1 Encountered Issues
Severril issues ma'; bc encountered when incorpor~ting a model tiom one simulator into
rinother. One of the main differençes ktween the ns and the IP-TX simulators is the user
interf.clces ot' exh . Recrill that the ns user interface wris developed in OTcl and the simula-
tion components wrt . Jsw1opt.d in Ci-+, When de%nin_o an ris simulation scenano. tach
simulation component is mapped to an interface component and a Tci interpreter is used to
initialize the state of the simulation components. During ri simulation run. Lin' changes in
the sttits of ci simulation component are conveysd to its corresponding inrerfrice componsnr
through the Tcl intcrpreter. As a resulr, r x h simulütion component contains c d for corn-
municating with thc Tc1 intsrpreter. Two ns simulütion components wsre incorporritsd into
the [P-TY simulation environment. the tclnèt and Tahor: TCP components. To rivoid the
nrtcessity ofchanging pans of thesil simulrition components. a new Tc1 interpreter uas con-
structed that does no[ providc any functionality. This allows the ns simulation componenrs
ro communiute \cith ri Tcl interpreter !vithout actually providing a Tc1 interface.
.Another main diifercnce ktwren the 11s and IP-TN simulators is the simultititin mir-
ronments of each. As ri rrsult. some iunctionality of the ns simulation environment could
not tc directl- mappcd to functionality of the IP-TY simulation environment. The sihtdul-
ing of events in r i s ~btis erisily mripped to the scheduling of events by the IP-TN simulation
kernel. The crincellation of ewnrs in ns. however. could not be replriced by functionalip of
the [P-TN sirnularton kemel. To overcome this dificulty. a list of cancellations is k p t so
that I\ hen an event ts recei~ed. i t san he drltermined whether or not i t should bti e'tecuied.
Another more rninor diikrence between ~ 1 . s and IP-TY is the structure of the tvent ~liiss.
In ris. the P d r r class ~i hich IS derived from the Ei*rnr clriss ts used to tepresent IP packcrs.
In IP-TN. 1P packcts arc represented usrng the ip tnippu-ker class derived from the sk-rwnr
ilriss. -4s al1 e\cnts. interna1 or externiil. schedulcd by the IP-TY simulation kernel must te
drinved t'rom the s k - r i m r clriss. the IP-TY iprnippctcket class wris modi f ed to enc.apsulars
an instance of the r i s Pwkrr clriss. This enabled an ns simulation component to send an ris
packet event iis part of an IP-TS pticket event to another ns simulation component within
the IP-Th' simulation environment.
The issues describeci in this section rire the main issues that hrid to be üddressed to in-
corporrite 11s simulation models into the IP-T;\I simulation environment. Other less comp1e.c
issues ikere also encountered that rire of less interest.
6.2.2 Reuse of ns Tahoe TCP Mode1
To incorporrite the ris Tahoe TCP mode1 into the IP-TN simulation environment. both the
11s TCP.4gent and TCPSink componsnts ivsrc requircd. The ns clriss structure of these
components is displayed in the left portion of Figure 6.1. To avoid the incorporation of
this mi re class hierrirchy. the Agent cornponcnt wlis disconnected h m its parent. the
Connecter component.
Figure 6.1: C l a ~ Structure of ris and ITMT for ns TCP Nodel
The Internet Traffic Model Toolkit providrs the Protocol class for Jevsloping protocol
rnodsls. Ti) incorporritt. the ns Tahot. TCP mode1 into the IP-TY simulation environment.
the Protocol class \tas erctended to cwrite the nspnir CIXS as show in the right portion of
Fisure 6.1. As both thc r i s TCPAgent and TCPSink components were required. the rtsprot
component t u s then estendeii into the n s s r c p n ~ r and msinkpror clrisses. The rrssnpn)r
dass ivas designcd to cncapsula[e an ns TCP.4gent cornponent. and the n.ssirikp)r class
itas Jèsigned to sncripsulrire an ns TCPSink component. This enribled an ris TCP.4gent
componsnt to wnd prickets to an ns TCPSink agent ivithin the [P-TX sirnulrition environ-
ment.
Recall that the Protoc01 cliiss of the Internet Trriffic Mociel Toolkit provides a set of
methods for developing ri protocol mode1 as described in Section 4.1.4. This set consists
of the iniridizr. ttvmimrrr. procrss-rr.enf. and procrsssrreum methods. Only the tirst three
o t these werc required by the nssrc-pmt and nssink-prot classes. The procwssrrrmi
method wris designcd to break a &ritri strerim representation into packet events. however.
as the ris TCP-Agent and TCPSink components provrde this functionalit~. this method \\ris
not r t . q u i ~ d . The i n t r i d i x method is cailsd Junng simutarion initialization and u.âs de-
I ind in the ris-src-prot clriss to creats an ris TCPAgent component and initidize irs stats.
S~milrirly. the i r r i r ic t l ix msthod ot' the nssink-pro[ clriss wris defined to create and config-
ure an r i s TCPSink component. The ~rmiiricirr method \vas ddesigned to print out statistics
L~I the c»rnplsrion (if ;t simulation mn. This method was def nrci by the ns-src-prot and
ns-sink-prot clrisses ta print out stritistics seneratcd hy the ns TCP.A_oent and TCPSink
componrnts respcctivrly.
1Vhen an r ~ s Packet ewnt 1s sent bu e~ther a TCP.4gent or 3 TCPSink componcnt. i t
is sent through a Prutod Ohject. ctithrir an ns-srcpot or an nssink-prot object. .An IP-
3 3 packet evcnt is crcritéd and the ns Packcl éwnt is èncapsulrited by the IP-T?i packet
cLent. .A Protocol Ohject recrives an IP-Tii packrt evcnt through the prtict,.ss_n.rnr method.
This mcthod extr~cts the ris P x k t frorn ~ h e IP-TIi packet tvent and passes it to an us
cnmprincnt. tiither a TCP:\gcnt or TCPSink component. This enables ns packrts to he srnt
hetu een trs T~hoe TCP stmulrition components i k ithin an [P-TY simulation sccnano.
.-\i; dcscnkd. the Interner Trriftic Mode1 Tiicdkii prin~cled a irclmwcirk for the incor-
poration of the r i s T ~ h w TCP model componenrs into the IP-TN simulatton envtronment.
The Protocol clriss of the iTS1T provtcfed set r)i methods thrir rnabled the ris Tahw TCP
simulation components ro srnd r i s packets to one another wthin IP-TX simulation scenrir-
10s.
In order to rncorporm rhr ris tclnet model into the [P-T?; simulation environment. onl- one
jtmulatron component \tris mquired. The r i s c l s s structure of the teInet mode1 is displayed
in the ieft punion of Figure 6.2. To rivoid the incorporation of this entire clriss hiermhy.
the ns-prwess cornponent \kas disconnecteci frorn irs prirent. ihe TclObjecr component.
R e d 1 ihat the Intemet Trriffic Modd Tmlhtt prouides the Tr~ffic clriss for deveIoping
appiicmon rnodels rts descrikd in Secrion 4.1.3. To incorporate the ns teInet mode1 into
the 1P-T'i simulation environment, the Trafic clriss \vas extended to crertte the n.s_rss clriss
as shoiin in the nght portion of Figure 6.1. The ns-tss c I z s was designed to rncripsulatr
Lin r i s telnet component.
LOS
rn Setrnrk Simuktor C'las Structure ITMr Ckas Stniciurr
Figure 6.2: Class Structure of ns and ITMT for ns Telnet h d c l
Thc Trriftic ciriss of the ITMT provides a ser of methods for developing an application
mcidrl. This set consists of the iriirirdix. tcv-mitrcit~. prrrcu.s.s-~~i.~~rrr. and Wdpac'kkff meth-
d s . ,411 ut' these mcthods wrrs requircd hy the ns-tss cirtss. Tht. i i t i r i d i x method is cal1t.d
dunng ~irnulatton initialixrttion and s a s derinrd to crt'ate ;ln ns teln~t component. inicialize
irs siatc. and schedule an çvrnt to iniokc i t to srm generiting and sendina data. The rtJrrtti-
mite rnethod \ias designed to prinr out staristics rit the complction of ;i simulation run and
\\ as definecl to pnnt out stritistics yerrited hy an rts telnet component. The pn~r.r.s.s-cwv1t
methoci \\ris Jrsigned to reccive extemal eïents representing 1P pwkcts and intemal e w t s .
IVhcn ;in ns.tss object reccivçs an extcrnrtl packet svent. it passes the cvent to rin ns-prot
ohjwt. \L hich sntncts the n s Packet and prisses it to ri TCP.\gont or TCPSink sornponenr.
.An ns-tljs object also reccives interna1 events that are used to i m o k the telnet componeni
to gcnente and send data. Finallç. the srndpackt*t method is used by an ns-prot ohject
to p a s c.\ents representing IP packets to an ns-tss objecr. The ns-tss object prisses thess
packet evsnts IO the host LP to be sent.
6.2.4 Timer Component
The r r s telnet and Trihot. TCP modeis both use ns Timer cornponents. The telnet mode1
uses a timer to invoke the sendin: of data. The Tahoe TCP mode1 uses several timers. one
o f n hich to invoke the retrmsmission of unacknowledged packet rvents. When a timer is
set ustng an ns Timer component. an event is scheduled. When the ekent is processed. ri
Irancllr method is called on the somponcnt that set it. To incorporate the use of ris Timer
components into the IP-TN simulation environment. the ns Timercomponent was moditied.
When ri timer is set. instsad of scheduling an ILS event. the timercomponent calls a srr-rinier
method on an ns-tss objsct. The srr-rinier method cdls ri sclrud-rrrnt method on the host
LP n hich schedules an intemal event. When the host LP rcceives the intemal event. it
passes i t to the ns-tss object that requested it to be schedulrcf through the proc-rs.s_r\wir
rnethod. The ns-tss or ns-prot object cdls the hanclle method on the Timrr component
that requestrd i t to be schedulcd. This enables rrs models [O set tirners using an ris Timer
component ~bithin the IP-TY simulation environment.
6.3.5 Examples of Component Interaction
To Jernonstrrite more clearly how the Trriffic and Protocol classes of the Intemet Traffic
lllodsl Toalkit urre iised tu incorpor;Lte the ns trlnet and Tahw TCP modcls into the IP-TN
sirnulaticm mironment. an euample is provided in Figure 6.3. :\s shwn in the dirigram. an
ns-tss oh!ect encapsu13t~s a telnet mode1 and either an nssrc-pro[ or an nssink-prot objccr.
.An nssrc-prot object encapsulates an ns TCPAgent component. and an ns-sink-prot objcct
encapsiilrites an 11s TCPSink component. .An ns tdnd mode1 still communicates with either
an ru TCP:\_oent or an ns TCPSink cornponent.
To set ri timer to tngger ~ h e genrrrttion oi packers. an ris telnet cornponent communicates
mith the ns-tss object that i t &longs to ivhich in turn communicates \vith ri host LP. The
result is an intemal event scheduled by the host LP. When this ment is received. the host
LP communictitcs t u t h the ns-tss objeçt ~vhich tn_o_oers t h s teinet cornponent to = nenerate
packers.
.An ris packet evenr that 1s pwrtitèd hy a telnet component 1s passed to the ns TCPAgent
compontint that i t intenicts xith. Once the ns TCP.\gent componcnt is finished formtltting
the ris packet tient. it prisses it to the nssrc-prot object that it belongs to. The nssrc-prot
object encapsulatrs the ILS Prii-ker event in rtn IP-TN packet event. and passes the IP-TY
packet e\ent to the ns-tss object to which i r beiongs. The ns-tss object prisses the I P - N
packet e\ent to the host LP to be sent.
When ri host LP recerves an IP-'l?i pricket event. if passes it to an ns-tss object that i t
encapsu1att.s. The ns-tss object then passes the IP-TX pricket event to an nssink-prot object
Figure 6.3: Encapsulation of ns Mxiels bu ITJlT Objccts
that r t enciipsulrites. and the nssink-prot objcct extracts the ris Packct event irom thc IP-Tii
packet cLent and passcs thc ns Packet cvent to thc ris TcpSink somponent for processin_o.
F~nall'. the TCPSink cornponent prisses the rccctved data ro the ns telnet rnodel. .-\ similar
proct'ss occ'urs t'or rin r i s TCPSink component to scnd ~icknou idgcmrint packtts to an n . ~
TCP:\gent component.
>ou that thc application of the Intcmct Traftic 'tludel Toolkit tu the incorpormon of
rhc ns telncr ancl Trihuc TCP rnodels into thc IP-TY simulation tnvtronmrsnt has been 3e-
iicnhéd. somc testin: that \tas performcd to provide ebidence in support of the succesi; of
this application u i l 1 tic prcsented.
6.3 i ls Mode1 Testing
To enstire that thc r i s tclnct and Tahot. TCP modcls had not k e n altered by the Internet
Traftic hlndrl Toolkit. tcsting 1 4 u performed on these rnodels within the IP-T?i simularion
cn\ironment. This testing involveci the comparison of the output of the ns models in an
IP-TI; sirnulmon scenrino with their output in an ns simulation scenario. To perforrn this
tcsting. a jet o t simulation runs \vcre exccuted usine both an [P-TY simulation seenririo
ancl an ri.v simulation scenano. The results of the simulation mns usin2 the IP-TIi simulator
\\ere then comprired 16 ith those of the ns sirnulator. Descriptions of the simulation scenarios
are prokided in Section 6.2.1 white a presentation of the resuiis is _oiven in Section 6-32 .
6.3.1 Simulation Scenario
The simulation scenario rhat w s used to test the ns telner and Tahoe TCP rnodels within
the IP-TN simulation encironment is dispIayèd in F i y ~ 6.1. The scenririo consisrs of twa
hosts. host 1 and host 2. Host 1 ciintrtins an ris telnet source and an 11s Tahm TCP source.
and host 2 contains an ris telnet sink 2nd an ris Trihoe TCP sink. Other components of
the IP-TN simulacar w r e used. tuo huh components. one muter component. and four link
cumponents. The huh components connect the host components to the sirnulritcd Interner.
and routçr componcnts direct packet rlvt'nts to their destination. Each host is connscred ro
ri huh and each hub 1s connccted to a router using link cornponents. AIL Iink cornponcnts
uscd tn this sccnario have the same set of partimeten which rire shobvn in the box k l o u
the simulation scenario. E x h link has ri leneth of Ikm and propasrition JeIli! of Lrndkrn.
Thercforc. the dt'lay tn sendinp a puckct from onc simulation component to rtnother 1s Ims
oncc the prichct hris been entirely placeci on thé link. Thc rtite of tach link 1s 1.OE7 hits per
scciind. .-\s ;r result. the rate o i the i c d rtmc o i each link. N hich is the rate of the nmc' 11
takcs tu plciie a plicker on link. is I .OE-7 seconds F r bit. or S.OE-7 seciincfs p u hste. ,As
i t takcs a tcitril time of L .Sms for a packet tii he plxed on a link and r in ice at the simulation
~ - ..................................
linh Imnh: Ibn
linh prnpwtinn del?: Imdm
link Id timr: 1 t . h linlr n i e : 10 Mhp* packtt *ire llW h!Is
Figure 6.4: iP-TS Simulation Scenario I
To evaluate the results of the simulation runs performed using the above IP-TN scenruio,
an ris simulation scenario wüs also developed. The purpose was to create a simulation sce-
nario identical to the IP-T'I simulation scenruio so that the output of the n s models within
the IP-TY simulation environment could be compared to the output of these same models
ktithin the ris simulation environment. The trsulting ns simulation scrnario is shown in
Figure 6.5. The scenario consists of tive 11s n d e components conncctcd using four link
components. The tirsr nodt. contains an rrs ielnet source and an rrs Tahw TCP source. and
the titih node contains an 11s telnet sink and an ris Tahoc: TCP sink. E x h link component
hüs the same set of parameters uhich rire shown in the box bslow the simulation scenürio.
The ris l ink paramerers werc easily set IO march the char~cteristics of the links in the IP-TN
simulation scenario. The r i s link dclay i s rhe time i t takes for a paçket to rexh ri simulation
component once i t is entirely plriced on the link. and u.as set to lrns as in the IP-TII sim-
ulrition scenano. Each link also has ii bandwdth. or rate. of I.OE7 bits per second and the
packet site used \tas the cftlt'ault r i s pxkst s i x of 1000 bytes. Thr feed time of each link rs
calculrtted in the same manner in ns lis i t is in [P-TN.
\ d e Y +-. .
\ndr l \ndc .i Y d e 4 - m tçlnçt - - IinL Iink IinL ' ttnk
-4
*ink , - - - mï t3hw
t('P iink Pd
ünk hïndwiih: I R \ l h p
Figure 6.5: ns SimuIation Scenario 1
6.3.2 Simulation Results
To compare the output of the tis mdels tt~thin the [P-TN simulation environment to their
output in thcir onginal ns simulation environment. a set of simulation runs were eltecuted
Tribls 6.1: Simulation Scenario Panmeters
using both the IP-TN and n s simulation scenarios that were just described. -4s previously
descnhed. the ris telnet mode1 sends packct events at tirnes that rire randomly choscn using
an euponcntial distribution. For cach simulrition run. both the seed ot' the r~ndom number
cenerritor and the mean of the txponcntial distribution ivcre sperified. The parameters for - ctich simulation run are shown in Table 6.1.
Each simulation run in this set wris sxecuted tuice. once usin: the IP-TN simulation
scenano and once using the rts simulation scenario. For sach simulation run. a set of
statistics wcre collected. Iiicluded in this set \+srt. the packct sequence number and time
stamp pairs of the packet evsnts sent and received by hoth hosts of the IP-TN scenario and
hy both nodes of the r u scenrino that contain telnef and TCP models. Four cornparisons of
the output of the t~vo simulators ivere pcrfonned for each simulation run. The time stamp
and sequcnce number pairs of iho packct events rhat wcre sent by host 1 of the IP-T3
scenano were compareci with those of ihe packet evcnts that were sent by node I of the ris
sccnano. Similarly. the packtit evsnts that tiere rcçeived by IP-TN host 1 were compared
\i ith those rcceived by ris node 1. The same companson \vas then performcd on the packet
cvents sent and reccived by [P-T?i host 2 uith those sent and received by ris node 5 . The
purpose c~as to observe whtther the packet tirne stamp and scquence numbcrpüirs obtaincd
t'rom the IP-TII scenano matched thosc obtained from ns scenrino. In frtct. each comprinson
shoued thrit the IP-TN resulrs did match the ns results. The results of one simulation run
arc shou n here ris an example. Fisure 6.6 displays the gridphical cornparison of the packet
sequence number versus rime stamp plots tor rhe pricket events that were sent by IP-TK
host 1 IL ith the those sent bl; ns node 1 for simulation run 5 of Table 6.1. Fisure 6.7 shows
the sarne companson for the xknowledement packets sent by IP-TK host 2 and ns node
4 also for simulation run 5.
Figure 6.6: Cornparison of IP-'i'N and ns Telnct Sources
Figure 6.7: Cornparison of IP-TN and ns Telnet Sinlis
For the simulation runs pdormed. the results obtained from the IP-TN simulator match
those obrtiined from the irs simulator. This provides evidence to support the succcss of the
cipplicritiiin of the 1ntt.rnt.t Trriffic Mde i Taolkit to the incorporrition of the ris telnet rind
Tihw TCP modeIs into the IP-TN simulation environmenr. For the models and simulation
sccnartm used here. the lntsrnrt Traftic Mode1 Tuolkit proi,ided ri fr~rnework for the reuse
of rriftk and protocol rnodels from a sequenritil simulation environrnenr within the IP-TN
prtmllel ~imulation environment.
6.4 Host Model Testing
Once rht. r is telnef and Tahoe TCP models were incorpor~ted into thc IP-TN simulation
cnwonmcnt anci had been testéd according to the scenririo just descnbsd. rhey wrrc uscd
to test the capühilirv of the Intemet Traific MoJd Toolktt host LP to contriin more than
iine ~ipplicatiiin modcl. To pcrfurm this testing. 3 ncu IP-TN simulation scenririo wris
ciri\c.lopr.d that includt.s .i h~ist i~ ith tira ~ i . < trlnrt rnodeIb. According ru the rcsuits obtained
from thc previous testins scenmu, tht output of the telnèt models wcts the sarne within
hoth thc LP-TN and ns simulatriin sc~nriricis ussd. Thercfortl. nètr 11s simulation scenrino
i i a s cic\sloped so thrit ;t cornpanson of the output o i the n.v models in the IP-TY sçenrirïo
soiilcf as;iin bè cornpiirai with their output in the rrs scenano. The purpose wlis to obsérve
n hethcr the ITMT host rnuitiple'ct.d the output of the two application models in a manner
thrit mainrarned each of rhcir iraitic patrems. .A description of the sirnulrition scenarios 1s
giwn in Section 6.4.1 and presentrition of the rcsults obtaincd is provided in Section 6.4.2.
6.41 Simulation Scenario
Thè IP-TN stmularion scenrino thrit urts developed consists of t ~ o ns t~o rks and is shotbn
tn F~gure 6.8. ?iet\\ork L conssts of one host ccmponcnr that contains t ~ o 11s telnet source
modcls and t ~ o 11s T'iihoe TCP source models. Nerwork 1 consists of tuo host components
sach cont~inin~cine ns teInet sink modet rind one ns Tahoe TCP sink mudel. Telnet source I
of Hosr 1 sends to Host 3. and telnet source 2 of Host 1 sen& to Host 2. -4s in the prevtously
descnhrd [P-TN srmulation scenano of Figure 6.4- otherccimponents of the IP-TN srmula-
[or uere usrd. three hub sornponrnts. two router components. and seven Iink cornponents.
The hub cornponents connect the host components to the simulated Intemet. and the router
components direct packet events to their destination. Host. hub and router components are
connectcd tising link cornponents. .-\II link components used in this scenario have the same
set of parrimeters that were used for the links of the previously described sconario of Figure
6.4. Thesc parrimeters are s h o w in the box below the simulation scenario of Figure 6 3 .
Fignre 6.8: IP-TN Simulation Sccnario 1
.-\n ri,\ simulation >cenano \tas also dcvsloped so that the output of thc ILS tt'lnet models
in the [P-T'; ~imulaiion scenlino could be compared to thcir output in an ris simulation
a n a n o . The r i s simulation scenanc, is shonn in Figure 6.9.
.As the ns nuds sompvnent crin only contain one application mode1 and one protocol
model. the [P-T'i ~ n d ns simulation scenmos could not lx made identical in this crise.
Theretore. a scenano \br is de\eloped using a single application model. and for a given
ewcutton of the IP-TI(' simulation scenano. the output of each of the ns telnet source
TC'P w r c e
--
linti handwith: IO Mbps
linh dria?: IAms pncka sizc: IiWO bytes
-- --
Figure 6.9: ns Simulation Scenario I
models i b i i s compared ivith the output of the ris telnet source model for the execution of the
t1.v simulation scenano that used the srimç set of telnçt source model parametm. .-1s shoun
in Figure 6.0. thc ris sccnarto conststs of six 11s node components connscted usin2 tive linli
componenfs. The tint nodc contains an t t s telnet source and an rrs Tahw TCP sriurcc. and
the siirth node contains an rrs rclner sink and an ns Tahoc TCP sink. Each link component
h u the stimc set of plirtirnctcrs ;is uscd in thc prc\ iously dcscnbed ris simulatirin scc'nario of
Figure 6.5. Thesc parameters arc show in the box below the simulation scenririo of Figure
6.9.
6.4.2 Simulation Results
To ohsene 1s hether the Intcmet Traffic Model Toolkit host could multiplex the output of
the tuo m telnet modçls in a manner that maintained each of their traffic patterns. the
output of the ris telnet models in the IP-TY simulation scenario wris compared with the
output of the ns teinet rnodel in the ns simulation scenario. To perform this comparison. ri
set of simulation mns nere executed using each of the [P-TN and ris simulation scenririos
that ibere lust descnkd. .As in the previous testing scenario. both the seed of the nndom
numkr generator and the mean of the exponential distribution were specified for each
telnet source model of each simulation run. The important thing \vas to determine ivhether
the output from the ns telnet models within the ns sirnulator rnatched their output within
the tP-T'i simulator. and not the actual means and seeds chosen. The p m e t e r s for each
simulation run that was executed usin? the IP-TN simulation scenario are shown in Table
6.1. The parimeters for e x h simulation run that wris executed using the ris simulation
scenario are s h o w in T'able 6.3.
I I I , Simulation Run , 1 1 2 3 4 , 5 1 6 / 7 1 S 1 9 ' 10 , I I
Source I Mean 1 3 ' 3 i 5 10 1 1 / 2 i 3 1 5 1 10 : 1
SourcelSeed 1 1 : 1 : I 1 . 1 0 ~ 1 0 ! 1 0 ) 1 0 ~ 1 0 ~
Source 3 Sced 10 1 10 10 1 10 1 10 i 10 10 10 / 10 10 i Table 6.2: IP-TN Simulation Scenario Parameters
For each simulation run. the samc set of statistics WCK collected as in the previous
testing sccnano. For the IP-TN s~muIrition sciinario these included the packet sequcnce
numher and time stamp pairs ot the packt wents sent and rcceivsd hy tach of the tslnrt
source models of host 1 and the tslnet sink rnodels of host 2 and host 3. The sequcnce
number and time stamp pairs WK collectod from pxkets just More bang placed on the
l ink by the host. For the ris simulation sçeniino these incIuded the packet sequencc number
and time stamp pairs of the packet events sent and rcceived by the telnet models of nodes 1
and 6 .
For ii g1vt.n simulation run of the [P-T'; scenano. the tirne stamp and sequenct. num-
her pairs of the packet events sent iind received by erich of the telnet source models were
comptired to those oi the tdner source mode1 k)r the 11s simulation run that used the same
telnet source mcan and srcd. For sitamplc. rhe inpur and output of telnet source 1 for IP-TN
simulation run 1 \tris cornparrd to the input and output of the telnet source for ns simulation
Simulation Run I 1 3 4 ' 5 ' 6 1 7 S 9 I 10 1
Sourcrlblean 1 2 3 5 101 1 2 , 3 : 5 ' 1 0 '
SourceIserd 1 1 I I 1 1 0 101 101 101 10j
Trlble 6.3: ns Simulation Scenario Panmeters
run 1. and the input and output of trlnet source 2 for IP-TN simulation nin 1 was cornpmd
to that of the telnet source for ns simulation run 10. Similarly. the time stamp and sequence
number pairs of the packet t xn ts sent and rcceived by ertch of the telnet sink rnodels of the
IP-TN simulation scenano w r e compared with those of the telnet sink rnodel of node 6
of the ns simulation scenano sending acknowlerJ?ement pxksts to a telnet source uith the
sarnt. mran and seed L rtlues. The purpose u ris to observe u herher the packet time starnp
and scquence number pairs of the pocksts of a telnet rnodel sent by the host LP iiithin
IP-TN marchcd those sent h> a telnet rnodel u irh the same mean and seed values t i ithin ris.
In frict. each cornpanson sho\\sd thrit the IP-TY results did match the 11s results.
The results of a simulation nin arc shonn h m as an example. Figure 6.10 displays the
wphical cornpanson of the srlqucnce nurnhr tersus rime stamp plots for the pxket events h
sent hy four telnet source rnodels. telnet source I and telnet source 2 of IP-Th' simulat~on
nin 5 . the telnet sourcc of ris simularion nin 5 and the telnet source of ris simulation nin 10.
Figure 6.10: Two Cornparisons of IP-T3 and ns Telnet Sources: (a.) IP-T3 and ns Telnet
Source with Meün 10 and S d 1 t b.) IP-TN and ns Telnet Source with Mean 10 and S d 10
Both trlnet source 1 of IP-TY simulation run 5 and the trlnct source of ns strnulation
run 5 use a rnertn of 10 and a seed of 1. and the output of these two sources match. Both
telnet source 2 of IP-TN simulation run 5 and the telnet source of ns simulation run 10 use
a mean of 10 rind a seed of 10. and the output of these two sources match.
-4 second example of ~ s u l t s from the same simuIation nin are shown in Figure 6.1 1.
Figure 6.1 1: Two Cornparisons of IP-Ti(' rind ns Teinet Sinks: (a.) IP-TN and ns Telnet
Sink ~\cknonledgcments to Source with 'Ilean 10 and Serd 1 i h.) IP-TN and ns Telnet Sink
.\cknowledgcmcnts ta Stiurcc with 'Ilcün 10 and Setid 10
The rigure JispIriys the gnphtcal cornpanson of the sequence numkr versus time strimp
plots for the packet e\ents sent b> four telnet sink m&is. telnet sink of host 2 and telnrt
sink of host ! of fP-T3i simulation run 5. telnet sink of node 6 of ns simulation run 5 and
telnet zink of nodo 6 of ns simulation run 10. R ~ a l l that in the IP-TX simulation scenano.
telnet source L sen& to host 3 and telnet source 1 sen& to host 2. Thedore. in IP-T'I
simulation scenano 5. host 2 receives packets tiorn telnet source I uhich uses ri mean of 10
and a sscd of 1. and hosr I rrceives packets from telnet source 1 which uses ri mean of 10
and a seed of 10. Thus. the output of [P-TY host j is cornparecf wth the output of the telnet
sink of r r s stmdrition nin 5. and the output of IP-Ti% host 1 1s compared with the output
of the telnet srnk ot ns simulation run 10. As shown In the p p h . the output of the IP-TY
telnet sinh and the RS relnet sink that receivc packets from a telnet source with merin LO
and seed 1 match. and the output of the IP-TN telnet sink and the rrs tolnct sink thrit receive
packets from a telnet source ~ v i t h mean 10 and seed 10 match.
For ~ h e execution of the set o i simulation runs described here. the output of the ns telnet
source models as rnultiplexed by the host LP in the IP-T?J simulation scenxio was the
same 3 the output of the telnet source mode1 in the ns simulation scenario. This provides
evidence to support the S U C C ~ S S of the Internet Tnffic Mode1 Toolkit host LP to multiplex
the output from tno application models in a manner thrit maintains the traftic partern of
eaih. In this crise. the Internet Trriffic Mode1 Toolkit provided a framework for the reusr of
t\w trriftic and protwol models from a sequential simulation cnvironment nithin a s in~le
host of an [P-T'; simulation scenario.
6.5 Summary
Ont of the main goals in the development of the Internet Trrit'tic Mode1 Toolkit iras to
promit. a frameuork t'or the reuss of traftic and protocol models that N N C devcLoped ln
a sequential simulation enkironment within the IP-TN sirnulrition entironment thrit allows
for pamllrl ewcutian of simulation scenanos. To show that the ITMT can be used for
this purposc. i r lias applied to the incorpontton of a trriftic and a protoc.ol modtl of the
r i s [1. 121 netmurk simulator into the IP-TN simulation environment. That 1s. the ITMT
was uscd to irciitc an interface ktween the ns models and the IP-TN simulator so that
the r t s modcls could he used in simulation scenxios created with the IP-TS simulator.
This chapter proi1dt.d a description of how the iT4tT w t i s applicd [O the reuse of thest. r i s
models.
To ensure that the output of the r i s telnet and Tahm TCP modrls had not k e n altered
br rhe Internet Trriitic .LIodtl Toolkit. testing wris performed on these modcls ~bithin the
IP-T'i simulation environment. This testing involved the cornplirison of thc output of the
11s rnodels in an IP-TN simullttion scenario with their output in an r i s simulation scenario.
The results obtained providr a set of evidence to support the success of the application of
the Intemet Trriffs Mode1 Toolkit [O the incorporation of the ns telnet and Trihm TCP mod-
els into the LP-TY simulation environrnent. For the models and simulation scenuios used
in this testing scenmo. the iTMT provided a frrirnework for the reuse of trafiic and proto-
col models (rom a sequential simulation environrnent within the IP-TB parriIIel simulrttion
environment.
Thc r r s models \vere also used to test the capability of the Internet Tr~ffic Moiid Toolkit
host to multiplrir the output of two application models in a münnsr that maintains the traffic
pattern of erich. To perfonn this trsting. an IP-TIi simulation scenario wris dsvrloped that
included a host iiith tuo ris telnet source modrls. The output of this host was separateci
into two sets of packets. each including the packrts sent by one of the tillnrt rnodels. Exh
set of output \\as thrn cornpüred with the output of the n.s tslnet source mode1 t b i t h i n an
r i s siniulation scrnano. The results obtained provide evidence to suppon the succsss of
the [T'cIT host to multiplt.ir thc output of two 11s trlnet source models in a rnanner that
maintains the trat'tic pattern of each. For the simulation scenrino usd . the interner Triii'tic
blodel Toolkit provideci a fr~mcwork for the reuse of t~vo tr~fîîc and protocol rnocfels (rom
a srqurntial simiillition enLironment uithin a singlt. host of an IP-TX simulation scenano.
Summary of Contributions to Traffic Modeling
The result of this thssis is the Intçrnet Trtifiic b1odt.l Toolkit (ITIVIT) ~vhich \vas developed
i s pan of the Internet Protrxol Traftic an3 Network ( I P - l N simulator [:SI. The main zoal
In the de\elopment of the Inrcmet Traffc hiode1 Twlkit wris to provide ri kimt.\vork ior the
reusc anci dcvelopment of tmffic and prmxiil models uithin a simulation en\ ironment thrit
alIo\\ i; for partiilcl execution. To ;ichievt. this. rhe ITMT was developed within ri simulation
en\ironment that uses the lopical process modcliq methodologp.
Thc IP-TN simulator pro\ ides rin emulrition interface that enables interaction ktneen
simulation scenanos and actual lntemet hosts. This pocsntiallp allows for an\.. ripplicat~on
proudcd by an Intrmet host thrit is ifesigned to be used over a nettvork to be testcd using
a sirnulated netnork dewlopsd with IP-TN. .As the ITIVIT \vas developcd as pan of IP-TS.
tr~fiic and protocol rnodels that arc devrloped or reused with the ITMT can he used in
simulatsd net\~orks thrit arc used for this type of testing.
0tht.r nct\\orh simulators have k e n developed that support tritrtic and protocol rnodel
devsloprnent. The simulation cnvlronmznts of thése simulncors. hoivever. are limited in
some aspects. Sorne of thssr sirnulators only allow for the sequentiril execution of srmula-
tion models. .As a result. the size and cornpiexity of simulation scenarios ma! bs limited
due to sirnulrition run times. Most of these orher simulators do not provide Lin emulation
interiace for the interxtion bat\ een sirnulritcd rietworks and actual tntemet hosts. There-
fore. rictual srnices probided by internet hosts crtnnot bc tssted using simulrited netwrks
developed N i th these simulators.
After devolopment. tno applications of the ïl%lT were completed. The iirst one in-
bolbed the incorpormon of a ~ a \ s l e t model mto the IP-RJ simulation enbironment. Thar
1s. the ITbIT lias used to m a t s an interface bstween the wawlet model and the IP-TN
simulator so that the bkabelet model could lx used in simulation scenanos. The second
application in~olbed the incorporxion of the telnet and Trihm TCP models from the ris
simulator [2 . 131 into the [P-T'J simulation emirunment. The us simulation enLironrnent
onlr r i l l i~s for the sequential execution of simulation scenanos. Therefore. the use of the
ri.) models uirh the IP-Th' simulator potentiall) rillows them to bs used in Iaryr and more
cornpleu simulation scenano5 than hefurir.
Possible Future Work
Tno applications of the Intsrnrt Tr~ffic blodel Toolkir h a ~ e been completed. .As a result.
t ~ o trrifti c nodels. a \vavelet and ri telnct model. and one protocol rnodel. a TCP model. rire
a\ailatilc for use in simulation seenrinos createJ nith the IP-TX simulator. .A possihility for
future nork is to complt.te more rippliiations cit' the [TMT to provide a I a r p set of tmttic
and protocol models a\ailahle for use n ~ t h thc I P - D simulator.
Both the telnet and TCP modrls \\CR reused h m the ns simulator 11. 111. The ns
simulator pro\ ides man' TCP mocfcls. e x h implemcnting a differcnt vanant of TCP. Thc
1TMTci)uld he applied to the incorporation of other TCP models into the IP-TS simulation
sn\irmmrlnr. This could result in a set ni' b t i r y i n s TCP rnodels ribailriblc for use uith the
IP-TS simulator. In addition to rhs rslnet miidel. the 11s simulator also providrs othsr trriftic
models. Thest. includt: a tile trrinsfer protocol i FïPI. ti hyper text trtinsfer protocol iI-¶lTP)
rnodel. 2nd severril trrittfic models that do not require interaction 1 ~ 1 t h a protocol model.
The ITMT could also be applied to ihr tncorporrition of more of these ns traffic models
into the I P - D simulation environment. This couid result in a set of widely used trtiffic
models a\tiilable tor use in drveioping simulation scrnarios with the IP-TN simulator. Fur-
therrnore. using models from the ns simulator wirh the IP-TS simulator potentirilly iillows
[hem to be used in Irirger and more complri simulation scenanos ris the I P - D simuIator
allou s for prirlillrl ewcution.
The other netuorti simuIators mentioned in rhis thests also provide trtiftic and protocol
models. Furthsr resemh cnuld k done iniu the muse of models from these simulators.
and the ITblT could aiso be appiied to the incorporation of these models. Xgain. this could
funher expanci the set of tmftic and protocol rndels rivaitable for use in simulated network
scenanos developed using the IP-T?i simulator. Applying the ITMT in this manner would
also iunher test its capability to provide a frrimework for the Ruse of traftic and protocol
models from other simulators.
The ns telnet and TahW TCP modeis include several state variables that can lx con-
tipred during simulation initiaIizrition tvhen using them within the rts simulator. The 11s
rnodels that are incorporatrd into the IP-T'i' sirnulrition environment currentl! use the de-
iriult values for state variables from the n.$ simulator. Another possihility for future \vork is
to add the caprtbility to contigure the state of thesc models. This would involve thc addition
of functionality ro the initialization procedures of thest' miKlrls, As ri result. the state of
thrisc models could bs specitied ~iccording to the valuri rit ton of spccitic network scenarios.
Cumntlv. the set of statistics coilect~d from a traftic or protocol model developed usin2
the ITMT is dependent on thc model implementatiiin. This means that the developer of
ri mode1 must specih \vhich ~tat is t ic~ are displayrd rit the end of a simulation run. .A
possihility of future \\ork to improve thc IT'cIT is to cicsry and implement a module for
ciispla>ing ri set of statistics that can k used i i i t h an' trriftic or protocol mode1 developed
\i i t h the [TMT. This could a1Iw ior a set of statrstu to btl printed out for each model at
thc completion oi a simulation run ~ ~ i t h rnin~mal \\ork on the pan oC the de\eloper.
The simulation scenanos used to test the I I 3 I - T i b i t h incorporrited traftic and protocol
models included ri scenario u ith a host that contained t w triflic modcls each \L irh ri single
priitociil modd. The' did no[. hoivcber. incliide ri scenano ~ i t h a host that had a trriffic
model n ith more than one protwot model. This type of situation could occur. For rxample.
tu midel a nrtscapc weti brou ser ;i Tmitic Object rhrit ensapsulrites four Protocol Ohjects
mal nced to ht. used to modd the use of up ro four srmultaneous TCP connections. .As
the rihilit' of thc [DIT traftir: compncnt ro prciper!:. multiplex the output for t ~ o or more
simultancous stmulated connections hrts not k e n resred using a tmffic model incorporatrd
from another simulator. this testing is ti possrhilit!. for future ivork. The incorporation of a
\\eh model that uses multiple simultaneous s~rnulrited connections could ht: useful both to
ridd to the set ot mociels a~aiIahle for use ti ith the IP-TY sirnulritor. and to provide a mode1
for the testing of this scenano.
[71 Charles Chui. .-ln Irirndrlcrion ru Miidrrs. Xcridemic Press. Inc.. L992.
[SI James Cowie. Honsbo Liu. Jason Liu. David Nicol. and Xndy Ogielski. Towuds
rsalistic million-nodr intemet simulations. In Proi~rerlirtp- r,friir 1999 Irirrni~iriorinl
C'ori/irrc.~ic.r or1 Ptrrcillei alid Disrribrired Pmcr.ssin.q Tecltriiyrrrs ~ m d .-lppli~~urïoris.
1999.
[9l James Cowie. David Nicol. and Xndy Ogielski. Modcling the global internet.
C;)rtrptrrin,q tri Si*irnc*r arul En,ginrrrirzy. L ( 1 ):42-50. 1999.
[ 1 0 1 .A. Dupu);. J. Schwartz. 1'. Ycmini. rind D. Bacon. ilest: .A netbbork simulation and
prototypin_o trstkd. Conrrriiuiic-urio~t.s (l'rhr .-\CM. 3 3 10):63-74. 1900.
[ 1 11 Kwin Ftill rind Sallv Floyd. Simulation-baserl comparisons of tahot.. reno. and sack
tcp. tip://ftp.es.lbl.gov/pape~s/sacks/ps.Z.
[ 121 Kt.\ in Ftill and Kannan V'arxihan. rrs .Vorr.\ miti Doixriirriruriori. 1999. The C'IiuT
Projt'ct. .A 'Tcchntcd Repon.
http:ll\r \VIL -mash.cs.hcirkelt'~.~du/ns/ns-d~c~mcnt~~~on.html.
[ 131 A. Fcldrnlinn. A. Gilbcn. and W. Willinger. Data ntituorks ris casctides: Investisating
the multifrtictal nature of internet \van trriffic. In Procwciing.~ ofrhr 1'198 .-\CC1
SI(;C'Il!W:CI Con/2rmcr. pages 42-55- L99S.
[ 141 Richard Fujimoto. Airiillrl und Di.srribtrrrdSiniltltrrion Sy.srrrti.s. John Riley and
Sons. inc.. 2000.
[l51 .A. Ht-lm! and D. Estnn. Simulation-based stress vsting case study: .A rnulticast
routins protocol. In Procwt1inq.s of'riir Inrrniurionul S~nipr~sirrrrr on ,Mocleling.
.-\rttrl\.sis cmrl Sirruilorion ofC;~rrtpirr~.r tirrd Trleconinrlinicurim S F S ~ P ~ I I S . pages 3 6 4 3 .
109s.
(161 Barablira Burk Hubbürd. nie Ct.i)rl~l .-\cwrtIin,y to Cliciidrrs. .A K Peters. Ltd.. 1998.
[17] Inttirnrt rnftic archive. hnp:/lita.sr.Ihl.gov/
[LS] S. Ksshav. Real: a network simuiator. Technical Report SS/477. L'niversity of Californiri. Berkeley. 198s.
[19] W. Leland. .LI. Tiqqu. W. Williny. and D. Wilson. On the self-sirnilu nature of
sthernst traffic ( e'ctended version 1. IEEEZ4CM Trtinsticrioris on !Veni.or;(-ing.
1(1):1-15. 1994.
1 S. Ma and C. Ji. h,Il.ideling video trriffic in the wavrlet domain. In Proc.rrdirr,q.s rfrliu
1211 .-\ririiirrl IEEE Cori#~rrricr on Compirrrr Ci)ncnitirtic~rriorr.~. pages 10 1-108. 1998.
lx] Yusuf Oztiirk. Saad Lamour. and Kerirn Tunnay. Yctsom: 'Ier\vork simulaton object
modcl. In I~irc~ni~rrionol Chrift1rc.nc.r Cottt~rlti~ticiirio~t :Vtm+orks icrtd Disrribrlfrd
S ~ s r ~ n i s .Clo~lrliriy rerirl Sinicilarion: 2000 Ilé..sturn .ClidriCimj~rrnce. pages 1- 10.
1000.
[23] C'. Puson and S. Flo'd. Wide area trriffic: The hilure of poisson rnodeling. In
Proc~rrdirry.~ ol'riit~ 1494 .-\CM SIGC-0;ClM C*(irif>rrricr. pages 257-26s. I994.
[25] Brtrin Premorc and Da~id Nicol. PamlleI simulation o f TCPIIP usin: TeD. In
Pnuwlincs ,$rite Ilïnrrr Sinriiitrririrr Corijtwricr. pascs 4 3 7 4 3 , 1997.
[Y] Reynolds and Pcstel. Assigned Numbers RFC. IETF RFC 1340. 1991.
[XI File Trrinsfrr Protoc-ol. IETF RFC 959.
[29] H\ psrte'tt Trtinsfrr Protocol. IETF RFC 2660.
[-:O] Interner Protwd. IETF RFC 79 1.
[3 1 1 Telnet Protocol. IETF RFC 854.
[72] Transport Control ProtwoI. IETF RFC 1723.
[33j Trivial File Trrinsfer Protocol. [ETF RFC 1350.
[74] User Datagrrim Protocol. IETF RFC 765.
[35l V. Ribeiro. R. Riedi. M. Crouse, and R. Barriniuk. Simulation of non-yussian
long-rianse-dependent tmffic iising tvavelets. In Prucrrdin~.~ iq'rlit. 1999 .-\C,GI
SIGCIETRICS Coril;.rrrice. pages I - 12. 1999.
[36] Georg Rilry, Richard Fujimoto. and blostafri Ammar. .A gcncric frrirneworl for
parrillelization of nerwork simulatims. In IEEE Inrernciriond Wrkshop on
.CIotlrliti,p. :\~~til~.sis c m 1 Sitrrtrlrrriorz ri/C(mpurrr i~nd Trlrcirntrrituticcirio~~ 5.wrrrrr.s.
pages 125-135. 1999.
[37 1 Robert Sedgen ick. .-\lqoririir~~s tr i C . .Addison-LVeslsy Puhlishing Companq. Inc..
1 'NO.
[-BI Rob Sirnmonds. RusseIl Brdford. and Bnan Cnger. :'ippl!ing pirrillel discrett' ebeni
sirnuiation to netnork emuhtion. ln Proc.rdi~ryv ofrlir I-trii \\+irk.sliop on P~~ruilrl
ccritl Di.srrihrrrt.ei Sinirrlhirr. pases 15-12. 2000.
[-391 Richard Ste~ens. lrtrls Ntmork Pniqmnrrritng. Prentict: Hall. 199s.
[4 1 1 Carel Williamson. Wa\slet-basrd nctwork trat'tic modeling.
u u u . c~ .~~ ;~~k . c ;U I ' r i c~ l t ~ / ca re~ /talks/WaveletsTutonal.ppt.
[J3 1 Z. !Gao. B. Cnger. R. Simmonds. and J. C I e q . Scheduling cntical channels in
consenative parriIlel discrete event simulation. In Procrrciirrys uj'rlir rhirrrrnth
\i~)rksliop on Purcdlrl cmd Dismiburd Sitririlurion. pages 20-28. 1999.