· 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]

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


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


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,


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


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. representing 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.

Bibliography

[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.

Documents

· 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]