Performance Measurement

of IP Networks using the Two-Way

Active Measurement Protocol

INGMAR BÄCKSTRÖM

Master of Science Thesis

Stockholm, Sweden 2009
 Performance Measurement
of IP Networks using the Two-Way
Active Measurement Protocol

INGMAR BÄCKSTRÖ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
 Abstract
Computer 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 IP
are becoming more popular. These types of services are sensitive to dis-
turbances; therefore it is important that the providing networks meet
their requirements. To verify the quality of a network and to gather
knowledge 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 and
methods for measuring the quality of IP networks. An implementation
of 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 as
it collects two-way performance data in one measurement. Metrics such
as latency, packet loss, packet duplication and packet reorder have been
measured, and the results show that TWAMP is a competitive protocol
for 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ånga
nya 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 det
underliggande nätverket uppfyller tjänsternas krav. För att verifiera
nätverksanslutningens prestanda och för att undersöka dess egenska-
per har flera metoder för tjänstekvalitetsmätningar utvecklats. Det här
examensarbetet 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 är
det första protokoll av sitt slag som har standardiserats, då det samlar
två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, och
resultaten visar att TWAMP är ett bra alternativ för att genomföra
tjänstekvalitetsmätningar av IP-nätverk.
Acknowledgements
This master’s thesis was conducted at Prosilient Technologies, and I would like to
thank my colleagues for their input and for their encouragement.
I would especially like to thank my supervisor Olof Hagsand for his support
and for the time that he has invested in this project, as well as for giving me the
opportunity to gain a better understanding of the field of network performance
measurement.

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

Contents

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Network Performance 5
2.1 Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Singletons, Samples and Statistics . . . . . . . . . . . . . . . 5
2.1.2 Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Timing Considerations . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Loss Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Round-trip Delay . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5 One-way Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.6 Delay Variation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.7 Reordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.8 Duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.9 Further metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Methods 15
3.1 The One-way Active Measurement Protocol . . . . . . . . . . . . . . 15
3.1.1 OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Current Implementations . . . . . . . . . . . . . . . . . . . . 18
3.2 The Two-way Active Measurement Protocol . . . . . . . . . . . . . . 19
3.2.1 TWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 TWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3 TWAMP Extensions . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4 Current Implementations . . . . . . . . . . . . . . . . . . . . 21
3.3 Reference methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
 3.3.2 PTAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Implementation and Results 23

4.1 TWAMP Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Netem Test Sessions . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Internet Test Sessions . . . . . . . . . . . . . . . . . . . . . . 28

5 Summary and Conclusion 31

5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Improvements and Recommendations . . . . . . . . . . . . . . . . . . 33
5.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 decade
and the trend is evident; the Internet continues to grow rapidly. According to
a forecast, Internet traffic increased with 46 percent in 2007 and is estimated to
grow by another 51 percent in 2008[1]. The annual growth rate will then slightly
decrease, and by 2012 the total annual IP traffic is estimated to reach about 500
exabytes per year. Internet video, excluding peer to peer file sharing, accounts today
for one quarter of all consumer Internet traffic. The forecast points out that high
definition 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 consuming
as visual media, this service still requires available bandwidth to operate, and as
all interactive real time applications, it is sensitive to quality disturbances in the
network. To assure the quality of these services, it is important that the providing
Internet connection fulfils the requirements of capacity and available bandwidth.
Network performance measurement is not a new phenomenon, but lately, this
field has come more in focus. This science, also known as communication network
metrology, is very wide, and several research projects have been launched with
different purposes[2][3][4][5]. Some studies investigate traffic characterization and
traffic modelling, whereas others focus on network topology or path symmetry.
The results of the projects are useful for several parties: researchers can adopt
network characteristics in simulation models to develop new network protocols;
Internet Service Providers, ISPs, can determine network trends for resource capacity
planning and discover performance bottlenecks; network equipment designers might
find the data useful when designing routers, and the end-users are interested in
measuring the quality of the Internet connection they are paying for. Consumers
using real time services with Quality of Service constraints, QoS, often negotiate QoS
levels with their ISP through a Service Level Agreement, SLA. Network performance
measurement is an efficient approach for customers to verify the SLA, as well as
a marketing strategy for ISPs to demonstrate the capacity and reliability of their
networks.

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 only
observed, and packet headers are captured and analyzed. The passive mode can yet
again be divided into two sub types. At a microscopic level, the passive measure-
ment analyzes every packet passing through the measurement node and notes its
characteristics. When measuring at a macroscopic level, packets passing through
the node are aggregated into flows and then analyzed. Passive network performance
measuring techniques are especially useful for traffic engineering, as they describe
flow 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 type
of 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 nodes
is a difficult task.
Active monitoring techniques are on the other hand well suited for performing
end-to-end measurements between nodes in a network. Measurement data, or probe
packets, are injected into the network. The packets are transmitted between the
test end points, and measurement data is collected upon the packets’ arrival. This
method can also be divided into different sub categories. Cooperative measurement
tools consist of a client and a dedicated server for collecting measurement metrics.
When applying non cooperative tools, only one client program is used. Measurement
data is sent to an existing, independent server, such as a web server, and its response
is used for computing the result. Other tools rely on generated replies, such as ICMP
messages.
A problem with active measurement techniques is that they generate traffic, and
may influence the behaviour of the network. This problem is known as intrusiveness
or invasiveness. When designing active measurement tools, it is therefore important
that the amount of data generated by the probe packets does not affect the network
performance.

Approaches for Active Network Measurements

When performing active measurements, probe packets are typically timestamped at
the source host, transmitted by the network to the destination host where another
timestamp is recorded. When a sufficiently large number of test packets have been
transferred between the end points, statistics such as packet loss, latency, packet
reorder 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 has
then been calculated as half the RTT[9]. However, several studies[10][11] show
that path asymmetry often prevail between end points in a large network, and this
approximation is therefore incorrect.

2
1.2. PURPOSE

Several sophisticated measurement tools[12] have been developed in order to give

a more accurate representation of communication networks. Measurements distin-
guish the forward path from the reverse path, probing packets can be shaped to
resemble actual traffic and tools can be used to monitor the network performance
from 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 input
packets and analyze the packets output by the network. This makes the procedure
simple but yet powerful as test endpoints, either software or hardware nodes, can
easily be moved to different locations in the network to isolate a malfunctioning
link.
Several different tools for active network measurement exist, but these tech-
niques lack interoperability. The Internet Engineering Task Force, IETF[13], is an
open international community developing Internet standards. It consists of many
work groups, and the IP Performance Metrics work group, IPPM[14], is currently
releasing 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 network
measurement area. The problem within this field is the lack of interoperable tools,
and in this project we have implemented and evaluated the upcoming TWAMP
standard. The thesis is focused on the progress of the IETF IPPM group, and
describes metrics and methods used for network performance measurement. An
implementation of the TWAMP protocol has been made and compared to existing
measurement 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, the
reader will achieve comprehension of what we actually measure. The third chapter,
Methods, explains how the measurements are carried out. We elaborate on four
different active measurement techniques, with focus on OWAMP and TWAMP. In
the 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 well
as 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 IPPM

work group has defined a framework for performance metrics[15]. This chapter
describes notions and metrics that are useful when performing measurements in an
IP network.

2.1 Notions
2.1.1 Singletons, Samples and Statistics
The metrics can be separated into three distinct categories. A singleton metric is a
single, atomic measurement of a packet characteristic, for example the loss or the
delay of a packet. Sample metrics are derived from singleton metrics by collecting
a sequence of distinct instances together. A sample metric of packet delay between
two hosts can be defined as a collection of singleton delay metrics between the two
nodes during one hour. The singleton metrics are collected at intervals defined
by a statistical distribution. Statistical metrics are derived from sample metrics by
computing statistics of the collected samples. By computing the mean latency value
of 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 sampling
is used, measurements are collected with fixed intervals. Samples can also be col-
lected at moments random in time, and the sampling intervals are then determined
by a statistical distribution.

Periodic Sampling
With periodic sampling, samples are derived from measurements separated by a
fixed 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 and
video traffic[16].
This method does however have drawbacks since regularly spaced singleton
measurements may be synchronized with other periodic behaviours in the network.
There is therefore a risk that the measurement only observes parts of the periodic
pattern, 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 be
manipulated. Components in the network can anticipate when measurements are
being made and can then temporarily change their behaviour, which will result in
false 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 only
analyses parts of the performance spectrum, this may well match the spectrum used
for media flows, which simplifies the estimate of the application performance.
The analysis of network performance is also simplified in other ways. Some
characteristics of a network, such as delay variation and reordering, are sensitive to
the sampling frequency. When the impairments are time-varying themselves, the
analysis can be facilitated by a constant sampling frequency.

Random sampling
To avoid the potential problems with periodic sampling, another method called
random additive sampling can be used. The samples are collected at randomly
generated intervals with a common statistical distribution. The randomness of the
samples depends on the quality of the distribution. If the function for example
generates a constant value with probability one, then the sampling is equivalent to
periodic 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 the
exponential distribution is used. Poisson sampling uses exponential distribution
with rate lambda to compute the arrival of new samples. With Poisson sampling it
is impossible to predict arrival time of the next sample, a feature which sometimes
is desired. There are other similar techniques based on statistical distributions
for collecting samples. The geometric sampling is closely related to the Poisson
sampling, and its arrival times for sampling cannot be predicted either. These
methods do however not model media streams with the same accuracy as periodic
sampling does.

2.1.3 Timing Considerations

When performing latency measurements in a network, timing between nodes is
crucial for obtaining consistent results. This paragraph explains notions related to
clock 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 and
the true time defined by Coordinated Universal Time, UTC. The difference in time
between two clocks is called the relative offset or synchronization. It is not always
critical that the offset is zero as long as all measurement nodes agree on what time it
is. 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’s
offset is zero, it is described as accurate. Skew measures the change of a clock’s
accuracy in time, a clock might for example gain or lose a couple of milliseconds
per hour. A clock’s skew may be affected over time by for example changes in
temperature. Drift measures the variation of skew in time.

Wire time
Active delay measurement techniques usually include timestamping packets at end
hosts 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 is
timestamped. The notion wire time defines the time taken for a packet to travel
between hosts. Let us introduce an Internet host observing the link in question in
order to make these concepts clearer. The wire exit time for a packet on that link
is the time when the observation host has spotted all bits of the packet. The wire
arrival 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 transmission
time at the MAC interface.
In practice, timestamps are set and read by measurement software just prior to
sending or after receiving a packet, these are known as host times. The difference
between wire times and host times depends on the latency between receiving the
packet 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 for
timestamping and directly synchronized to a GPS receiver[18], or by timestamping
the 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 is
however 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 for
reception. 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
 CHAPTER 2. NETWORK PERFORMANCE

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 where
the top of the tree, stratum 1, consists of computers synchronized to an external
source, typically an atomic clock or a GPS receiver. Computers synchronized to
stratum 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 which
peers 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 received
by a server. In that manner, discontinuity is prevented and the transition to the
correct time is made smoother. The accuracy of NTP depends on the quality of the
network connection between the server and the client, but with a reasonably good
link, 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 this
metric, 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 arrive
to its destination or not. This metric is mostly used as building blocks for further
connectivity 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 directions
between two hosts. If both hosts comply with this criterion to one another, they
fulfil 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 momentary
as the previous metric. This metric might however not be useful when defining full
connectivity. 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 one
another. Another metric called interval temporal connectivity is defined as a source
host having instantaneous connectivity to its destination within a time interval,
and the destination host has instantaneous connectivity back to the source host at
a later time in the same interval. This interval is specified to be long enough for
transmitting a packet and its response between two hosts. The packets sent in the
two directions may be of different types, since some applications use different types
of 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 transmitted
over the network or not. The singleton metric definition for one-way packet loss from
a source host to its destination at a specific time is described with a boolean[27]. Its
value is zero if the destination host received the packet, and one otherwise. With
this metric it is also important to separate lost packets from packets received with
a large delay. For many applications, treating packets with long delay as lost is not
considered a big problem. For example, a TCP packet which is delayed with several
multiples of the round-trip time may as well have been declared lost. Packets from
media 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 another
communication channel, possibly a control protocol, by which the destination host
knows 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 loss
rates but different loss distributions can present two widely different performance
experiences. Loss distance describes the difference in sequence numbers between
two lost packets, defined as zero for the first packet lost. A loss period begins if the
previous packet was received as expected, and the current packet is lost. With this
definition 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 each
time a new loss period begins. The loss period for a successfully received packet is
zero. An example of loss distance and loss period is shown in Figure 2.1.

Loss period: 1 2 3

s1 s2 s3 s4 s5 s6 s7 s8 s9

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

9
 CHAPTER 2. NETWORK PERFORMANCE

2.2.4 Round-trip Delay

The round-trip delay metric measures the time it takes for a packet to be transmitted
from the source host to its destination, and then back again[29]. The source host
timestamps the packet upon transmission. When the destination host receives the
packet, it immediately sends another packet as response back to the source. When
the response packet is received, the source host records another timestamp. The
value of the metric is then computed by subtracting the two timestamps and any
known uncertainties. If the packet is lost, the round-trip delay is undefined. No
distinction is made between in what direction the packet was lost. The definition
itself is ambiguous in that matter: it is not specified which node acts as source, and
which one acts as destination. There is no strict need for synchronization between
the two hosts, since only the source host performs and collects the timestamps. If
its clock is synchronized with a time service, erroneous results may be presented if
the 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 measurements
examine the union of two distinct paths, and do not treat the forward and reverse
path separately. One-way delay is a singleton metric measuring the time taken for
a packet to travel from the source host to its destination[30]. An upper bound for
the metric needs to be specified to determine whether a packet is delayed but still
on its way, or whether it is lost. The metric is undefined or infinite if the packet
never is received. If multiple copies of the same packet are received, the arrival time
of the first packet establishes the one-way delay. The methodology for determining
the delay varies depending on the type of the packet, but the approach is similar
for all types. To achieve fruitful measurements, it is important for the sending and
receiving hosts to have synchronized clocks. It is also important that the padding of
the test packet is filled with randomized bits to avoid that the packet is compressed
on 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 for
measuring the performance of a network, in most cases it is the maximum delay
variation within a high percentile that is of interest. This is particularly true for
media streams which require a delivery of packets at regular intervals, and the
measurement 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 packets
within a stream[31]. The singleton metric one-way ipdv defines a single instance
of an ipdv measurement, but the measurement is only statistically usable when
combined in pairs. The measurement is performed by sending a stream of equally
sized packets between the measuring nodes, and two packets are selected from the
stream. The two packets are timestamped at the source and at the destination
hosts, and the one-way delay metric is computed. The one-way delays of the two
packets are subtracted, and the inter packet delay variation can be measured. Using
this technique, the clock synchronization between the two hosts is not as crucial
as in one-way delay measurements, the relative offset is not noticeable after the
subtraction. If one or both of the chosen packets are lost or do not arrive within
the specified time limit, the IPDV metric is undefined.

Packet Delay Variation

Instead of comparing two following packets in the stream, PDV uses a reference
packet from the interval, typically the packet with the lowest delay. The PDV of a
packet 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 values
that are positive or zero[32]. This metric has not yet been standardized by the IETF
IPPM group, but a draft documenting the difference between IPDV and PDV has
been released.
Both metrics are affected by the packet loss ratio, but only IPDV is affected by
the loss distribution. In the worst case where every other packet is lost, IPDV is
unusable. IPDV can however measure the network’s ability to retain the original
spacing between packets, it does also reduce the demands on the system’s clock
in the aspect of skew and stability. IPDV is memory less and only describes the
difference in delay between two adjoined packets whereas PDV is defined over a
longer interval. PDV is a more usable metric, and especially PDV percentiles are
used when sizing play out buffers and describing long-term trends. A comparison
of values between IPDV and PDV is shown in Table 2.1.

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

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

11
 CHAPTER 2. NETWORK PERFORMANCE

2.2.7 Reordering
Packets sent over a network might be transmitted over different paths, and may
therefore not be received in the intended order. The Internet Protocol does not
account for lost or misplaced packets, and this must be taken care of by higher-level
protocols. To accomplish correct packet order, each packet must contain a unique
identifier, a sequence number, which identifies the order in which the packets were
sent. The sequence number is then used at the destination to detect rearranged
packets. As an example, eight packets, sent with consecutive sequence numbers,
arrive to their destination as described in Figure 2.2.
Reordered

s1 s2 s3 s7 s4 s5 s6 s8

e=3 e=2 e=1

New sequence discontinuity
of size 3.

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 packet
with sequence number s7 is reordered, or packets with identifiers s4, s5 and s6 are
labelled as misordered. The IETF IPPM group defines packets with lower packet
identifiers than their predecessors, or late packets, in this case packets with sequence
number s4 to s6, as out of order[33]. Using the alternative definition and declaring
packet s7 as reordered is not recommended, since it is upon the arrival of packets
s4 to s6 that separates this occurrence from packet loss.
The goals of reordering metrics are to determine whether or not a packet has
been reordered and to what degree. To determine the extent of reorder, a number of
different metrics have been defined to fulfil the need of different applications. The
first notion is a function that generates a series of unique increasing numbers, this
could simply be an increase of a consecutive integer. The second basic concept is
an algorithm at the receiving side, a counter, which determines the next expected
sequence number. Normally, this number equals the sequence number of the previ-
ously received packet increased by one. The metric reordered defines if a packet is
misordered or not. The metric is false if the sequence number of the received packet
is equal to or larger than the next expected sequence number, and the counter is
then 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 are
received, only the first packet is considered reordered. If a packet arrives with a lar-
ger sequence number than expected, this indicates a sequence discontinuity caused
by either packet loss or reordering. The size of the discontinuity is the number of
missing packets and can be computed by subtracting the expected sequence number
form the arrived packet’s identifier. Source code for calculating the named metrics
is 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 with
the number of total packets received, excluding duplicates. This metric gives an
estimate of the percentage of reordered packets in the network. If the value is zero
there is no need to apply further reordering metrics to the stream.
The sample metric reordering extent stream defines to what extent the packets
in a stream have been reordered. The reordering extent is the distance in packets
between a reordered packet, and the earliest packet received with a larger sequence
number.
Late time stream defines the lateness of a reordered packet. By calculating
to what extent the packet has been reordered, its expected arrival time can be
compared to its real destination time, and the lateness can be computed. The sample
metric byte offset stream indicates the storage in bytes needed to accommodate the
reordered packets. The byte offset value for a reordered packet is the total payload
size of packets with a larger sequence number that arrived prior to the reordered
packet. These packets can then be buffered until the previous sequence of packets
is complete.
Reordering gaps describe the distance between reordering discontinuities and
reordering free runs define the number of consecutive ordered packets between mis-
ordered packets. The reordering metrics are particularly useful when designing
general receiver buffer systems.

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

if s > NextExp then
SequenceDiscontinuty = True;
SeqDiscontinutySize = s - NextExp;
else
SequenceDiscontinuty = 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 expects
exactly one copy of each sent packet. We have already discussed packet loss, but
this passage treats the opposite occurrence: when a packet is sent, multiple copies
arrive to the receiving node. This case has not yet been standardized by the IETF
IPPM group, but an Internet draft has been published[34].
The metric one-way packet arrival count is an integer that measures the number
of identical and uncorrupted copies of a packet which are received by a measurement
node during a specified time interval. Packets are considered identical if they contain

13
 CHAPTER 2. NETWORK PERFORMANCE

identical information fields and if they were sent between the same hosts. The IP
headers do not need to match, since for example the time to live, TTL, field may
vary if a duplicated packet has been routed differently. If no packet is received the
metric is undefined. The metric one-way packet duplication is similar to one-way
packet 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 a
single copy of a packet is received, the metric is zero, and it is undefined if no packet
has arrived. This metric equals to one-way packet arrival count subtracted by one.
There are two proposed statistical metrics for one-way duplication. One-way
packet duplication fraction and rate gives the fraction and rate of additional packets
that arrived in a stream. The fraction is calculated by removing all packets with
undefined values of one-way packet duplication, and the difference is then divided
by 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 than
one.

2.2.9 Further metrics

The number of different network measurement tools[12] is very large, and the list
of performance metrics can of course be elongated. The IETF IPPM work group
has released standards and drafts which treat several new concepts.
Spatial composition[35] computes the performance of a complete path based
on measurements from separate path segments, and multi metrics[36] describe how
measurements can be performed in a multicast scenario with one source and multiple
destinations. 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 be
used to assess conversational quality by evaluating parameters such as latency,
packet delay variation, packet loss and encoding technique. This model can be
mapped to an estimated mean opinion score, MOS[42]. The MOS is a subjective
metric indicating the perceived quality of received media, and is well suited for
evaluating the quality of VoIP applications.

14
Chapter 3

Methods

Four different measurement methods have been compared in this thesis, and the
techniques differ somewhat from each other. The evaluation has been based on res-
ults collected from the TWAMP prototype implemented in this project, Internet2’s
One-way ping, Ping and PTAnalyzer developed by Prosilient Technologies[43]. The
well known Ping utility uses the ICMP protocol to transmit its packets, and does
only calculate the round-trip time. Ping is therefore not affected by unsynchronized
clocks. 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 by
OWAMP and TWAMP, but since these two methods rely on the system time, it is
of 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 measurement
end 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 of
interoperability the IETF IPPM group has published a new standard for one-way
measurements. The One-way Active Measurement Protocol, OWAMP, analyzes
unidirectional network characteristics, and can calculate metrics such as one-way
loss and one-way delay[44]. The authors’ vision is to make one-way measurements
as common as the usage of today’s ICMP based round-trip measurements. This
can be achieved by a widespread deployment of open OWAMP servers and the fact
that 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 the
network, are to provide flexible measurement nodes and that the protocol traffic
will be difficult to detect and manipulate. The traffic is difficult to detect since it
consists 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 traffic
impossible to alter and indistinguishable from other data in the network.

15
 CHAPTER 3. METHODS

The OWAMP protocol consists of two different protocols: OWAMP-Control and

OWAMP-Test. The control protocol is used for setting up and terminating test ses-
sions, collect results etcetera, whereas the test protocol constitutes the test packets
exchanged 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 two
protocols 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 are
described in Figure 3.1.

Session- OWAMP- Session-

Sender Test Receiver
y
rietar
Prop col
prot o
Server
Proprietary
protocol OW
OWAMP- Co AMP
Control ntr -
ol

Control- Fetch-
Client Client

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

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

Control-
Client OWAMP-
Control
Server
Fetch-
Client
Session- OWAMP- Session-
Sender Test Receiver

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 a
well-known port, and this connection remains open throughout the entire OWAMP
session. OWAMP-Control data is transmitted only before and after the test, and
not during the test session itself, with the exception of a request for terminating
the 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 from
being injected by unknown users, and encryption prevents routing equipment from
distinguishing the stream of test packets and alter its priority.
The control connection is initiated by the control-client. The server responds
with a greeting, and presents supported modes, a challenge and other parameters
used to setup the test session. These parameters are used in authenticated and
encrypted modes and will not be thoroughly discussed here. If the server does not
want to communicate, e.g. due to the limit of maximum concurrent tests has been
reached, 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 if
the desired mode is not supported, otherwise it must transmit a packet containing
the mode of the current session. The next packet exchanged is sent from the server
to the control-client and contains an accept field and a timestamp indicating the
time when the instance of the current test server was created. The connection setup
is now complete. The control-client can now issue one of the following commands:
request-session, start-session, stop-session and fetch-session. The packets exchanged
during a request-session contains information about addresses, ports, packet size,
number of test slots, number of packets, start time, timeout and a unique session
identifier, SID. The server responds with an accept-session message to confirm the
upcoming test session. The control-client and the server have now agreed on a
send schedule; in case of lost packets, the session-receiver still knows when they
were supposed to be sent. The test session is started when the client issues a start
command. The server transmits a start acknowledgement, and if the session was
accepted, the test streams are started immediately.
When test sessions have ended, or in order to cancel a test session before it is
completed, 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 sequence
numbers indicating which packets that will be excluded from the test session. When
a 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. The
server responds with a fetch acknowledgement and then transmits the timestamped
packet records back to the control-client, which computes one-way metrics on the
received 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. The
test packets contain a sequence number, a timestamp indicating when the packet
was sent, an error estimate representing the sending host’s offset to UTC and an
optional packet padding. The timestamp consists of 64 bits where the first 32 bits
are an unsigned integer indicating the number of seconds elapsed since January
1900. 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 is
used. 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 sequence
number, send time, receive time and TTL from the IP header. This data will later
be 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 about
six years later, in September 2006, the final standardizing document was released.
Three different implementations of OWAMP have been distinguished, of which one
project was discontinued in 2005. Possibly a larger number of implementations have
been 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. The
current stable implementation, version 3.0c, was released in 2007. It supports the
complete standard and is available for Unix-like systems. One-way ping is a typical
client-server application, where the client program, Owping, contacts the server
running a daemon known as Owampd. When the send schedule is negotiated, each
side spawns a child process which constitute the test end points. The two end points
are identical, and by default, two measurement sessions, one in each direction, are
started and the results are returned back to the client.

J-OWAMP
J-OWAMP[46], a Java implementation of the OWAMP protocol has been made
available by H. Verga et al. It is platform independent and does also include a web
interface where sessions can be configured and results presented visually. Another
feature of J-OWAMP is its built in NTP client, which offers direct synchronization
with an NTP server. This eliminates the need of a synchronized system clock. The
program 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 the
development of J-OWAMP ceased in 2005.

Java Client for OWAMP

Since the J-OWAMP project has been discontinued, the only current OWAMP
implementation is available for Unix systems. To facilitate for end users, a Java
implementation featuring a manageable applet is desirable. M. Hofstra is currently
developing 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 Code
2008[48].

3.2 The Two-way Active Measurement Protocol

The Two-way Active Measurement Protocol, TWAMP, is a protocol for collecting
two-way metrics[49]. The protocol is still in the development phase, it is currently
being reviewed and will probably be standardized in the near future. TWAMP
is based on the OWAMP protocol and their architectures are very similar, there
are however important changes in the logical model. The session-receiver from
OWAMP is called session-reflector. Unlike the session-receiver it does not collect
any measurement data, but instead upon arrival of a measurement packet, it sends
an immediate response packet back to the session-sender. In the TWAMP architec-
ture, the session-sender is able to receive measurement data and to communicate
the results back to the control-client. Since the session-reflector does not collect
any packet information, the role of fetch-client is superfluous, and this entity has
been removed from the TWAMP architecture. The role of the server is similar to
OWAMP, it configures the test end points. However, if the server is implemented
on the same host as a session-reflector, it is not able to return the measurement
results, as it was capable of in OWAMP. A model of the TWAMP architecture is
shown in Figure 3.3.

Session- TWAMP- Session-

Sender Test Reflector

Proprietary Proprietary
protocol protocol

Control- TWAMP-
Control
Server
Client

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 carried
out 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 security
mode is agreed upon. The session identifier is decided by the receiving side. Since
the session-reflector does not process the incoming test packets, it does not need
knowledge about the number of incoming packets or time when they were sent.
Therefore, the send schedule defined in OWAMP has been removed. The TWAMP
stop-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 it
receives. Two different packet formats are used: the packet sent from the session-
sender is exactly the same as the test packet defined for OWAMP, containing
sequence number, timestamp, error estimate and optional packet padding. The
packet transmitted by the session-reflector contains the information from the re-
ceived packet along with its TTL, with additional timestamps and error estimate
added by the session-reflector. A detailed description of the packet format is shown
in Appendix A.
Upon arrival of a packet, the session-reflector sets a timestamp, extracts the
information from the packet, compiles a new packet and adds another timestamp
when the packet leaves the reflector. The session-reflector timestamps the packet
twice so the time for processing the packet is accounted for, and then removed when
computing the wire time in the control-client. The session-reflector must transmit
a 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 in
progress, and it is not possible to control single test sessions independently unless
separate 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, this
setting applies to both the control and test protocol. Extended connection setup[52]
has been proposed to allow the security mode to differ between TWAMP-Control
and TWAMP-Test in a concurrent session.

20
3.3. REFERENCE METHODS

If there is a need of injecting further information into the test stream, additional
data may be inserted as packet padding by the control-client or session-sender. A
suggested expansion[53] of the protocol introduces padding reflection, where the
session-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 has
reached its final stage. The network company Shenick has announced that their
product diversifEye supports the full TWAMP standard[50]. However, this solution
is not freely available.

3.3 Reference methods

In order to properly evaluate the TWAMP implementation, two further methods
were used and their measurement results were compared. This passage briefly de-
scribes the Ping utility and the method used by Prosilient Technologies for collecting
performance 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 as
well as the round-trip time to that host. Ping uses the Internet Control Message
Protocol, ICMP, for sending its packets. The source host sends an ICMP packet
of type 8, echo request, to the destination, which responds with an ICMP packet
of type 0, echo reply[54]. The ICMP packets contain a sequence number, and by
timestamping when packets are sent and replies are received, the round-trip time
can be calculated. Depending on the implementation, the number of lost packets
and duplicates is reported. Although Ping is widely used, it is a bad way to measure
delays. 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 incoming
echo request for security reasons.

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

21
Chapter 4

Implementation and Results

The implementation phase was twofold; first an implementation of OWAMP-Test

in unauthenticated mode was developed. Since there already exist several OWAMP
applications, the work was later focused on TWAMP. Thanks to the similarity of
the 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 provide
a network with light test points. The protocol can be implemented in a two host
scenario where the client side, known as the controller, constitutes the roles of
the server, the control-client and the session-sender. The reflecting side of the
implementation is called responder, and contains the session-reflector. The test
sessions are established through non standard means and TWAMP-Test packets
are 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 the
controller and responder. However, the logical role of the server was left out of
the implementation and a control protocol was therefore also omitted, as well as
support for authenticated and encrypted test sessions. Figure 4.1 describes the
implementation.

controller responder

Control-
Client
Session- TWAMP- Session-
Sender Test Reflector

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 to
send, and a periodic sampling interval between the packets. Once started, the packet
transmitter is forked into a separate process, and sends the TWAMP-Test packets
according to the input parameters. When the sender process is finished, its exit
signal 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. It
listens for incoming packets on a specified port and sends a response upon the arrival
of each test packet. TWAMP Light without a control protocol is not as dynamic
as an implementation in compliance with the complete TWAMP standard. This
project focuses however on the measurement method itself, and not on the setup of
the 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, along
with 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 find
good reference values. The most accurate approach is to provide each test site with
a reliable external clock, such as an atomic clock or a GPS receiver. These solutions
are costly, and other less expensive procedures were used to verify the implement-
ation. Several tests were carried out in two different environments to evaluate the
measurement 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 Stockholm
and the test traffic was routed over the Internet. The test probes were running
Fedora 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 server
located at KTH[55] in Stockholm was used for all measurements. The system clocks
were 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 module
for 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 testing
the behaviour of different network protocols and provides options to emulate a real
world network response[58]. The current version emulates delay, loss, duplication
and reordering.
Netem implements the four different properties using statistical distributions
and correlation values between packets, which gives a good resemblance to real
networks. 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 specified
window size of transmitted packets. The evaluation with Netem does unfortunately
not provide this feature, but running the test sessions over a long period of time
makes 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 test
streams with 100 packets per second. In the first four test sessions, Netem emulated
one of the four properties delay, loss, duplication and reordering individually, since
the properties might have influence on each other. During the last test session,
all four properties were activated simultaneously. Netem’s emulation of delay was
activated in both directions, but further metrics were only emulated on the reverse
path 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 on
the reverse path. The reordering was set to 100% gap 100. This setting causes
every 100th packet to be sent immediately, and all other packets were delayed as
usual, in this case with 100 milliseconds. The test setup is shown in Figure 4.2.

Delay: 50ms
Delay: 100ms Netem
Loss: 20%
Duplicate: 15%
Reorder: 100% gap 100

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

25
 CHAPTER 4. IMPLEMENTATION AND RESULTS

Internet Test Sessions

During the second experiment, the different techniques were evaluated between two
hosts 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 were
separated 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 server
was 11 milliseconds. Different NTP servers were evaluated, but the difference was
about 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 sessions
with the network emulator, all four measurement tools ran simultaneously. During
the 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 outgoing
bandwidth from site A was strained by sending file transfers to another host, and
during the third session, the incoming bandwidth to site A was used. The test setup
is shown in Figure 4.3.
The duration of the tests was reduced to 1 minute per test session, but each
session was performed ten times in order to characterize a more accurate average
of the metrics. Since the bandwidth at site A was allocated to file transfers during
the second and third test sessions, the NTP packets were delayed and the resulting
measurement data was worthless. Therefore the system clock was synchronized
before the test sessions began, and the NTP daemon was shut down during the
sessions. The sessions were kept short due to skew.

Internet

Session 2

Session 3

Probe A Probe B
Figure 4.3. Probe A, the controller, sends TWAMP-Test packets routed over the
Internet to probe B, the responder, which are reflected back. During sessions 2 and
3, the bandwidth at site A was used for file transfers in the outgoing respectively
incoming 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 discusses
why some deviations occurred.

4.3.1 Netem Test Sessions

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

Individual Tests
The results of the individual test sessions, shown in Table 4.1, turned out as expected
with exception for the duplication rate and the reorder rate reported by Owping.
While the network emulator was adjusted to send duplicated packets with a
ratio of 15%, Netem computes the percentage based on the number of real pack-
ets it receives. The performance metric applications, on the other hand, compute
the percentage based on the total number of packets received, i.e. both real and
emulated packets, which leads to a lower, but correct percentage.
The reorder metric was set to send every 100th packet immediately, and all other
packets were delayed by 100 milliseconds. When a packet is sent immediately, it
starts a sequence discontinuity, which in this case lasted for 100 milliseconds until
the packet stream had catched up. Since the packet rate was set to 100 packets
per second, approximately 10 packets passed the network emulator until the stream
was in order. After another 90 packets, the sequence starts all over again. This
causes 10 out of 100 packets (10%) to be reordered. The Ping utility does not
report reorder, and surprisingly, One-way ping only considers the early packet as
reordered. Consequently it reports 1 packet out of 100 as reordered.
The mean delays vary somewhat, but none of the tools deviate more than 1.2
milliseconds from the reference value, and their relative deviation is less than 0.7
millisecond. The average round-trip time between the hosts without any emulation
activated was approximately 0.8 millisecond.

Table 4.1. Emulation of one metric at a time using Netem. 1w refers to the delay
of 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.00
TWAMP 50.73 100.83 19.96 13.03 9.44
OWAMP 51.15 100.24 20.03 13.05 0.97
PTAnalyzer 50.76 100.17 20.09 13.02 9.47
Ping 150.90 20.11 12.99

27
 CHAPTER 4. IMPLEMENTATION AND RESULTS

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 an
obvious influence on each other. The results were not as close to Netem’s values
as when only a single metric was emulated. All applications reported however
approximately the same differences which must be interpreted as the measurements
were still accurate. The PTAnalyzer system reported a slightly lower percentage of
reordered packets. This method does however not remove duplicated packets from
the calculation, which leads to a lower ratio. The mean delay on the reverse path
was slightly less than previous sessions, which can be explained by the reordering
where every 100th packet was sent immediately.

Table 4.2. Emulation of all metrics simultaneously using Netem. 1w refers to the
delay 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.00
TWAMP 50.65 99.83 16.88 10.30 8.58
OWAMP 50.62 99.82 16.94 10.37 0.99
PTAnalyzer 50.21 99.69 17.05 10.42 8.12
Ping 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 are
shown in Table 4.3. These values represent a 95% confidence interval based on the
ten measurements presented in Appendix B.
Some packet loss was reported during the last two tests sessions, but the ratio
was less than one percent. The NTP synchronization was turned off during the test
sessions since when other applications used the bandwidth, the NTP packets would
have been delayed with approximately 60 milliseconds, and no consistent results
would have been achieved. The round-trip time to the NTP server was longer for
site A, its system clock would fall behind and a slightly lower delay on the reverse
path 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 values
from PTAnalyzer and Ping. However, no such distinction could be made. The
four methods reported approximately the same delay, but differences of up to 6
milliseconds were measured. This value has to be considered large, and would most
likely not be accepted when performing professional measurements. However, the
largest deviations occurred during session 2 when the link capacity was used for
outgoing file transfers. Since the UDP protocol is not aware of network congestion
and 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 a
buffer 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 as
in session 2. This can be explained by the asymmetric Internet connection at site
A, 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 variance
is low. The deviation between the tools exceeds 1 millisecond on one occasion only.
These values were more accurate than expected, and within the 95% confidence
interval only sub millisecond deviations were reported. The measurements during
session 1 were carried out carefully with consecutive updates from the NTP server
before each test, to make sure the shared Internet connection was used to the least
extent. These updates might however have had a negative influence on the results
from the PTAnalyzer system. The PTAnalyzer does not rely on external time
sources, but still uses the system clock during the synchronization phase. Resetting
the local time on the probes to UTC repeatedly may have deteriorated the accuracy
of the system.
The measurements reported by the Ping application did not differ as much as
expected; although ICMP is often treated differently than other protocols, the values
were of the same magnitude. The results from session 2 and 3 clearly show why
round-trip time should not be used for delay measurements, as it is impossible to
distinguish in what direction the bottleneck has occurred.
Many different factors have influenced these results, and they form a vague basis
for giving an opinion about the methods. The bandwidth used at one of the test
sites has been shared, and not solely dedicated to performance measuring. The
three 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 system
clock might also have been an issue.

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

Session 1 Session 2 Session 3

1w 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.70
OWAMP 6.77 ± 0.16 6.24 ± 0.13 69.39 ± 3.10 6.50 ± 0.12 6.85 ± 0.22 59.98 ± 0.66
PTAnalyzer 6.25 ± 0.18 6.19 ± 0.18 70.94 ± 2.64 6.52 ± 0.20 6.24 ± 0.26 59.88 ± 0.50
Ping 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 can
be designed, the performance metrics themselves have been standardized. This is
equally 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 differently
formatted packets in different directions. Larger packets require greater amount
time to be transmitted over a network, and differently sized packets introduce un-
certainty into the measurement. A comparison between the two packet formats is
shown in Appendix A. To achieve equally sized packets in both directions, packet
padding must be used when transmitting the packet from the session-sender. The
padding must then be reduced or removed from the reflected packet since its data
payload is larger. A more sound approach would have been to use similar packets in
both directions and fill the unused bits with randomized data. This comment was
e-mailed to the Internet Engineering Steering Group during a review of a TWAMP
draft, and two paragraphs treating this problem was inserted into the next version
of the draft.
A minor but questionable detail in the OWAMP and TWAMP protocols is the
format of the timestamp. The first 32 bits represent the number of seconds elapsed
since January 1900. When requesting the local time on a Unix system, the number of
seconds elapsed since 1970 is returned. Converting this timestamp into OWAMP’s
format is an unnecessary source of error.
Another problem with the TWAMP protocol is that it relies on the test protocol
to report the results back to the session-sender. In OWAMP, the results of a one-way
test session are transmitted by the control protocol using TCP. TWAMP merges the
results from the forward path into the reflected test packets transmitted over the
UDP 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 directions
becomes inaccessible.
If TWAMP Light is used without a control protocol, the sequence number of
a 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 made
concerning reordering or packet duplicates.
An interesting feature of Internet2’s One-way ping is that it automatically starts
an OWAMP session in each direction, allowing performance metrics of the two
paths to be reported independently. We name this approach Two-way OWAMP,
TWOWAMP, and consider this more reliable than TWAMP. However, the current
Internet2 implementation uses completely different ports for the two test sessions,
which may lead to incoming packets being blocked by a firewall. The TWAMP
specification states that the same port must be used for sending and receiving test
packets, and although UDP is used, a connection is established which may facilitate
the traversal through a firewall. A drawback with the One-way ping application is
that it only presents the minimum, median and maximum delay of the packets. In
order to present the average value, a program setting to report each packet delay
individually 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 bandwidth
to 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 source
address of the UDP test packets can easily be spoofed, forcing all packets to be
reflected to another party. To prevent this, the default behaviour of the OWAMP
and TWAMP servers is to only accept test connections when the receiving address
belongs to the server or to the host which setup the control-session. This security
measure is not available in TWAMP Light. Limiting the usage of resources such
as bandwidth and memory on a test server is also important. Otherwise the server
itself could become the target of a DoS attack.
The most difficult part when performing active end-to-end measurement is the
timing estimation. More precisely, the timestamping of packets and the synchron-
ization between the end points. Publicly available solutions such as TWAMP are
designed 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 updates
received 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 link
is on the order of hundreds of milliseconds, inaccuracy of a few milliseconds might
be acceptable. One must also remember that it is not always latency that is of
primary interest. Several performance metrics have been discussed and their values
are 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 is
to introduce a control protocol in compliance to the specification. The second im-
provement is to add support for authenticated and encrypted sessions. Concerning
the TWAMP protocol, better synchronization between the measurement nodes can
be achieved by introducing kernel level timestamping and by using an external time
source with better accuracy. It is recommended that packet padding is added by
the session-sender and then reduced or removed by the session-reflector to make
the packets in both directions equally sized. Three extensions of the protocol have
already been discussed in Section 3.2.3, and as TWAMP becomes a finalized IETF
standard, we think that the usage of the protocol will be widespread and further
expansions 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 IP
networks and we have implemented parts of the upcoming TWAMP standard. The
implementation presented in this work has been evaluated by comparing it to three
other active measurement tools. The evaluation was performed in a separated net-
work environment where the properties latency, loss, reorder and duplication were
emulated. Test sessions where traffic was routed over the Internet have also been
performed.
The results from the experiments in the closed network environment show that
the latency reported by the TWAMP software deviated approximately 0.8 milli-
second from the emulated values. The true deviation in each direction can however
be computed to about 0.4 millisecond, since the actual link delay of 0.8 millisecond
is not taken into account by the network emulator. The relative latency between
the different measurement tools differed by less than 0.7 millisecond. The remaining
metrics reported by the TWAMP implementation showed a loss deviation of 0.04
percentage points, a duplicate deviation of 0.03 pp and a reorder deviation of 0.56
pp, compared to the emulated reference values. As explained in this report, the net-
work emulator uses statistical distributions, and deviations of this small magnitude
are 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 this
session allow a preset reference value. Multiple measurements were performed and
a 95% confidence interval was calculated. With available bandwidth, the variance
within the confidence interval was less than 0.2 millisecond for each measurement
tool, and no more than 0.5 millisecond among themselves. The variance of the
TWAMP 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 the

importance of available bandwidth as the accuracy of the measurement was consid-
erably deteriorated. If NTP is used for synchronization, link capacity is even more
important, as delayed NTP packets may be a source of error.
The TWAMP implementation presented in this report has been proven useful for
measuring network performance metrics. Although it is difficult to determine the
exact one-way delay, the time reported by our application under stressed conditions
has differed by no more than 6 milliseconds from the reference methods. Under more
favourable conditions when bandwidth capacity was available, the measurements
within the 95% confidence interval deviated in the sub millisecond range. Along with
the high correctness of the measurements in the emulated environment, the TWAMP
implementation must be considered successful, and the TWAMP protocol can be
established as a competitive alternative for network performance measurements.

34
Bibliography

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

[2] The Cooperative Association for Internet Data Analysis web page, last visit
2008-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: Metrics

and 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 Workshop
PAM’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, Regional

and National Network Backbone Paths. In proceedings of IEEE International
Conference on Computer Communications and Networks (ICCCN), pp. 537-542,
October 2005.

[10] Pathak, A. et al. A Measurement Study of Internet Delay Asymmetry. In

proceedings of Passive and Active Measurement Conference PAM’08, 2008.

[11] Jiang, W & Williams T. Detecting and Measuring Asymmetric Links in an

IP 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 measurement

with periodic streams, November 2002.

[17] Friedman, T. Active Measurements. In proceedings of Journées Techniques

Réseaux, JTR 2004, 2004.

[18] Kobayashi, K & Shu, Z. HOTS: An OWAMP-Compliant Hardware Packet

Timestamper. In proceedings of Passive and Active Measurement Workshop
PAM’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 visit
2008-10-01.
http://www.ntp-time-server.com/gps-time-server/gps-time-server.
htm

[21] Stempfhuber, W. System Calibration in Precision Farming. In proceedings

of 5th International Conference on Optical 3d Measurement Techniques, October
2001.

[22] NIST IEEE 1588-2002 Standard for a Precision Clock Synchronization Protocol
web 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 Measuring
Connectivity, 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 Pattern
Sample 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 Variation
Metric for IP Performance Metrics (IPPM), November 2002.

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

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

[34] Uijterwaal, 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 spatial
and 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 use
in transmission planning, May 2000.

[42] Walker, J, NetIQ Corporation White Paper, Assessing VoIP Call Quality
Using 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, September
1981.

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

TERENA 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 Linux

Conference Australia, linux.conf.au 2005, 2005.

38
Appendix A

Format of Test Packets

This document describes the different types of test packets transmitted by the
OWAMP[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’s
session-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 of
variable length.
0 15 31
Sequence Number

Timestamp

Error Estimate

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 error
estimate are copied from the received packet. The receive timestamp represents the
time the arriving test packet was received by the reflector, the error estimate is the
responder’s estimate of synchronization error, the timestamp indicates when the test
packet was reflected back to the session-sender and the sequence number is generated
independently from the identifier of the arriving packets. If TWAMP Light is used,
the sender sequence number is used as sequence number. This information along
with 8 bits indicating the TTL of the arriving packet and an optional packet padding
of variable length constitute the test packet. The bits labelled MBZ (must be zero)
are set to zero and must be ignored by receivers.
0 15 31
Sequence Number

Timestamp

Error Estimate 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 Ping

1w 2w 1w 2w 1w 2w RTT
6.30 6.31 6.56 6.29 5.76 6.26 13.08
6.51 6.17 6.73 6.22 6.39 5.94 13.06
6.47 6.28 6.73 6.29 6.46 6.41 13.21
6.11 6.59 6.37 6.56 6.63 5.89 13.11
6.35 6.39 6.62 6.39 6.11 6.16 13.16
6.53 6.27 6.83 6.28 6.41 6.01 13.25
6.56 6.22 6.86 6.19 6.37 6.06 13.23
6.68 6.08 6.94 6.06 6.20 6.48 13.19
6.85 6.27 7.10 6.27 6.02 6.64 13.55
6.76 5.91 7.04 5.87 6.20 6.01 13.11

41
 APPENDIX B. INTERNET TEST SESSIONS

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

TWAMP OWAMP PTAnalyzer Ping

1w 2w 1w 2w 1w 2w RTT
65.46 6.51 65.93 6.66 65.66 6.54 72.60
67.05 6.54 67.68 6.59 70.84 6.22 73.67
68.04 6.25 68.00 6.30 68.84 6.70 76.32
67.02 6.21 67.20 6.27 71.01 6.35 73.83
77.12 6.62 79.79 6.71 76.52 6.41 85.84
66.76 6.48 67.26 6.52 72.10 6.89 75.49
73.85 6.62 74.20 6.66 77.61 6.94 80.23
66.75 6.23 67.31 6.30 68.05 6.57 73.56
67.05 6.51 68.15 6.54 68.69 6.62 73.80
68.07 6.44 68.39 6.47 70.10 6.03 76.30

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

TWAMP OWAMP PTAnalyzer Ping

1w 2w 1w 2w 1w 2w RTT
6.58 58.68 6.83 59.23 6.80 59.01 65.72
6.63 60.35 6.85 60.80 6.22 60.96 66.82
6.62 59.53 6.89 59.99 6.05 59.65 66.43
6.80 61.36 7.00 61.96 5.73 60.12 68.49
6.61 60.74 6.02 60.05 5.87 60.24 67.38
6.65 58.71 6.93 59.21 6.25 59.88 65.88
6.74 58.90 6.97 59.07 6.61 58.64 65.81
6.81 59.27 7.07 59.54 6.07 59.48 66.16
6.77 58.67 7.04 59.30 6.77 60.31 65.94
6.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