performance measurement of ip networks using the two-way active

Performance Measurement of IP Networks using the Two-Way

Active Measurement Protocol

I N G M A R B Ä C K S T R Ö M

Master of Science Thesis Stockholm, Sweden 2009

Performance Measurement of IP Networks using the Two-Way

Active Measurement Protocol

I N G M A R B Ä C K S T R Ö M

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2009 Supervisor at CSC was Olof Hagsand Examiner was Karl Meinke TRITA-CSC-E 2009:038 ISRN-KTH/CSC/E--09/038--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

AbstractComputer networking is becoming a new standard for exchanging in-formation. Many new services have been introduced to IP networks,and real time applications such as streaming media and Voice over IPare becoming more popular. These types of services are sensitive to dis-turbances; therefore it is important that the providing networks meettheir requirements. To verify the quality of a network and to gatherknowledge of its characteristics, several methods of network perform-ance measurements have been developed. This master’s thesis investig-ates active end-to-end measurements, and presents notions, metrics andmethods for measuring the quality of IP networks. An implementationof the Two-way Active Measurement Protocol, TWAMP, has been made,and evaluated by comparing the results with three other active meas-urement tools. TWAMP is the first standardized protocol of its kind asit collects two-way performance data in one measurement. Metrics suchas latency, packet loss, packet duplication and packet reorder have beenmeasured, and the results show that TWAMP is a competitive protocolfor network performance measurements.

Sammanfattning

Tjänstekvalitetsmätning av IP-nätverk med TWAMP

Datornätverk spelar en allt större roll vid utbyte av information. Månganya tjänster har gjorts tillgängliga för IP-nätverk, och realtidsapplika-tioner som mediaströmmar och IP-telefoni blir alltmer populära. Des-sa tillämpningar är känsliga för störningar, och det är viktigt att detunderliggande nätverket uppfyller tjänsternas krav. För att verifieranätverksanslutningens prestanda och för att undersöka dess egenska-per har flera metoder för tjänstekvalitetsmätningar utvecklats. Det härexamensarbetet undersöker aktiva mätningar mellan två ändpunkter.Det beskriver begrepp, mätvärden och metoder som används för att be-stämma kvaliteten av IP-nätverk. Ett nätverksprotokoll med detta syfte,TWAMP, the Two-way Active Measurement Protocol, har implemente-rats och utvärderats gentemot tre andra aktiva mätverktyg. TWAMP ärdet första protokoll av sitt slag som har standardiserats, då det samlartvåvägsinformation i en mätning. Mätvärden som latens, förlorade pa-ket, dubbletter och paket som levereras i oordning har undersökts, ochresultaten visar att TWAMP är ett bra alternativ för att genomföratjänstekvalitetsmätningar av IP-nätverk.

Acknowledgements

This master’s thesis was conducted at Prosilient Technologies, and I would like tothank my colleagues for their input and for their encouragement.

I would especially like to thank my supervisor Olof Hagsand for his supportand for the time that he has invested in this project, as well as for giving me theopportunity to gain a better understanding of the field of network performancemeasurement.

Ingmar Bäckström, Stockholm, April 2009.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Network Performance 52.1 Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Singletons, Samples and Statistics . . . . . . . . . . . . . . . 52.1.2 Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.3 Timing Considerations . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 Loss Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Round-trip Delay . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 One-way Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.6 Delay Variation . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.7 Reordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.8 Duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.9 Further metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Methods 153.1 The One-way Active Measurement Protocol . . . . . . . . . . . . . . 15

3.1.1 OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 Current Implementations . . . . . . . . . . . . . . . . . . . . 18

3.2 The Two-way Active Measurement Protocol . . . . . . . . . . . . . . 193.2.1 TWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 TWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3 TWAMP Extensions . . . . . . . . . . . . . . . . . . . . . . . 203.2.4 Current Implementations . . . . . . . . . . . . . . . . . . . . 21

3.3 Reference methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.1 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.2 PTAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Implementation and Results 234.1 TWAMP Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.1 Netem Test Sessions . . . . . . . . . . . . . . . . . . . . . . . 274.3.2 Internet Test Sessions . . . . . . . . . . . . . . . . . . . . . . 28

5 Summary and Conclusion 315.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Improvements and Recommendations . . . . . . . . . . . . . . . . . . 335.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Bibliography 35

Appendices 38

A Format of Test Packets 39

B Internet Test Sessions 41

Chapter 1

Introduction

The usage of IP based networks has increased enormously during the last decadeand the trend is evident; the Internet continues to grow rapidly. According toa forecast, Internet traffic increased with 46 percent in 2007 and is estimated togrow by another 51 percent in 2008[1]. The annual growth rate will then slightlydecrease, and by 2012 the total annual IP traffic is estimated to reach about 500exabytes per year. Internet video, excluding peer to peer file sharing, accounts todayfor one quarter of all consumer Internet traffic. The forecast points out that highdefinition video will be responsible for a majority of the increase in bandwidth usage.Along with the quick growth of media streams and video conferences, Voice over IP,VoIP, is also becoming more popular. Although it is not as bandwidth consumingas visual media, this service still requires available bandwidth to operate, and asall interactive real time applications, it is sensitive to quality disturbances in thenetwork. To assure the quality of these services, it is important that the providingInternet connection fulfils the requirements of capacity and available bandwidth.

Network performance measurement is not a new phenomenon, but lately, thisfield has come more in focus. This science, also known as communication networkmetrology, is very wide, and several research projects have been launched withdifferent purposes[2][3][4][5]. Some studies investigate traffic characterization andtraffic modelling, whereas others focus on network topology or path symmetry.The results of the projects are useful for several parties: researchers can adoptnetwork characteristics in simulation models to develop new network protocols;Internet Service Providers, ISPs, can determine network trends for resource capacityplanning and discover performance bottlenecks; network equipment designers mightfind the data useful when designing routers, and the end-users are interested inmeasuring the quality of the Internet connection they are paying for. Consumersusing real time services with Quality of Service constraints, QoS, often negotiate QoSlevels with their ISP through a Service Level Agreement, SLA. Network performancemeasurement is an efficient approach for customers to verify the SLA, as well asa marketing strategy for ISPs to demonstrate the capacity and reliability of theirnetworks.

1

CHAPTER 1. INTRODUCTION

1.1 Background

Network performance measurements can be divided into two different categories:active and passive monitoring[6][7]. When performed passively, the network is onlyobserved, and packet headers are captured and analyzed. The passive mode can yetagain be divided into two sub types. At a microscopic level, the passive measure-ment analyzes every packet passing through the measurement node and notes itscharacteristics. When measuring at a macroscopic level, packets passing throughthe node are aggregated into flows and then analyzed. Passive network performancemeasuring techniques are especially useful for traffic engineering, as they describeflow dynamics and distribution. A drawback with passive monitoring is that it col-lects and stores a great amount of data and consumes a lot of memory. This typeof measurement typically presents information from only one node in the network.It is difficult to collect data from a packet travelling between measurement points,and even though it can be done, matching packet information from different nodesis a difficult task.

Active monitoring techniques are on the other hand well suited for performingend-to-end measurements between nodes in a network. Measurement data, or probepackets, are injected into the network. The packets are transmitted between thetest end points, and measurement data is collected upon the packets’ arrival. Thismethod can also be divided into different sub categories. Cooperative measurementtools consist of a client and a dedicated server for collecting measurement metrics.When applying non cooperative tools, only one client program is used. Measurementdata is sent to an existing, independent server, such as a web server, and its responseis used for computing the result. Other tools rely on generated replies, such as ICMPmessages.

A problem with active measurement techniques is that they generate traffic, andmay influence the behaviour of the network. This problem is known as intrusivenessor invasiveness. When designing active measurement tools, it is therefore importantthat the amount of data generated by the probe packets does not affect the networkperformance.

Approaches for Active Network Measurements

When performing active measurements, probe packets are typically timestamped atthe source host, transmitted by the network to the destination host where anothertimestamp is recorded. When a sufficiently large number of test packets have beentransferred between the end points, statistics such as packet loss, latency, packetreorder and packet duplication may be computed.

For a long time, the Ping command[8] has been used for measuring the round-trip time, RTT, between two hosts. The one-way delay between the nodes hasthen been calculated as half the RTT[9]. However, several studies[10][11] showthat path asymmetry often prevail between end points in a large network, and thisapproximation is therefore incorrect.

2

1.2. PURPOSE

Several sophisticated measurement tools[12] have been developed in order to givea more accurate representation of communication networks. Measurements distin-guish the forward path from the reverse path, probing packets can be shaped toresemble actual traffic and tools can be used to monitor the network performancefrom an end-user’s point of view.

Active measurement techniques also have the advantage of considering the un-derlying network as a black box. No knowledge is needed about the network to-pology or how individual routers treat the traffic. These methods generate inputpackets and analyze the packets output by the network. This makes the proceduresimple but yet powerful as test endpoints, either software or hardware nodes, caneasily be moved to different locations in the network to isolate a malfunctioninglink.

Several different tools for active network measurement exist, but these tech-niques lack interoperability. The Internet Engineering Task Force, IETF[13], is anopen international community developing Internet standards. It consists of manywork groups, and the IP Performance Metrics work group, IPPM[14], is currentlyreleasing standards for metrics and methods used for network performance meas-urement.

1.2 Purpose

The purpose of this master’s thesis is to investigate the active end-to-end networkmeasurement area. The problem within this field is the lack of interoperable tools,and in this project we have implemented and evaluated the upcoming TWAMPstandard. The thesis is focused on the progress of the IETF IPPM group, anddescribes metrics and methods used for network performance measurement. Animplementation of the TWAMP protocol has been made and compared to existingmeasurement tools.

1.3 Outline

The report is divided into five chapters. After introducing the reader to the field,we explain the terminology used throughout the thesis, and describe different net-work performance metrics. Within the second chapter, Network Performance, thereader will achieve comprehension of what we actually measure. The third chapter,Methods, explains how the measurements are carried out. We elaborate on fourdifferent active measurement techniques, with focus on OWAMP and TWAMP. Inthe following chapter, Implementation and Results, we clarify our TWAMP imple-mentation, present how we evaluated the method and give account of our results.The last chapter, Summary and Conclusion, constitutes the completion of the re-port; different aspects of the protocols and implementations are discussed as wellas improvements and the competitiveness of the TWAMP protocol.

3

Chapter 2

Network Performance

To get an accurate representation of a network’s characteristics, the IETF IPPMwork group has defined a framework for performance metrics[15]. This chapterdescribes notions and metrics that are useful when performing measurements in anIP network.

2.1 Notions

2.1.1 Singletons, Samples and Statistics

The metrics can be separated into three distinct categories. A singleton metric is asingle, atomic measurement of a packet characteristic, for example the loss or thedelay of a packet. Sample metrics are derived from singleton metrics by collectinga sequence of distinct instances together. A sample metric of packet delay betweentwo hosts can be defined as a collection of singleton delay metrics between the twonodes during one hour. The singleton metrics are collected at intervals definedby a statistical distribution. Statistical metrics are derived from sample metrics bycomputing statistics of the collected samples. By computing the mean latency valueof packets from a sample metric, a statistical metric has been produced.

2.1.2 Sampling

There are different methods for collecting sample metrics. When periodic samplingis used, measurements are collected with fixed intervals. Samples can also be col-lected at moments random in time, and the sampling intervals are then determinedby a statistical distribution.

Periodic Sampling

With periodic sampling, samples are derived from measurements separated by afixed amount of time, a method which is commonly used for its simplicity. Trans-mitting uniform packets over a network at fixed intervals simulates a constant bit-

5

CHAPTER 2. NETWORK PERFORMANCE

rate stream, also known as periodic streams, which resembles to encoded audio andvideo traffic[16].

This method does however have drawbacks since regularly spaced singletonmeasurements may be synchronized with other periodic behaviours in the network.There is therefore a risk that the measurement only observes parts of the periodicpattern, and that only a part of the performance spectrum is sampled. If the meas-urements are made with fixed intervals, they are also easier to predict and may bemanipulated. Components in the network can anticipate when measurements arebeing made and can then temporarily change their behaviour, which will result infalse measurements.

As previously mentioned, the periodic streams can be configured to have resem-bling characteristics of media flows. These kinds of services are often time critical,and measuring their quality is of great interest. Although the periodic sampling onlyanalyses parts of the performance spectrum, this may well match the spectrum usedfor media flows, which simplifies the estimate of the application performance.

The analysis of network performance is also simplified in other ways. Somecharacteristics of a network, such as delay variation and reordering, are sensitive tothe sampling frequency. When the impairments are time-varying themselves, theanalysis can be facilitated by a constant sampling frequency.

Random sampling

To avoid the potential problems with periodic sampling, another method calledrandom additive sampling can be used. The samples are collected at randomlygenerated intervals with a common statistical distribution. The randomness of thesamples depends on the quality of the distribution. If the function for examplegenerates a constant value with probability one, then the sampling is equivalent toperiodic sampling. With random additive sampling, measurements are less predict-able and they will not cause synchronization problems to the same extent.

However, the sampling still remains predictable to a certain degree unless theexponential distribution is used. Poisson sampling uses exponential distributionwith rate lambda to compute the arrival of new samples. With Poisson sampling itis impossible to predict arrival time of the next sample, a feature which sometimesis desired. There are other similar techniques based on statistical distributionsfor collecting samples. The geometric sampling is closely related to the Poissonsampling, and its arrival times for sampling cannot be predicted either. Thesemethods do however not model media streams with the same accuracy as periodicsampling does.

2.1.3 Timing Considerations

When performing latency measurements in a network, timing between nodes iscrucial for obtaining consistent results. This paragraph explains notions related toclock uncertainty, and presents different approaches for clock synchronization.

6

2.1. NOTIONS

Offset, Synchronization, Accuracy, Skew, Drift

A clock’s offset defines the difference between the time reported by the clock andthe true time defined by Coordinated Universal Time, UTC. The difference in timebetween two clocks is called the relative offset or synchronization. It is not alwayscritical that the offset is zero as long as all measurement nodes agree on what time itis. If the relative offset of a pair of clocks is zero, they are described as synchronized.The accuracy of a clock is defined as the absolute value of the offset. If the clock’soffset is zero, it is described as accurate. Skew measures the change of a clock’saccuracy in time, a clock might for example gain or lose a couple of millisecondsper hour. A clock’s skew may be affected over time by for example changes intemperature. Drift measures the variation of skew in time.

Wire time

Active delay measurement techniques usually include timestamping packets at endhosts upon transmission and reception. However, timestamps do not always indic-ate the true delay since the packet has to be processed by the system before it istimestamped. The notion wire time defines the time taken for a packet to travelbetween hosts. Let us introduce an Internet host observing the link in question inorder to make these concepts clearer. The wire exit time for a packet on that linkis the time when the observation host has spotted all bits of the packet. The wirearrival time for a packet is when any bit of the packet has appeared at the obser-vation host. An alternative definition[17] of wire time is the packet’s transmissiontime at the MAC interface.

In practice, timestamps are set and read by measurement software just prior tosending or after receiving a packet, these are known as host times. The differencebetween wire times and host times depends on the latency between receiving thepacket at kernel space and transfer it to user space where it can be timestamped.This error can be reduced by using a network interface card specially designed fortimestamping and directly synchronized to a GPS receiver[18], or by timestampingthe packets at kernel level.

Synchronization methods

Clock synchronization is difficult to achieve. The Global Positioning System, GPS,can be used, which offers nanosecond accuracy[19]. GPS uses positioning inform-ation from different satellites to compute the current time[20]. This method ishowever complicated and expensive to deploy in larger scale.

Long wave radio transmissions can also be used to propagate the correct time.DCF77 is a German project for transmitting a long wave time signal. The ra-dio transmissions are not affected by obstacles and do not require an antenna forreception. DCF77 allows time signals to be registered under a millisecond range[21].

The Precision Time Protocol, PTP, defined in the IEEE 1588 - 2002 standard[22]is a new emerging standard which uses the link level for clock synchronization. The

7


timestamps are generated by hardware and provides accuracy within the micro-second range[23].

The Network Time Protocol, NTP, is a widely used IP based method for syn-chronizing computers connected to networks[24]. It has a hierarchical design wherethe top of the tree, stratum 1, consists of computers synchronized to an externalsource, typically an atomic clock or a GPS receiver. Computers synchronized tostratum 1 hosts become stratum 2 clocks, and act as NTP servers for higher strata.The NTP protocol is semi-self-organizing. An NTP server needs to be manually con-figured with a list of synchronization peers, but then automatically chooses whichpeers to communicate with in order to get a good synchronization. The NTP dae-mon in a host adjusts the clock tick instead of directly setting the new time receivedby a server. In that manner, discontinuity is prevented and the transition to thecorrect time is made smoother. The accuracy of NTP depends on the quality of thenetwork connection between the server and the client, but with a reasonably goodlink, the accuracy of the protocol is typically around 1-2 milliseconds[25].

2.2 Metrics

2.2.1 Connectivity

One of the most basic metrics is connectivity[26]. There are several types of thismetric, and the parameters differ slightly, but they all use booleans for metric units.The most fundamental type is instantaneous unidirectional connectivity, which de-scribes if a packet transmitted from the source host at a specific time will arriveto its destination or not. This metric is mostly used as building blocks for furtherconnectivity metrics, but one-way connectivity can also be of interest when for ex-ample testing firewalls. This definition can be widened to apply in both directionsbetween two hosts. If both hosts comply with this criterion to one another, theyfulfil the metric instantaneous bidirectional connectivity.

In similar ways, unidirectional and bidirectional interval connectivity are defined.The connectivity is now measured within a time interval and is not as momentaryas the previous metric. This metric might however not be useful when defining fullconnectivity. The bidirectional interval connectivity is defined over a short interval,and it is not certain that two hosts can reply to the packet they receive from oneanother. Another metric called interval temporal connectivity is defined as a sourcehost having instantaneous connectivity to its destination within a time interval,and the destination host has instantaneous connectivity back to the source host ata later time in the same interval. This interval is specified to be long enough fortransmitting a packet and its response between two hosts. The packets sent in thetwo directions may be of different types, since some applications use different typesof packets for forward and reverse traffic.

8

2.2. METRICS

2.2.2 Packet Loss

There is another metric which defines whether a packet was successfully transmittedover the network or not. The singleton metric definition for one-way packet loss froma source host to its destination at a specific time is described with a boolean[27]. Itsvalue is zero if the destination host received the packet, and one otherwise. Withthis metric it is also important to separate lost packets from packets received witha large delay. For many applications, treating packets with long delay as lost is notconsidered a big problem. For example, a TCP packet which is delayed with severalmultiples of the round-trip time may as well have been declared lost. Packets frommedia streams can be treated the same way if they arrive after the playback point.The two hosts must be somewhat synchronized in time and should share anothercommunication channel, possibly a control protocol, by which the destination hostknows the type of the packet and when it was sent.

2.2.3 Loss Pattern

One important factor when measuring performance, for both real-time and non-real-time applications, is the loss pattern[28]. Two transmissions with identical lossrates but different loss distributions can present two widely different performanceexperiences. Loss distance describes the difference in sequence numbers betweentwo lost packets, defined as zero for the first packet lost. A loss period begins if theprevious packet was received as expected, and the current packet is lost. With thisdefinition the sequence numbers of the test packets must be increased monotonically.The loss period is an integer with an initial value of zero, and is incremented eachtime a new loss period begins. The loss period for a successfully received packet iszero. An example of loss distance and loss period is shown in Figure 2.1.

Loss period:

s1 s8s7s6s5s4s3s2 s9

1 2 3

Loss distance: 0 1 2 3 1Figure 2.1. Crossed out packets are lost. Loss distance describes the separationbetween packet losses, and the loss period analyses the consecutive packet loss foreach occurrence.

9


2.2.4 Round-trip Delay

The round-trip delay metric measures the time it takes for a packet to be transmittedfrom the source host to its destination, and then back again[29]. The source hosttimestamps the packet upon transmission. When the destination host receives thepacket, it immediately sends another packet as response back to the source. Whenthe response packet is received, the source host records another timestamp. Thevalue of the metric is then computed by subtracting the two timestamps and anyknown uncertainties. If the packet is lost, the round-trip delay is undefined. Nodistinction is made between in what direction the packet was lost. The definitionitself is ambiguous in that matter: it is not specified which node acts as source, andwhich one acts as destination. There is no strict need for synchronization betweenthe two hosts, since only the source host performs and collects the timestamps. Ifits clock is synchronized with a time service, erroneous results may be presented ifthe clock is adjusted between the timestamps.

2.2.5 One-way Delay

There are several reasons for performing one-way measurements: asymmetric rout-ing and queuing, Quality of Service agreements etcetera. Round-trip measurementsexamine the union of two distinct paths, and do not treat the forward and reversepath separately. One-way delay is a singleton metric measuring the time taken fora packet to travel from the source host to its destination[30]. An upper bound forthe metric needs to be specified to determine whether a packet is delayed but stillon its way, or whether it is lost. The metric is undefined or infinite if the packetnever is received. If multiple copies of the same packet are received, the arrival timeof the first packet establishes the one-way delay. The methodology for determiningthe delay varies depending on the type of the packet, but the approach is similarfor all types. To achieve fruitful measurements, it is important for the sending andreceiving hosts to have synchronized clocks. It is also important that the padding ofthe test packet is filled with randomized bits to avoid that the packet is compressedon its path.

2.2.6 Delay Variation

There are two different notions describing delay variation. Inter packet delay vari-ation, IPDV, and packet delay variation, PDV. Delay variation is important formeasuring the performance of a network, in most cases it is the maximum delayvariation within a high percentile that is of interest. This is particularly true formedia streams which require a delivery of packets at regular intervals, and themeasurement is meaningful when sizing buffers for these sorts of applications.

10

2.2. METRICS

Inter Packet Delay Variation

IPDV analyses the difference between one-way delay metrics of two selected packetswithin a stream[31]. The singleton metric one-way ipdv defines a single instanceof an ipdv measurement, but the measurement is only statistically usable whencombined in pairs. The measurement is performed by sending a stream of equallysized packets between the measuring nodes, and two packets are selected from thestream. The two packets are timestamped at the source and at the destinationhosts, and the one-way delay metric is computed. The one-way delays of the twopackets are subtracted, and the inter packet delay variation can be measured. Usingthis technique, the clock synchronization between the two hosts is not as crucialas in one-way delay measurements, the relative offset is not noticeable after thesubtraction. If one or both of the chosen packets are lost or do not arrive withinthe specified time limit, the IPDV metric is undefined.

Packet Delay Variation

Instead of comparing two following packets in the stream, PDV uses a referencepacket from the interval, typically the packet with the lowest delay. The PDV of apacket is then computed by comparing its one-way delay with the reference value.This way, PDV will be normalized to the minimum delay and can only take valuesthat are positive or zero[32]. This metric has not yet been standardized by the IETFIPPM group, but a draft documenting the difference between IPDV and PDV hasbeen released.

Both metrics are affected by the packet loss ratio, but only IPDV is affected bythe loss distribution. In the worst case where every other packet is lost, IPDV isunusable. IPDV can however measure the network’s ability to retain the originalspacing between packets, it does also reduce the demands on the system’s clockin the aspect of skew and stability. IPDV is memory less and only describes thedifference in delay between two adjoined packets whereas PDV is defined over alonger interval. PDV is a more usable metric, and especially PDV percentiles areused when sizing play out buffers and describing long-term trends. A comparisonof values between IPDV and PDV is shown in Table 2.1.

Table 2.1. Comparison between IPDV and PDV. This PDV measurement uses thepacket with the lowest delay (10ms) as reference value.

Packet number 1 2 3 4 5 6 7 8 9 10Delay (ms) 20 15 30 10 15 20 25 10 10 15IPDV n/a -5 15 -20 5 5 5 -15 0 5PDV 10 5 20 0 5 10 15 0 0 5

11


2.2.7 Reordering

Packets sent over a network might be transmitted over different paths, and maytherefore not be received in the intended order. The Internet Protocol does notaccount for lost or misplaced packets, and this must be taken care of by higher-levelprotocols. To accomplish correct packet order, each packet must contain a uniqueidentifier, a sequence number, which identifies the order in which the packets weresent. The sequence number is then used at the destination to detect rearrangedpackets. As an example, eight packets, sent with consecutive sequence numbers,arrive to their destination as described in Figure 2.2.

Reordered

e = 3 e = 2 e = 1New sequence discontinuity

of size 3.

s1 s8s6s5s4s7s3s2

Figure 2.2. Packets arriving out of order. Packet s7 starts a new sequence discon-tinuity and packets s4, s5 and s6 are considered as reordered with extent e.

There are two alternatives when distinguishing the packet disorder: either the packetwith sequence number s7 is reordered, or packets with identifiers s4, s5 and s6 arelabelled as misordered. The IETF IPPM group defines packets with lower packetidentifiers than their predecessors, or late packets, in this case packets with sequencenumber s4 to s6, as out of order[33]. Using the alternative definition and declaringpacket s7 as reordered is not recommended, since it is upon the arrival of packetss4 to s6 that separates this occurrence from packet loss.

The goals of reordering metrics are to determine whether or not a packet hasbeen reordered and to what degree. To determine the extent of reorder, a number ofdifferent metrics have been defined to fulfil the need of different applications. Thefirst notion is a function that generates a series of unique increasing numbers, thiscould simply be an increase of a consecutive integer. The second basic concept isan algorithm at the receiving side, a counter, which determines the next expectedsequence number. Normally, this number equals the sequence number of the previ-ously received packet increased by one. The metric reordered defines if a packet ismisordered or not. The metric is false if the sequence number of the received packetis equal to or larger than the next expected sequence number, and the counter isthen increased. If the packet identifier is smaller than the expected sequence num-ber, the metric is true and the counter is not increased. If duplicated packets arereceived, only the first packet is considered reordered. If a packet arrives with a lar-ger sequence number than expected, this indicates a sequence discontinuity causedby either packet loss or reordering. The size of the discontinuity is the number ofmissing packets and can be computed by subtracting the expected sequence numberform the arrived packet’s identifier. Source code for calculating the named metricsis shown in Figure 2.3.

12

2.2. METRICS

Reordered ratio stream is a sample metric to compute the ratio of reordered pack-ets. Under a time interval, it simply divides the number of reordered packets withthe number of total packets received, excluding duplicates. This metric gives anestimate of the percentage of reordered packets in the network. If the value is zerothere is no need to apply further reordering metrics to the stream.

The sample metric reordering extent stream defines to what extent the packetsin a stream have been reordered. The reordering extent is the distance in packetsbetween a reordered packet, and the earliest packet received with a larger sequencenumber.

Late time stream defines the lateness of a reordered packet. By calculatingto what extent the packet has been reordered, its expected arrival time can becompared to its real destination time, and the lateness can be computed. The samplemetric byte offset stream indicates the storage in bytes needed to accommodate thereordered packets. The byte offset value for a reordered packet is the total payloadsize of packets with a larger sequence number that arrived prior to the reorderedpacket. These packets can then be buffered until the previous sequence of packetsis complete.

Reordering gaps describe the distance between reordering discontinuities andreordering free runs define the number of consecutive ordered packets between mis-ordered packets. The reordering metrics are particularly useful when designinggeneral receiver buffer systems.

if s >= NextExp, then /* s is in-order */if s > NextExp then

SequenceDiscontinuty = True;SeqDiscontinutySize = s - NextExp;

elseSequenceDiscontinuty = False;

NextExp = s + 1;Type-P-Reordered = False;

else /* when s < NextExp */Type-P-Reordered = True;SequenceDiscontinuty = False;

Figure 2.3. Reordering metrics calculation for packet with sequence number s.NextExp corresponds to the next expected sequence number.

2.2.8 Duplicates

When data is sent over a network connection, the receiving host usually expectsexactly one copy of each sent packet. We have already discussed packet loss, butthis passage treats the opposite occurrence: when a packet is sent, multiple copiesarrive to the receiving node. This case has not yet been standardized by the IETFIPPM group, but an Internet draft has been published[34].

The metric one-way packet arrival count is an integer that measures the numberof identical and uncorrupted copies of a packet which are received by a measurementnode during a specified time interval. Packets are considered identical if they contain

13


identical information fields and if they were sent between the same hosts. The IPheaders do not need to match, since for example the time to live, TTL, field mayvary if a duplicated packet has been routed differently. If no packet is received themetric is undefined. The metric one-way packet duplication is similar to one-waypacket arrival count, but instead of counting the number of occurrences of a packet,it counts the number of additional identical and uncorrupted copies received. If asingle copy of a packet is received, the metric is zero, and it is undefined if no packethas arrived. This metric equals to one-way packet arrival count subtracted by one.

There are two proposed statistical metrics for one-way duplication. One-waypacket duplication fraction and rate gives the fraction and rate of additional packetsthat arrived in a stream. The fraction is calculated by removing all packets withundefined values of one-way packet duplication, and the difference is then dividedby the total number of packets sent and not lost. The rate is calculated similarly,but the numerator consists of packets with one-way packet arrival count larger thanone.

2.2.9 Further metrics

The number of different network measurement tools[12] is very large, and the listof performance metrics can of course be elongated. The IETF IPPM work grouphas released standards and drafts which treat several new concepts.

Spatial composition[35] computes the performance of a complete path basedon measurements from separate path segments, and multi metrics[36] describe howmeasurements can be performed in a multicast scenario with one source and multipledestinations. Metrics for measuring network capacity[37] have also been released.

There are several other organizations[38][39] that publish standardization doc-uments. The International Telecommunication Union, ITU[40], which creates stand-ards for telecommunication, has released a recommendation known as the E-model[41].The E-model is a computational approach for transmission planning, and can beused to assess conversational quality by evaluating parameters such as latency,packet delay variation, packet loss and encoding technique. This model can bemapped to an estimated mean opinion score, MOS[42]. The MOS is a subjectivemetric indicating the perceived quality of received media, and is well suited forevaluating the quality of VoIP applications.

14

Chapter 3

Methods

Four different measurement methods have been compared in this thesis, and thetechniques differ somewhat from each other. The evaluation has been based on res-ults collected from the TWAMP prototype implemented in this project, Internet2’sOne-way ping, Ping and PTAnalyzer developed by Prosilient Technologies[43]. Thewell known Ping utility uses the ICMP protocol to transmit its packets, and doesonly calculate the round-trip time. Ping is therefore not affected by unsynchronizedclocks. PTAnalyzer collects two-way measurement data, but uses its own synchron-ization plane, which allows it to operate independently from the system clocks.This technique sends its traffic as UDP packets. The UDP protocol is also used byOWAMP and TWAMP, but since these two methods rely on the system time, it isof great importance that the clocks in the measurement nodes are synchronized.

3.1 The One-way Active Measurement Protocol

In order to analyze the different metrics, test traffic is sent between measurementend points, and the results may then be compiled. There are several existing meas-urement platforms for collecting metrics in IP networks, but due to the lack ofinteroperability the IETF IPPM group has published a new standard for one-waymeasurements. The One-way Active Measurement Protocol, OWAMP, analyzesunidirectional network characteristics, and can calculate metrics such as one-wayloss and one-way delay[44]. The authors’ vision is to make one-way measurementsas common as the usage of today’s ICMP based round-trip measurements. Thiscan be achieved by a widespread deployment of open OWAMP servers and the factthat more and more hosts on the Internet have clocks synchronized to GPS or NTP.The design goals of the protocol, besides giving an accurate understanding of thenetwork, are to provide flexible measurement nodes and that the protocol trafficwill be difficult to detect and manipulate. The traffic is difficult to detect since itconsists of a stream of UDP packets to and from negotiated port numbers. The pro-tocol also implements modes of authentication and encryption to make the trafficimpossible to alter and indistinguishable from other data in the network.

15

CHAPTER 3. METHODS

The OWAMP protocol consists of two different protocols: OWAMP-Control andOWAMP-Test. The control protocol is used for setting up and terminating test ses-sions, collect results etcetera, whereas the test protocol constitutes the test packetsexchanged between the measurement nodes. The two protocols are closely related,but the test protocol can be used with some other control protocol than OWAMP-Control. The IETF IPPM group does however recommend implementing the twoprotocols together to ensure interoperability.

OWAMP has been divided into different logical roles in order to provide max-imum flexibility. The following roles are defined: session-sender, session-receiver,server, control-client and fetch-client. The different roles and their relationship aredescribed in Figure 3.1.

Session-Sender

Server

Fetch-Client

Session-Receiver

Control-Client

OWAMP-Test

Proprietaryprotocol

OWAMP-Control

Proprietary

protocol

OWAMP-Control

Figure 3.1. Possible relationship between OWAMP’s logical roles.

The control-client is an end system which contacts the server to initiate or terminateOWAMP-Test sessions. The server manages OWAMP-Test sessions, and configuresthe measurement end points with data from the control-client. The server is alsoable to return the measurement results from a session. The session-receiver andsession-sender are two end points of the test session between which test packetsare transmitted. The role of the fetch-client is to initiate requests for fetching theresults of a completed test session. One host may play several different logicalroles, and a simple setup can be achieved with only two hosts. One host actscontrol-client, fetch-client and session-sender, whereas the other host acts serverand session-receiver, as shown in Figure 3.2.

Session-Sender

Fetch-Client

Control-Client

Session-Receiver

ServerOWAMP-Control

OWAMP-Test

Figure 3.2. OWAMP setup between two hosts.

16

3.1. THE ONE-WAY ACTIVE MEASUREMENT PROTOCOL

3.1.1 OWAMP-Control

As previously mentioned, OWAMP is built up by two interrelated protocols: OWAMP-Control and OWAMP-Test. The control protocol establishes a TCP connection to awell-known port, and this connection remains open throughout the entire OWAMPsession. OWAMP-Control data is transmitted only before and after the test, andnot during the test session itself, with the exception of a request for terminatingthe test session earlier than previously negotiated. Both the control and test pro-tocol support three different modes: unauthenticated, authenticated and encrypted,where the two latter modes require a shared secret. The authenticated and encryp-ted modes provide increased security; authenticated traffic prevents packets frombeing injected by unknown users, and encryption prevents routing equipment fromdistinguishing the stream of test packets and alter its priority.

The control connection is initiated by the control-client. The server respondswith a greeting, and presents supported modes, a challenge and other parametersused to setup the test session. These parameters are used in authenticated andencrypted modes and will not be thoroughly discussed here. If the server does notwant to communicate, e.g. due to the limit of maximum concurrent tests has beenreached, this information is sent as response and the server may close the connection.Upon receiving the response packet, the control-client may close the connection ifthe desired mode is not supported, otherwise it must transmit a packet containingthe mode of the current session. The next packet exchanged is sent from the serverto the control-client and contains an accept field and a timestamp indicating thetime when the instance of the current test server was created. The connection setupis now complete. The control-client can now issue one of the following commands:request-session, start-session, stop-session and fetch-session. The packets exchangedduring a request-session contains information about addresses, ports, packet size,number of test slots, number of packets, start time, timeout and a unique sessionidentifier, SID. The server responds with an accept-session message to confirm theupcoming test session. The control-client and the server have now agreed on asend schedule; in case of lost packets, the session-receiver still knows when theywere supposed to be sent. The test session is started when the client issues a startcommand. The server transmits a start acknowledgement, and if the session wasaccepted, the test streams are started immediately.

When test sessions have ended, or in order to cancel a test session before it iscompleted, either of the two hosts can issue a stop command. This command in-cludes the number of sessions to stop, the session identifier and a range of sequencenumbers indicating which packets that will be excluded from the test session. Whena test session is completed, the client issues a fetch command to collect the meas-urement data containing the SID and the range of sequence numbers to collect. Theserver responds with a fetch acknowledgement and then transmits the timestampedpacket records back to the control-client, which computes one-way metrics on thereceived data.

17

CHAPTER 3. METHODS

3.1.2 OWAMP-Test

The OWAMP-Test protocol is layered over UDP and transmits singleton measure-ment packets between the two end points negotiated during the request-session. Thetest packets contain a sequence number, a timestamp indicating when the packetwas sent, an error estimate representing the sending host’s offset to UTC and anoptional packet padding. The timestamp consists of 64 bits where the first 32 bitsare an unsigned integer indicating the number of seconds elapsed since January1900. The last 32 bits constitute the fractions of the last second that have passed.The test packets contain further parameters if encrypted or authenticated mode isused. A detailed description of the packet format is shown in Appendix A.

The session-sender starts transmitting the packets according to the send sched-ule, and upon arrival, the receiver timestamps the packets and stores the sequencenumber, send time, receive time and TTL from the IP header. This data will laterbe transferred back to the control-client for computation of performance metrics.

3.1.3 Current Implementations

The first draft of OWAMP was released to public in November 2000 and aboutsix years later, in September 2006, the final standardizing document was released.Three different implementations of OWAMP have been distinguished, of which oneproject was discontinued in 2005. Possibly a larger number of implementations havebeen done, but not publicly released with source code.

Internet2 One-way Ping

The network consortium Internet2 has developed an application, One-way ping[45],which implements the OWAMP protocol using the programming language C. Thecurrent stable implementation, version 3.0c, was released in 2007. It supports thecomplete standard and is available for Unix-like systems. One-way ping is a typicalclient-server application, where the client program, Owping, contacts the serverrunning a daemon known as Owampd. When the send schedule is negotiated, eachside spawns a child process which constitute the test end points. The two end pointsare identical, and by default, two measurement sessions, one in each direction, arestarted and the results are returned back to the client.

J-OWAMP

J-OWAMP[46], a Java implementation of the OWAMP protocol has been madeavailable by H. Verga et al. It is platform independent and does also include a webinterface where sessions can be configured and results presented visually. Anotherfeature of J-OWAMP is its built in NTP client, which offers direct synchronizationwith an NTP server. This eliminates the need of a synchronized system clock. Theprogram offers single one-way test sessions and confidence test interval sessions,where the test session is split into several intervals conducted over a longer period

18

3.2. THE TWO-WAY ACTIVE MEASUREMENT PROTOCOL

of time, to achieve better reliability. Conformance tests between J-OWAMP ver-sion 1.2 and One-way ping version 1.6f were successfully performed[47], but thedevelopment of J-OWAMP ceased in 2005.

Java Client for OWAMP

Since the J-OWAMP project has been discontinued, the only current OWAMPimplementation is available for Unix systems. To facilitate for end users, a Javaimplementation featuring a manageable applet is desirable. M. Hofstra is currentlydeveloping the client part of OWAMP in Java to make it interoperable with Inter-net2’s One-way ping. This project is carried out as a part of Google Summer Code2008[48].

3.2 The Two-way Active Measurement Protocol

The Two-way Active Measurement Protocol, TWAMP, is a protocol for collectingtwo-way metrics[49]. The protocol is still in the development phase, it is currentlybeing reviewed and will probably be standardized in the near future. TWAMPis based on the OWAMP protocol and their architectures are very similar, thereare however important changes in the logical model. The session-receiver fromOWAMP is called session-reflector. Unlike the session-receiver it does not collectany measurement data, but instead upon arrival of a measurement packet, it sendsan immediate response packet back to the session-sender. In the TWAMP architec-ture, the session-sender is able to receive measurement data and to communicatethe results back to the control-client. Since the session-reflector does not collectany packet information, the role of fetch-client is superfluous, and this entity hasbeen removed from the TWAMP architecture. The role of the server is similar toOWAMP, it configures the test end points. However, if the server is implementedon the same host as a session-reflector, it is not able to return the measurementresults, as it was capable of in OWAMP. A model of the TWAMP architecture isshown in Figure 3.3.

Session-Sender

Server

Session-Reflector

Control-Client

Proprietaryprotocol

TWAMP-Test

Proprietaryprotocol

TWAMP-Control

Figure 3.3. Possible relationship between TWAMP’s logical roles.

19

CHAPTER 3. METHODS

3.2.1 TWAMP-Control

The procedure for creating test sessions is derived from OWAMP; the packet ex-change during the connection setup looks similar to OWAMP-Control and is carriedout in the same manner. A test session is negotiated to start between a session-sender and a session-reflector, where information about addresses, ports and securitymode is agreed upon. The session identifier is decided by the receiving side. Sincethe session-reflector does not process the incoming test packets, it does not needknowledge about the number of incoming packets or time when they were sent.Therefore, the send schedule defined in OWAMP has been removed. The TWAMPstop-session does not contain information about session identifiers or skip ranges,when a stop command is received, all previously requested test sessions are dropped.Since test packets are reflected by the session-reflector, the fetch-client is not used,and consequently, the fetch session command has been removed.

3.2.2 TWAMP-Test

The TWAMP-Test protocol is designed similarly to OWAMP-Test, with the excep-tion of the session-reflector, which responds with a packet for each test packet itreceives. Two different packet formats are used: the packet sent from the session-sender is exactly the same as the test packet defined for OWAMP, containingsequence number, timestamp, error estimate and optional packet padding. Thepacket transmitted by the session-reflector contains the information from the re-ceived packet along with its TTL, with additional timestamps and error estimateadded by the session-reflector. A detailed description of the packet format is shownin Appendix A.

Upon arrival of a packet, the session-reflector sets a timestamp, extracts theinformation from the packet, compiles a new packet and adds another timestampwhen the packet leaves the reflector. The session-reflector timestamps the packettwice so the time for processing the packet is accounted for, and then removed whencomputing the wire time in the control-client. The session-reflector must transmita response as immediately as possible when a test packet is received.

3.2.3 TWAMP Extensions

There are currently three drafts treating possible extensions of the TWAMP pro-tocol. As previously described, a TWAMP stop command drops all test sessions inprogress, and it is not possible to control single test sessions independently unlessseparate control connections are used. An independent session control feature[51]has been introduced to control test sessions based on their SID, allowing the control-client to start and stop test sessions irrespectively.

When selecting authenticated or encrypted mode for TWAMP sessions, thissetting applies to both the control and test protocol. Extended connection setup[52]has been proposed to allow the security mode to differ between TWAMP-Controland TWAMP-Test in a concurrent session.

20

3.3. REFERENCE METHODS

If there is a need of injecting further information into the test stream, additionaldata may be inserted as packet padding by the control-client or session-sender. Asuggested expansion[53] of the protocol introduces padding reflection, where thesession-reflector returns a number of unassigned bits back the session-sender.

3.2.4 Current Implementations

No open source implementation of the TWAMP protocol has been found at present.It is probable that new implementations will emerge as the standardization hasreached its final stage. The network company Shenick has announced that theirproduct diversifEye supports the full TWAMP standard[50]. However, this solutionis not freely available.

3.3 Reference methods

In order to properly evaluate the TWAMP implementation, two further methodswere used and their measurement results were compared. This passage briefly de-scribes the Ping utility and the method used by Prosilient Technologies for collectingperformance metrics.

3.3.1 Ping

Ping[8] is a well known utility which is included in almost every operating system.It is often used for determining if a host is properly connected to the network aswell as the round-trip time to that host. Ping uses the Internet Control MessageProtocol, ICMP, for sending its packets. The source host sends an ICMP packetof type 8, echo request, to the destination, which responds with an ICMP packetof type 0, echo reply[54]. The ICMP packets contain a sequence number, and bytimestamping when packets are sent and replies are received, the round-trip timecan be calculated. Depending on the implementation, the number of lost packetsand duplicates is reported. Although Ping is widely used, it is a bad way to measuredelays. ICMP packets are often treated differently than for example UDP packets,and may be rate limited in a router. Many devices also refuse to reply to an incomingecho request for security reasons.

3.3.2 PTAnalyzer

The PTAnalyzer, developed by Prosilient Technologies[43], is a system for networksupervision and end-to-end performance management. It provides both passive andactive measurements, but focuses on active performance tests by injecting config-urable traffic types into a network. The system architecture is partitioned into acontrol plane, a measurement plane and a synchronization plane. Instead of connect-ing the measurement probes to an external time source, the nodes are synchronizedby a patented software solution.

21

Chapter 4

Implementation and Results

The implementation phase was twofold; first an implementation of OWAMP-Testin unauthenticated mode was developed. Since there already exist several OWAMPapplications, the work was later focused on TWAMP. Thanks to the similarity ofthe two protocols, much of the code base could be reused.

4.1 TWAMP Light

TWAMP Light is an implementation with a simple architecture to easily providea network with light test points. The protocol can be implemented in a two hostscenario where the client side, known as the controller, constitutes the roles ofthe server, the control-client and the session-sender. The reflecting side of theimplementation is called responder, and contains the session-reflector. The testsessions are established through non standard means and TWAMP-Test packetsare exchanged.

The implementation was programmed in C and targeted towards a Linux plat-form. It resulted in two command line utilities that performed accordingly to thecontroller and responder. However, the logical role of the server was left out ofthe implementation and a control protocol was therefore also omitted, as well assupport for authenticated and encrypted test sessions. Figure 4.1 describes theimplementation.

Session-Sender

Control-Client

Session-Reflector

controller responder

TWAMP-Test

Figure 4.1. TWAMP Light implementation.

23

CHAPTER 4. IMPLEMENTATION AND RESULTS

Input to the controller is the address to the destination host, number of packets tosend, and a periodic sampling interval between the packets. Once started, the packettransmitter is forked into a separate process, and sends the TWAMP-Test packetsaccording to the input parameters. When the sender process is finished, its exitsignal is registered and a timeout of three seconds is set to wait for delayed packets.Thereafter, the session-sender terminates and reports the results to the control-client. The session-reflector performs as specified by the TWAMP-Test protocol. Itlistens for incoming packets on a specified port and sends a response upon the arrivalof each test packet. TWAMP Light without a control protocol is not as dynamicas an implementation in compliance with the complete TWAMP standard. Thisproject focuses however on the measurement method itself, and not on the setup ofthe latter, thus TWAMP Light is a good choice for evaluation.

Based on the test packets received by the session-sender, the control-client com-putes two-way performance metrics. The delay in each direction is reported, alongwith the packet loss, reorder, and number of duplicated packets.

4.2 Evaluation

Evaluating delays in a wide area network is a difficult task since it is hard to findgood reference values. The most accurate approach is to provide each test site witha reliable external clock, such as an atomic clock or a GPS receiver. These solutionsare costly, and other less expensive procedures were used to verify the implement-ation. Several tests were carried out in two different environments to evaluate themeasurement techniques. The first setup consisted of two hosts in a separated net-work, interconnected through a third computer which acted as a network emulator.In the second setup the two hosts were placed at different locations in Stockholmand the test traffic was routed over the Internet. The test probes were runningFedora 8 with a customized 2.6.24 Linux kernel on an Intel Pentium Celeron pro-cessor at clock speeds of 600 MHz and with 256 megabytes of RAM. An NTP serverlocated at KTH[55] in Stockholm was used for all measurements. The system clockswere synchronized every minute for optimal accuracy[56].

Netem Test Sessions

Netem[57] is an application which provides network emulation functionality by emu-lating properties of wide area networks. Netem consists of a small kernel modulefor queuing discipline, which is included in recent Linux kernels, and a configur-ation utility which is part of the iproute2 package. It is a useful tool for testingthe behaviour of different network protocols and provides options to emulate a realworld network response[58]. The current version emulates delay, loss, duplicationand reordering.

Netem implements the four different properties using statistical distributionsand correlation values between packets, which gives a good resemblance to realnetworks. In the case of evaluating network protocols it would also be desirable to

24

4.2. EVALUATION

be able to decide an exact percentage of loss, duplication and reorder for a specifiedwindow size of transmitted packets. The evaluation with Netem does unfortunatelynot provide this feature, but running the test sessions over a long period of timemakes the results more reliable.

Five separate one hour test sessions were carried out. During each session,TWAMP, One-way ping, PTAnalyzer and Ping ran in parallel, all methods used teststreams with 100 packets per second. In the first four test sessions, Netem emulatedone of the four properties delay, loss, duplication and reordering individually, sincethe properties might have influence on each other. During the last test session,all four properties were activated simultaneously. Netem’s emulation of delay wasactivated in both directions, but further metrics were only emulated on the reversepath between the two measurement nodes.

The emulator configuration was set to 20% loss rate and 15% duplication rate.The delay on the forward path was set to 50 milliseconds, and 100 milliseconds onthe reverse path. The reordering was set to 100% gap 100. This setting causesevery 100th packet to be sent immediately, and all other packets were delayed asusual, in this case with 100 milliseconds. The test setup is shown in Figure 4.2.

Probe A

Netem

Probe B

Delay: 50msDelay: 100ms

Loss: 20%Duplicate: 15%

Reorder: 100% gap 100

Figure 4.2. Probe A, the controller, sends TWAMP-Test packets to probe B, theresponder, which are reflected back. The emulator adds 50 milliseconds delay on theforward path, and adds 100 milliseconds delay together with the remaining metricson the reverse path.

25


Internet Test Sessions

During the second experiment, the different techniques were evaluated between twohosts in Stockholm interconnected through the Internet. Test site A was connec-ted through Telia and test site B had Bredbandsbolaget as ISP, the two hosts wereseparated by 10 hops. The quality of the two connections differed; the host at Bred-bandsbolaget had a round-trip time to the NTP server of about 1.5 milliseconds,while the round-trip time between the host connected to Telia and the NTP serverwas 11 milliseconds. Different NTP servers were evaluated, but the difference wasabout the same or worse, and the tests were carried out with the initial setup.

Three different tests were performed, and similarly to the previous test sessionswith the network emulator, all four measurement tools ran simultaneously. Duringthe first test session, no other traffic was deliberately injected into the network.However, the Internet connection at site A was shared with others, which unfortu-nately lead to a wide margin of error. During the second test session, the outgoingbandwidth from site A was strained by sending file transfers to another host, andduring the third session, the incoming bandwidth to site A was used. The test setupis shown in Figure 4.3.

The duration of the tests was reduced to 1 minute per test session, but eachsession was performed ten times in order to characterize a more accurate averageof the metrics. Since the bandwidth at site A was allocated to file transfers duringthe second and third test sessions, the NTP packets were delayed and the resultingmeasurement data was worthless. Therefore the system clock was synchronizedbefore the test sessions began, and the NTP daemon was shut down during thesessions. The sessions were kept short due to skew.

Probe A Probe B

Internet

Session 3

Session 2

Figure 4.3. Probe A, the controller, sends TWAMP-Test packets routed over theInternet to probe B, the responder, which are reflected back. During sessions 2 and3, the bandwidth at site A was used for file transfers in the outgoing respectivelyincoming direction.

26

4.3. RESULTS

4.3 Results

The outcome of the test sessions show that the different methods for measuring per-formance metrics behaved similarly. This section describes the results and discusseswhy some deviations occurred.

4.3.1 Netem Test Sessions

Five different test sessions were performed, during the first four, emulation of onlyone metric at a time was activated. During the last session all metrics were evaluatedsimultaneously.

Individual Tests

The results of the individual test sessions, shown in Table 4.1, turned out as expectedwith exception for the duplication rate and the reorder rate reported by Owping.

While the network emulator was adjusted to send duplicated packets with aratio of 15%, Netem computes the percentage based on the number of real pack-ets it receives. The performance metric applications, on the other hand, computethe percentage based on the total number of packets received, i.e. both real andemulated packets, which leads to a lower, but correct percentage.

The reorder metric was set to send every 100th packet immediately, and all otherpackets were delayed by 100 milliseconds. When a packet is sent immediately, itstarts a sequence discontinuity, which in this case lasted for 100 milliseconds untilthe packet stream had catched up. Since the packet rate was set to 100 packetsper second, approximately 10 packets passed the network emulator until the streamwas in order. After another 90 packets, the sequence starts all over again. Thiscauses 10 out of 100 packets (10%) to be reordered. The Ping utility does notreport reorder, and surprisingly, One-way ping only considers the early packet asreordered. Consequently it reports 1 packet out of 100 as reordered.

The mean delays vary somewhat, but none of the tools deviate more than 1.2milliseconds from the reference value, and their relative deviation is less than 0.7millisecond. The average round-trip time between the hosts without any emulationactivated was approximately 0.8 millisecond.

Table 4.1. Emulation of one metric at a time using Netem. 1w refers to the delayof the forward path, 2w refers to the delay of the reverse path.

1w (ms) 2w (ms) Loss (%) Duplicate (%) Reorder (%)Netem 50.00 100.00 20.00 15.00 10.00TWAMP 50.73 100.83 19.96 13.03 9.44OWAMP 51.15 100.24 20.03 13.05 0.97PTAnalyzer 50.76 100.17 20.09 13.02 9.47Ping 150.90 20.11 12.99

27


Complete emulation

All emulated metrics were applied simultaneously during the complete test session.The results are shown in Table 4.2. Combining packet loss and duplication had anobvious influence on each other. The results were not as close to Netem’s valuesas when only a single metric was emulated. All applications reported howeverapproximately the same differences which must be interpreted as the measurementswere still accurate. The PTAnalyzer system reported a slightly lower percentage ofreordered packets. This method does however not remove duplicated packets fromthe calculation, which leads to a lower ratio. The mean delay on the reverse pathwas slightly less than previous sessions, which can be explained by the reorderingwhere every 100th packet was sent immediately.

Table 4.2. Emulation of all metrics simultaneously using Netem. 1w refers to thedelay of the forward path, 2w refers to the delay of reverse path.

1w (ms) 2w (ms) Loss (%) Duplicate (%) Reorder (%)Netem 50.00 100.00 20.00 15.00 10.00TWAMP 50.65 99.83 16.88 10.30 8.58OWAMP 50.62 99.82 16.94 10.37 0.99PTAnalyzer 50.21 99.69 17.05 10.42 8.12Ping 149.94 17.05 10.31

4.3.2 Internet Test Sessions

The results from the test sessions where traffic was routed over the Internet areshown in Table 4.3. These values represent a 95% confidence interval based on theten measurements presented in Appendix B.

Some packet loss was reported during the last two tests sessions, but the ratiowas less than one percent. The NTP synchronization was turned off during the testsessions since when other applications used the bandwidth, the NTP packets wouldhave been delayed with approximately 60 milliseconds, and no consistent resultswould have been achieved. The round-trip time to the NTP server was longer forsite A, its system clock would fall behind and a slightly lower delay on the reversepath was expected.

We expected similar results from One-way ping and the TWAMP implement-ation as both methods rely on NTP synchronization, and slightly different valuesfrom PTAnalyzer and Ping. However, no such distinction could be made. Thefour methods reported approximately the same delay, but differences of up to 6milliseconds were measured. This value has to be considered large, and would mostlikely not be accepted when performing professional measurements. However, thelargest deviations occurred during session 2 when the link capacity was used foroutgoing file transfers. Since the UDP protocol is not aware of network congestionand delivers the packets on a best effort basis, a high latency difference between

28

4.3. RESULTS

lucky packets that experience minimum delay and packets that are queued up in abuffer is expected.

The results from the measurements in session 3 did not show the same deviations,and according to the delays, the link capacity was not used to the same extent asin session 2. This can be explained by the asymmetric Internet connection at siteA, which made it easier to fill the bandwidth in the outgoing direction.

The values from session 1 have to be considered reliable as the reported varianceis low. The deviation between the tools exceeds 1 millisecond on one occasion only.These values were more accurate than expected, and within the 95% confidenceinterval only sub millisecond deviations were reported. The measurements duringsession 1 were carried out carefully with consecutive updates from the NTP serverbefore each test, to make sure the shared Internet connection was used to the leastextent. These updates might however have had a negative influence on the resultsfrom the PTAnalyzer system. The PTAnalyzer does not rely on external timesources, but still uses the system clock during the synchronization phase. Resettingthe local time on the probes to UTC repeatedly may have deteriorated the accuracyof the system.

The measurements reported by the Ping application did not differ as much asexpected; although ICMP is often treated differently than other protocols, the valueswere of the same magnitude. The results from session 2 and 3 clearly show whyround-trip time should not be used for delay measurements, as it is impossible todistinguish in what direction the bottleneck has occurred.

Many different factors have influenced these results, and they form a vague basisfor giving an opinion about the methods. The bandwidth used at one of the testsites has been shared, and not solely dedicated to performance measuring. Thethree measurement sessions were performed on different occasions and the band-width used by others may have varied from time to time. The skew of the systemclock might also have been an issue.

Table 4.3. Delay results (ms) with 95% confidence intervals from the Internet testsessions. 1w refers to the forward path, 2w refers to the reverse path.

Session 1 Session 2 Session 31w 2w 1w 2w 1w 2w

TWAMP 6.51± 0.16 6.25± 0.13 68.72± 2.66 6.44± 0.11 6.69± 0.06 59.66± 0.70OWAMP 6.77± 0.16 6.24± 0.13 69.39± 3.10 6.50± 0.12 6.85± 0.22 59.98± 0.66PTAnalyzer 6.25± 0.18 6.19± 0.18 70.94± 2.64 6.52± 0.20 6.24± 0.26 59.88± 0.50Ping 13.20± 0.10 76.16± 2.89 66.58± 0.64

29

Chapter 5

Summary and Conclusion

The goal of the IETF IPPM work group has been to introduce a new interoper-able measurement standard. Apart from specifying how measurement tools canbe designed, the performance metrics themselves have been standardized. This isequally important, since values reported by different protocols can now be com-pared, provided that the different tools use the same metrics.

5.1 Discussion

One problem identified with the TWAMP test protocol is that it sends differentlyformatted packets in different directions. Larger packets require greater amounttime to be transmitted over a network, and differently sized packets introduce un-certainty into the measurement. A comparison between the two packet formats isshown in Appendix A. To achieve equally sized packets in both directions, packetpadding must be used when transmitting the packet from the session-sender. Thepadding must then be reduced or removed from the reflected packet since its datapayload is larger. A more sound approach would have been to use similar packets inboth directions and fill the unused bits with randomized data. This comment wase-mailed to the Internet Engineering Steering Group during a review of a TWAMPdraft, and two paragraphs treating this problem was inserted into the next versionof the draft.

A minor but questionable detail in the OWAMP and TWAMP protocols is theformat of the timestamp. The first 32 bits represent the number of seconds elapsedsince January 1900. When requesting the local time on a Unix system, the number ofseconds elapsed since 1970 is returned. Converting this timestamp into OWAMP’sformat is an unnecessary source of error.

Another problem with the TWAMP protocol is that it relies on the test protocolto report the results back to the session-sender. In OWAMP, the results of a one-waytest session are transmitted by the control protocol using TCP. TWAMP merges theresults from the forward path into the reflected test packets transmitted over theUDP protocol. If a TWAMP-Test packet is lost, there is no way of distinguishing on

31

CHAPTER 5. SUMMARY AND CONCLUSION

which path the packet loss occurred, and the measurement data in both directionsbecomes inaccessible.

If TWAMP Light is used without a control protocol, the sequence number ofa reflected packet is directly copied from the packet sent by the session-sender.This means that no distinction between the forward and reverse path can be madeconcerning reordering or packet duplicates.

An interesting feature of Internet2’s One-way ping is that it automatically startsan OWAMP session in each direction, allowing performance metrics of the twopaths to be reported independently. We name this approach Two-way OWAMP,TWOWAMP, and consider this more reliable than TWAMP. However, the currentInternet2 implementation uses completely different ports for the two test sessions,which may lead to incoming packets being blocked by a firewall. The TWAMPspecification states that the same port must be used for sending and receiving testpackets, and although UDP is used, a connection is established which may facilitatethe traversal through a firewall. A drawback with the One-way ping application isthat it only presents the minimum, median and maximum delay of the packets. Inorder to present the average value, a program setting to report each packet delayindividually was activated, and a script was compiled to compute the average delay.

There is a security related problem concerning the OWAMP and TWAMP proto-cols and measurement servers may be exploited to participate in a Denial of Service,DoS, attack. Public measurement nodes will typically offer some of their bandwidthto perform test sessions. Setting up streams of measurement packets between pub-lic nodes and an unsuspecting host, may lead to allocating the host’s resources,rendering it unusable. This is especially true for TWAMP Light where the sourceaddress of the UDP test packets can easily be spoofed, forcing all packets to bereflected to another party. To prevent this, the default behaviour of the OWAMPand TWAMP servers is to only accept test connections when the receiving addressbelongs to the server or to the host which setup the control-session. This securitymeasure is not available in TWAMP Light. Limiting the usage of resources suchas bandwidth and memory on a test server is also important. Otherwise the serveritself could become the target of a DoS attack.

The most difficult part when performing active end-to-end measurement is thetiming estimation. More precisely, the timestamping of packets and the synchron-ization between the end points. Publicly available solutions such as TWAMP aredesigned to work on many different end systems, without the need of special hard-ware or a customized system kernel. These solutions often rely on time updatesreceived from an NTP server. Depending on the requirements of the measure-ment, the accuracy of NTP may be sufficient. If the delay on the measured linkis on the order of hundreds of milliseconds, inaccuracy of a few milliseconds mightbe acceptable. One must also remember that it is not always latency that is ofprimary interest. Several performance metrics have been discussed and their valuesare reported independently of the clock offset.

32

5.2. IMPROVEMENTS AND RECOMMENDATIONS

5.2 Improvements and Recommendations

The obvious extension of the TWAMP implementation presented in this work isto introduce a control protocol in compliance to the specification. The second im-provement is to add support for authenticated and encrypted sessions. Concerningthe TWAMP protocol, better synchronization between the measurement nodes canbe achieved by introducing kernel level timestamping and by using an external timesource with better accuracy. It is recommended that packet padding is added bythe session-sender and then reduced or removed by the session-reflector to makethe packets in both directions equally sized. Three extensions of the protocol havealready been discussed in Section 3.2.3, and as TWAMP becomes a finalized IETFstandard, we think that the usage of the protocol will be widespread and furtherexpansions will evolve.

5.3 Conclusion

In this report we have examined the field of active network performance meas-urement. We have presented notions and metrics for measuring the quality of IPnetworks and we have implemented parts of the upcoming TWAMP standard. Theimplementation presented in this work has been evaluated by comparing it to threeother active measurement tools. The evaluation was performed in a separated net-work environment where the properties latency, loss, reorder and duplication wereemulated. Test sessions where traffic was routed over the Internet have also beenperformed.

The results from the experiments in the closed network environment show thatthe latency reported by the TWAMP software deviated approximately 0.8 milli-second from the emulated values. The true deviation in each direction can howeverbe computed to about 0.4 millisecond, since the actual link delay of 0.8 millisecondis not taken into account by the network emulator. The relative latency betweenthe different measurement tools differed by less than 0.7 millisecond. The remainingmetrics reported by the TWAMP implementation showed a loss deviation of 0.04percentage points, a duplicate deviation of 0.03 pp and a reorder deviation of 0.56pp, compared to the emulated reference values. As explained in this report, the net-work emulator uses statistical distributions, and deviations of this small magnitudeare difficult to avoid.

The evaluation over the Internet did also include some uncertainties; the band-width at one of the end-points was not solely dedicated to test traffic, nor did thissession allow a preset reference value. Multiple measurements were performed anda 95% confidence interval was calculated. With available bandwidth, the variancewithin the confidence interval was less than 0.2 millisecond for each measurementtool, and no more than 0.5 millisecond among themselves. The variance of theTWAMP implementation was 0.16 respective 0.13 millisecond in each direction.When traffic was deliberately injected into the network to fill up any available

33

CHAPTER 5. SUMMARY AND CONCLUSION

bandwidth, the variance increased to approximately 3 seconds. This shows theimportance of available bandwidth as the accuracy of the measurement was consid-erably deteriorated. If NTP is used for synchronization, link capacity is even moreimportant, as delayed NTP packets may be a source of error.

The TWAMP implementation presented in this report has been proven useful formeasuring network performance metrics. Although it is difficult to determine theexact one-way delay, the time reported by our application under stressed conditionshas differed by no more than 6 milliseconds from the reference methods. Under morefavourable conditions when bandwidth capacity was available, the measurementswithin the 95% confidence interval deviated in the sub millisecond range. Along withthe high correctness of the measurements in the emulated environment, the TWAMPimplementation must be considered successful, and the TWAMP protocol can beestablished as a competitive alternative for network performance measurements.

34

Bibliography

[1] Cisco Systems, White Paper: Cisco Visual Networking Index - Forecast andMethodology 2007-2012, June 2008.

[2] The Cooperative Association for Internet Data Analysis web page, last visit2008-10-01.http://www.caida.org/

[3] The Résaux IP Européens web page, last visit 2008-10-01.http://www.ripe.net/test-traffic/

[4] AT&T Research Projects web page, last visit 2008-10-01.http://research.att.com/projects.cfm#@a1

[5] Cottrell, L. et al. Web reference Comparison of some Internet Active End-to-end Performance Measurement projects last visit 2008-10-01.http://www.slac.stanford.edu/comp/net/wan-mon/iepm-cf.html

[6] Lepage, F. & Michaut, F. Application-oriented Network Metrology: Metricsand Active Measurement Tools. IEEE Communications Surveys and Tutorials,vol. 7(2), pp. 2-24, 2005.

[7] Corral, J. et al. End-to-end active measurement architecture in IP net-works (saturne). In proceedings of Passive and Active Measurement WorkshopPAM’03, 2003.

[8] Muuss, M. Web reference The Story of the PING Program, last visit 2008-10-01.http://ftp.arl.mil/~mike/ping.html

[9] Calyam, P. et al. Active and Passive Measurements on Campus, Regionaland National Network Backbone Paths. In proceedings of IEEE InternationalConference on Computer Communications and Networks (ICCCN), pp. 537-542,October 2005.

[10] Pathak, A. et al. A Measurement Study of Internet Delay Asymmetry. Inproceedings of Passive and Active Measurement Conference PAM’08, 2008.

[11] Jiang, W & Williams T. Detecting and Measuring Asymmetric Links in anIP Network. Global Telecommnications Conference vol. 3, pp 1727-1731, 1999.

35

BIBLIOGRAPHY

[12] Cottrell, L. Web reference Network Monitoring Tools, last visit 2008-10-01.http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html

[13] The Internet Engineering Task Force web page, last visit 2008-10-01.http://www.ietf.org

[14] The IP Performance Metrics web page, last visit 2008-10-01.http://www.ietf.org/html.charters/ippm-charter.html

[15] Paxson, V. et al. IETF RFC 2330, Framework for IP Performance Metrics,May 1998.

[16] Raisanen, V. et al. IETF RFC 3432, Network performance measurementwith periodic streams, November 2002.

[17] Friedman, T. Active Measurements. In proceedings of Journées TechniquesRéseaux, JTR 2004, 2004.

[18] Kobayashi, K & Shu, Z. HOTS: An OWAMP-Compliant Hardware PacketTimestamper. In proceedings of Passive and Active Measurement WorkshopPAM’05, 2005.

[19] Lewandowski, W. et al. Precision and Accuracy of GPS Time Transfer.IEEE Transactions on Instrumentation and Measurement, vol. 42(2), pp. 474-479, April 1993.

[20] National Physical Laboratory. Web reference GPS Time Server, last visit2008-10-01.http://www.ntp-time-server.com/gps-time-server/gps-time-server.htm

[21] Stempfhuber, W. System Calibration in Precision Farming. In proceedingsof 5th International Conference on Optical 3d Measurement Techniques, October2001.

[22] NIST IEEE 1588-2002 Standard for a Precision Clock Synchronization Protocolweb page, last visit 2008-10-01.http://ieee1588.nist.gov/

[23] Cohen, R. Precision Time Protocol (Presentaion). In proceedings of 68th In-ternet Engineering Task Force Meeting, March 2007.

[24] Minar, N. A Survey of the NTP Network, MIT, December 1999.http://alumni.media.mit.edu/~nelson/research/ntp-survey99/ntp-survey99-minar.ps

[25] Gunter, D & Tierney, B. A Standard Timestamp for Grid Computing(Draft). In proceedings of First Global Grid Forum & European Datagrid Cen-ference, March 2001.

36

[26] Mahdavi, J. & Paxson, V. IETF RFC 2678, IPPM Metrics for MeasuringConnectivity, September 1999.

[27] Almes, G. et al. IETF RFC 2680, A One-way Packet Loss Metric for IPPM,September 1999.

[28] Koodli, R. & Ravikanth, R. IETF RFC 3357, One-way Loss PatternSample Metrics, August 2002.

[29] Almes, G. et al. IETF RFC 2681, A Round-trip Delay Metric for IPPM,September 1999.

[30] Almes, G. et al. IETF RFC 2679, A One-way Delay Metric for IPPM,September 1999.

[31] Chimento, P. & Demichels, C. IETF RFC 3393, IP Packet Delay VariationMetric for IP Performance Metrics (IPPM), November 2002.

[32] Claise, B. & Morton, A. IETF Draft, Packet Delay Variation ApplicabilityStatement - draft-ietf-ippm-delay-var-as-01, July 2008.

[33] Morton, A. et al. IETF RFC 4737, Packet Reordering Metrics, November2006.

[34] Uĳterwaal, H. IETF Draft, A One-way Packet Duplication Metric - draft-ietf-ippm-duplicate-04.txt, July 2008.

[35] Morton, A. & Stephan, E. IETF Draft, Spatial Composition of Metrics -draft-ietf-ippm-spatial-composition-07, July 2008.

[36] Stephan, E. et al. IETF Draft, IP Performance Metrics (IPPM) for spatialand multicast - draft-ietf-ippm-multimetrics-08, September 2008.

[37] Chimento, P & Ishac, J. IETF RFC 5136, Defining Network Capacity, Feb-ruary 2008.

[38] International Electrotechnical Commission web page, last visit 2008-10-01.http://www.iec.ch/

[39] IEEE Standards web page, last visit 2008-10-01.http://www.ieee.org/web/standards/home/index.html

[40] International Telecommunication Union web page, last visit 2008-10-01.http://www.itu.int/publications/sector.aspx?sector=2

[41] ITU-T, Recommendation G.107, The E-model, a computational model for usein transmission planning, May 2000.

[42] Walker, J, NetIQ Corporation White Paper, Assessing VoIP Call QualityUsing the E-model, 2002.

37

BIBLIOGRAPHY

[43] Prosilient Technologies web page, last visit 2008-10-01.http://www.prosilient.com/

[44] Shalunov, S. et al. IETF RFC 4656, A One-way Active Measurement Pro-tocol (OWAMP), September 2006.

[45] Internet2 OWAMP Implementation web page, last visit 2008-10-01.http://e2epi.internet2.edu/owamp/

[46] J-OWAMP web page, last visit 2008-10-01.http://www.av.it.pt/jowamp/

[47] Veiga, H. et al. OWAMP Performance and Interoperability Tests. In pro-ceedings of 4th International Workshop on Internet Performance, Simulation,Monitoring and Measurement, February 2006.

[48] Java Client for OWAMP web page, last visit 2008-10-01.https://wiki.internet2.edu/confluence/display/GSoC/soc2008-owamp

[49] Hedayat, K. et al. IETF Draft, A Two-way Active Measurement Protocol -draft-ietf-ippm-twamp-09, July 2008.

[50] Shenick web page, last visit 2008-10-01.http://www.shenick.com/show_news.php?id=71

[51] Morton, A. IETF Draft, Independent Session Control Feature for TWAMP- draft-morton-ippm-twamp-session-cntrl-00, July 2008.

[52] Hedayat, K. & Morton, A. IETF Draft, More Features for TWAMP -draft-morton-ippm-more-twamp-02, July 2008.

[53] Ciavattone, L. & Morton, A. IETF Draft, TWAMP Reflect Padding Fea-ture - draft-morton-ippm-twamp-reflect-padding-00, July 2008.

[54] Postel, J. IETF RFC 792, Internet Control Message Protocol, September1981.

[55] Royal Institute of Technology web page. last visit 2008-10-01.http://www.kth.se/?l=en_UK

[56] Smotlacha, V. One-way Delay Measurement Using NTP. In proceedings ofTERENA Networking Conference, May 2003.

[57] Netem web page, last visit 2008-10-01.http://www.linuxfoundation.org/en/Net:Netem

[58] Hemminger, S. Network Emulation with NetEm. In proceedings of LinuxConference Australia, linux.conf.au 2005, 2005.

38

Appendix A

Format of Test Packets

This document describes the different types of test packets transmitted by theOWAMP[44] and TWAMP[49] test protocols in unauthenticated mode.

Test Packet from the Session-sender

Figure A.1 shows the format of a test packet transmitted by OWAMP’s and TWAMP’ssession-sender. The packet contains a 32 bit sequence number, a 64 bit timestamp,a 16 bit error estimate of the synchronization and an optional packet padding ofvariable length.

Sequence Number

Timestamp

Error Estimate

0 15 31

Packet Padding

Figure A.1. Test packet transmitted by OWAMP’s and TWAMP’s session-sender.

39

APPENDIX A. FORMAT OF TEST PACKETS

Test Packet from the Session-reflector

Figure A.2 shows the format of a test packet transmitted by the TWAMP session-reflector. The sender sequence number, the sender timestamp and sender errorestimate are copied from the received packet. The receive timestamp represents thetime the arriving test packet was received by the reflector, the error estimate is theresponder’s estimate of synchronization error, the timestamp indicates when the testpacket was reflected back to the session-sender and the sequence number is generatedindependently from the identifier of the arriving packets. If TWAMP Light is used,the sender sequence number is used as sequence number. This information alongwith 8 bits indicating the TTL of the arriving packet and an optional packet paddingof variable length constitute the test packet. The bits labelled MBZ (must be zero)are set to zero and must be ignored by receivers.

Sequence Number

Timestamp

Error Estimate

0 15 31

MBZ

Receive Timestamp

Sender Sequence Number

Sender Timestamp

Sender Error Estimate MBZ

Sender TTL

Packet Padding

Figure A.2. Test packet transmitted by TWAMP’s session-reflector.

40

Appendix B

Internet Test Sessions

This document presents the delay measurements from the Internet test sessions.1w refers to the delay of the forward path, 2w refers to the delay of the reverse path.

Table B.1. Delay (ms) from Internet test session 1.

TWAMP OWAMP PTAnalyzer Ping1w 2w 1w 2w 1w 2w RTT

6.30 6.31 6.56 6.29 5.76 6.26 13.086.51 6.17 6.73 6.22 6.39 5.94 13.066.47 6.28 6.73 6.29 6.46 6.41 13.216.11 6.59 6.37 6.56 6.63 5.89 13.116.35 6.39 6.62 6.39 6.11 6.16 13.166.53 6.27 6.83 6.28 6.41 6.01 13.256.56 6.22 6.86 6.19 6.37 6.06 13.236.68 6.08 6.94 6.06 6.20 6.48 13.196.85 6.27 7.10 6.27 6.02 6.64 13.556.76 5.91 7.04 5.87 6.20 6.01 13.11

41

APPENDIX B. INTERNET TEST SESSIONS



65.46 6.51 65.93 6.66 65.66 6.54 72.6067.05 6.54 67.68 6.59 70.84 6.22 73.6768.04 6.25 68.00 6.30 68.84 6.70 76.3267.02 6.21 67.20 6.27 71.01 6.35 73.8377.12 6.62 79.79 6.71 76.52 6.41 85.8466.76 6.48 67.26 6.52 72.10 6.89 75.4973.85 6.62 74.20 6.66 77.61 6.94 80.2366.75 6.23 67.31 6.30 68.05 6.57 73.5667.05 6.51 68.15 6.54 68.69 6.62 73.8068.07 6.44 68.39 6.47 70.10 6.03 76.30



6.58 58.68 6.83 59.23 6.80 59.01 65.726.63 60.35 6.85 60.80 6.22 60.96 66.826.62 59.53 6.89 59.99 6.05 59.65 66.436.80 61.36 7.00 61.96 5.73 60.12 68.496.61 60.74 6.02 60.05 5.87 60.24 67.386.65 58.71 6.93 59.21 6.25 59.88 65.886.74 58.90 6.97 59.07 6.61 58.64 65.816.81 59.27 7.07 59.54 6.07 59.48 66.166.77 58.67 7.04 59.30 6.77 60.31 65.946.73 60.34 6.92 60.62 6.04 60.54 67.18

42

TRITA-CSC-E 2009:038 ISRN-KTH/CSC/E--09/038--SE

ISSN-1653-5715

www.kth.se

performance measurement of ip networks using the two-way active

Documents