A Unified Load Generator for Geographically Distributed Generation of Network Traffic

A Unified Load Generator for

Geographically Distributed Generation of Network Traffic

Master Thesis Computer Engineering

Leila Hadji

Sweden, Dalarna University

October 2006

Dedicated…

To my dear parents who always urged me forward

iii

DEGREE PROJECT In Computer Engineering

Program

Master of Science in Computer Engineering

Credits

30 ECTS

Registration #

E3429D

Month/Year

October 2006

Name of student

Leila Hadji

Examiner

Prof. Mark Dougherty

Supervisor at the Company/Department

Prof. Dr. Bernd E. Wolfinger

Company/Department

Telecommunications and Computer Networks Division, Computer Science Department, University of Hamburg, Germany

Advisor

Dr. Ernst Nordström

Title

A Unified Load Generator for Geographically Distributed Generation of Network Traffic

Keywords

Traffic Models, UniLoG, Formal Load Description, Load generator, Master/

Slave Distributed Load Generation System

Abstract

During the last decade, the Internet usage has been growing at an enormous rate which has been accompanied by the developments of network applications (e.g., video conference, audio/video streaming, E-learning, E-Commerce and real-time applications) and allows several types of information including data, voice, picture and media streaming. While end-users are demanding very high quality of service (QoS) from their service providers, network undergoes a complex traffic which leads the transmission bottlenecks. Considerable effort has been made to study the characteristics and the behavior of the Internet. Simulation modeling of computer network congestion is a profitable and effective technique which fulfills the requirements to evaluate the performance and QoS of networks. To simulate a single congested link, simulation is run with a single load generator while for a larger simulation with complex traffic, where the nodes are spread across different geographical locations generating distributed artificial loads is indispensable. One solution is to elaborate a load generation system based on master/slave architecture.

Acknowledgements

I would like to express my thanks for Prof. Dr. Bernd E. Wolfinger, my dear supervisor for his supports at the Department of Computer Science, Hamburg University and his extreme precision in developing the overall organization of this thesis, also my thanks to my local supervisor at Department of Computer Science at Dalarna University, Dr. Ernst Nordström.

v

Contents

Chapter 1 Introduction

1.1 What is the main Task in Traffic Engineering (TE)? . . . . . . . . . 1

1.2 Problem Definition. . . . . . . . . . . . . 3

1.3 Thesis Objectives . . . . . . . . . . . . . . 3

1.4 Thesis Structure. . . . . . . . . . . . 4

Chapter 2 State of The Art in Load Modeling and Load Generation

2.2 Analytical Modeling versus Simulation Modeling. . . 6

2.2.1 Analytical Modeling . . . 6

2.2.2 Simulation Modeling. . . 7

2.3 Traffic and Load Modeling. . . 8

2.3.1 Definition of Traffic . . . . . . 8

2.3.2 Renewal Traffic Models. . . 9

2.3.3 Markov and Embedded Markov Models. . . 10

2.3.4 Markov Modulated Poisson Process (MMPP) . . . 10

2.3.5 Voice Telephony Model. . . .11

2.3.6 ON/OFF Traffic Model. . . .12

2.3.7 Transform-Expand-Sample (TES) model. . . 13

2.3.8 Self- Similar Traffic Models. . . 13

2.3.8.1 Video Traffic Model. . . 13

2.3.8.2 Audio. . . 14

2.3.8.3 LAN. . . 14

2.3.8.4 WAN. . . 14

2.3.9 The Poisson Pareto Burst Process (PPBP) . . . 15

2.4 Load Measurement. . . 15

2.5 Load Generator. . . 17

2.6 Summary . . . 20

Chapter 3 The UniLoG load Generator

3.2 The Reason We Need Load Generators. . . 22

3.3 Prerequisites to Design a Valid Artificial Load Generation. . . .22

3.3.1 The Behavior of End-Users . . . .23

3.3.2 Formal Description of Load Generation Process. . . 23

3.3.2.1 Determination and Specification of Concrete Sequences of Requests . . . . . 24

3.3.2.2 Determining Durations between Successive Request Generations (Trace of Durations of delays) . . . 25

3.3.2.3 Actual Parameterization of Requests Attributes. . . 25

3.4 Specification MPEG-encoded Video Load based on FDT . . . . . . 25

3.5 Architecture for a Unified Load Generator (UniLoG) . . . 34

3.6 Summary. . . .36

3.3.2.1

Chapter 4 Requirements for Geographically Distributed Load Generation Systems

4.2 Distributed Load Generation . . . 38

4.3 Examples of when a Distributed Load Generation is needed. . . .39

4.3.1 Mesh network topology. . . 39

4.3.2 Distributed application services. . . .40

4.3.3 Inter-network. . . 40

4.4 Centralized Load Generator versus Distributed Load Generator. . . 41

4.5 Distributed Load Generation System. . . 42

4.6 Different Distributed Load Generation Models. . . 43

vii

4.6.2.1 Load generator controller (master) nodes. . . 44

4.6.2.2 Load generators (slaves) nodes. . . .45

4.6.3 Distributed load generation with distributed control. . . .45

4.7 Summary. . . .46

Chapter 5 Functionality and Architecture for a Distributed UniLoG Tool and Implementation Aspects

5.2 Design Phase. . . .48

5.3 Important Aspects of Implementation. . . .53

5.4 How this Program Works. . . 54

5.5 A Case Study for Validation of Synchronization Accuracy. . . .56

5.6 Summary. . . .58

Chapter 6 Case Study: Influence of UDP Background Loads on Video/Audio Streaming Applications in a WLAN Infrastructure

6.2 Objective of These Experiments. . . 60

6.3 Experimental Set-up and Preparation. . . 60

6.3.1 Required Hardware. . . 61

6.3.2 Necessary Software and Files . . . .61

6.3.3 How to Stream Media . . . 63

6.3.4 How to Generate Background Load. . . 64

6.3.5 Metrics for Streaming Media Test. . . 64

6.4 Designing Groups of Scenarios. . . 65

6.4.1 G 1: Streaming Without Background Loads. . . 65

6.4.1.1 Scenario 1. . . 65

6.4.1.2 Scenario 2. . . 69

6.4.1.3 Scenario 3. . . 71

6.4.2 G 2: Streaming While Applying Different Background Loads of Single Types. . . 73

6.4.3 G 3: Streaming With Mix of Traffic (heterogeneous) . . . .88

6.4.3.1. Scenario 5. . . .88

6.4.3.2 Scenario 6 streaming with mix of traffic. . . .90

6.4.3.3 Scenario 7. . . 91

6.5 Experimental Results . . . 93

Chapter 7 conclusions and Future Works

7.2 Future Works. . . .98

References

Appendix A

ix

List of Figures

Figure 2.1: Stream of requests. . . 8

Figure 2.2: MMPP models of state 2, 3, and 4, respectively. . . 11

Figure 2.3: Packetized voice source. . . 12

Figure 2.4: A single ON/OFF model. . . 12

Figure 3.1: The set of the macro-states and the transitions between them (Cf. [20]) . . . 23

Figure 3.2: GUI of an MPEG-encoded video load model. . . 27

Figure 3.3: Requests types Definition using GUI. . . .28

Figure 3.4: (a) Definition of IP-Address attribute. . . 29

Figure 3.4: (b) Definition of port number attribute. . . 29

Figure 3.4: (c) Definition of frame length attribute. . . 30

Figure 3.5: Depiction of requests attributes (zielAddr, Zielport, Nutzdaten) . . . ..30

Figure 3.6: Constant values for a frame length attribute. . . 32

Figure 3.7: Parameterization of frame length attribute according to normal distribution. . . .33

Figure 3.8: Parameterization of frame length attribute according to a predefined trace file. . . 33

Figure 3.9: The architecture of a UniLoG. . . 34

Figure 4.1: Example of geographically distributed load generation in network router /switch. . . . 38

Figure 4.2: Mesh network architecture . . . 39

Figure 4.3: Centralized load generator architecture. . . 41

Figure 4.4: Distributed load generator architecture. . . .42

Figure 4.5: An example of distributed load generation (IF: Interface at which load is generated) . .42 Figure 4.6: The architecture of a distributed load generation system with an autonomous model. . 43

Figure 4.7: The architecture of a distributed load generation system with master/slave control. . . ..44

Figure 4.8: Generating traffic from a client to different nodes in various locations (dashed lines) . 45 Figure 4.9: The architecture of distributed load generation system with distributed control model..46 Figure 5.1: The communication in distributed load generation system master/slave control model. 48

Figure 5.2: Synchronization and timing. . . 51

Figure 5.3: Control from server (master) to both client1 and client 2 (slaves) in a typical LAN. . . 56

Figure 6.1: The streaming media process . . . 64

Figure 6.2: The load generation process. . . 64

Figure 6.3: Scenario 1, (1) streaming media from server to client1 (2) streaming media from server to client2. . . 66

Figure 6.4: Scenario 2, streaming media from server to both client1 and client2 at the same time. 69 Figure 6.5: Scenario 3, streaming media from server to client1, client2 and client 3 at the same time . . . 71

Figure 6.6: Scenario 4, process of disturbing the streaming media by applying background loads. 73 Figure 6.7: Quality of streaming video under different background loads. . . 77

Figure 6.8: Background Loads versus percentage of packet loss. . . 80

Figure 6.9: Background Loads versus percentage of sequence errors. . . 80

Figure 6.10: Background loads versus number of transmitted packets. . . 81

Figure 6.11: Background loads versus number of transmitted packets. . . 81

Figure 6.12: Background loads versus valid video packets received. . . .82

Figure 6.13: Background loads versus mean IP bandwidth. . . 82

Figure 6.14: Background loads versus mean delay between valid packets received. . . 83

Figure 6.15: Background Loads versus percentage of packet loss. . . .85

Figure 6.16: Background Loads versus percentage of sequence errors. . . 85

Figure 6.17: Background loads versus number of transmitted packets. . . 86

Figure 6.18: Background loads versus number of transmitted packets. . . 86

Figure 6.19: Background loads versus valid video packets received. . . .87

Figure 6.20: Background loads versus mean IP bandwidth. . . .87

Figure 6.21: Background loads versus Mean Delay between valid packets received. . . 88

Figure 6.22: Scenario 5, streaming with mix of traffic. . . .89

Figure 6.23: Scenario 6, streaming with mix of traffic. . . .90

Figure 6.24: Scenario 7, streaming with mix of traffic. . . .92

xi

List of Tables

Table 3.1: A typical example of trace files. . . 31

Table 5.1: The average ADIF on three different tests. . . 57

Table 6.1: Laptops Hardware Configuration. . . .61

Table 6.2: Movie trailer “Matrix Revolution” specifications. . . .62

Table 6.3: Statistical results of scenario 1 (first run) . . . 68

Table 6.4: Statistical results of scenario 1 (second run) . . . .68

Table 6.5: Statistical results of scenario 2 . . . .70

Table 6.6: Statistical results of scenario 3 . . . 72

Table 6.7: Background loads properties . . . 74

Table 6.8: Statistical results of Scenario 4 video streaming . . . 79

Table 6.9: Statistical Results of Scenario 4 audio streaming . . . 84

Table 6.10: Background loads properties . . . 89

Table 6.11: Statistical results of scenario 5 . . . 90

Table 6.12: Statistical results of scenario 6 . . . 91

Table 6.13: Statistical results of scenario 7 . . . 93

Chapter 1

Introduction

During the last decade, the Internet usage has been growing at an enormous rate which has been accompanied by the developments of network applications which allows several types of information including data, voice, picture and media streaming. Such applications range from the text-based utilities, Electronic mail, network news from the early days of the Internet to the advent of video conference, audio/video streaming, E-learning, E-Commerce, Voice over IP (VOIP) , and real time applications that are capable of transmitting data in real time with a high data rate.

Moreover Internet provides the operating environments which are very dynamic. While end-users are demanding very high quality of service (QoS) from their service providers, and their demands are continue to grow at a rapid pace resulting in network’s ever-increasing size, network undergoes a complex traffic which leads transmission bottlenecks. Several efforts are tackling this problem, to keep pace with the ever-increasing volume of the Internet. To do this end, traffic engineering (TE) is being called up to optimize the performance of an operational network. We will explain traffic engineering task in further details in the following section.

1.1 What is the main Task in Traffic Engineering (TE)?

Internet traffic engineering is defined as that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational networks [52]. The task of traffic engineering in particular is to map traffic flows onto an existing physical topology. TE is currently a topic of intense discussion within the Internet Engineering Task Force (IETF) and

large ISPs [33]. It can be used to balance the traffic load on the various links, routers, and switches in the network so that none of these components is over utilized or underutilized. Performance evaluation can be achieved in many different ways, but according to [52], the key components of the traffic engineering process model include measurement, modeling, simulation and optimization. The operational state of a network can be conclusively determined only through measurement.

Measurement is also critical to the optimization function because it provides feedback data which is used by traffic engineering. A network model is an abstract description of the network behavior.

Network simulation tools are extremely useful for traffic engineering. A good network simulator can be used to mimic and visualize network characteristics under various conditions in a safe and non- disruptive manner. To emulate a communication system, artificial loads are indispensable, because the performance of a network is not only based on hardware and software but also on the load that it must handle. Artificial load refers to load which is induced into the network in order to reflect the behavior of additional users and/or to generate a dedicated background or a peak load for the network, (e.g. what will be the response time for a user’s request to a web site when the number of users is going to be doubled?). Network performance optimization involves resolving network issues by transforming such issues into concepts that enable a solution.

So far we learned that, traffic engineering employs different techniques to enhance the performance of network. Moreover we mentioned the need for using artificial load generators to predict user behavior under different load scenarios. But our thesis objective is not to propose a new optimization technique, load model or simulator in the field of traffic engineering, and not to design a new load generator to find out the reflection of new users while adding to communication system or changing the system functionality. We will present a description of our thesis objectives, problem definition, as well as the structure of this thesis in the following sections.

1.2 Problem Definition

To evaluate the performance of distributed applications which involve the interactions of multiple independent systems, generating artificial load at geographically distributed locations is indispensable. According to the restricted data range generated by a single load generator, when an experimenter needs to generate a large amount of traffic, e.g., to test a router node which should

Chapter 1 – Introduction 3

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se routing, bottleneck avoidance mechanisms are example of where the load generators are required to be used in distributed manner to simulate an environment in which experimenters could assess the network performance under different load scenarios. Therefore it is of major importance to elaborate a distributed load generation system (design and implementation). We present an example of the need for distributed load generator in distributed application, to make this subject more clear as follows:

We are adding a new functionality to a web site or redesigning it. We must know how this will affect response time before our customers find out. An artificial load generator can mimic the end- user’s behavior (e.g., a request of file transfer) and generate load in the link between web server and web client (a node is used as a controller or server and a number of nodes might be used as end- users or clients), since we have several users, a combination of different load generators which are spread in different geographical locations could be required to generate traffic. Then we test the web page performance under different competing traffics which are induced by several artificial load generators in the given network. Doing so lets us detect potential performance problems and fix them before they occur.

1.3 Thesis Objectives

The main goal of this thesis is analysis, design and implementation of a distributed load generation system based on master/slave architecture. In this thesis we discuss different versions of how to design distributed load generation system including, autonomous model, master/slave model and distributed control model and depict some of the main issues relevant to requirements for geographically distributed load generation systems. The load generator we will use in our thesis is a unified load generator named UniLoG proposed in [20], based on a formal description technique which is a valid tool for QoS studies and can produce some accurate predefined traffic at different interfaces within the protocol hierarchy of computer networks. Due to the main task in this thesis, we concentrate more on the architecture of load generation systems based on master/slave model and focus on issues relevant to this model in the design and implementation phases. Different aspects, such as synchronization and security, are of major significance for us in the phase of design and implementation; therefore we make a validation test to test the accuracy of our solution.

According to the rapid growth in popularity of distributed applications over the past few years it is

quite important to study the influence of distributed applications (e.g., audio/video streaming applications) under different background loads. Therefore we present a case study to investigate the impact of UDP background load on distributed media streaming applications in a WLAN infrastructure.

1.4 Thesis Structure

Chapter 1(Introduction): presents the motivation of this thesis including in traffic engineering and distributed load generation systems, the problem definition and main goal in our work.

Chapter 2(State of The Art in Load Modeling and Load Generation): provides an overview of load

modeling, different types of traffic models as well as load measurement and load generators.

Chapter 3(The UniLoG Load Generator): addresses a unified methodology for artificial load

generation based on a formal description technique proposed in [20].

Chapter 4(Requirements for Geographically Distributed Load Generation Systems): introduces the concepts and architectural solutions for distributed load generation systems based on [20] and discusses some of the main issues relevant to requirements for geographically distributed load generation systems.

Chapter 5(Functionality & Architecture for a Distributed UniLoG Tool and Implementation Aspects):

presents a solution for design and implementation of distributed load generation system based on master/slave architecture,

Chapter 6(Case Study: Influence of UDP Background Loads on Video/Audio Streaming Applications in a WLAN Infrastructure): investigates the impact of UDP background load on a distributed application (e.g., streaming media) in a WLAN test bed.

Chapter 7(Conclusions and future works): gives the summary and results we achieved as well as future works in the filed of distributed load generation systems.

Chapter 2

State of The Art in Load Modeling and Load Generation

2.1 Introduction

With rapid development of new communication services and applications, the requirements of the end users highly change which compel manufacturer and professionals upgrade their serviceability and respond to changing customers needs quickly. Therefore it is always of interest to study a proposed communication network to improve as well as predict system performances. To do this end, telecommunications professionals are being called upon to design and manage these systems in the face of fast-moving technology and a climate of increasing customer expectation. Design and management decisions, require accurate predictions of network performance to guarantee an acceptable level of Quality of Service (QoS) to the end users; decision based on poor predictions may adversely affect network customer’s perception of new technology [62]. It is generally necessary to use a model for this purpose, since experimentation with the network itself is disruptive, not cost effective, or simply impossible (e.g., because the network has not yet been built) [2]. A network model is an abstract representation of the network which captures relevant network features, attributes and characteristics [52]. The model facilitates analysis and/or simulation which can be used to predict network performance under various conditions. Measuring the amount and type of traffic on a particular network is another key component of traffic engineering process model which is crucial to the traffic engineering function. Furthermore load generators can be use to

mimic user behavior to evaluate the QoS as it is offered by the network under different load scenarios.

This chapter is intended to be a review of different traffic definitions, load models, load measurement approaches, as well as load generators. The structure of this chapter is as follows. We address an overview of the traffic modeling including analytical and simulation in Section 2.2.

Network simulation is explained in Section 2.3. In the Section 2.4 we introduce the traffic notion and describe different traffic models using examples. Load measurement is described in the Section 2.5. Section 2.6 deals with the load generators and their usage in the communication networks, which ends up with some typical examples of load generators and finally we present a chapter summary in the last Section.

2.2 Analytical Modeling versus Simulation Modeling

Generally modeling methods are employed in two fundamental ways either as analytical modeling or to drive simulation experiments. Although there are significant differences between analytical and simulation modeling, particularly in the areas of scalability and complexity [3].

2.2.1 Analytical Modeling

Analytical modeling is represented by mathematical methods (such as algebra, calculus, or probability theory) to obtain exact answers to the questions of interest [2]. While it may be easy and fast to model a single node through analytical methods using queuing theory equations and formulas to estimate the performance of system, the mathematical methods have limited ability to model more complex or dynamic environments accurately. In addition, analytical models cannot be effectively used where there is no existing model and we want to design a new model as well as when we must determine the effect of changes on system performance. Furthermore additional shortcomings of analytic queuing models are as follows [2]:

• Only steady-state results are typically possible

• Original analytic solutions require considerable mathematical sophistication on the part of the analyst.

Chapter 2 - State of the Art 7

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

Due to drawbacks of the analytical methods, and current expansion of the network complexity, there seems to be significant increase in use of simulation modeling to date.

2.2.2 Simulation Modeling

In a simulation modeling a mathematical/logical model is numerically evaluated over a time period of interest, and performance measures are estimated from model-generated data. Simulation analyses are applicable to systems of almost any level of complexity [2], and offer the ability to create a valid representation of an entire complex system consisting of all computers, routers, bridges, applications, and database servers [3]. Real world systems are dynamic in design and one small change in a single component or process can trigger a much larger change that may have a negative effect on end user response time [2].Unlike analytical models which often require many assumptions and are too restrictive for most real world systems, simulation modeling places few restrictions on the classes of system under study [62]. Moreover highlights errors created on design phase and remove them before the system is completed.

One of the most significant reasons that the communication network is deployed based on simulation modeling is the simplicity of converting a system description to a computer program.

Simulated models are supported by general-purpose programming languages (e.g. C or Pascal), object-oriented programming languages (e.g. C++) or simulation software for this purpose or communications-oriented simulation languages (such as OPNET Modeler [63]) which reduces coding time. Simulation tools are extremely useful for traffic engineering [52]. Due to complexity of realistic quantitative analysis of network behavior, certain aspects of network performance studies can only be conducted effectively using simulation. A good network simulator can be used to mimic and visualize network characteristics under various conditions in a safe and non-disruptive manner.

For example, a network simulator may be used to depict congested resources and hot spots, and to provide hints regarding possible solutions to network performance problems. A good simulator may also be used to validate the effectiveness of planned solutions [52].

Moreover simulation modeling could be used to do the following [3]:

• Maintain accuracy by scaling and reacting to system or platform variations.

• Address capacity planning questions at both the hardware and software resource levels, while allowing the connection between the two to influence the results.

• Create accurate models of truly concurrent systems when multiple threads may exist within one or several components.

• Represent database locking and I/O processing with greater accuracy.

• Validate the effectiveness of planned solutions.

• Investigate and identify how best to make the network evolve and grow, in order to accommodate projected future demands.

2.3 Traffic and Load Modeling

In the following subsections we present the definition of traffic and workload as well as different load models.

2.3.1 Definition of Traffic

Traffic (e.g., packet, cell) moves on the communication link, while load implies the traffic. There are a number of definitions to depict traffic, below are three definitions for workload and traffic:

Def 1: The workload or load L=L (E, S, IF, T) denotes the total sequence of requests [1], [20] which is offered by an environment E to a service system S via a well-defined interface IF during the time- interval T. The load is a function of (E, S, IF, T) while can be viewed as a vector of (time, request), where T_i is a point in time (T_i∈R) and ri is a request. Each request can be denoted by an unequivocal request type and a set of attributes associated to request type with dedicated attributes values for a given request. A stream of requests at a well-defined interface is illustrated in Figure 2.1.

Chapter 2 - State of the Art 9

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

Def 2: The network load is a collection of user generated inputs, or a collection of client generated events. A client on a network initiates a sequence of sessions demarcated by login and logout, during which commands are issued by the users [61].

Def 3: Simple traffic consists of single arrivals of discrete entities (packets, cells, etc) [62]. It can be mathematically described as a point process consisting of a sequence of arrival instants T1, T₂… T_n measured from the origin 0; by convention T₀=0. There are two additional equivalent descriptions of point processes. A counting process {N (t)}

=0

∞

t is a continuous - time, non - negative integer- valued stochastic process, where N (t) = max {n:Tn≤ t} is the number of (traffic) arrivals in the interval (0,t]. An inter-arrival time process is a non-negative random sequence {t_n}

=1

∞

n , where tn=Tn – T n-1 is the length of the time interval separating the n-th arrival from the previous one. The equivalence of these descriptions follows from the equality of events:

{N (t) = n} = {Tn≤ t ≤ T n+1} = {

∑

= n

k

tk

1

≤ t<

∑

= 1

1 n

k

tk} (2.1) Since Tn=

∑

= n

k

tk

1

. Unless otherwise stated, we assume that {tn} is a stationary sequence and that the common variance of t_n is finite.

We employ the first definition of load in our thesis work.

2.3.2 Renewal Traffic Models

Renewal models have a long history, because of their relative mathematical simplicity. In a renewal traffic process, the interarrival times {An} are Independent Identically Distributed (IID) [62], but their distribution is allowed to be general. Renewal models have a severe modeling drawback -the autocorrelation function of {An} vanishes identically for all nonzero lags. Queuing models historically have routinely assumed a renewal-offered traffic. Two cases of such models, namely Poisson Process and Bernoulli process are discussed here.

2.3.3 Markov and Embedded Markov Models

In many situations, the activities of a source can be modeled by a finite number of states. The idea is to deploy the traffic stream using an explicit notion of state. For a given state space S = {s1, s2…

SM} let Xn be a random variable which defines the state at time n. The set of random variables { Xn

} will form a discrete Markov chain, if the probability of the next value Xn+ 1 = sj depends only on the current state [8]. This is known as Markov property. If state transitions may occur only at integer values (0, 1… n …), the Markov chain is discrete time. Otherwise, the Markov chain will be continuous time.

2.3.4 Markov Modulated Poisson Process (MMPP)

The most commonly used Markov-modulated model is the Markov-Modulated Poisson Process (MMPP) model which combines the simplicity of modulating (Markov) process with that of the modulated (Poisson) process [62]. A Markov modulated process, also called doubly stochastic process [8] [15] [7] [12], whose intensity is controlled by a finite state continuous-time Markov chain (CTMC). An MMPP parameterized by an

m

Q =





















−

−

−

m m

m

m m

σ σ

σ

σ σ

σ

σ σ

σ

...

. ...

. .

...

...

2 1

2 2

21

1 12

1

, σ i =

∑

≠

= m

i j j

j i , 1

σ, ,Λ =(λ^1,λ^2,...,λ^m) (2.2)

Figure 2.2 illustrates MMPP examples of state 2, 3, and 4. MMPP is commonly used in telecommunication traffic modeling and it has several attractive properties, such as being able to capture correlations between interarrival times while still remaining analytically tractable.

Chapter 2 - State of the Art 11

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se Figure 2.2: MMPP models of state 2, 3, and 4, respectively

2.3.5 Voice Telephony Model

This model is a two States Markovian Model for Individual Voice Sources [13]. The typical behavior of packet voice sources is as follows: (Daigle et. al., 1986). A source is said to be “active”

as denoted in figure 2.3, when a user is literally speaking, during this period, the voice source generates packets of fixed length at regular time intervals. Afterwards, comes a silence period during which the source changes its state to “inactive” and no packets are produced. When we identify these two states of the process, it is possible to model the voice with Markovian chains since they allow us to characterize a discrete variable that changes in the time domain through its states transition probabilities. A packet burst from a voice source is being modeled by arrivals at fixed intervals with T msecs duration, and by a silence period during which there is no arrival (figure 3). A voice source is modeled by the following equation [10]:

F (t) = [(1- α T) + α T (1- e^=β(t−T) ] U (t-T) (2.3)

Where U(t) is the singled step function, α is the average value of the active period, β is the average value of the silence period; both periods are described by exponential distribution functions, the arrival rate is of 1/αT packets, and corresponds to a geometric distribution.

Figure 2.3: Packetized voice source

2.3.6 ON/OFF Traffic Model

There are a number of definitions for ON/OFF model proposed in [5], [8], [4], [9], [10], and [11].

An ON/OFF process represents traffic between a single source/destination pair [5]. It alternates between two states: the ON state, during which the source transmits data at a constant rate; and the OFF state, during which the source is silent. Figure 2.4 depicts a schematic view of a section of the ON/OFF process. X1, X2 . . . are Independent Identically Distributed (IID) nonnegative random variables representing the duration of the ON states, and Y1, Y2 . . . are IID nonnegative random variables representing the duration of OFF states.

The ON/OFF model came to explain, for the first time, the self-similar behavior of traffic, which was experimentally observed by many researchers. It is basically the heavy-tail ON and OFF durations that lead to such behavior. This assumption is consistent with network measurements.

Indeed, the OFF duration can have high variability, since some source model phenomena that are triggered by humans (e.g., HTTP sessions) have extremely long period of latency. There is also significant amount of empirical evidence suggesting that the ON duration is heavy-tail. A well established observation for instance is that the sizes of the files available on a server are heavy-tail, which implies that the transfer times for these files also have the same type of characteristics. (See [5] for more details).

Chapter 2 - State of the Art 13

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

2.3.7 Transform-Expand-Sample (TES) model

TES models provide another modeling approach geared toward capturing both marginal and autocorrelations of empirical record simultaneously, traffic included [51]. The empirical TES methodology assumes that some stationary empirical time series is available. TES processes come in two flavors: TES⁺ and TES^-. The superscript (+ and -) depicts a positive and negative lag-1 to TES process respectively. See [62] for more details.

2.3.8 Self- Similar Traffic Models

Self-similarity means the process looks statistically the same over a wide range of different scales and it is closely related to the so-called “bursty” behavior and Long Range Dependence (LRD) [15].

A self-similar or fractal phenomenon exhibits structural similarities across all of time scales. In the case of packet traffic, self-similarity is manifested itself in the absence of natural length of a burst [62]. Models of self-similar processes are needed for simulation and performance analysis. Three important examples of self-similar traffic models are:

• superposition of many renewal arrival process with heavy-tailed interarrival time distributions

• superposition of arrival processes from many ON/OFF sources with heavy-tailed ON and/or OFF period durations

• Fractional Brownian motion (FBM)

Following subsections address some examples of traffic models which show the self-similar behavior. To find more details, refer to [16].

2.3.8.1 Video Traffic Model

Recent measurements have shown that compressed video (e.g. MPEG) traffic exhibits self-similar behavior on a wide range of time scales [16]. It has been shown that there is a knee-point of the buffer size below which the buffer distribution is dominated by the short-range correlations and above which by long-range correlations. The conclusion is that if the queue operates under

conditions of low utilization and practical buffer size, the input traffic can be modeled by a short- range dependent model which is generally Markovian although the input traffic has long-range dependence (LRD). For queuing analysis purposes, the video source can be modeled by a superposition of ON/OFF Markov fluid sources or by a superposition of two-state MMPP sources.

With proper matching of parameters of the autocorrelation function, the set of MMPP sources is able to produce self-similar traffic over a certain range of time scales. The FBM model is another self-similar traffic model that has been suggested for compressed video.

2.3.8.2 Audio

From a traffic modeling perspective compressed audio (e.g. MP3) is similar to compressed video [16]. That is, a superposition of Markov modulated fluid or Poisson sources can be used for queuing analysis.

2.3.8.3 LAN

Measurements on LAN Ethernet traffic at Bellcore in the early 90s showed that Ethernet packet traffic is self-similar [16]. The aggregate Ethernet traffic can be modeled by an FBM process or by a set of ON/OFF sources with heavy tailed ON/OFF period durations.

2.3.8.4 WAN

Measurements on WWW and TELNET packet traffic in the Internet conducted in the mid 90s showed that such traffic is self-similar [16]. Plausible traffic models are the FBM model or a superposition of ON/OFF sources with heavy tailed ON/OFF period durations. Similar measurements on FTP data bursts within FTP sessions have shown that the FTP data burst sizes are heavy-tailed.

Chapter 2 - State of the Art 15

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

2.3.9 The Poisson Pareto Burst Process (PPBP)

A number of studies have shown that a range of bursty traffic sources supply a significant part of the traffic carried on broadband networks. One possible source of this burstiness [62] was in the aggregation of independent on-off sources with heavy-tailed on and/or off time distributions. A process such as the PPBP could be considered a limiting case for the multiplexing of a large number of such independent heavy-tailed on-off sources. Thus the PPBP appears a natural candidate for the modeling of bursty packet data traffic streams [17].

2.4 Load measurements

An objective in managing next generation networks is the efficient use of network resources. Recent advances in protocol development are trying to transform the Internet from a pure best-effort service into a network with ability of supporting QoS which increases the flexibility of networks in handling traffic with different performance requirements, but they also increase the complexity of network management and dimensioning [55]. To support QoS guarantees we might encounter the questions like:

• What combinations of users can a network provider accept while ensuring some target level of performance?

• How many more users can the provider accept if he increases the capacity of his network, introduces priority scheduling, or shapes incoming traffic?

• How can a user select the parameters of his traffic contract or service level agreement (SLA) with his provider?

To answer the aforementioned questions, researchers might employ network traffic measurement as a methodology to collect detailed information about transmission of packets on the network including timing structure and contents, to analyze data relevant to operation and performance of network protocols and to realize what is/isn’t working properly on a LAN or WAN [54].

Network measurement entails robust statistics collection and systems development [53]. For instance, to ensure that the QoS objectives have been met, performance measurements and performance monitoring are required so that real-time traffic control actions, or policy-based actions, can be taken.

Measurement is also critical to the optimization function because it provides feedback data which is used by traffic engineering control subsystems [52]. This data is used to adaptively optimize network performance in response to events and stimuli originating within and outside the network.

We should consider the following questions to develop a measurement system:

• Why is measurement needed in this particular context?

• What parameters are to be measured?

• How should the measurement be accomplished?

• When should the measurement be performed?

• How frequently should the monitored variables be measured?

• What level of measurement accuracy and reliability is desirable?

• What level of measurement accuracy and reliability is realistically attainable?

• To what extent can the measurement system permissibly interfere with the monitored network components and variables?

• What is the acceptable cost of measurement?

The answers to these questions will determine the measurement tools and methodologies appropriate in any given traffic engineering context. Following subsections address different network measurement methodologies [53]:

• Hardware-based vs. Software-based Measurement Tools

Hardware-based network traffic analyzers are special-purpose equipments which are employed to collect and analyze network data. Depending on the number of network interfaces, types of network cards, and the protocol analysis capabilities, the price of network analyzers are different but rather expensive. NavTel IW95000 ATM network traffic analyzer [54] is an example of hardware-based network analyzer. Moreover there are a plenty of hardware packet analyzers in [6], such as Agilent , InMon sFlow Probe, LinkView, SnifferPro.

Chapter 2 - State of the Art 17

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

Software-based measurement tools typically rely on kernel-level modifications or developing new components with packet capture capability over networks. One widely used utility is tcpdump, a user-level tool for TCP/IP packet capture, made possible with the Berkeley Packet Filter (BPF). Unlike hardware network analyzers, the software-based approach is not expensive, but may not offer the same functionality and performance as a dedicated network traffic analyzer. According to [6] EtherPeek, ettercap, hping, LanExplorer, LANQuest Net/WRx, CoralReef, Cricket, Pipechar, and Ethereal are software based network analyzer examples.

• On-line vs. Offline Traffic Analysis

Some network traffic analyzers, mostly hardware-based network analyzers, support real-time collection and analysis of network data (e.g LinkView , EtherPeek and LAN traffic monitor – RT) [54]. In other network measurement devices collection of data is carried out in real- time stage but the analysis is postponed to an off-line state (e.g tcpdump utility) falls into this category. Once the traffic data is collected and stored, a researcher can perform as many analyses as desired in the post-processing phase.

2.5 Load generators

As we mentioned earlier, with growing usage of computer networks, performance evaluation of networks has become an important field of study. Any performance evaluation study requires understanding how various components will perform under heavy loads and ensure that the system behaves appropriately. One approach to measure the QoS performance is to use workload testing based on actual customer behavior. The load generator denotes hardware and /or components which create an artificial load within one or more network nodes [66] that mimics user behavior, for instance to evaluate QoS of a Web Site, load generator continuously submits requests to the Web site, waits for a period of time after the site sends a reply to the request (the think time), and then submits a new request [64]. The load generator can emulate thousands of concurrent users to test Web site scalability. In fact communication scenarios that are complex and time consuming to

model, such as complex protocol behaviors and complex/realistic traffic patterns are suitable for studies by emulation.

Each emulated browser is called a virtual user, which is a key load-testing concept. A load test is valid only if virtual users’ behavior has characteristics similar to those of actual users [64]. We must therefore ensure that virtual users follow patterns similar to real users, use realistic think times, and react like frustrated users, abandoning a Web session if response time is excessive. Following are several circumstances which call for load testing [64]:

• Server components for popular Web sites need to respond to millions of requests per day.

• We anticipate a significant traffic increase to our site following a marketing campaign. In place of what is now a peak of 2,000 session starts per hour, we’re expecting twice that.

Currently, our dial-up customers experience an average 6.5-second response time on search requests, the most critical e-business function. What will be the response time when the site’s load increases to 4,000 sessions per hour?

• We are adding new functionality to the site or redesigning Web pages. We must know how this will affect response time before our customers find out; doing so lets us detect potential performance problems and fix them before they occur. Another good time to perform load testing is when we plan to implement IT infrastructure changes.

communication scenarios that are complex and time consuming to model, such as complex protocol behaviors and complex/realistic traffic patterns. Protocol modeling issues include TCP timers, forward error correction by error correcting checksum, backward error correction by acknowledgements, packetization, segmentation/reassembly, control of TCP congestion window, including slow start and slow recovery, random early detection, and more.

Realistic traffic patterns can be generated by real traffic traces.

Artificial load generators could be classified as hardware-based and software-based load generators.

Hardware-based load generators are equipments which are employed to generate traffic, but expensive in updating stage when concerning new requirements, while software-based load generators could be modified and updated more conveniently according to the source codes

Chapter 2 - State of the Art 19

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

flexibility. Following are some examples of software-based load generators and hardware-based load generators.

• Software-Based Load Generators:

1. Webserver Stress Tool is a powerful HTTP-client/server test application designed to pinpoint critical performance issues in the web site or web server that may prevent optimal experience for the site's visitors. Webserver Stress Tool simulates different users accessing the website at the same time. This quickly and easily demonstrates the performance capabilities of the infrastructure under stress. By simulating the HTTP requests generated by hundreds or even thousands of simultaneous users, we can test the web server performance under normal and excessive loads to ensure that critical information and services are available at speeds the end-users expect [65].

2. Nsasoft Network Traffic Emulator generates IP / ICMP / TCP / UDP traffic from clients to server to stress test servers, routers and firewalls under heavy network load. It is a very simple and fast program which can simulate client activity. The tool is designed with a user- friendly interface and is easy to use [56].

3. DTM DB Stress is a utility for stress testing the server parts of information systems and applications, as well as Database Management Systems (DBMS) and servers themselves.

This tool is able to create and configure a continuous set of requests to the server of the Online Analytic Processing (OLAP) for query execution and Online Transaction Processing (OLTP) for adding, modifying and deleting data in the database types [58].

• Hardware-Based Load Generators:

1. The UWB Generator 320 is the world's first frame generator for WiMedia Ultrawideband and Certified Wireless USB protocols. It helps verify product and component reliability by generating reproducible traffic, timing and error scenarios [59].

2. The HP E4829B is a flexible cell /traffic generator and analyzer system for the functional verification and debugging of today’s complex cell-based communication designs. These include ATM switches, hubs, routers, chip sets and ASICs from parallel custom or UTOPIA interfaces [60].

According to the high price of hardware-based load generators and the restriction many load generators may have including: the low flexibility, generating traffic at specific interface, not providing any transformation mechanism for generating specific abstract sequence of requests moreover not applying a formal methodology for designing existing load, we will employ a software-based load generator named UniLoG (cf. Chapter 3). We use this tool (designed by [20]), in our study and in implementation of distributed load generation systems, which uses a formal method for specifying load models at a well-defined interface in communication system.

2.6 Summary

The intention of this chapter was to give an insight related to workload modeling, load measurement and load generator. Emphasis was given to accurate prediction and understanding the behavior of real system. We mentioned that to guarantee an acceptable level of QoS it is of major importance to use a model for capturing network features, attributes and characteristics. We compared analytical models with simulation models. The first one is represented by mathematical methods which may be easy to model but have limitation in complex and dynamic systems while the latter one uses computer programs to describe the system and places fewer restrictions on system. Moreover to have better understanding of load models, we presented different traffic models (e.g. Markov and Embedded Markov Models, MMPP, Voice Telephony Model, TES model and so forth). We also mentioned that, it is necessary to collect the information about transmission of packets on the Internet (refer to load measurement methodology) to analyze data relevant to operation and performance of network protocols. An alternative to evaluate the performance of network is to find out the behavior of system under heavy loads, therefore load generator is used to create artificial load within one or more network nodes which mimics user behavior under the given conditions. We will explain about the UniLoG load generator in further detail in the preceding chapter.

Chapter 3

The UniLoG Load Generator

3.1 Introduction

The need for telecommunication networks capable of providing communication services such as data, voice and video motivated to deliver an acceptable QoS level to the users, and their success depends on the development of effective congestion control schemes. In particular, many challenges must be faced with significant increasing size of networks as we observe to date (e.g. in the Internet). To optimize the performance of an existing network, a realistic and valid load generation tool is required. Since the network loads might vary over the time, the load generator should be developed in a flexible manner to reproduce these loads accurately [66]. This chapter addresses a unified methodology for artificial load generation as proposed in [20] based on a formal description technique which is a valid tool for QoS studies and can produce some accurate predefined traffic at different interfaces within the protocol hierarchy of computer networks. This methodology has been validated by means of implementing a prototype of such a load generator (UniLoG) which is capable of producing network traffic with different characteristics.

This chapter is organized as follows: Section 3.2 presents the reason that a load generator is employed in communication systems. In Section 3.3 we explain the prerequisites to design a load generator. The specification of MPEG-encoded Video load, as an example of describing load based on Formal Description Technique (FDT), is addressed in Section 3.4. We describe the architecture for a Unified Load Generator (UniLoG) in Section 3.5 and finally the last section summarizes the chapter.

3.2 The Reason We Need Load Generators

The complexity of network applications is growing rapidly which undergoes a huge expenditure either during the network management or (re) configuration phase. In order to avoid performance bottlenecks in the case of load variations, it is indispensable to understand and predict network behavior for various load scenarios. Therefore artificial load generators are of major importance because real applications typically can not be controlled in such a way that they produce exactly a predefined traffic [66].

3.3 Prerequisites to Design a Valid Artificial Load Generation

According to the complexity of today networks applications and issues regarding increasing the size of the network, elaborating an artificial load generator is quite a challenging task. So far we studied that to predict network behavior and complex real loads, an accurate load model is required (Cf.

Chapter 2), but to design an accurate artificial load generator which is responsible to act in a flexible manner under different situations we need not only a load model but also a formal method to specify the realistic load. With respect to the high percentage of workload which is directly induced by end- users in a communication system, the behavior of a user has direct influence on network’s load [20].

Therefore, a technique to describe the end-user behavior as a prerequisite for designing a valid artificial load generation is indispensable. We will explain in more details the foundation and requirements for an artificial load generator in the following subsections.

Chapter 3 – The UniLoG Load Generator 23

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

3.3.1 The Behavior of End-Users

In [66] and [20], the authors classified the user behaviors into the following types:

• Initializing or creating a first interaction with the service system,

• Preparing and generating requests,

• Waiting for the reactions of the service system,

• Terminating the generation of requests or ending the connection between the user and its service system.

3.3.2 Formal Description of Load Generation Process

In the formal load specification technique a user behavior automaton (UBA) U= {ϕi,ϕa,ϕb,ϕt, Tϕ } is denoted by an extended finite-state automaton based on a set of macro-states ϕ ={ϕi,ϕa,ϕb,ϕt} as illustrated by figure 3.1. Tϕ denotes the set of transitions between the macro- states [20], [66], [70].

ϕi: initial state, a load generation process always begins from this state.

ϕa: active state, comprises a number of member states in which requests can be generated.

ϕb: blocked state, where the user waits for the reactions of the service system.

ϕt: terminated state, a load generation process always ends at this state.

The arcs in the user behavior graph denote the probability of moving from one state to another one.

Figure 3.1: The set of the macro-states and the transitions between them (cf. [20])

Each macro-state consists of a set of LG-states (member-state). Initial and termination states consist of one LG-state (to start and stop the load generation process) while active-state and blocked-state might have different types of LG-states depending on the number of requests and on the waiting for a reaction of service system. Moreover each request may have different attributes according to the type of the request, e.g. a request of sending packets might have attributes such as “Packet-length”

and “Destination-address”. The attributes data types could be integer, char, real or other extended data types such as Port-Number and IP-address. The reader may refer to [20] and [66] to find more details.

So far we explained the UBA user model, macro-states and requests attributes, but the description technique mentioned above is still not a complete form of load specification, and there are some other essential components that have to be considered including demonstration of requests sequences, decision regarding the actual duration of requests generation and parameterization of requests attributes. We will explain the aforementioned points in further details in the following subsections.

3.3.2.1 Determination and Specification of Concrete Sequences of Requests

A sequence of requests is a finite list of requests which exactly reflects the sequential order of the requests generated by a user [20]. It is always of major importance to figure out which state would be the next state in a sequence of states or requests. Trace of requests can be obtained through:

• Observations of a real network for instance by means of load measurement which results in a predefined sequence of requests (Trace),

• Probabilistic methods, in which the next LG-state is determined by taking transition probabilities. If P_i (i=1,2,…,n and 0≤ < P_i <1) be the set of probabilities from one state (R_j) to all its adjacent (R₁, R₂,…R_n), then transition probabilities from R_j could be represented as (R₁,P₁) (R₂,P₂)….(R_n, P_n),

• Deterministic, the next LG-state is always a fixed state,

• Procedure method which can accept the current state as an input and return the next state as output.

Chapter 3 – The UniLoG Load Generator 25

Dalarna University Tel: +46-23-77 8000

Röda vägen 3 Fax: +46-23-77 8050

S-781 88 Borlänge - Sweden http://www.du.se

3.3.2.2 Determining Durations between Successive Request Generations (Trace of Durations of delays)

The duration of delay refers to either the delay between generating the requests in active- state (e.g.

a user needs a specific time to prepare his/her next request) or the delay of processing a system response in the blocked-state (e.g. the time takes to interpret the previous system reaction). A trace of durations of delays consists of the sequence of inter-arrival times or delay mentioned before, which can be chosen by:

• Constant values when the duration of delay is not variable,

• Observation of a real network for instance by means of load measurements to produce a predefined sequence of delays (Trace),

• Probability Distribution the distribution of delay could be e.g. exponential distribution, log, normal distribution and so forth. For example, a Poisson process model can be characterized as a process whose inter-arrival times are exponentially distributed with rate parameterλ , that is, P {∆t ≤t} =1-exp (-λ t).

• Procedure method which returns the duration of delay using a procedure.

3.3.2.3 Actual Parameterization of Requests Attributes

Requests attributes can be parameterized according to their data types. To have a more flexible parameterization of requests attributes we use the methods we explained before, (Probability Distribution, Procedure, Constant, and Observation of real network), and to have more clear understanding of above-mentioned Formal load Description Techniques (FDT) we introduce an example of designing a load generator for MPEG-encoded video streams in the following section.

3.4 Specification of MPEG-encoded Video Load based on FDT

Video traffic is expected to be the major source of broadband integrated service digital network (B- ISDN). Due to the high bandwidth which is essential to transmit uncompressed video with high