Measurements and Models of One-Way Transit Time in IP Routers

MEASUREMENTS AND MODELS OF ONE-W A Y TRANSIT TIME IN IP R OUTERS

The main goals of this thesis are towards an un- derstanding of the delay process in best-effort Internet for both non-congested and congested networks. A novel measurement system is repor- ted for delay measurements in IP routers, which follows specifi cations of the IETF RFC 2679. The system employs both passive measurements and active probing and offers the possibility to mea- sure and analyze different delay components of a router, e.g., packet processing delay, packet trans- mission time and queueing delay at the output link.

Dedicated application-layer software is used to ge- nerate UDP traffi c with TCP-like characteristics.

The reported results are in form of several impor- tant statistics regarding processing and queueing delays of a router, router delay for a single data fl ow, router delay for multiple data fl ows as well as end-to-end delay for a chain of routers. They con- fi rm results reported earlier about the fact that the delay in IP routers is generally infl uenced by traffi c characteristics, link conditions and, to some extent, details in hardware implementation and

different IOS releases. The delay in IP routers may also occasionally show extreme values, which are due to improper functioning of the routers.

Furthermore, new results have been obtained that indicate that the delay in IP routers shows heavy- tailed characteristics, which can be well modeled with the help of several distributions, either in the form of a single distribution or as a mixture of distributions. There are several components contributing to the OWTT in routers, i.e., proces- sing delay, queueing delay and service time. The ob- tained results have shown that, e.g., the processing delay in a router can be well modeled with the Normal distribution, and the queueing delay is well modeled with a mixture of Normal distribution for the body probability mass and Weibull distri- bution for the tail probability mass. Furthermore, OWTT has several component delays and it has been observed that the component delay distribu- tion that is most dominant and heavy-tailed has a decisive infl uence on OWTT.

ABSTRACT

Blekinge Institute of Technology

Licentiate Dissertation Series No. 2005:14 School of Engineering

MEASUREMENTS AND MODELS OF

ONE-WAY TRANSIT TIME IN IP ROUTERS

Doru Constantinescu

ISSN 1650-2140

Doru Constantinescu

Measurements and Models of One-Way Transit Time in IP Routers

Doru Constantinescu

Karlskrona, October 2005

Department of Telecommunication Systems School of Engineering

Blekinge Institute of Technology

SE–371 79 Karlskrona, Sweden

Blekinge Institute of Technology

Licentiate Dissertation Series No. 2005:14 ISSN 1650-2140

ISBN 91-7295-072-2 Published 2005

Printed by Kaserntryckeriet AB Karlskrona, 2005

Sweden

This publication was typeset using L

TEX.

To my family

Abstract

The main goals of this thesis are towards an understanding of the delay pro- cess in best-effort Internet for both non-congested and congested networks. A novel measurement system is reported for delay measurements in Internet Pro- tocol (IP) routers, which follows specifications of the Internet Engineering Task Force (IETF) Request For Comments (RFC) 2679. The system employs both passive measurements and active probing and offers the possibility to measure and analyze different delay components of a router, e.g., packet processing de- lay, packet transmission time and queueing delay at the output link. Dedicated application-layer software is used to generate User Datagram Protocol (UDP) traffic with Transmission Control Protocol (TCP)-like characteristics. Pareto traffic models are used to generate self-similar traffic in the link.

The reported results are in form of several important statistics regarding pro- cessing and queueing delays of a router, router delay for a single data flow, router delay for multiple data flows as well as end-to-end delay for a chain of routers. They confirm results reported earlier about the fact that the delay in IP routers is generally influenced by traffic characteristics, link conditions and, to some extent, details in hardware implementation and different Internetwork Operating System (IOS) releases. The delay in IP routers may also occasionally show extreme values, which are due to improper functioning of the routers.

Furthermore, new results have been obtained that indicate that the delay in IP

routers shows heavy-tailed characteristics, which can be well modeled with the

help of several distributions, either in the form of a single distribution or as a

Way Transit Time (OWTT) in routers, i.e., processing delay, queueing delay and service time. The obtained results have shown that, e.g., the processing delay in a router can be well modeled with the Normal distribution, and the queueing delay is well modeled with a mixture of Normal distribution for the body probability mass and Weibull distribution for the tail probability mass.

Furthermore, OWTT has several component delays and it has been observed

that the component delay distribution that is most dominant and heavy-tailed

has a decisive influence on OWTT.

Acknowledgments

I would like to take this opportunity to express my appreciation and deep grat- itude to several persons for their contributions to this research and for their support and encouragement during this thesis work. First and foremost, I want to thank my adviser and examiner, Docent Adrian Popescu at the Department for Telecommunication Systems at Blekinge Institute of Technology (BTH) for his invaluable support and advice.

Special thanks go to my PhD colleagues at the Department for Telecommunica- tion Systems, especially to David Erman and Dragos Ilie for their humor, help and encouragement during this work.

I am also grateful to Professor Arne A. Nilsson for accepting me as PhD student and without whom this work would not have been possible.

Finally, I am greatly indebted to my wife, Carmen, and our children, Antonia and Rafael for enduring many hours away from them. I dedicate this work to them.

This research work was jointly supported by the Swedish Agency for Innovation Systems (VINNOVA) and BTH.

Doru Constantinescu

Karlskrona, October 2005

Acronyms

AD Anderson-Darling ACK Acknowledgment

ARP Address Resolution Protocol ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BTH Blekinge Institute of Technology CCDF Complementary Cumulative Dis-

tribution Function

CDF Cumulative Distribution Func- tion

DHCP Dynamic Host Configuration Pro- tocol

DUCK DAG Universal Clock Kit e2e end-to-end

EDF Empirical Distribution Function fBm fractional Brownian motion fGn fractional Gaussian noise FCFS First-Come-First-Served GPS Global Positioning System IP Internet Protocol

IID Independent and Identically Dis- tributed

ICMP Internet Control Message Proto- col

IETF Internet Engineering Task Force

IOS Internetwork Operating System IPPM IP Performance Metrics

IS-IS Intermediate System to Interme- diate System

ISP Internet Service Provider KS Kolmogorov-Smirnov LAN Local Area Network LLC Logical Link Control LRD Long-Range Dependence LST Laplace-Stieltjes Transform MLE Maximum Likelihood Estimation ML Maximum-Likelihood

MP Measurement Point MTU Maximum Transfer Unit NTP Network Time Protocol OSPF Open Shortest Path First OWTT One-Way Transit Time PDF Probability Density Function PIT Probability Integral Transform PPS Pulse-Per-Second

QQ Quantile-Quantile QoS Quality of Service RED Random Early Detection

RIP Routing Information Protocol RTP Real-time Transport Protocol RTT Round Trip Time

RTT Router Transit Time SHA-1 Secure Hash Algorithm One SLA Service Level Agreement SNMP Simple Network Management

Protocol

STL Standard Template Library TCP Transmission Control Protocol TTL Time-To-Live

UDP User Datagram Protocol UTC Universal Time Coordinated WAN Wide Area Network WG Working Group WFQ Weighted Fair Queueing

Contents

Page

1 Introduction 1

1.1 Related Work . . . . 2

1.2 Contribution of the Thesis . . . . 3

1.3 Outline of the Thesis . . . . 4

2 Traffic Measurements 7 2.1 Introduction . . . . 8

2.2 Active Measurements . . . . 8

2.3 Passive Measurements . . . . 9

2.4 Existing Solutions . . . . 10

2.5 The BTH Solution . . . . 13

3 Router Architecture 15 3.1 Introduction . . . . 16

3.2 IP Routing Algorithm . . . . 16

3.3 IP Routing . . . . 17

4 Delay Components 21

4.1 Introduction . . . . 22

4.2 OWTT Components . . . . 22

4.3 Queueing Delay in Chained IP Routers . . . . 24

5 Measurement Setup 27 5.1 Introduction . . . . 28

5.2 OWTT Measurements . . . . 28

5.3 Synchronization Issues . . . . 30

5.4 Packet Generation . . . . 31

5.5 Packet Identification . . . . 35

5.6 Estimation of OWTT and Router Delay . . . . 41

5.7 Sources of Errors . . . . 46

6 Traffic Modeling 49 6.1 Introduction . . . . 49

6.2 Long-Range Dependence . . . . 50

6.3 Self-Similarity . . . . 51

6.4 Heavy-Tailed Distributions . . . . 53

6.5 Traffic Models in Packet Networks . . . . 54

7 Modeling Methodology 57 7.1 Introduction . . . . 58

7.2 Distribution Selection . . . . 58

7.3 Parameter Estimation . . . . 61

CONTENTS

7.4 Goodness of Fit . . . . 64

7.5 Fitness Assessment . . . . 67

7.6 Power Spectrum . . . . 68

8 Experiments 71 8.1 Introduction . . . . 71

8.2 Router Delay for a Single Data Flow . . . . 72

8.3 Router Delay for Multiple Data Flows . . . . 74

8.4 End-to-End Delay for a Chain of Routers . . . . 75

9 Delay Performance 77 9.1 Processing Delay of a Router . . . . 77

9.2 Router Delay for a Single Data Flow . . . . 81

9.3 Router Delay for Multiple Data Flows . . . . 88

9.4 End-to-End Delay for a Chain of Routers . . . . 95

9.5 Comments on Modeling Results . . . 105

10 Lessons Learned 109 10.1 The Kleinrock Independence Assumption . . . 109

10.2 Packet Size . . . 110

10.3 End-to-End Delay . . . 111

10.4 Router Delay . . . 113

11 Conclusions 115

11.1 Contributions . . . 116

11.2 Future Work . . . 117

Bibliography 119

List of Figures

Figure Page

3.1 Router architecture . . . . 19

4.1 Tandem queueing . . . . 24

5.1 Measurement setup . . . . 29

5.2 Packet generation: Timing issues . . . . 32

5.3 Packet payload data structure . . . . 33

5.4 SHA-1 hashing . . . . 36

5.5 Matching software flowchart . . . . 40

5.6 Example of output file . . . . 41

5.7 Timestamping a packet . . . . 42

5.8 Router delay model . . . . 43

6.1 Example of Ethernet traffic with different Hurst parameters . . . 52

7.1 Example of a finite mixture distribution . . . . 60

8.1 Measurement setup: Router delay for a single data flow . . . . . 74

8.2 Measurement setup: Router delay for multiple data flows . . . . 75

8.3 Example of traffic collected and associated histograms . . . . 76

9.1 Router processing delay for ICMP and UDP payloads . . . . 78

9.2 Router processing delay for ICMP payloads with different sizes . 78 9.3 Router processing delay for UDP payloads with different sizes . . 78

9.4 Minimum processing delay obtained in experiment 1-3 . . . . 79

9.5 Minimum processing delay obtained in experiment 1-7 . . . . 79

9.6 Results obtained in experiment 1-9 and associated histograms . . 83

9.7 Delay distributions obtained in experiment 1-9 . . . . 84

9.8 Modeling of delays obtained in experiment 1-9 . . . . 86

9.9 Contribution of delay components in experiment 1-9 . . . . 87

9.10 Results obtained in experiment 1 on power spectrum . . . . 88

9.11 Results obtained in experiment 2-5 and associated histograms . . 90

9.12 Delay distributions obtained in experiment 2-5 . . . . 91

9.13 Modeling of delays obtained in experiment 2-5 . . . . 92

9.14 Contribution of delay components in experiment 2-5 . . . . 93

9.15 Results obtained in experiment 2 on power spectrum . . . . 95

9.16 Results obtained in experiment 3-7 and associated histograms . . 96

9.17 Delay distributions obtained in experiment 3-7 at router R1 . . . 98

9.18 Delay distributions obtained in experiment 3-7 at router R2 . . . 99

9.19 Delay distributions obtained in experiment 3-7 at router R3 . . . 100

9.20 OWTT distributions obtained in experiment 3-7 . . . 104

LIST OF FIGURES

9.21 Results obtained in experiment 3-7 on power spectrum . . . 104

9.22 Summary of measured OWTT performance . . . 106

10.1 OWTT vs Exponential . . . 111

10.2 e2e OWTT in experiment 3-7 . . . 113

10.3 Convolution of delay components in experiment 1-9 . . . 114

List of Tables

Table Page

7.1 Boundaries for fitness quality . . . . 68

8.1 Summary of experiments and associated parameters . . . . 73

9.1 Summary of OWTT results for experiment 1 . . . . 82

9.2 Modeling results obtained for delays in experiment 1 . . . . 85

9.3 Summary of OWTT results for experiment 2 . . . . 89

9.4 Modeling results obtained for delays in experiment 2 . . . . 94

9.5 Summary of OWTT results for experiment 3 . . . . 96

9.6 Modeling results obtained for delays in experiment 3 at R1 . . . 101

9.7 Modeling results obtained for delays in experiment 3 at R2 . . . 102

9.8 Modeling results obtained for delays in experiment 3 at R3 . . . 103

9.9 Modeling results obtained for e2e OWTT in experiment 3 . . . . 105

Chapter 1

Introduction

The beginning of knowledge is the discov- ery of something we do not understand.

–

Frank Herbert

As the Internet emerges as the backbone of worldwide business and commercial activities, end-to-end (e2e) Quality of Service (QoS) for data transfer becomes a significant factor. One-way delay is a key metric in evaluating the performance of networks as well as the QoS perceived by end users. Today, network capac- ities are being deliberately overprovisioned in the Internet so that the packet loss rate is very low. Throughput maximization can be done by minimizing the e2e delay. However, given the heterogeneity of the network and the fact that the overprovisioning solution is not adopted everywhere, especially not by back- bone teleoperators in developing countries, the question arises as to how the delay performance impacts the e2e performance. There are several important parameters that may impact the e2e delay performance in the link, e.g., traffic self-similarity, routing flaps and link utilization [46, 58].

Understanding the network traffic characteristics is of crucial importance for

proper design of network algorithms such as routing and flow control, dimension-

ing of buffers, link capacity as well as for choosing realistic network parameters

in simulations and analytic studies. QoS still remains one of the biggest chal- lenges in IP networking and in Internet in general. The goal is to satisfy different service requirements while sharing the same infrastructure. That is, QoS offers the ability to define qualitative (e.g., desired class of service) or quantitative (e.g., bandwidth) attributes for the particular network service provided.

One-way delay is an important QoS parameter. It is defined by both the IETF (One Way Delay for IP Performance Metrics) and the International Telecom- munications Union - Telecommunications Standardization (IP Packet Transfer Delay). In both cases it relies on time-sensitive parameters and time synchro- nization of both sender and receiver is required.

1.1 Related Work

Several papers report on e2e delay performance, and both Round Trip Time (RTT) and OWTT are considered [10, 15, 58, 62]. Traffic measurements based on both passive measurements and/or active probing are used. In general, RTT measurements are simpler but the analysis is more complex due to different problems related to clock synchronization, packet timestamping, protocol com- plexity, asymmetries in direct and return paths as well as path variations [15].

Other problems related to difficulties in measuring queueing delays in opera- tional routers and switches further complicates the picture [58].

As a general comment, it has been observed that both RTT and OWTT show large ”peak-to-peak” variations, in the sense that maximum delays far exceed minimum delays. It has for instance been observed that a range of more than 10:1 in RTTs seems to be common; most connections however seem to show RTTs between 15 and 500 s [29]. Further, it has been observed that OWTT variations (for opposite directions) are asymmetric in most cases, with different delay distributions, and they seem to be correlated with packet loss rates [62].

Periodic delay spikes and packet losses have been also observed, which seem to

be a consequence of routing flaps [58]. Typical distributions for OWTT have

been observed to have a Gamma-like shape and to possess a heavy-tail [10, 51].

1.2. CONTRIBUTION OF THE THESIS

The parameters of the Gamma distribution have been observed to depend upon the path (e.g., regional, backbone) and the time of day. The heavy-tail behavior is due to the presence of self-similarity in Internet traffic [9]. Furthermore, typical queueing models like M/M/1, M/G/1 and using fractional Brownian motion (fBm) models have been shown to underestimate average queueing delays for link utilization below 70% [58].

1.2 Contribution of the Thesis

The main goals of the thesis are towards an understanding of the delay process in best-effort Internet for both non-congested and congested networks. A novel measurement system that enables delay measurements in IP routers has been designed at Blekinge Institute of Technology (BTH), which follows specifications of the IETF RFC 2679 [3, 18]. The system uses both passive measurements and active probing.

Dedicated application-layer software is used to generate UDP traffic with TCP- like characteristics. The well-known interactions between TCP sources and net- work are thus avoided [33, 77]. UDP is not aware of any network congestion, and this gives the choice of doing experiments where the focus is on the network only and not on terminals. The software consists of a client and a server run- ning on two different hosts, which are separated by a number of routers. Pareto traffic models are used to generate self-similar traffic in the link. Both packet interarrival times and packet sizes are matching real traffic models [37].

A passive measurement system is used for data collection that is based on using several so-called Measurement Points (MPs), each equipped with DAG monitor- ing cards [6, 21]. Hashing is used for the identification and matching of packets.

The combination of passive measurements and active probing, together with us- ing the DAG monitoring system, gives an unique possibility to perform precise traffic measurements as well as the flexibility needed to compensate for the lack of analytic solutions.

The real value of this study lies in the hop-by-hop instrumentation of the devices

involved in the transfer of IP packets. The mixture of passive and active traffic measurements allows to study changes in traffic patterns relative to specific reference points and to observe different contributing factors to the observed changes. This approach offers the choice of better understanding the various components that may impact on the performance of OWTT as well as measuring queueing delays in operational routers.

The reported results in the thesis are in form of several important statistics regarding processing and queueing delays in IP routers. They confirm results reported earlier about the fact that the delay in IP routers is generally influ- enced by traffic characteristics, link conditions and, to some extent, details in hardware implementation and different IOS releases. Different delay compo- nents contributing to the OWTT in IP routers, i.e., processing delay, queueing delay and service time are reported as well.

Furthermore, the thesis reports new results that indicate that the delay process in IP routers exhibits heavy-tailed characteristics, which can be well modeled with the help of several distributions, either in the form of a single distribution or as a mixture of distributions. The results have shown that, e.g., the processing delay in a router can be well modeled with the Normal distribution while the queueing delay is well modeled with a mixture of Normal distribution for the body probability mass and of Weibull distribution for the tail probability mass.

It has been also observed that OWTT is well modeled in this case with the Generalized Pareto distribution. OWTT has several component delays and it has been observed that the component delay distribution that is most dominant and heavy-tailed has a decisive influence on the OWTT properties.

1.3 Outline of the Thesis

The thesis is organized as follows. Chapter 2 provides a short review of traf-

fic measurement methodologies. Chapter 3 describes the architecture of an IP

router and the associated hardware components. Chapter 4 describes the de-

lay components associated with OWTT in a chain of IP routers. A model for

1.3. OUTLINE OF THE THESIS

single-hop delay analysis is provided in Chapter 5 together with the measure- ment system and the technology used for collecting data. A discussion on the implementation as well as the accuracy and the limitations of the system is provided as well. Chapter 6 gives a short explanation of important concepts used in traffic modeling followed by some examples of existing traffic models.

Chapter 7 describes the goodness-of-fit statistics as well as the traffic modeling

approach used in this thesis. Chapter 8 illustrates the experiments done and

reports on specific details related to these experiments. Chapter 9 is dedicated

to reporting the results obtained on different components contributing to router

delay. Chapter 10 presents some interesting observations regarding the per-

formed experiments. Finally, Chapter 11 concludes the thesis with an overview

of the thesis contributions and planned future work.

Chapter 2

Traffic Measurements

Measure what is measurable, and make measurable what is not so.

–

Gottlob Frege

Network traffic monitoring and measurement is increasingly regarded as an es- sential function in developing and supporting high-quality network services as well as analyzing trends in network traffic and user behavior. In order to sup- port QoS-enabled services, traffic engineering and network monitoring is needed to provide the necessary feedback to operators in an efficient fashion.

In this chapter, the main approaches to traffic measurements are presented.

Advantages and disadvantages of these methods are discussed. Furthermore, some of the most widely used tools for network traffic monitoring are presented.

The monitoring software developed by the Telecommunications research group

at Blekinge Institute of Technology (BTH) is also introduced in this chapter.

2.1 Introduction

Traffic measurements are crucial in the development, optimization and testing of innovative networking technologies by providing important metrics related to network infrastructure, traffic patterns and overall network performance. The need for reliable information from the network infrastructure may be motivated by several reasons such as offering an Internet Service Provider (ISP) the ability to:

• better forecast resource requirements meeting thus, newer business de- mands.

• verify and implement effective security policies.

• verify and measure Service Level Agreements (SLAs).

• utilize better network resources.

Generally, network traffic monitoring reduces to two basic approaches: active probing and passive traffic measurements. The main difference between these two methodologies lies in the way traffic monitoring is done.

2.2 Active Measurements

Active probing can be regarded as the process of creating and injecting pre-

defined, artificial packets, into the network under study. These packets can be

captured and timestamped with the help of various capturing software, e.g.,

tcpdump [79]. Different delay metrics (e.g., minimum delay, maximum delay,

delay variance, probability distribution function) can be calculated. The main

drawback is related to the potential distortion and interference of the injected

traffic with real traffic. If, for instance, too much artificial traffic is inserted into

the network, this could lead to an overload situation and the obtained results are

no longer relevant for the network under study. Such situations must be care-

fully considered when the measurements are conducted under periods of high

2.3. PASSIVE MEASUREMENTS

network load. Active measurements are however very useful for traffic engineer- ing purposes and for other tasks such as network operation and performance debugging.

Some of the most popular examples of active probing approaches include the well-known programs ping [64] and traceroute [34] that measure hop-by-hop link capacities, loss rates and packet delay [39]. However, these tools were not originally designed for measurement purposes and the consequence is that they are not suitable for measuring packet delay at the router level. The main limitations are the risk of:

• changing the path followed by successive probe packets (and addressed to the same destination).

• false routes.

• denial of service attacks (ping of death).

• protocol filtering (due to denial of service attacks).

Furthermore, these tools have limited clock support with the consequence of difficulties for reliable measurements of packet delay (e.g., need for Global Po- sitioning System (GPS)).

2.3 Passive Measurements

In the case of passive measurements no artificial traffic is generated, with the consequence of no interference with existing network traffic. Passive measure- ments rely instead on directly capturing the traffic at the link layer at particular points in the network. This approach often uses specialized capturing hardware, e.g., DAG-cards [21].

By essence, passive monitoring involves tapping the link of interest and record-

ing either complete packets or packet headers only, together with timestamps

indicating the arrival times. Further, traffic monitoring and analysis can be done

either at the packet level, or at the aggregate level. In the first case specific met- rics at the packet levels are relevant (e.g., e2e delay per packet), whereas in the second case aggregate metrics are considered (e.g., throughput per traffic flow).

An important aspect to be considered in this case is related to storage require- ments. A passive measurement tool often needs large amounts of storage ca- pacity. As such a passive tool usually has the possibility of capturing every packet on the link, the storage requirements might grow fast; on the order of tens and hundreds of gigabytes or even terabytes of storage capacity. The ac- tive measurement approach scales much better with respect to storage as the requirement in this case is often much lower since it captures only the injected traffic.

Another important aspect to be considered when doing traffic monitoring is re- lated to user privacy. In the case of passive measurements, the captured traffic contains real user data. This is a major source of difficulty when trying to mon- itor an operational network. Some of the privacy concerns can be overcomed by eliminating unnecessary data from the captured packets and by anonymization of the monitored IP addresses. The active probing approach is however not affected by this issue as it generates and captures its own traffic.

2.4 Existing Solutions

2.4.1 Passive Approach

When single point monitoring is employed, passive measurements allow only for

collecting traffic with a limited set of parameters. Some of them, like amount of

transferred data or link utilization, are important for describing particular data

flows on the monitored network segment. However, these are in principle not

viewed as QoS parameters. On the other hand, bandwidth can be considered

QoS parameter and for particular protocols, e.g., TCP or Real-time Transport

Protocol (RTP), packet loss can be monitored. Delay and delay variation for

some specific path can be assessed only in the case of simultaneous monitor-

2.4. EXISTING SOLUTIONS

ing at both ends of this path. When passive monitoring is used, data can be collected at the network layer and submitted via the Simple Network Manage- ment Protocol (SNMP) protocol [50]. Alternatively, proprietary solutions, like CISCO NetFlow [53], have been deployed for this purpose. Large sets of tools for analyzing Netflow output are available today, e.g., CAIDA Cflowd [14].

Data capturing and analysis are two independent operations and therefore it is desired to store the traffic traces in a common format. For instance, in the project Passive Measurement and Analysis [57], three formats are used:

fr, crl and tsh. All these formats preserve both the IP and TCP header.

The crl format is oriented towards the Asynchronous Transfer Mode (ATM) technology and preserves the ATM cell header and the Logical Link Control (LLC) information as well.

Capturing data at a high-speed line brings new challenges for broadband links like OC-48 (2.5 Gbit/s) or OC-192 (10 Gbit/s), as they exceed the capacity of the 64-bit PCI bus. To avoid bus limitation issues, intelligent data filtering, aggregation and compression should be integrated directly into a specialized capturing adapter. Requirements on the design principles of such adapters are described in [16]. An example of such solution is the DAG project [21], which develops hardware and software analysis tools capable of providing real-time monitoring of high performance optical networks.

Another method of passive measurement is regarding traffic monitoring done directly in the workstation. Such tools allow for examining data from a live network and often provide both analysis and statistics of the monitored traffic.

However, they do not deal with QoS parameters. NTOP [56], libpcap [47] and Ethereal [25] can be mentioned as complex tools of this type.

2.4.2 Active Approach

There are several tools used for active measurements of network parameters.

Probably the most common and best known tool is ping [64], which measures

reachability, round-trip delay, packet loss ratio, maximum, minimum and av-

erage round-trip delay. The measurements can be done for arbitrary packet

sizes. Another useful tool is netperf [54], which measures path throughput for both UDP and TCP and packet loss ratio for UDP. Yet another tool is RUDE/CRUDE [71], which consists of a pair of programs for one-way delay, one- way delay variation and packet loss measuring. It uses UDP as a transport protocol.

It is mentioned again that the main problem connected with the active measure- ment approach is the invasive character. It affects the behavior of the network under study, making the design and operation of active measurement tools a non-trivial problem. The interpretation of the obtained results must be done carefully in order to avoid incorrect interpretation of the monitored traffic. Sev- eral projects dealing with active measurements are worth mentioning. The pri- mary metric of interest for these projects is always the measurement of the one-way delay.

• AMP - Active Measurement Project [5]: project of NLANR (National Laboratory for Applied Network Research). There are currently about 130 AMP monitors collecting data. Three types of measurements are currently available: RTT, loss and topology. The tests are continuously run on all AMP monitors. The tests are also done to a number of other sites where the site managers have agreed to accept this traffic. The data from these monitors is available through several interfaces: a Web interface, as animations viewable by web browser and as raw data.

• RIPE TTM: The Test Traffic project [70] is one of the activities proposed

by RIPE - (R´eseaux IP Europ´eens). The goal of the project is to indepen-

dently measure connectivity parameters, such as delays, losses and routing

vectors, in the Internet. The project implements the metrics designed by

the IP Performance Metrics (IPPM) Working Group (WG) [32]. In order

to measure the delays and determine the routing vectors, measurement

boxes (RIPE-boxes) are installed at each participating provider. These

boxes measure and collect the data. Data is then transferred to a central

machine at RIPE, where it is processed and made available to the project

partners. As the measurement of one-way delay requires clock accuracy

of 1 ms or better, each box has its own GPS receiver for synchronization

2.5. THE BTH SOLUTION

purposes.

• Surveyor: Project Surveyor [78] aims to measure the performance paths among participating organizations. It is based on IETF standards of the IPPM WG [32]. The infrastructure consists of measurement machines and a central database to which the results of the measurements are reported.

The measurement machines are running the BSD operating system and deployed at various locations around the world. Precise global time syn- chronization among the machines is achieved by using GPS. While the accuracy is important in the current wide area of network measurements, it becomes even more important when measuring performance between nodes in a high-speed network.

2.5 The BTH Solution

The Telecommunications research group at BTH has designed and developed a hybrid traffic measurement system for doing traffic measurements in IP best- effort networks [6, 17]. The system uses both passive measurements and active probing. It uses specialized commercial hardware to obtain accurate and high- precision traffic traces while the active probing is done with the help of dedicated application-layer software that generates artificial traffic with ”real-life” charac- teristics. The passive measurement system used for data collection is based on using several so-called Measurement Points (MPs), each of them equipped with DAG monitoring cards [6, 21].

Dedicated application-layer software is used to generate UDP traffic with TCP-

like characteristics. By doing so the well-known interactions between TCP

sources and the network are avoided (i.e., the TCP congestion avoidance mech-

anism [33, 77]). UDP is not aware of any network congestion and this gives

the choice of doing experiments where the focus lies on the network behavior

only and not on terminals. The traffic generating software uses the client-server

paradigm. The client and the server run on different hosts separated by a num-

ber of routers. Network traffic is generated such as packet interarrival times and

packet sizes matches real traffic models [37]. Pareto traffic models are used to generate self-similar traffic at the link level.

An important aspect is regarding the correct identification of packets present on multiple captured traces. Both hashing and masking is performed before pro- cessing the collected traffic traces. The hashing function is based on the Secure Hash Algorithm One (SHA-1) [72]. SHA-1 provides a very low probability of hash collision. The packet identification software, i.e., hashing and matching, is implemented in C/C++. In order to store all relevant information necessary for fast and accurate packet processing, the template containers defined by the Standard Template Library (STL) [52] are used.

The combination of passive and active measurements, together with the use of

a DAG monitoring system, provides a unique possibility of performing precise

traffic measurements as well as the flexibility needed to compensate for the lack

of analytic solutions.

Chapter 3

Router Architecture

The Internet is like a giant jellyfish. You can’t step on it. You can’t go around it.

You’ve got to get through it.

–

John Evans

The tremendous growth of Internet-based applications has triggered an unseen growth of network traffic as well. Consequently, this places enormous pressure on IP routers with regard to performance. The heterogeneity of Internet traffic puts very high demands on the network infrastructure and the router as they should meet several critical demands, e.g.,

• optimally utilize the underlying network capacity.

• scale quickly and cost effectively while minimizing the impact on the net- work.

• proper delivery of packets while minimizing packet loss along the network path.

This chapter provides a short overview of the routing process in IP routers. De-

tails of the router architecture for commonly available IP routers are presented.

Moreover, a brief presentation of an IP routing algorithm is provided.

3.1 Introduction

Routing is the process of moving packets from a source node to a destina- tion node (possibly in another network) across a previously determined path.

Routers are devices that connect heterogeneous physical networks by means of appropriate physical attachments. They differ from switches in the sense that the connected network types need not be the same. For instance, a router can be used to connect only Local Area Networks (LANs), or only Wide Area Networks (WANs) or combinations of LANs and WANs.

There are two basic functions performed by a router. They are:

• Routing, i.e., using route advertisements to acquire the knowledge to cre- ate a routing table for path determination that is used by the forwarding protocol.

• Datagram forwarding, i.e., using the routing table to make a forwarding decision from a specific input port to a specific output port.

3.2 IP Routing Algorithm

Path determination means that some specific criteria is used to determine opti-

mal routes for specific paths; source node 7→ destination node. Dedicated routing

algorithms are used to initialize and maintain routing tables, where the route

information depends upon the routing algorithm used. One or more routing

protocols may be used for path determination, such as for instance Routing

Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate

System to Intermediate System (IS-IS) and Border Gateway Protocol (BGP),

in the case of IP routing. These are dynamic protocols that provide exchange of

routing information among routers as well as help routers to convert the routing

3.3. IP ROUTING

information into a routing table. The content of routing tables is updated when changes in topology and, eventually, traffic occur. Compared to static routing (where routing tables are constructed manually or from a file at boot time), dynamic routing is advantageous because the routing tables are created auto- matically based on a specific routing metric (e.g., link cost, bandwidth, number of hops, delay) and network conditions.

On the other hand, the procedure of datagram forwarding is used by routers to determine where to forward the datagram for the next hop. This is done by first examining the header of datagram (received on some specific input port), determining then the output port of the next hop, sending the datagram to the output port (through the internal switch fabric), changing the destination physical address (in the header of datagram) to the one of the next hop, and finally transmitting the datagram. As the datagram traverses the Internet, the physical addresses change but the IP addresses remain unchanged.

Algorithm 1 illustrates the procedure used for the routing of IP datagrams for both routers and hosts [18]. There are several entities that may be used to solve the routing task, namely Address Resolution Protocol (ARP), ARP cache, specific routing protocols and default routes.

IP routers often incorporate more than two network interfaces. Usually, they have a hardware component (to handle physical and data link layer protocols) and another hardware and software component (to handle network layer pro- tocols). The routers must be able to cope with a variety of differences among networks regarding, e.g., addressing schemes, Maximum Transfer Unit (MTU) sizes, and interfaces. Figure 3.1 shows an example of a router architecture [44].

3.3 IP Routing

The input port has a part containing physical layer functions of terminating the

input physical link to the router. The next part handles the data link layer

functions needed to inter-operate with the data link layer at the opposite side

of the input link and to unencapsulate the incoming datagram from the link

Algorithm 1 Routing IP Datagrams

preparation: Extract Destination IP address (D) from the Datagram (PKT) and compute the Network Prefix (NetId) by bitwise-AND of D and Subnet Mask (SM)

if NetId matches any directly connected network address (own interface) then

deliver PKT to destination D over that network (this involves resolving D to a physical address with the help of ARP or ARP cache, encapsulating PKT and sending the frame)

else if Routing Table (RT) contains a host-specific route for D then send PKT to the next-hop router specified in RT

else if RT contains a route for the network NetId then send PKT to the next-hop router specified in RT

else if RT contains a default route for network NetId then send PKT to the default router specified in RT

else

declare a routing error end if

layer frame. Finally, there is a third part containing network layer lookup and forwarding functions used to forward the datagram through the switch fabric to the specific output port. Practically, one or multiple ports are gathered together on a single line card that serves one or more physical ports.

The output port has similar parts and performs the reverse data link layer and physical layer functionality of the input port. It encapsulates the datagram in the outgoing frame according to the specific hardware format of the next hop.

The output port also stores the datagrams that are sent to the same next hop

and forwarded through the switch fabric. The part containing queueing and

buffer management functions has a packet scheduler associated with it, with

the help of which specific packets waiting in the queue to be served are selected

for transmission. Different scheduling policies may be used, e.g., First-Come-

First-Served (FCFS) for best-effort services, Weighted Fair Queueing (WFQ)

3.3. IP ROUTING

Switch fabric Routing processor

Physical Layer processing

Data Link Layer processing

Network Layer processing

Physical Layer processing

Data Link Layer processing

Network Layer processing

Network Layer processing

Data Link Layer processing

Physical Layer processing

Network Layer processing

Data Link Layer processing

Physical Layer processing Input port 1

Input port N

Output port 1

Output port N

Figure 3.1: Router architecture

for services with QoS guarantees [44]. Furthermore, active queue management algorithms are used to implement packet dropping and marking policies in the case of buffer overflow, e.g., Random Early Detection (RED) [18].

The routing processor is used to execute specific routing protocols, maintain the routing tables as well as to perform functions related to network management.

The switch fabric provides the switching function needed in a router to con- nect the input ports to the output ports. Switching can be accomplished in different ways, e.g., via shared memory, shared bus or crossbar/interconnection network. Switching via shared memory has a throughput limited by the memory bandwidth, so fast memory is typically used in this case. Shared bus has the throughput performance limited by the system bus bandwidth, and bus band- widths of over 1 Gbps are possible today. Higher performance may be obtained with crossbar switching, with bandwidths up to 60 Gbps.

Generally, there are two types of IP routers with reference to the implementation

of packet forwarding, each of them with own advantages and drawbacks. These

are of the type centralized and distributed forwarding model. In the centralized

model, the algorithm of datagram forwarding is done in a single processing mod-

ule, which handles the traffic from all input ports. In the case of the distributed

model the algorithm of datagram forwarding is done on several processing mod-

ules, in most cases one per port or one per line card. The distributed model

has the capability of forwarding more datagrams per second through the router,

simply because of the presence of more processing power. The drawback is how-

ever that the software architecture is more sophisticated due to the need for

every forwarding module to have its own routing table. That means a higher

burden is placed on the routing processor to consistently update the routing

tables.

Chapter 4

Delay Components

Defer no time; delays have dangerous ends.

–

William Shakespeare

In today’s operational Internet there are several metrics closely related to the performance and reliability of the underlying networks. According to RFC 2679 [3], the measurement of one-way delay, as opposed to round-trip delay, is motivated by several important factors: i) asymmetric paths, ii) asymmetric queueing for symmetric paths, iii) asymmetric application performance require- ments and iv) asymmetric provisioning for direct and reverse paths in QoS- enabled networks.

These factors have major implications on the performance of real-time applica- tions as these types of application usually have tight constraints for the max- imum value for e2e delay. Another implication is the effect e2e delay has for instance on the behavior of TCP congestion avoidance mechanism [77] in the sense that higher values for the e2e delay would trigger the mechanism having thus a negative impact on the e2e bandwidth utilization.

This chapter introduces important elements regarding the delay components of

the OWTT. The notions introduced in this chapter will be used throughout the thesis. Furthermore, a discussion on the issues related to the queueing delay in chained IP routers is also given.

4.1 Introduction

OWTT is measured by timestamping a specific packet at the sender, sending the packet into the network, and comparing then the timestamp with the timestamp generated at the receiver [3]. Packet timestamping can be done either in software (for the case of delay measurements at the application level) or in hardware (for the case of delay measurements at the network level), in which case special hardware is used.

Clock synchronization between the sender and the receiver nodes is important for the precision of one-way delay measurements. On top of that, delay measure- ments at the application level are sensitive to possible uncertainties related to the difference between the ”wire time” and the ”host time” as well. ”Wire time”

is defined as being the time difference between the moment when the last bit of the packet leaves the network interface of the sender and the moment when the last bit of the packet completely arrives at the network interface at receiver [3].

If timestamping is done by software, these timestamps can be measured only after the software just sends alternatively receives respective packet. This is referred to as ”host time”.

4.2 OWTT Components

The OWTT has several components:

OW T T = D

+

N

X

i=0

D

(4.1)

where the delay per node i, D

is given by:

D

= D

+ D

+ D

(4.2)

4.2. OWTT COMPONENTS

The components are as follows:

• D

is the total propagation delay along the physical links that make up the Internet path between the sender and the receiver. This time is solely determined by the properties of the communication channel and the distance between hosts. It is independent of traffic conditions on the links.

• N is the number of nodes between the sender and the receiver.

• D

is the transmission time for node i. This is the time it takes for the node i to copy the packet into the first buffer and to serialize the packet over the communication link. It depends on the packet length and is inversely proportional to the link speed.

• D

is the processing delay at node i. This is the time needed to process an incoming packet (e.g., to decode the packet header, to check for bit errors, to lookup routes in a routing table, to recompute the checksum of the IP header) and the time needed to prepare the packet for further transmission, on another link. This delay depends on parameters like network protocol, computational power at node i, and efficiency of network interface cards.

• D

is the queueing delay at node i. This delay refers to the waiting time in the output buffer, and depends upon traffic characteristics, link conditions (e.g., link utilization, interference with other IP packets) as well as implementation details of the node. For this thesis, only routers with a best-effort service model are considered, i.e., routers where an output port is modeled as a single output queue.

Statistics like mean, median, maximum, minimum, standard deviation, variance

and peakedness are commonly used in the calculation of delay for non-corrupted

packets. Typical values obtained for OWTT range from tens of µs (between

two hosts on the same LAN) to hundreds of ms (in the case of hosts placed in

different continents) [12].

For a general discussion, the OWTT delay can be partitioned into two compo- nents, a deterministic delay D

and a stochastic delay D

:

OW T T = D

+ D

(4.3)

D

, D

and (partly) D

are contributing to the deterministic delay D

, whereas the stochastic delay D

is created by D

and, to some extent, D

. The stochastic part of the router processing delay can be observed especially in the case of low and very low link utilization, i.e., when the queueing delays are minor.

4.3 Queueing Delay in Chained IP Routers

An important delay component in IP networks is the queueing delay in routers or switches. This is especially important in the case of real-time services due to the upcome of jitter that may appear in the case of large queueing delays in routers. It is therefore important to measure and model queueing delays in routers as well as possible correlations that may appear between, e.g., ser- vice times at neighboring routers. In packet-switched networks, there may be many transmission queues (part of output ports in routers) that may interact with each other in the sense that a traffic stream leaving a queue enters others queues, likely after merging with other traffic streams coming from other queues (Figure 4.1).

Figure 4.1: Tandem queueing

The direct effect of traffic merging in packet networks is that the character of

the arrival process at a downstream queue changes. Since the same packet visits

each queue in a tandem queueing system, the service times of each packet at the

4.3. QUEUEING DELAY IN CHAINED IP ROUTERS

visited successive queues are typically positively correlated. Furthermore, given that the service times at two queues are dependent, the packet interarrival times become correlated with packet lengths at the downstream queue as well. Long packets typically wait less than short packets at a downstream queue, which is because they need longer time for service at the upstream queue and therefore the downstream queue has more time to empty out. An analogy is a slow truck traveling on a narrow street, with one track only. The truck will typically have empty space ahead but faster cars following behind the truck. Simulation studies have shown that in real situations, when interarrival times and service times are strongly correlated, the average delay per packet at the downstream queue tends to be shorter than if the dependence was not existent. On the other hand, under heavy loads, the average delay tends to be dramatically shorter.

The reverse situation is true under light traffic conditions [26].

Leonard Kleinrock studied the problem of correlations between service and in- terarrival times in the context of a queueing network model for communication networks [40]. He observed that, if there is sufficient mixing of traffic, the depen- dence effect becomes negligibly small, and can therefore be completely ignored.

Kleinrock suggested that merging several packet streams on a tandem queueing system has an effect similar to restoring the independence of interarrival times and packet lengths. This means that each time a packet is received at a node in a network, an exponential distribution can be used to generate a new length for the specific packet. This is clearly false since packets maintain their lengths as they pass through the network, but Kleinrock has shown that the effect on delay performance is negligible.

It was accordingly concluded that it is appropriate to adopt an M/M/1 queueing

model for every queue in a tandem queueing system regardless of the interaction

of traffic with other traffic flows. This is known as the Kleinrock independence

assumption, which amounts to ignoring correlations. This assumption seems to

be a good approximation for the case of Poisson arrival processes, exponentially

distributed packet lengths, a densely connected network with sufficient traffic

mixing and moderate-to-heavy traffic loads [8, 40]. It can however significantly

overestimate delays in tandem queueing systems with little traffic mixing, where

there is strong positive correlation between service and interarrival times.

The process of changing the character of the arrival process at downstream queues is very complicated, and it is heavily influenced by different aspects, like the presence of different traffic classes (with specific traffic characteristics) shar- ing the same queue, the presence of Long-Range Dependence (LRD) in traffic, the presence of tandem links with different link utilization and the presence of a large number of traffic sources sharing the network. Today the situation is such that it is not clear what the arrival processes at downstream queues are, and therefore it is impossible to do a precise analysis like in the case of, e.g., M/M/1 or M/G/1 queueing systems. Delay models based, e.g., on Poisson assumptions are inappropriate for analysis at downstream queues and no analytical solutions are known even for a simple tandem queueing system with Poisson arrivals and exponentially distributed service times [8].

There are several classes of correlations in a queueing system, and all of them are contributing to the complexity of changing the character of the arrival process at downstream queues [26]. These are:

• autocorrelations in packet interarrival times

• autocorrelations in packet service times

• crosscorrelations in packet interarrival times and packet service times

• crosscorrelations in packet service times for tandem queues

Generally, in packet-switched networks, successive packet interarrival times are often positively correlated [26]. This is valid for successive packet service times as well. Diverse factors like the presence of LRD in traffic and segmentation of large messages into IP packets with maximum 1500 byte lengths heavily in- fluence the appearance of correlations. On the other hand, packet interarrival times and packet service times are often negatively correlated with each other.

Altogether, the above-mentioned types of correlations tend to make packet de-

lays larger than in the case of Independent and Identically Distributed (IID)

packet lengths [26].

Chapter 5

Measurement Setup

Nothing has really happened until it has been recorded.

–

Virginia Woolf

Measurement and analysis of network traffic is extremely important for gaining knowledge about the inherent traffic characteristics. Without traffic measure- ments, building realistic traffic models is not possible. Although QoS in packet- switched networks may be achieved by means of overprovisioning, the need for a deep understanding of the traffic characteristics still remains.

This chapter gives a detailed presentation of the measurement tool used for

the traffic measurements reported in the thesis. The measurement system is

presented together with a discussion on possible limitations. Furthermore, the

methodology for separating the different delay components is also described in

this chapter.

5.1 Introduction

The main goal of this work is on understanding the delay process in a chain of IP routers. For doing that, accurate traffic measurements are required. A novel measurement system is therefore reported that provides the needed accu- racy and offers the possibility of controlling the traffic parameters as well. The system follows specifications of the IETF RFC 2679 and it uses both passive measurements and active probing.

5.2 OWTT Measurements

The thesis reports on delay measurements done at the network level. Figure 5.1 shows the measurement configuration used in the performed experiments [17].

The key component in the system is a Measurement Point (MP) [6], the device that does the actual packet capturing. The capabilities of an MP are decided by the capture hardware that is installed in the MP, and in these experiments the DAG 3.5E network monitoring card are used. The MPs are capable of collecting and timestamping frames with an accuracy of less than 100 ns. Data analysis is done off-line and the MPs are synchronized locally to each other.

The system is capable of collecting and timestamping traces consisting of the first 96 bytes (and possibly more) of every frame captured on Ethernet links of 10 Mbps. Thus, the Ethernet, IP and transport headers are collected as well as part of the payload. Packets smaller than 96 bytes are zero-padded. The clocks of the DAG cards, which generate the timestamps, are synchronized locally in the sense that all clocks are synchronized to one MP’s DAG clock which, in turn, is synchronized to a Network Time Protocol (NTP) server.

High timestamp accuracy is obtained (less than 100 ns), compared to the com-

puter timestamps of about 10 µs. This offers the advantage of accurate delay

measurements that are suitable for the experiments described in this thesis. For

instance, the smallest events on a 10 Mbps Ethernet (back-to-back 64 byte pack-

ets) have a minimum inter-frame gap time of 9.6 µs, and therefore the times-

5.2. OWTT MEASUREMENTS

E

(source)

A

(cross traffic) (cross traffic)

DAG 3.5E DAG 3.5E DAG 3.5E

DAG 3.5E

wiretap wiretap

MP03 MP04 MP05 MP06

R1 R2 R3

B C D

(sink)

(cross traffic)

Figure 5.1: Measurement setup

tamping system provides a precision that is about two orders of magnitude better relative to the object of observation. Trace collection is done by using four MPs [6].

The networks measured are 10 Mbps full duplex Ethernets. On a 10 Mbps Ether- net the maximum frame rate is 14881 frames/s, which equals a frame interarrival time of 67.2 µs. This time is significantly larger than the timestamp accuracy of an MP.

The routers R1, R2 and R3 are all of the same type (Cisco 3620). The source host A, the sink host E and the hosts that generate cross traffic (computers B, C, and D) are all identical with regards to hardware and software configuration.

During a test run each MP generates a packet trace and stores it locally to a hard disk. MP03 differs from the others MPs in the sense that it uses two independent wiretaps to collect data. However, this has no effect on the collected trace. Once the test has been completed all traces are collected and analyzed off-line.

To calculate the delay that a packet experiences it is required to accurately

identify the packets as they pass the MPs on their way through the routers.

Hashing is used for the identification and matching of packets. The hashing function is implemented with the SHA-1 [72]. All captured packets are bit- masked before hashing. The hash covers the entire IP header including the source and destination IP addresses, the IP header Identification field etc., with the exception of Time-To-Live (TTL) and Header Checksum fields (as they are changed at every router). 37 bytes of the IP payload (including IP options and eventual padding) are included in the hash as well.

The traffic generating software uses the client-server model and consists of a client (traffic sink) and a server (traffic generator) running on two different computers separated by a number of routers.

5.3 Synchronization Issues

An important issue when doing traffic measurements with DAG cards is regard- ing their synchronization capability to provide for highly accurate timestamps.

The system providing this feature in DAG cards is called DAG Universal Clock Kit (DUCK). Each DAG card is equipped with its own clock that runs inde- pendently from the internal clock of the host PC. Once initialized, the crystal oscillator on the DAG card controlling its clock will run freely. The DUCK must therefore be configured to avoid drift between sets of interconnected DAG cards.

The DAG card has a synchronization connector that supports a Pulse-Per- Second (PPS) input signal using RS-422 signaling [21]. The synchronization connector also allows to output synchronization pulses to other DAG cards.

This can be used for instance to chain DAG cards together to maintain local

synchronization. An external clock source can be used as an accurate time ref-

erence, e.g., GPS. In order to use an external clock reference source, the host

PC’s clock must be accurate to Universal Time Coordinated (UTC) within one

second. This is only used for initializing the DUCK and can easily be done

using for instance NTP on the host PC. Once a DAG card has synchronized

to the PC internal clock, it can then act as a ”master” for other DAG cards,

5.4. PACKET GENERATION

guaranteeing in this way that all timestamps issued by all cards in the chain are directly comparable [21].

In our experiments we use the ”DAG chain” approach, meaning that all DAG cards are synchronized locally to one DAG card which, in turn, is initialized to the internal clock of the host PC. The host PC of the ”master” DAG card is first synchronized to a local time server via NTP.

5.4 Packet Generation

The solution described in [17] has been used for traffic generation. Generally, traffic generation can be described as a process that introduces artificial traffic into a given network. Typically, the generated traffic is used for different network tests, under the conditions that normal traffic is low or non-existing. Traffic generation is not limited by the underlying physical layer and can be generated at almost any layer in a protocol stack.

When traffic is generated at the application layer, the resulting behavior of the generated traffic, as observed at the link layer, is also influenced by the intermediate layers in the stack and not only by the characteristics of the traffic generator. For instance, if the objective is to generate traffic at the link layer that incorporate ”real” TCP segments, then the traffic generator should insert the generated traffic into a TCP socket. On the other hand, if the objective is to generate IP datagrams that emulate the TCP behavior, then the traffic generation should be done at a lower layer, i.e., network or link layer, or by using a UDP socket.

Consider that the goal is to generate traffic at the application level. In this case,

the generated traffic can be described by two independent random variables X

and Y with associated Probability Density Functions (PDFs) f

(x) and f

(y)

respectively. The variable X identifies the payload length (in bytes) whereas

Y specifies the inter-packet time. In this thesis, inter-packet time is defined as

being the time interval between the end of a packet and the arrival time of the

next packet at the transport layer, under the assumption that the transport