SIST-V ETSI/EG 202 765-3 V1.1.1:2016
(Main)Speech and multimediaTransmission Quality (STQ) - QoS and network performance metrics and measurement methods - Part 3: Network performance metrics and measurement methods in IP networks
Speech and multimediaTransmission Quality (STQ) - QoS and network performance metrics and measurement methods - Part 3: Network performance metrics and measurement methods in IP networks
The present document provides an overview of the common metric definitions and measurement method specifications
upon which the interoperability of network performance measurement (also called QoS measurement) is based. Two
different standardisation bodies, the Internet Engineering Task Force (IETF) and the International Telecommunication
Union - Telecommunication Standardization Sector (ITU - T), have addressed this issue. The present document
addresses the following points:
• Survey the existing network performance related IETF standards and how these standards can be applied to
end-to-end network performance measurements. The scope of this work is also to discuss the relationship of
those standards to those of ITU-T and ETSI.
• Discuss and compare definitions of metrics used to specify and assess performance in IP networks. The
metrics addressed in the present document are those defined by the IETF IPPM working group and ITU-T
Study Group 12. Besides comparing the different definitions, the present document gives applicability
guidelines on which metric is more appropriate for a particular application, configuration or scenario.
• Define measurement methods for selected performance metrics in IP networks, addressing both active and
passive methods. Clarifying guidelines are given.
NOTE: All text sections in the remainder of the present document which are enclosed in quotation marks (") and
formatted in italic style denote citations taken verbatim from referenced documents.
Kakovost prenosa govora in večpredstavnih vsebin (STQ) - Metrika kakovosti storitev (QoS) in zmogljivosti omrežja ter merilne metode - 3. del: Metode metrike in merjenja zmogljivosti omrežij v omrežjih IP
Ta dokument zagotavlja pregled splošnih definicij metrik in specifikacij metod merjenja, na katerih temelji skupna uporabnost merjenja zmogljivosti omrežja (z drugim imenom merjenje kakovosti storitev (QoS)). To težavo obravnavata dva različna organa za standardizacijo, Delovna skupina za internetno inženirstvo (IETF) in Mednarodna telekomunikacijska zveza – Sektor za standardizacijo telekomunikacij (ITU-T). Ta dokument obravnava naslednje točke:
• Raziskava obstoječih standardov IETF glede zmogljivosti omrežja in kako jih je mogoče uporabiti za celovito merjenje zmogljivosti omrežja. Področje tega dela je tudi razprava o razmerju teh standardov ter standardov ITU-T in ETSI.
• Predstavitev in primerjava definicij metrik, ki se uporabljajo za določanje in ocenjevanje zmogljivosti v omrežjih IP. Metrike, obravnavane v tem dokumentu, določata delovna skupina IETF IPPM in študijska skupina ITU-T 12. Poleg primerjave različnih definicij ta dokument podaja tudi smernice o tem, katera metrika je ustreznejša za določeno vrsto uporabe, konfiguracijo ali scenarij.
• Opredelitev metod merjenja za izbrane metrike zmogljivosti v omrežjih IP, pri čemer so zajete tako aktivne kot pasivne metode. Podane so pojasnjevalne smernice.
OPOMBA: Vsi razdelki besedila v preostanku tega dokumenta, ki so v narekovajih (»«) in oblikovani ležeče, označujejo citate, vzete neposredno iz referenčnih dokumentov.
General Information
Standards Content (Sample)
Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
ETSI Guide
Speech and multimedia Transmission Quality (STQ);
QoS and network performance metrics and
measurement methods;
Part 3: Network performance metrics and
measurement methods in IP networks
2 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
Reference
DEG/STQ-00104-3
Keywords
performance, QoS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Symbols . 9
3.3 Abbreviations . 10
4 Performance Metrics Definitions and Measurement Methods . 10
4.1 One Way Delay vs. IP Packet Transfer Delay . 11
4.1.1 IETF Definition . 11
4.1.2 ITU-T Definition . 12
4.1.3 Comparison and Recommendations . 12
4.1.4 Active Measurement Method . 13
4.1.5 Passive Measurement Method . 14
4.2 Round Trip Delay . 15
4.2.1 IETF Definition . 15
4.2.2 ITU-T Definition . 16
4.2.3 Comparison and Recommendations . 16
4.2.4 Active Measurement Method . 16
4.2.5 Passive Measurement Method . 17
4.3 IP Packet Delay Variation vs. End-to-end 2-point IP Packet Delay Variation . 19
4.3.1 IETF Definition . 19
4.3.2 ITU-T Definition . 20
4.3.3 Comparison and Recommendations . 21
4.3.4 Active Measurement Method . 22
4.3.5 Passive Measurement Method . 22
4.4 One Way Packet Loss vs. IP Packet Loss Ratio . 22
4.4.1 IETF Definition . 23
4.4.2 ITU-T Definition . 23
4.4.3 Comparison and Recommendations . 23
4.4.4 Active Measurement Method . 23
4.4.5 Passive Measurement Method . 24
4.5 Connectivity vs. IP Service Availability . 24
4.5.1 IETF Definition . 24
4.5.2 ITU-T Definition . 25
4.5.3 Comparison and Recommendations . 25
4.5.4 Active Measurement Method . 26
4.5.5 Passive Measurement Method . 26
5 Other Metrics . 26
5.1 Data and Packet Volume . 26
5.2 Packet Reordering . 27
5.3 Bandwidth Capacity, Available Bandwidth, and Utilization . 27
5.4 Bulk Transport Capacity . 27
5.5 Loss Patterns . 27
5.6 RTCP reported metrics . 28
6 Overview of Network Performance Relevant Standard Bodies and Working Groups . 29
6.1 IETF . 29
6.1.1 IPPM (IP Performance Metrics) Working Group . 29
ETSI
4 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
6.1.2 IPFIX (IP Flow Information eXport) Working Group . 29
6.1.3 PSAMP (Packet SAMPling) Working Group . 30
6.2 ITU-T . 30
6.2.1 Study Group 12 (Performance and quality of service) . 30
6.2.2 Study Group 15 (Optical and other transport network infrastructures) . 30
Annex A: Bibliography . 32
History . 33
ETSI
5 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Speech and multimedia Transmission Quality
(STQ), and is now submitted for the ETSI standards Membership Approval Procedure.
The present document is part 3 of a multi-part deliverable covering the QoS and network performance metrics and
measurement methods, as identified below:
Part 1: "General considerations";
Part 2: "Transmission Quality Indicator combining Voice Quality Metrics";
Part 3: "Network performance metrics and measurement methods in IP networks";
Part 4: "Indicators for supervision of Multiplay services".
Introduction
The need to define Internet performance metrics and measurement methodologies stems from the need to compare
different measurements and to measure performance with a reproducible and unambiguous methodology, independent
from transmission technology and implementation details. Both the ITU-T Study Group 12 and the IETF IPPM
Working Group have produced such definitions (see table 1), although each with a different emphasis closely linked to
the historical background of both organizations. The ITU has its origins in telephony, while the IETF has a data
networking background. Whereas the ITU emphasizes the evaluation of a service and its quality, the IETF measures the
network and wants to provide the IT-community with an accurate, common understanding and measurement of the
performance and reliability the Internet [i.3].
In most cases this results in different terminology rather than in incompatibilities; most differences in approach and
emphasis serve the different intended use of each metric, but have no operational significance. In some cases the
terminology used by each organisations can be mapped to the other, while in some others there is only approximate
equivalence (e.g. ITU network section versus an IPPM cloud; one focuses on corresponding events while the other
measures the fate of a single packet). Other terms have no correspondence. For example, ITU-T Recommendation
I.380 [i.38] has a notion of an IP packet transfer reference event while IPPM defines "wire time".
Other differences between IETF and ITU-T metrics result from their intended application. ITU-T metrics seek to
provide a common language for providers to communicate about performance, so the ITU-T metrics do not concentrate
on performance within a single network, while the IETF focuses on performance measurement protocols and
implementation. ITU-T seeks to evaluate service and to exclude unfair use, while the IETF seeks to measure network
quantities and avoid biased measurement results. Due to their respective backgrounds, the ITU generally produces
statistical metrics geared towards a quantitative representation of the complete end-to-end user experience while the
IETF IPPM working group mainly focuses more on statistical metrics which provide a detailed technical view of
different aspects of transmission quality along the network path.
ETSI
6 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
Table 1: Overview of Relevant Standards
IETF RFCs ITU-T Recommendations
Framework
RFC 2330 [i.3] Y.1540 [i.1], sections 1 through 5
Loss RFC 2680 [i.6] Y.1540 [i.1], section 5.5.6
G.1020 [i.23]
Delay
RFC 2679 [i.5] (One-way) Y.1540 [i.1], section 6.2
RFC 2681 [i.7] (Round Trip) G.1020 [i.23]
G.114 [i.22] (One-way)
Delay Variation RFC 3393 [i.10] Y.1540 [i.1], section 6.2.2
G.1020 [i.23]
Connectivity / Availability RFC 2678 [i.4] Y.1540 [i.1], section 7
Loss Patterns RFC 3357 [i.9] G.1020 [i.23]
Packet Reordering RFC 4737 [i.15] Y.1540 [i.1], sections 5.5.8.1 and 6.6
Packet Duplication Y.1540 [i.1], sections 5.5.8.3, 5.5.8.4,
6.8, and 6.9
Link/Path Bandwidth Capacity, Link
RFC 5136 [i.31]
Utilization, Available Capacity
Bulk Transport Capacity RFC 3148 [i.8], RFC 5136 [i.31]
The goal of the present document is to define network performance metrics for applications sensitive to quality of
service such as Voice over IP, referring to the existing work produced by both IETF and ITU-T. The present document
highlights the differences between the two standards and provides guidelines on resolving these differences, when they
are due to addressing different goals.
The scope of the present document is limited to IP performance metrics relevant for data transmission over IP-based
networks for use in QoS sensitive applications. For each addressed metric, the document recommends one or more
measurement methods. The document only focuses on intrinsic network QoS metrics; perceived QoS metrics applicable
for voice transmission are out of scope of the present document.
The remainder of the present document is organised as follows: Clause 4 describes the definitions of the most important
performance metrics as defined by the standard bodies and methods for measuring them, and discusses the applicability
of the definitions and the differences between them. Clause 5 discusses other metrics applicable to QoS. Finally,
clause 6 gives an overview of relevant QoS measurement standards, which can be used in end to end performance
evaluation.
ETSI
7 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
1 Scope
The present document provides an overview of the common metric definitions and measurement method specifications
upon which the interoperability of network performance measurement (also called QoS measurement) is based. Two
different standardisation bodies, the Internet Engineering Task Force (IETF) and the International Telecommunication
Union - Telecommunication Standardization Sector (ITU - T), have addressed this issue. The present document
addresses the following points:
• Survey the existing network performance related IETF standards and how these standards can be applied to
end-to-end network performance measurements. The scope of this work is also to discuss the relationship of
those standards to those of ITU-T and ETSI.
• Discuss and compare definitions of metrics used to specify and assess performance in IP networks. The
metrics addressed in the present document are those defined by the IETF IPPM working group and ITU-T
Study Group 12. Besides comparing the different definitions, the present document gives applicability
guidelines on which metric is more appropriate for a particular application, configuration or scenario.
• Define measurement methods for selected performance metrics in IP networks, addressing both active and
passive methods. Clarifying guidelines are given.
NOTE: All text sections in the remainder of the present document which are enclosed in quotation marks (") and
formatted in italic style denote citations taken verbatim from referenced documents.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
ETSI
8 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ITU-T Recommendation Y.1540: "Internet protocol data communication service - IP packet
transfer and availability performance parameters".
[i.2] Void.
[i.3] IETF RFC 2330: "Framework for IP Performance Metrics". V. Paxson, G. Almes, J. Mahdavi,
M. Mathis. May 1998.
[i.4] IETF RFC 2678: "IPPM Metrics for Measuring Connectivity". J. Mahdavi, V. Paxson.
September 1999.
[i.5] IETF RFC 2679: "A One-way Delay Metric for IPPM". G. Almes, S. Kalidindi, M. Zekauskas.
September 1999.
[i.6] IETF RFC 2680: "A One-way Packet Loss Metric for IPPM". G. Almes, S. Kalidindi,
M. Zekauskas. September 1999.
[i.7] IETF RFC 2681: "A Round-trip Delay Metric for IPPM". G. Almes, S. Kalidindi, M. Zekauskas.
September 1999.
[i.8] IETF RFC 3148: "A Framework for Defining Empirical Bulk Transfer Capacity Metrics".
M. Mathis, M. Allman. July 2001.
[i.9] IETF RFC 3357: "One-way Loss Pattern Sample Metrics". R. Koodli, R. Ravikanth. August 2002.
[i.10] IETF RFC 3393: "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)".
C. Demichelis, P. Chimento. November 2002.
[i.11] Void.
[i.12] Void.
[i.13] Void.
[i.14] IETF RFC 4656: "A One-way Active Measurement Protocol (OWAMP)". S. Shalunov,
B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006.
[i.15] IETF RFC 4737: "Packet Reordering Metrics". A. Morton, L. Ciavattone, G. Ramachandran,
S. Shalunov, J. Perser. November 2006.
[i.16] Void.
[i.17] Void.
[i.18] IETF RFC 5101: "Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow
Information". B. Claise, S. Bryant, S. Leinen, T. Deitz, B.Trammell. January 2008.
[i.19] IPFIX Architecture. N.Brownlee et Al. Internet-Draft, work in progress.
[i.20] IETF RFC 5102: "IPFIX Information Model". J. Quittek et Al. January 2008.
[i.21] "IPFIX Applicability Statement". T. Zseby, E. Boschi, N.Brownlee, B. Claise. Internet-Draft, work
in progress.
[i.22] ITU-T Recommendation G.114 (05/03): "One-way transmission time".
[i.23] ITU-T Recommendation G.1020 (07/06): "Performance parameter definitions for quality of speech
and other voiceband applications utilizing IP networks".
ETSI
9 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
[i.24] IETF RFC 3917: "Requirements for IP Flow Information Export". J. Quittek, T. Zseby, B. Claise,
S. Zander. October 2004.
[i.25] Void.
[i.26] Void.
[i.27] Void.
[i.28] Void.
[i.29] "Reporting Metrics: Different Points of View", A. Morton, G. Ramachandran, G. Maguluri, work
in progress, draft-morton-ippm-reporting-metrics-02.
NOTE: http://tools.ietf.org/html/draft-morton-ippm-reporting-metrics-02, and the derived presentation "Reporting
Metrics: Different Points of View" presented by Al Morton on IETF66 July 2006,
http://www3.ietf.org/proceedings/06jul/slides/ippm-2.pdf .
[i.30] IETF RFC 3611: "RTP Control Protocol Extended Reports (RTCP XR)", T. Friedman, R. Caceres,
A. Clark. November 2003.
[i.31] IETF RFC 5136: "Defining Network Capacity", P. Chimento, J. Ishac. February 2008.
[i.32] IETF RFC 2581: "TCP Congestion Control", M. Allman, V. Paxson, W. Stevens. April 1999.
[i.33] IETF RFC 5357: "A Two-Way Active Measurement Protocol (TWAMP)", K. Hedayat,
R. Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008.
[i.34] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers", R. Braden ed.
October 1989.
[i.35] IETF RFC 3550: "User Accounts for UCSB On-Line System".
[i.36] IETF RFC 1633: "Integrated Services in the Internet Architecture: an Overview".
[i.37] IETF RFC 2216: "Network Element Service Specification Template".
[i.38] ITU-T Recommendation I.380: "Internet protocol data communication service - IP packet transfer
and availability performance parameters".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in RFC 2330 [i.3], ITU-T Recommendation
G.1020 [i.23] and RFC 2680 [i.6] apply.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
T, t Time
T Time threshold
max
dT Time difference
ETSI
10 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASON Automatically Switched Optical Network
ATM Asynchronous Transfer Mode
BTC Bulk transport Capacity
DNS Domain Name System
ESD End System Delay
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IPDV IP Packet Dealy Variation
IPFIX IP Flow Information eXport
IPLR IP Packet Loss Ratio
IPPM IP Performance Metrics
IPTD IP Packet Transfer Delay
ITU-T International Telecommunication Union - Telecommunication standardisation sector
MIB Management Information Base
NSE Network Section Ensemble
OP Observation Point
OWAMP One Way Active Measurement Protocol
OWD One Way Delay
PDV Packet Delay Variation
PIA Percent IP service Availability
PON Passive Optical Network
PSAMP Packet SAMPling
QoS Quality of Service
RFC Request For Comments
RTCP Real Time Control Protocol
RTD Round Trip Delay
RTP Real-Time Transport Protocol
RTT Round Trip Time
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
TCP Transmission Control Protocol
TWAMP Two-Way Active Measurement Protocol
UTC Coordinated Universal Time
VoIP Voice over IP
4 Performance Metrics Definitions and Measurement
Methods
This clause provides common definitions for network performance metrics. These definitions are based, whenever
possible, on existing definitions proposed by other relevant standard bodies such as IETF or ITU-T. Note that the
different definitions of similar metrics are in most cases compatible, that is, semantically equivalent or easily
convertible into one another.
ETSI
11 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
For each metric, passive and active measurement methods are defined. Note that we chose to focus on commonly used
measurement methods rather than on standards; when a standard exists, a reference is provided as well. Note also that
throughout this text we refer for each metric to active and passive measurements in the following way:
• Active measurements
Active measurement methods inject traffic into the network and compute traffic metrics based on monitoring
the injected traffic or the response to the injected traffic. Active test traffic may perturb other traffic already
present on the network; therefore its scheduling and volume should be carefully configured. One can
distinguish active monitoring systems based on the position of sender and receiver and the observed traffic;
this is specified in detail for the considered metrics in the following text.
• Passive measurements
Passive measurements provide information about traffic in the observed network by capturing all or a selected
subset of the IP packets traversing a monitoring point. Since no test traffic is generated, passive measurements
can only be applied when the traffic of interest is already present on the network. The physical deployment of
monitoring probes in the network can be realised in different ways, depending on the metrics of interest, but
also on the network technology, e.g. via a physical line splitter, via a normal client connection in broadcast
networks, or via a dedicated monitoring port on a switch or router.
4.1 One Way Delay vs. IP Packet Transfer Delay
Delay is used to measure the expected time for an IP packet to traverse the network from one host to another. Delay is
applicable to QoS for latency-sensitive protocols. The IETF and ITU-T metrics for measuring delay are essentially
compatible, though there are minor differences; the details of these metrics are given in this clause.
4.1.1 IETF Definition
RFC 2679 [i.5] distinguishes between a "singleton analytic metric", called Type-P-One-way-Delay, and a "sample",
called Type-P-One-way-Delay-Poisson-Stream. The singleton is introduced to measure a single observation of one-way
delay, while the sample is used to measure a sequence of singleton delays measured at times taken from a Poisson
process. Based on these samples, several statistics are defined, such as Type-P-One-way-Delay-Percentile, Type-P-One-
way-Delay-Median, Type-P-One-way-Delay-Minimum, and Type-P-One-way-Delay-Inverse-Percentile.
Since the value of many of these metrics depends on the type of the IP packet used to perform the measurements, IPPM
metrics definitions include the generic notion of "a packet of type P", which should be further specified when making
actual measurements.
RFC 2679 [i.5] defines:
"For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at T is dT<< means that Src sent the first bit
of a Type-P packet to Dst at wire-time* T and that Dst received the last bit of that packet at wire-time T+dT."
The notion of wire time is introduced in RFC 2330 [i.3] in order to take into account the additional delay derived from
the use of Internet hosts to perform the measurements. Wire time is defined with reference to an Internet host H
observing an Internet link L at a particular location. More precisely, for a given packet P, the "wire arrival time" of P at
H on L is the first time (see note) T at which the first bit of P has appeared at H's observational position on L. On the
other side, For a given packet P, the 'wire exit time' of P at H on L is the first time T at which all the bits of P have
appeared at H's observational position on L. Wire time delay is defined as the time between the first wire arrival time,
the moment in which the first bit of the packet leaves the network interface of the source and the subsequent wire exit
time at the remote end, the moment at which it has arrived completely at the network interface of the destination host.
NOTE: An IP packet might arrive at the destination Dst more than once, due to retransmission.
An upper bound for the expected packet delivery is taken into account (this threshold should also be reported):
"If the packet fails to arrive within a reasonable period of time, the one-way delay is taken to be undefined (informally,
infinite)."
ETSI
12 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
Further RFC 2680 [i.6] states about corrupted packets:
"If the packet arrives, but is corrupted, then it is counted as lost."
This is a useful approach since corrupted packets (even though they arrived) cannot be safely assigned to a flow or
traffic sender, as the source identifier might be a part of the packet that was corrupted.
4.1.2 ITU-T Definition
The ITU-T Recommendation Y.1540 [i.1] defines the IP Packet Transfer Delay (IPTD) metric as the one-way IP
packet transfer delay for all successful and errored packet transmissions across a basic section or a Network Section
Ensemble (NSE). IPTD is the time, (t - t ) between the occurrence of two corresponding IP packet reference events,
2 1
ingress event IPRE at time t and egress event IPRE at time t , where (t > t ) and (t - t ) ≤ T . If fragmentation
1 1 2 2 2 1 2 1 max
occurs then the time t is considered the time of the final corresponding fragment [i.1].
To understand this definition, the meaning of IP packet reference event has to be clarified. ITU-T Recommendation
Y.1540 [i.1] defines it as follows:
An IP packet transfer event occurs when:
• an IP packet crosses a Measurement Point (MP); and
• standard IP procedures applied to the packet verify that the header checksum is valid; and
• the source and destination address fields within the IP packet header represent the IP addresses of the expected
source host and destination host.
The IP packet transfer reference events are defined without regard to packet fragmentation.
An IP egress event is said to correspond to an earlier ingress event if they were created by the "same" IP packet.
Finally, the end-to-end IP packet transfer delay is the one-way delay between the measurement point at the source host
and destination host.
ITU-T Recommendation Y.1540 [i.1] also mentions the mean IP packet transfer delay, which is defined as the
arithmetic average of IP packet transfer delays for a packet population of interest.
4.1.3 Comparison and Recommendations
In general the ITU-T, due to its telecommunications origin, often assesses the observed delay at the endpoints of a full
end-to-end connection, i.e. from Network Termination Point to Network Termination Point., while IETF is concerned
with network delays among arbitrary points in the network. When setting upper limits for e.g. network planning then the
desired application (e.g. VoIP) as well as effects on QoS due to codecs and de-jitter buffers should be taken into
account for the assessment of the needed network QoS.
The two definitions from IETF and ITU-T for one way delay can be considered compatible, as for both definitions the
relevant events are (a) the time just before the packet is being put on the wire and (b) the time after complete reception
of the packet at the destination. Even though the RFC 2330 [i.3] definition of wire time delay has no direct equivalent in
ITU-T terminology, it can be interpreted as "visibility of a given packet at both Measurement Points"; to be precise for
the IETF the timing of the first and last bits of a packet on the wire is relevant, while ITU-T defines these events based
on the moment when the packet crosses a point in the sender's or the recipient's IP stack (see note). One can state that
one-way delay for both definitions yields the delay that one bit of the packet takes to travel across the network plus one
time the serialisation delay of the IP packet, depending on packet length and physical link speed. From the ITU-T
definition in ITU-T Recommendation Y.1540 [i.1] it is unclear what further delays inside the Measurement Points
might add to the measured delay.
NOTE: However Y.1540 states "The exact location of the IP Service measurement point in the IP protocol stack
is for further study"
ETSI
13 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
In the IETF definition corrupted packets are deemed as lost, and their delay is formally defined as an undefined value of
delay, which can informally be designated "infinity". In contrast to that the IP packet transport delay, defined in ITU-T
Recommendation Y.1540 [i.1] applies to the combined set of successfully delivered and corrupted packets. Deciding
whether a packet is corrupted or lost can be difficult to detect in certain circumstances, such as applying hashing
methods to identify packets on reference and observation measurement points through an ID determined on the base of
the packet content. Special care should be taken to detect corrupted packets: In case that packet header or payload fields
are used in the measurement (e.g. serial packet id counter in active probing packets) then all checksums up to the
respective header or payload have to be checked.
Both, RFC 3393 [i.10] and ITU-T Recommendation Y.1540 [i.1], express their metrics on populations that are
conditioned on successful arrival within the waiting time, i.e. both definitions treat packets arriving after the waiting
time as lost packets. It is important to select a reasonably safe threshold to decide when packets are deemed lost. It
should be set so that no significant number of packets is observed as lost just because of being slightly late, i.e. a small
amount over the threshold. Otherwise the derived traffic statistics would be biased. This threshold should be reported
together with the measurement results. In case of fragmentation the time for the complete reception of all fragments
counts. If not all fragments are received, a packet is deemed lost. A detailed comparison of packet treatment for
one-way delay measurements is given in [i.29].
When computing statistics based on a series of delay values it is crucial to decide whether or not to include also the
"lost" (lost or too much delayed) packets in this computation. Both standards assume that for statistics like median or
other percentiles lost packets will be included (with a delay value of undefined or +infinity). For other statistics like
mean delay this is not a useful approach since otherwise the average delay would be undefined or +infinity even if only
one packet was lost in this measurement.
Apart from these details on the measurement of one-way delays and some differences in terminology there are no
significant differences between the definitions of One Way Delay versus IP Packet Transfer Delay.
To measure one-way metrics it is needed to ensure a synchronisation of both transmission ends of the measurement
device. This synchronisation may be done by GPS clocks when the two ends are distant. When ends are co-located
synchronisation may be done directly by the analyser. To assess the metric, the clock accuracy of the analyzer should be
better than 10 ppm.
4.1.4 Active Measurement Method
Active measurement of One-way Delay as defined by the IETF in RFC 2679 [i.5] requires the observation of test
packets transmitted between two endpoints across a network, a "source" host, which sends the test packet, and a
"destination" host, which receives the test packet. The One-way Delay is then calculated as the difference between the
time at which the test packet is received at the destination and the time the test packet is sent.
The procedure to take a One-way Delay measurement involves the following steps:
1) The source host and the destination host are synchronized.
2) The destination host is prepared to receive the test packets sent by the source host.
3) The source host constructs a test packet. Any 'padding' portion of the packet needed only to make the test
packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is
lower than it would otherwise be due to compression techniques along the path.
4) The source host places a timestamp in the prepared packet.
NOTE: Usually it also places a counter or identifier in the test packet, so that the destination host may also
identify the number of lost test packets.
5) The source host sends the test packet to the destination host.
6) The destination host receives the test packet and records its arrival time.
7) The destination host calculates a One-way Delay by subtracting the two timestamps. If the delay between
source host's timestamp and the actual sending of the packet is known, then the estimate could be adjusted by
subtracting this amount. Similarly, if the delay between the actual complete receipt of the packet by the
destination's network interface card and destination host's timestamp is known, then the estimate could be
adjusted by subtracting this amount. If the packet fails to arrive within a reasonable period of time, the
one-way delay is taken to be undefined.
ETSI
14 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
8) The destination host optionally forwards the result back to the source, if the result is required at the source.
Figure 1: Active One-Way Delay Measurement Method
The IETF has defined the One-Way Active Measurement Protocol (OWAMP) [i.14] for the active measurement of the
one-way delay metric. OWAMP consists of a control protocol to negotiate active performance measurement sessions,
and a test protocol for transmission of actual test packets. OWAMP requires some minimal measurement infrastructure.
It defines five entities, a Control Client, which specifies the test to run and passes that specification using the control
protocol to a Server; this control interaction then causes a Session Sender and Session Receiver to send packets via the
test protocol for the duration of the requested test. The Fetch Client then retrieves the test results from the Server. The
test protocol allows accurate measurement of one-way delay without including processing overhead or other unknown
timing components, and is designed to be resistant to detection and manipulation. In common usage, the Control Client,
Fetch Client, and Session Sender are on one host, and the Server and Session Receiver are on another.
4.1.5 Passive Measurement Method
One-way delay may be measured passively by observing the same packet at two points in the network, and calculating
the difference between the arrival times at these points. Calculating this metric requires the correlation of data from
multiple Observation Points (OPs). The same packet is recognised at different Observation Points; this can be done by
using invariant parts of the header or the payload or by calculating a packet identifier based on the invariant header
fields and/or the packet content. Using the packet identifier reduces the amount of measurement data and can be easily
obtained by calculating CRCs or hash functions. Proper clock synchronization between the observation points is
important.
The passive procedure to take a One-way Delay measurement involves the following steps:
1) The source Observation Point and the destination Observation Point are synchronized.
2) The source and destination OPs are prepared to measure packets sent from the source host.
3) A source host sends a packet to the destination on a path where it is observable by source and destination OP.
4) The source OP observes this packet, records a timestamp of the observation, and identifies it.
5) The source OP forwards information about the observation event, i.e. the packet identification and timestamp
to the destination OP. This operation may be performed in batches, after some specific number of packets have
been observed or a given time interval has passed.
6) The destination OP recognises the packet and records its arrival time.
7) One-way delay is computed as the difference between the two arrival times. There is no strict need to perform
this operation at the destination OP; a fifth host (not shown in figure 2) may also perform this operation when
source and destination OP forward information about the observation event to it.
ETSI
15 Final draft ETSI EG 202 765-3 V1.1.1 (2009-10)
These steps are also shown in figure 2. The red dotted lines in the figure show the potential delay measurement error,
which exists since there is a time difference between the source itself and the Observation point (OP), as well as
between the destination and the destination OP. It is therefore recommended to keep the OP as close as possible to the
source or destination, respectively.
Figure 2: Passive one-way delay measurement method
Note that in contrast to active one-way delay monitoring the approach for passive one-way delay measurements does
not include in the results the time for the serialisation delay due to the fact that both monitoring points are acting as
packet receivers. If active and passive OWD measurement results are compared then this should be taken into account;
however the serialization time becomes more and more negligible compared to the network delay the faster the net data
rate of the underlying networking technology is.
The IETF IPFIX [i.18] or PSAMP protocols may be used for reporting packet contents, hashes, and timestamps from
each passive observation point, as in [i.21]; each of these reports may be used to calculate a singleton in IPPM
terminology or a single delay in ITU-T terminology.
4.2 Round Trip Delay
Round-tri
...
ETSI Guide
Speech and multimedia Transmission Quality (STQ);
QoS and network performance metrics and
measurement methods;
Part 3: Network performance metrics and
measurement methods in IP networks
2 ETSI EG 202 765-3 V1.1.1 (2009-12)
Reference
DEG/STQ-00104-3
Keywords
performance, QoS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI EG 202 765-3 V1.1.1 (2009-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Symbols . 9
3.3 Abbreviations . 10
4 Performance Metrics Definitions and Measurement Methods . 10
4.1 One Way Delay vs. IP Packet Transfer Delay . 11
4.1.1 IETF Definition . 11
4.1.2 ITU-T Definition . 12
4.1.3 Comparison and Recommendations . 12
4.1.4 Active Measurement Method . 13
4.1.5 Passive Measurement Method . 14
4.2 Round Trip Delay . 15
4.2.1 IETF Definition . 15
4.2.2 ITU-T Definition . 16
4.2.3 Comparison and Recommendations . 16
4.2.4 Active Measurement Method . 16
4.2.5 Passive Measurement Method . 17
4.3 IP Packet Delay Variation vs. End-to-end 2-point IP Packet Delay Variation . 19
4.3.1 IETF Definition . 19
4.3.2 ITU-T Definition . 20
4.3.3 Comparison and Recommendations . 21
4.3.4 Active Measurement Method . 22
4.3.5 Passive Measurement Method . 22
4.4 One Way Packet Loss vs. IP Packet Loss Ratio . 22
4.4.1 IETF Definition . 23
4.4.2 ITU-T Definition . 23
4.4.3 Comparison and Recommendations . 23
4.4.4 Active Measurement Method . 23
4.4.5 Passive Measurement Method . 24
4.5 Connectivity vs. IP Service Availability . 24
4.5.1 IETF Definition . 24
4.5.2 ITU-T Definition . 25
4.5.3 Comparison and Recommendations . 25
4.5.4 Active Measurement Method . 26
4.5.5 Passive Measurement Method . 26
5 Other Metrics . 26
5.1 Data and Packet Volume . 26
5.2 Packet Reordering . 27
5.3 Bandwidth Capacity, Available Bandwidth, and Utilization . 27
5.4 Bulk Transport Capacity . 27
5.5 Loss Patterns . 27
5.6 RTCP reported metrics . 28
6 Overview of Network Performance Relevant Standard Bodies and Working Groups . 29
6.1 IETF . 29
6.1.1 IPPM (IP Performance Metrics) Working Group . 29
ETSI
4 ETSI EG 202 765-3 V1.1.1 (2009-12)
6.1.2 IPFIX (IP Flow Information eXport) Working Group . 29
6.1.3 PSAMP (Packet SAMPling) Working Group . 30
6.2 ITU-T . 30
6.2.1 Study Group 12 (Performance and quality of service) . 30
6.2.2 Study Group 15 (Optical and other transport network infrastructures) . 30
Annex A: Bibliography . 32
History . 33
ETSI
5 ETSI EG 202 765-3 V1.1.1 (2009-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Speech and multimedia Transmission Quality
(STQ).
The present document is part 3 of a multi-part deliverable covering the QoS and network performance metrics and
measurement methods, as identified below:
Part 1: "General considerations";
Part 2: "Transmission Quality Indicator combining Voice Quality Metrics";
Part 3: "Network performance metrics and measurement methods in IP networks";
Part 4: "Indicators for supervision of Multiplay services".
Introduction
The need to define Internet performance metrics and measurement methodologies stems from the need to compare
different measurements and to measure performance with a reproducible and unambiguous methodology, independent
from transmission technology and implementation details. Both the ITU-T Study Group 12 and the IETF IPPM
Working Group have produced such definitions (see table 1), although each with a different emphasis closely linked to
the historical background of both organizations. The ITU has its origins in telephony, while the IETF has a data
networking background. Whereas the ITU emphasizes the evaluation of a service and its quality, the IETF measures the
network and wants to provide the IT-community with an accurate, common understanding and measurement of the
performance and reliability the Internet [i.3].
In most cases this results in different terminology rather than in incompatibilities; most differences in approach and
emphasis serve the different intended use of each metric, but have no operational significance. In some cases the
terminology used by each organisations can be mapped to the other, while in some others there is only approximate
equivalence (e.g. ITU network section versus an IPPM cloud; one focuses on corresponding events while the other
measures the fate of a single packet). Other terms have no correspondence. For example, ITU-T Recommendation
I.380 [i.38] has a notion of an IP packet transfer reference event while IPPM defines "wire time".
Other differences between IETF and ITU-T metrics result from their intended application. ITU-T metrics seek to
provide a common language for providers to communicate about performance, so the ITU-T metrics do not concentrate
on performance within a single network, while the IETF focuses on performance measurement protocols and
implementation. ITU-T seeks to evaluate service and to exclude unfair use, while the IETF seeks to measure network
quantities and avoid biased measurement results. Due to their respective backgrounds, the ITU generally produces
statistical metrics geared towards a quantitative representation of the complete end-to-end user experience while the
IETF IPPM working group mainly focuses more on statistical metrics which provide a detailed technical view of
different aspects of transmission quality along the network path.
ETSI
6 ETSI EG 202 765-3 V1.1.1 (2009-12)
Table 1: Overview of Relevant Standards
IETF RFCs ITU-T Recommendations
Framework
RFC 2330 [i.3] Y.1540 [i.1], sections 1 through 5
Loss RFC 2680 [i.6] Y.1540 [i.1], section 5.5.6
G.1020 [i.23]
Delay
RFC 2679 [i.5] (One-way) Y.1540 [i.1], section 6.2
RFC 2681 [i.7] (Round Trip) G.1020 [i.23]
G.114 [i.22] (One-way)
Delay Variation RFC 3393 [i.10] Y.1540 [i.1], section 6.2.2
G.1020 [i.23]
Connectivity / Availability RFC 2678 [i.4] Y.1540 [i.1], section 7
Loss Patterns RFC 3357 [i.9] G.1020 [i.23]
Packet Reordering RFC 4737 [i.15] Y.1540 [i.1], sections 5.5.8.1 and 6.6
Packet Duplication Y.1540 [i.1], sections 5.5.8.3, 5.5.8.4,
6.8, and 6.9
Link/Path Bandwidth Capacity, Link
RFC 5136 [i.31]
Utilization, Available Capacity
Bulk Transport Capacity RFC 3148 [i.8], RFC 5136 [i.31]
The goal of the present document is to define network performance metrics for applications sensitive to quality of
service such as Voice over IP, referring to the existing work produced by both IETF and ITU-T. The present document
highlights the differences between the two standards and provides guidelines on resolving these differences, when they
are due to addressing different goals.
The scope of the present document is limited to IP performance metrics relevant for data transmission over IP-based
networks for use in QoS sensitive applications. For each addressed metric, the document recommends one or more
measurement methods. The document only focuses on intrinsic network QoS metrics; perceived QoS metrics applicable
for voice transmission are out of scope of the present document.
The remainder of the present document is organised as follows: Clause 4 describes the definitions of the most important
performance metrics as defined by the standard bodies and methods for measuring them, and discusses the applicability
of the definitions and the differences between them. Clause 5 discusses other metrics applicable to QoS. Finally,
clause 6 gives an overview of relevant QoS measurement standards, which can be used in end to end performance
evaluation.
ETSI
7 ETSI EG 202 765-3 V1.1.1 (2009-12)
1 Scope
The present document provides an overview of the common metric definitions and measurement method specifications
upon which the interoperability of network performance measurement (also called QoS measurement) is based. Two
different standardisation bodies, the Internet Engineering Task Force (IETF) and the International Telecommunication
Union - Telecommunication Standardization Sector (ITU - T), have addressed this issue. The present document
addresses the following points:
• Survey the existing network performance related IETF standards and how these standards can be applied to
end-to-end network performance measurements. The scope of this work is also to discuss the relationship of
those standards to those of ITU-T and ETSI.
• Discuss and compare definitions of metrics used to specify and assess performance in IP networks. The
metrics addressed in the present document are those defined by the IETF IPPM working group and ITU-T
Study Group 12. Besides comparing the different definitions, the present document gives applicability
guidelines on which metric is more appropriate for a particular application, configuration or scenario.
• Define measurement methods for selected performance metrics in IP networks, addressing both active and
passive methods. Clarifying guidelines are given.
NOTE: All text sections in the remainder of the present document which are enclosed in quotation marks (") and
formatted in italic style denote citations taken verbatim from referenced documents.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
ETSI
8 ETSI EG 202 765-3 V1.1.1 (2009-12)
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ITU-T Recommendation Y.1540: "Internet protocol data communication service - IP packet
transfer and availability performance parameters".
[i.2] Void.
[i.3] IETF RFC 2330: "Framework for IP Performance Metrics". V. Paxson, G. Almes, J. Mahdavi,
M. Mathis. May 1998.
[i.4] IETF RFC 2678: "IPPM Metrics for Measuring Connectivity". J. Mahdavi, V. Paxson.
September 1999.
[i.5] IETF RFC 2679: "A One-way Delay Metric for IPPM". G. Almes, S. Kalidindi, M. Zekauskas.
September 1999.
[i.6] IETF RFC 2680: "A One-way Packet Loss Metric for IPPM". G. Almes, S. Kalidindi,
M. Zekauskas. September 1999.
[i.7] IETF RFC 2681: "A Round-trip Delay Metric for IPPM". G. Almes, S. Kalidindi, M. Zekauskas.
September 1999.
[i.8] IETF RFC 3148: "A Framework for Defining Empirical Bulk Transfer Capacity Metrics".
M. Mathis, M. Allman. July 2001.
[i.9] IETF RFC 3357: "One-way Loss Pattern Sample Metrics". R. Koodli, R. Ravikanth. August 2002.
[i.10] IETF RFC 3393: "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)".
C. Demichelis, P. Chimento. November 2002.
[i.11] Void.
[i.12] Void.
[i.13] Void.
[i.14] IETF RFC 4656: "A One-way Active Measurement Protocol (OWAMP)". S. Shalunov,
B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006.
[i.15] IETF RFC 4737: "Packet Reordering Metrics". A. Morton, L. Ciavattone, G. Ramachandran,
S. Shalunov, J. Perser. November 2006.
[i.16] Void.
[i.17] Void.
[i.18] IETF RFC 5101: "Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow
Information". B. Claise, S. Bryant, S. Leinen, T. Deitz, B.Trammell. January 2008.
[i.19] IPFIX Architecture. N.Brownlee et Al. Internet-Draft, work in progress.
[i.20] IETF RFC 5102: "IPFIX Information Model". J. Quittek et Al. January 2008.
[i.21] "IPFIX Applicability Statement". T. Zseby, E. Boschi, N.Brownlee, B. Claise. Internet-Draft, work
in progress.
[i.22] ITU-T Recommendation G.114 (05/03): "One-way transmission time".
[i.23] ITU-T Recommendation G.1020 (07/06): "Performance parameter definitions for quality of speech
and other voiceband applications utilizing IP networks".
ETSI
9 ETSI EG 202 765-3 V1.1.1 (2009-12)
[i.24] IETF RFC 3917: "Requirements for IP Flow Information Export". J. Quittek, T. Zseby, B. Claise,
S. Zander. October 2004.
[i.25] Void.
[i.26] Void.
[i.27] Void.
[i.28] Void.
[i.29] "Reporting Metrics: Different Points of View", A. Morton, G. Ramachandran, G. Maguluri, work
in progress, draft-morton-ippm-reporting-metrics-02.
NOTE: http://tools.ietf.org/html/draft-morton-ippm-reporting-metrics-02, and the derived presentation "Reporting
Metrics: Different Points of View" presented by Al Morton on IETF66 July 2006,
http://www3.ietf.org/proceedings/06jul/slides/ippm-2.pdf.
[i.30] IETF RFC 3611: "RTP Control Protocol Extended Reports (RTCP XR)", T. Friedman, R. Caceres,
A. Clark. November 2003.
[i.31] IETF RFC 5136: "Defining Network Capacity", P. Chimento, J. Ishac. February 2008.
[i.32] IETF RFC 2581: "TCP Congestion Control", M. Allman, V. Paxson, W. Stevens. April 1999.
[i.33] IETF RFC 5357: "A Two-Way Active Measurement Protocol (TWAMP)", K. Hedayat,
R. Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008.
[i.34] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers", R. Braden ed.
October 1989.
[i.35] IETF RFC 3550: "User Accounts for UCSB On-Line System".
[i.36] IETF RFC 1633: "Integrated Services in the Internet Architecture: an Overview".
[i.37] IETF RFC 2216: "Network Element Service Specification Template".
[i.38] ITU-T Recommendation I.380: "Internet protocol data communication service - IP packet transfer
and availability performance parameters".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in RFC 2330 [i.3], ITU-T Recommendation
G.1020 [i.23] and RFC 2680 [i.6] apply.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
T, t Time
T Time threshold
max
dT Time difference
ETSI
10 ETSI EG 202 765-3 V1.1.1 (2009-12)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASON Automatically Switched Optical Network
ATM Asynchronous Transfer Mode
BTC Bulk transport Capacity
DNS Domain Name System
ESD End System Delay
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IPDV IP Packet Dealy Variation
IPFIX IP Flow Information eXport
IPLR IP Packet Loss Ratio
IPPM IP Performance Metrics
IPTD IP Packet Transfer Delay
ITU-T International Telecommunication Union - Telecommunication standardisation sector
MIB Management Information Base
NSE Network Section Ensemble
OP Observation Point
OWAMP One Way Active Measurement Protocol
OWD One Way Delay
PDV Packet Delay Variation
PIA Percent IP service Availability
PON Passive Optical Network
PSAMP Packet SAMPling
QoS Quality of Service
RFC Request For Comments
RTCP Real Time Control Protocol
RTD Round Trip Delay
RTP Real-Time Transport Protocol
RTT Round Trip Time
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
TCP Transmission Control Protocol
TWAMP Two-Way Active Measurement Protocol
UTC Coordinated Universal Time
VoIP Voice over IP
4 Performance Metrics Definitions and Measurement
Methods
This clause provides common definitions for network performance metrics. These definitions are based, whenever
possible, on existing definitions proposed by other relevant standard bodies such as IETF or ITU-T. Note that the
different definitions of similar metrics are in most cases compatible, that is, semantically equivalent or easily
convertible into one another.
ETSI
11 ETSI EG 202 765-3 V1.1.1 (2009-12)
For each metric, passive and active measurement methods are defined. Note that we chose to focus on commonly used
measurement methods rather than on standards; when a standard exists, a reference is provided as well. Note also that
throughout this text we refer for each metric to active and passive measurements in the following way:
• Active measurements
Active measurement methods inject traffic into the network and compute traffic metrics based on monitoring
the injected traffic or the response to the injected traffic. Active test traffic may perturb other traffic already
present on the network; therefore its scheduling and volume should be carefully configured. One can
distinguish active monitoring systems based on the position of sender and receiver and the observed traffic;
this is specified in detail for the considered metrics in the following text.
• Passive measurements
Passive measurements provide information about traffic in the observed network by capturing all or a selected
subset of the IP packets traversing a monitoring point. Since no test traffic is generated, passive measurements
can only be applied when the traffic of interest is already present on the network. The physical deployment of
monitoring probes in the network can be realised in different ways, depending on the metrics of interest, but
also on the network technology, e.g. via a physical line splitter, via a normal client connection in broadcast
networks, or via a dedicated monitoring port on a switch or router.
4.1 One Way Delay vs. IP Packet Transfer Delay
Delay is used to measure the expected time for an IP packet to traverse the network from one host to another. Delay is
applicable to QoS for latency-sensitive protocols. The IETF and ITU-T metrics for measuring delay are essentially
compatible, though there are minor differences; the details of these metrics are given in this clause.
4.1.1 IETF Definition
RFC 2679 [i.5] distinguishes between a "singleton analytic metric", called Type-P-One-way-Delay, and a "sample",
called Type-P-One-way-Delay-Poisson-Stream. The singleton is introduced to measure a single observation of one-way
delay, while the sample is used to measure a sequence of singleton delays measured at times taken from a Poisson
process. Based on these samples, several statistics are defined, such as Type-P-One-way-Delay-Percentile,
Type-P-One-way-Delay-Median, Type-P-One-way-Delay-Minimum, and Type-P-One-way-Delay-Inverse-Percentile.
Since the value of many of these metrics depends on the type of the IP packet used to perform the measurements, IPPM
metrics definitions include the generic notion of "a packet of type P", which should be further specified when making
actual measurements.
RFC 2679 [i.5] defines:
"For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at T is dT<< means that Src sent the first bit
of a Type-P packet to Dst at wire-time* T and that Dst received the last bit of that packet at wire-time T+dT."
The notion of wire time is introduced in RFC 2330 [i.3] in order to take into account the additional delay derived from
the use of Internet hosts to perform the measurements. Wire time is defined with reference to an Internet host H
observing an Internet link L at a particular location. More precisely, for a given packet P, the "wire arrival time" of P at
H on L is the first time (see note) T at which the first bit of P has appeared at H's observational position on L. On the
other side, For a given packet P, the 'wire exit time' of P at H on L is the first time T at which all the bits of P have
appeared at H's observational position on L. Wire time delay is defined as the time between the first wire arrival time,
the moment in which the first bit of the packet leaves the network interface of the source and the subsequent wire exit
time at the remote end, the moment at which it has arrived completely at the network interface of the destination host.
NOTE: An IP packet might arrive at the destination Dst more than once, due to retransmission.
An upper bound for the expected packet delivery is taken into account (this threshold should also be reported):
"If the packet fails to arrive within a reasonable period of time, the one-way delay is taken to be undefined (informally,
infinite)."
ETSI
12 ETSI EG 202 765-3 V1.1.1 (2009-12)
Further RFC 2680 [i.6] states about corrupted packets:
"If the packet arrives, but is corrupted, then it is counted as lost."
This is a useful approach since corrupted packets (even though they arrived) cannot be safely assigned to a flow or
traffic sender, as the source identifier might be a part of the packet that was corrupted.
4.1.2 ITU-T Definition
The ITU-T Recommendation Y.1540 [i.1] defines the IP Packet Transfer Delay (IPTD) metric as the one-way IP
packet transfer delay for all successful and errored packet transmissions across a basic section or a Network Section
Ensemble (NSE). IPTD is the time, (t - t ) between the occurrence of two corresponding IP packet reference events,
2 1
ingress event IPRE at time t and egress event IPRE at time t , where (t > t ) and (t - t ) ≤ T . If fragmentation
1 1 2 2 2 1 2 1 max
occurs then the time t is considered the time of the final corresponding fragment [i.1].
To understand this definition, the meaning of IP packet reference event has to be clarified. ITU-T Recommendation
Y.1540 [i.1] defines it as follows:
An IP packet transfer event occurs when:
• an IP packet crosses a Measurement Point (MP); and
• standard IP procedures applied to the packet verify that the header checksum is valid; and
• the source and destination address fields within the IP packet header represent the IP addresses of the expected
source host and destination host.
The IP packet transfer reference events are defined without regard to packet fragmentation.
An IP egress event is said to correspond to an earlier ingress event if they were created by the "same" IP packet.
Finally, the end-to-end IP packet transfer delay is the one-way delay between the measurement point at the source host
and destination host.
ITU-T Recommendation Y.1540 [i.1] also mentions the mean IP packet transfer delay, which is defined as the
arithmetic average of IP packet transfer delays for a packet population of interest.
4.1.3 Comparison and Recommendations
In general the ITU-T, due to its telecommunications origin, often assesses the observed delay at the endpoints of a full
end-to-end connection, i.e. from Network Termination Point to Network Termination Point., while IETF is concerned
with network delays among arbitrary points in the network. When setting upper limits for e.g. network planning then the
desired application (e.g. VoIP) as well as effects on QoS due to codecs and de-jitter buffers should be taken into
account for the assessment of the needed network QoS.
The two definitions from IETF and ITU-T for one way delay can be considered compatible, as for both definitions the
relevant events are (a) the time just before the packet is being put on the wire and (b) the time after complete reception
of the packet at the destination. Even though the RFC 2330 [i.3] definition of wire time delay has no direct equivalent in
ITU-T terminology, it can be interpreted as "visibility of a given packet at both Measurement Points"; to be precise for
the IETF the timing of the first and last bits of a packet on the wire is relevant, while ITU-T defines these events based
on the moment when the packet crosses a point in the sender's or the recipient's IP stack (see note). One can state that
one-way delay for both definitions yields the delay that one bit of the packet takes to travel across the network plus one
time the serialisation delay of the IP packet, depending on packet length and physical link speed. From the ITU-T
definition in ITU-T Recommendation Y.1540 [i.1] it is unclear what further delays inside the Measurement Points
might add to the measured delay.
NOTE: However Y.1540 states "The exact location of the IP Service measurement point in the IP protocol stack
is for further study"
ETSI
13 ETSI EG 202 765-3 V1.1.1 (2009-12)
In the IETF definition corrupted packets are deemed as lost, and their delay is formally defined as an undefined value of
delay, which can informally be designated "infinity". In contrast to that the IP packet transport delay, defined in ITU-T
Recommendation Y.1540 [i.1] applies to the combined set of successfully delivered and corrupted packets. Deciding
whether a packet is corrupted or lost can be difficult to detect in certain circumstances, such as applying hashing
methods to identify packets on reference and observation measurement points through an ID determined on the base of
the packet content. Special care should be taken to detect corrupted packets: In case that packet header or payload fields
are used in the measurement (e.g. serial packet id counter in active probing packets) then all checksums up to the
respective header or payload have to be checked.
Both, RFC 3393 [i.10] and ITU-T Recommendation Y.1540 [i.1], express their metrics on populations that are
conditioned on successful arrival within the waiting time, i.e. both definitions treat packets arriving after the waiting
time as lost packets. It is important to select a reasonably safe threshold to decide when packets are deemed lost. It
should be set so that no significant number of packets is observed as lost just because of being slightly late, i.e. a small
amount over the threshold. Otherwise the derived traffic statistics would be biased. This threshold should be reported
together with the measurement results. In case of fragmentation the time for the complete reception of all fragments
counts. If not all fragments are received, a packet is deemed lost. A detailed comparison of packet treatment for
one-way delay measurements is given in [i.29].
When computing statistics based on a series of delay values it is crucial to decide whether or not to include also the
"lost" (lost or too much delayed) packets in this computation. Both standards assume that for statistics like median or
other percentiles lost packets will be included (with a delay value of undefined or +infinity). For other statistics like
mean delay this is not a useful approach since otherwise the average delay would be undefined or +infinity even if only
one packet was lost in this measurement.
Apart from these details on the measurement of one-way delays and some differences in terminology there are no
significant differences between the definitions of One Way Delay versus IP Packet Transfer Delay.
To measure one-way metrics it is needed to ensure a synchronisation of both transmission ends of the measurement
device. This synchronisation may be done by GPS clocks when the two ends are distant. When ends are co-located
synchronisation may be done directly by the analyser. To assess the metric, the clock accuracy of the analyzer should be
better than 10 ppm.
4.1.4 Active Measurement Method
Active measurement of One-way Delay as defined by the IETF in RFC 2679 [i.5] requires the observation of test
packets transmitted between two endpoints across a network, a "source" host, which sends the test packet, and a
"destination" host, which receives the test packet. The One-way Delay is then calculated as the difference between the
time at which the test packet is received at the destination and the time the test packet is sent.
The procedure to take a One-way Delay measurement involves the following steps:
1) The source host and the destination host are synchronized.
2) The destination host is prepared to receive the test packets sent by the source host.
3) The source host constructs a test packet. Any 'padding' portion of the packet needed only to make the test
packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is
lower than it would otherwise be due to compression techniques along the path.
4) The source host places a timestamp in the prepared packet.
NOTE: Usually it also places a counter or identifier in the test packet, so that the destination host may also
identify the number of lost test packets.
5) The source host sends the test packet to the destination host.
6) The destination host receives the test packet and records its arrival time.
7) The destination host calculates a One-way Delay by subtracting the two timestamps. If the delay between
source host's timestamp and the actual sending of the packet is known, then the estimate could be adjusted by
subtracting this amount. Similarly, if the delay between the actual complete receipt of the packet by the
destination's network interface card and destination host's timestamp is known, then the estimate could be
adjusted by subtracting this amount. If the packet fails to arrive within a reasonable period of time, the
one-way delay is taken to be undefined.
ETSI
14 ETSI EG 202 765-3 V1.1.1 (2009-12)
8) The destination host optionally forwards the result back to the source, if the result is required at the source.
Figure 1: Active One-Way Delay Measurement Method
The IETF has defined the One-Way Active Measurement Protocol (OWAMP) [i.14] for the active measurement of the
one-way delay metric. OWAMP consists of a control protocol to negotiate active performance measurement sessions,
and a test protocol for transmission of actual test packets. OWAMP requires some minimal measurement infrastructure.
It defines five entities, a Control Client, which specifies the test to run and passes that specification using the control
protocol to a Server; this control interaction then causes a Session Sender and Session Receiver to send packets via the
test protocol for the duration of the requested test. The Fetch Client then retrieves the test results from the Server. The
test protocol allows accurate measurement of one-way delay without including processing overhead or other unknown
timing components, and is designed to be resistant to detection and manipulation. In common usage, the Control Client,
Fetch Client, and Session Sender are on one host, and the Server and Session Receiver are on another.
4.1.5 Passive Measurement Method
One-way delay may be measured passively by observing the same packet at two points in the network, and calculating
the difference between the arrival times at these points. Calculating this metric requires the correlation of data from
multiple Observation Points (OPs). The same packet is recognised at different Observation Points; this can be done by
using invariant parts of the header or the payload or by calculating a packet identifier based on the invariant header
fields and/or the packet content. Using the packet identifier reduces the amount of measurement data and can be easily
obtained by calculating CRCs or hash functions. Proper clock synchronization between the observation points is
important.
The passive procedure to take a One-way Delay measurement involves the following steps:
1) The source Observation Point and the destination Observation Point are synchronized.
2) The source and destination OPs are prepared to measure packets sent from the source host.
3) A source host sends a packet to the destination on a path where it is observable by source and destination OP.
4) The source OP observes this packet, records a timestamp of the observation, and identifies it.
5) The source OP forwards information about the observation event, i.e. the packet identification and timestamp
to the destination OP. This operation may be performed in batches, after some specific number of packets have
been observed or a given time interval has passed.
6) The destination OP recognises the packet and records its arrival time.
7) One-way delay is computed as the difference between the two arrival times. There is no strict need to perform
this operation at the destination OP; a fifth host (not shown in figure 2) may also perform this operation when
source and destination OP forward information about the observation event to it.
ETSI
15 ETSI EG 202 765-3 V1.1.1 (2009-12)
These steps are also shown in figure 2. The red dotted lines in the figure show the potential delay measurement error,
which exists since there is a time difference between the source itself and the Observation point (OP), as well as
between the destination and the destination OP. It is therefore recommended to keep the OP as close as possible to the
source or destination, respectively.
Figure 2: Passive one-way delay measurement method
Note that in contrast to active one-way delay monitoring the approach for passive one-way delay measurements does
not include in the results the time for the serialisation delay due to the fact that both monitoring points are acting as
packet receivers. If active and passive OWD measurement results are compared then this should be taken into account;
however the serialization time becomes more and more negligible compared to the network delay the faster the net data
rate of the underlying networking technology is.
The IETF IPFIX [i.18] or PSAMP protocols may be used for reporting packet contents, hashes, and timestamps from
each passive observation point, as in [i.21]; each of these reports may be used to calculate a singleton in IPPM
terminology or a single delay in ITU-T terminology.
4.2 Round Trip Delay
Round-trip delay is used to measure the expected time for network interaction between two hosts on a network;
conceptually, it is equivalent to Delay in each direction between the two hosts. Round-trip delay is applicable to QoS
for latency-sensitive protocols. The I
...
SLOVENSKI STANDARD
01-oktober-2016
.DNRYRVWSUHQRVDJRYRUDLQYHþSUHGVWDYQLKYVHELQ 674 0HWULNDNDNRYRVWL
VWRULWHY 4R6 LQ]PRJOMLYRVWLRPUHåMDWHUPHULOQHPHWRGHGHO 0HWRGHPHWULNH
LQPHUMHQMD]PRJOMLYRVWLRPUHåLMYRPUHåMLK,3
Speech and multimediaTransmission Quality (STQ) - QoS and network performance
metrics and measurement methods - Part 3: Network performance metrics and
measurement methods in IP networks
Ta slovenski standard je istoveten z: ETSI EG 202 765-3 V1.1.1 (2009-12)
ICS:
33.040.35 Telefonska omrežja Telephone networks
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
ETSI Guide
Speech and multimedia Transmission Quality (STQ);
QoS and network performance metrics and
measurement methods;
Part 3: Network performance metrics and
measurement methods in IP networks
2 ETSI EG 202 765-3 V1.1.1 (2009-12)
Reference
DEG/STQ-00104-3
Keywords
performance, QoS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI EG 202 765-3 V1.1.1 (2009-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Symbols . 9
3.3 Abbreviations . 10
4 Performance Metrics Definitions and Measurement Methods . 10
4.1 One Way Delay vs. IP Packet Transfer Delay . 11
4.1.1 IETF Definition . 11
4.1.2 ITU-T Definition . 12
4.1.3 Comparison and Recommendations . 12
4.1.4 Active Measurement Method . 13
4.1.5 Passive Measurement Method . 14
4.2 Round Trip Delay . 15
4.2.1 IETF Definition . 15
4.2.2 ITU-T Definition . 16
4.2.3 Comparison and Recommendations . 16
4.2.4 Active Measurement Method . 16
4.2.5 Passive Measurement Method . 17
4.3 IP Packet Delay Variation vs. End-to-end 2-point IP Packet Delay Variation . 19
4.3.1 IETF Definition . 19
4.3.2 ITU-T Definition . 20
4.3.3 Comparison and Recommendations . 21
4.3.4 Active Measurement Method . 22
4.3.5 Passive Measurement Method . 22
4.4 One Way Packet Loss vs. IP Packet Loss Ratio . 22
4.4.1 IETF Definition . 23
4.4.2 ITU-T Definition . 23
4.4.3 Comparison and Recommendations . 23
4.4.4 Active Measurement Method . 23
4.4.5 Passive Measurement Method . 24
4.5 Connectivity vs. IP Service Availability . 24
4.5.1 IETF Definition . 24
4.5.2 ITU-T Definition . 25
4.5.3 Comparison and Recommendations . 25
4.5.4 Active Measurement Method . 26
4.5.5 Passive Measurement Method . 26
5 Other Metrics . 26
5.1 Data and Packet Volume . 26
5.2 Packet Reordering . 27
5.3 Bandwidth Capacity, Available Bandwidth, and Utilization . 27
5.4 Bulk Transport Capacity . 27
5.5 Loss Patterns . 27
5.6 RTCP reported metrics . 28
6 Overview of Network Performance Relevant Standard Bodies and Working Groups . 29
6.1 IETF . 29
6.1.1 IPPM (IP Performance Metrics) Working Group . 29
ETSI
4 ETSI EG 202 765-3 V1.1.1 (2009-12)
6.1.2 IPFIX (IP Flow Information eXport) Working Group . 29
6.1.3 PSAMP (Packet SAMPling) Working Group . 30
6.2 ITU-T . 30
6.2.1 Study Group 12 (Performance and quality of service) . 30
6.2.2 Study Group 15 (Optical and other transport network infrastructures) . 30
Annex A: Bibliography . 32
History . 33
ETSI
5 ETSI EG 202 765-3 V1.1.1 (2009-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Speech and multimedia Transmission Quality
(STQ).
The present document is part 3 of a multi-part deliverable covering the QoS and network performance metrics and
measurement methods, as identified below:
Part 1: "General considerations";
Part 2: "Transmission Quality Indicator combining Voice Quality Metrics";
Part 3: "Network performance metrics and measurement methods in IP networks";
Part 4: "Indicators for supervision of Multiplay services".
Introduction
The need to define Internet performance metrics and measurement methodologies stems from the need to compare
different measurements and to measure performance with a reproducible and unambiguous methodology, independent
from transmission technology and implementation details. Both the ITU-T Study Group 12 and the IETF IPPM
Working Group have produced such definitions (see table 1), although each with a different emphasis closely linked to
the historical background of both organizations. The ITU has its origins in telephony, while the IETF has a data
networking background. Whereas the ITU emphasizes the evaluation of a service and its quality, the IETF measures the
network and wants to provide the IT-community with an accurate, common understanding and measurement of the
performance and reliability the Internet [i.3].
In most cases this results in different terminology rather than in incompatibilities; most differences in approach and
emphasis serve the different intended use of each metric, but have no operational significance. In some cases the
terminology used by each organisations can be mapped to the other, while in some others there is only approximate
equivalence (e.g. ITU network section versus an IPPM cloud; one focuses on corresponding events while the other
measures the fate of a single packet). Other terms have no correspondence. For example, ITU-T Recommendation
I.380 [i.38] has a notion of an IP packet transfer reference event while IPPM defines "wire time".
Other differences between IETF and ITU-T metrics result from their intended application. ITU-T metrics seek to
provide a common language for providers to communicate about performance, so the ITU-T metrics do not concentrate
on performance within a single network, while the IETF focuses on performance measurement protocols and
implementation. ITU-T seeks to evaluate service and to exclude unfair use, while the IETF seeks to measure network
quantities and avoid biased measurement results. Due to their respective backgrounds, the ITU generally produces
statistical metrics geared towards a quantitative representation of the complete end-to-end user experience while the
IETF IPPM working group mainly focuses more on statistical metrics which provide a detailed technical view of
different aspects of transmission quality along the network path.
ETSI
6 ETSI EG 202 765-3 V1.1.1 (2009-12)
Table 1: Overview of Relevant Standards
IETF RFCs ITU-T Recommendations
Framework
RFC 2330 [i.3] Y.1540 [i.1], sections 1 through 5
Loss RFC 2680 [i.6] Y.1540 [i.1], section 5.5.6
G.1020 [i.23]
Delay
RFC 2679 [i.5] (One-way) Y.1540 [i.1], section 6.2
RFC 2681 [i.7] (Round Trip) G.1020 [i.23]
G.114 [i.22] (One-way)
Delay Variation RFC 3393 [i.10] Y.1540 [i.1], section 6.2.2
G.1020 [i.23]
Connectivity / Availability RFC 2678 [i.4] Y.1540 [i.1], section 7
Loss Patterns RFC 3357 [i.9] G.1020 [i.23]
Packet Reordering RFC 4737 [i.15] Y.1540 [i.1], sections 5.5.8.1 and 6.6
Packet Duplication Y.1540 [i.1], sections 5.5.8.3, 5.5.8.4,
6.8, and 6.9
Link/Path Bandwidth Capacity, Link
RFC 5136 [i.31]
Utilization, Available Capacity
Bulk Transport Capacity RFC 3148 [i.8], RFC 5136 [i.31]
The goal of the present document is to define network performance metrics for applications sensitive to quality of
service such as Voice over IP, referring to the existing work produced by both IETF and ITU-T. The present document
highlights the differences between the two standards and provides guidelines on resolving these differences, when they
are due to addressing different goals.
The scope of the present document is limited to IP performance metrics relevant for data transmission over IP-based
networks for use in QoS sensitive applications. For each addressed metric, the document recommends one or more
measurement methods. The document only focuses on intrinsic network QoS metrics; perceived QoS metrics applicable
for voice transmission are out of scope of the present document.
The remainder of the present document is organised as follows: Clause 4 describes the definitions of the most important
performance metrics as defined by the standard bodies and methods for measuring them, and discusses the applicability
of the definitions and the differences between them. Clause 5 discusses other metrics applicable to QoS. Finally,
clause 6 gives an overview of relevant QoS measurement standards, which can be used in end to end performance
evaluation.
ETSI
7 ETSI EG 202 765-3 V1.1.1 (2009-12)
1 Scope
The present document provides an overview of the common metric definitions and measurement method specifications
upon which the interoperability of network performance measurement (also called QoS measurement) is based. Two
different standardisation bodies, the Internet Engineering Task Force (IETF) and the International Telecommunication
Union - Telecommunication Standardization Sector (ITU - T), have addressed this issue. The present document
addresses the following points:
• Survey the existing network performance related IETF standards and how these standards can be applied to
end-to-end network performance measurements. The scope of this work is also to discuss the relationship of
those standards to those of ITU-T and ETSI.
• Discuss and compare definitions of metrics used to specify and assess performance in IP networks. The
metrics addressed in the present document are those defined by the IETF IPPM working group and ITU-T
Study Group 12. Besides comparing the different definitions, the present document gives applicability
guidelines on which metric is more appropriate for a particular application, configuration or scenario.
• Define measurement methods for selected performance metrics in IP networks, addressing both active and
passive methods. Clarifying guidelines are given.
NOTE: All text sections in the remainder of the present document which are enclosed in quotation marks (") and
formatted in italic style denote citations taken verbatim from referenced documents.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
ETSI
8 ETSI EG 202 765-3 V1.1.1 (2009-12)
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ITU-T Recommendation Y.1540: "Internet protocol data communication service - IP packet
transfer and availability performance parameters".
[i.2] Void.
[i.3] IETF RFC 2330: "Framework for IP Performance Metrics". V. Paxson, G. Almes, J. Mahdavi,
M. Mathis. May 1998.
[i.4] IETF RFC 2678: "IPPM Metrics for Measuring Connectivity". J. Mahdavi, V. Paxson.
September 1999.
[i.5] IETF RFC 2679: "A One-way Delay Metric for IPPM". G. Almes, S. Kalidindi, M. Zekauskas.
September 1999.
[i.6] IETF RFC 2680: "A One-way Packet Loss Metric for IPPM". G. Almes, S. Kalidindi,
M. Zekauskas. September 1999.
[i.7] IETF RFC 2681: "A Round-trip Delay Metric for IPPM". G. Almes, S. Kalidindi, M. Zekauskas.
September 1999.
[i.8] IETF RFC 3148: "A Framework for Defining Empirical Bulk Transfer Capacity Metrics".
M. Mathis, M. Allman. July 2001.
[i.9] IETF RFC 3357: "One-way Loss Pattern Sample Metrics". R. Koodli, R. Ravikanth. August 2002.
[i.10] IETF RFC 3393: "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)".
C. Demichelis, P. Chimento. November 2002.
[i.11] Void.
[i.12] Void.
[i.13] Void.
[i.14] IETF RFC 4656: "A One-way Active Measurement Protocol (OWAMP)". S. Shalunov,
B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006.
[i.15] IETF RFC 4737: "Packet Reordering Metrics". A. Morton, L. Ciavattone, G. Ramachandran,
S. Shalunov, J. Perser. November 2006.
[i.16] Void.
[i.17] Void.
[i.18] IETF RFC 5101: "Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow
Information". B. Claise, S. Bryant, S. Leinen, T. Deitz, B.Trammell. January 2008.
[i.19] IPFIX Architecture. N.Brownlee et Al. Internet-Draft, work in progress.
[i.20] IETF RFC 5102: "IPFIX Information Model". J. Quittek et Al. January 2008.
[i.21] "IPFIX Applicability Statement". T. Zseby, E. Boschi, N.Brownlee, B. Claise. Internet-Draft, work
in progress.
[i.22] ITU-T Recommendation G.114 (05/03): "One-way transmission time".
[i.23] ITU-T Recommendation G.1020 (07/06): "Performance parameter definitions for quality of speech
and other voiceband applications utilizing IP networks".
ETSI
9 ETSI EG 202 765-3 V1.1.1 (2009-12)
[i.24] IETF RFC 3917: "Requirements for IP Flow Information Export". J. Quittek, T. Zseby, B. Claise,
S. Zander. October 2004.
[i.25] Void.
[i.26] Void.
[i.27] Void.
[i.28] Void.
[i.29] "Reporting Metrics: Different Points of View", A. Morton, G. Ramachandran, G. Maguluri, work
in progress, draft-morton-ippm-reporting-metrics-02.
NOTE: http://tools.ietf.org/html/draft-morton-ippm-reporting-metrics-02, and the derived presentation "Reporting
Metrics: Different Points of View" presented by Al Morton on IETF66 July 2006,
http://www3.ietf.org/proceedings/06jul/slides/ippm-2.pdf.
[i.30] IETF RFC 3611: "RTP Control Protocol Extended Reports (RTCP XR)", T. Friedman, R. Caceres,
A. Clark. November 2003.
[i.31] IETF RFC 5136: "Defining Network Capacity", P. Chimento, J. Ishac. February 2008.
[i.32] IETF RFC 2581: "TCP Congestion Control", M. Allman, V. Paxson, W. Stevens. April 1999.
[i.33] IETF RFC 5357: "A Two-Way Active Measurement Protocol (TWAMP)", K. Hedayat,
R. Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008.
[i.34] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers", R. Braden ed.
October 1989.
[i.35] IETF RFC 3550: "User Accounts for UCSB On-Line System".
[i.36] IETF RFC 1633: "Integrated Services in the Internet Architecture: an Overview".
[i.37] IETF RFC 2216: "Network Element Service Specification Template".
[i.38] ITU-T Recommendation I.380: "Internet protocol data communication service - IP packet transfer
and availability performance parameters".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in RFC 2330 [i.3], ITU-T Recommendation
G.1020 [i.23] and RFC 2680 [i.6] apply.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
T, t Time
T Time threshold
max
dT Time difference
ETSI
10 ETSI EG 202 765-3 V1.1.1 (2009-12)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASON Automatically Switched Optical Network
ATM Asynchronous Transfer Mode
BTC Bulk transport Capacity
DNS Domain Name System
ESD End System Delay
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IPDV IP Packet Dealy Variation
IPFIX IP Flow Information eXport
IPLR IP Packet Loss Ratio
IPPM IP Performance Metrics
IPTD IP Packet Transfer Delay
ITU-T International Telecommunication Union - Telecommunication standardisation sector
MIB Management Information Base
NSE Network Section Ensemble
OP Observation Point
OWAMP One Way Active Measurement Protocol
OWD One Way Delay
PDV Packet Delay Variation
PIA Percent IP service Availability
PON Passive Optical Network
PSAMP Packet SAMPling
QoS Quality of Service
RFC Request For Comments
RTCP Real Time Control Protocol
RTD Round Trip Delay
RTP Real-Time Transport Protocol
RTT Round Trip Time
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
TCP Transmission Control Protocol
TWAMP Two-Way Active Measurement Protocol
UTC Coordinated Universal Time
VoIP Voice over IP
4 Performance Metrics Definitions and Measurement
Methods
This clause provides common definitions for network performance metrics. These definitions are based, whenever
possible, on existing definitions proposed by other relevant standard bodies such as IETF or ITU-T. Note that the
different definitions of similar metrics are in most cases compatible, that is, semantically equivalent or easily
convertible into one another.
ETSI
11 ETSI EG 202 765-3 V1.1.1 (2009-12)
For each metric, passive and active measurement methods are defined. Note that we chose to focus on commonly used
measurement methods rather than on standards; when a standard exists, a reference is provided as well. Note also that
throughout this text we refer for each metric to active and passive measurements in the following way:
• Active measurements
Active measurement methods inject traffic into the network and compute traffic metrics based on monitoring
the injected traffic or the response to the injected traffic. Active test traffic may perturb other traffic already
present on the network; therefore its scheduling and volume should be carefully configured. One can
distinguish active monitoring systems based on the position of sender and receiver and the observed traffic;
this is specified in detail for the considered metrics in the following text.
• Passive measurements
Passive measurements provide information about traffic in the observed network by capturing all or a selected
subset of the IP packets traversing a monitoring point. Since no test traffic is generated, passive measurements
can only be applied when the traffic of interest is already present on the network. The physical deployment of
monitoring probes in the network can be realised in different ways, depending on the metrics of interest, but
also on the network technology, e.g. via a physical line splitter, via a normal client connection in broadcast
networks, or via a dedicated monitoring port on a switch or router.
4.1 One Way Delay vs. IP Packet Transfer Delay
Delay is used to measure the expected time for an IP packet to traverse the network from one host to another. Delay is
applicable to QoS for latency-sensitive protocols. The IETF and ITU-T metrics for measuring delay are essentially
compatible, though there are minor differences; the details of these metrics are given in this clause.
4.1.1 IETF Definition
RFC 2679 [i.5] distinguishes between a "singleton analytic metric", called Type-P-One-way-Delay, and a "sample",
called Type-P-One-way-Delay-Poisson-Stream. The singleton is introduced to measure a single observation of one-way
delay, while the sample is used to measure a sequence of singleton delays measured at times taken from a Poisson
process. Based on these samples, several statistics are defined, such as Type-P-One-way-Delay-Percentile,
Type-P-One-way-Delay-Median, Type-P-One-way-Delay-Minimum, and Type-P-One-way-Delay-Inverse-Percentile.
Since the value of many of these metrics depends on the type of the IP packet used to perform the measurements, IPPM
metrics definitions include the generic notion of "a packet of type P", which should be further specified when making
actual measurements.
RFC 2679 [i.5] defines:
"For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at T is dT<< means that Src sent the first bit
of a Type-P packet to Dst at wire-time* T and that Dst received the last bit of that packet at wire-time T+dT."
The notion of wire time is introduced in RFC 2330 [i.3] in order to take into account the additional delay derived from
the use of Internet hosts to perform the measurements. Wire time is defined with reference to an Internet host H
observing an Internet link L at a particular location. More precisely, for a given packet P, the "wire arrival time" of P at
H on L is the first time (see note) T at which the first bit of P has appeared at H's observational position on L. On the
other side, For a given packet P, the 'wire exit time' of P at H on L is the first time T at which all the bits of P have
appeared at H's observational position on L. Wire time delay is defined as the time between the first wire arrival time,
the moment in which the first bit of the packet leaves the network interface of the source and the subsequent wire exit
time at the remote end, the moment at which it has arrived completely at the network interface of the destination host.
NOTE: An IP packet might arrive at the destination Dst more than once, due to retransmission.
An upper bound for the expected packet delivery is taken into account (this threshold should also be reported):
"If the packet fails to arrive within a reasonable period of time, the one-way delay is taken to be undefined (informally,
infinite)."
ETSI
12 ETSI EG 202 765-3 V1.1.1 (2009-12)
Further RFC 2680 [i.6] states about corrupted packets:
"If the packet arrives, but is corrupted, then it is counted as lost."
This is a useful approach since corrupted packets (even though they arrived) cannot be safely assigned to a flow or
traffic sender, as the source identifier might be a part of the packet that was corrupted.
4.1.2 ITU-T Definition
The ITU-T Recommendation Y.1540 [i.1] defines the IP Packet Transfer Delay (IPTD) metric as the one-way IP
packet transfer delay for all successful and errored packet transmissions across a basic section or a Network Section
Ensemble (NSE). IPTD is the time, (t - t ) between the occurrence of two corresponding IP packet reference events,
2 1
ingress event IPRE at time t and egress event IPRE at time t , where (t > t ) and (t - t ) ≤ T . If fragmentation
1 1 2 2 2 1 2 1 max
occurs then the time t is considered the time of the final corresponding fragment [i.1].
To understand this definition, the meaning of IP packet reference event has to be clarified. ITU-T Recommendation
Y.1540 [i.1] defines it as follows:
An IP packet transfer event occurs when:
• an IP packet crosses a Measurement Point (MP); and
• standard IP procedures applied to the packet verify that the header checksum is valid; and
• the source and destination address fields within the IP packet header represent the IP addresses of the expected
source host and destination host.
The IP packet transfer reference events are defined without regard to packet fragmentation.
An IP egress event is said to correspond to an earlier ingress event if they were created by the "same" IP packet.
Finally, the end-to-end IP packet transfer delay is the one-way delay between the measurement point at the source host
and destination host.
ITU-T Recommendation Y.1540 [i.1] also mentions the mean IP packet transfer delay, which is defined as the
arithmetic average of IP packet transfer delays for a packet population of interest.
4.1.3 Comparison and Recommendations
In general the ITU-T, due to its telecommunications origin, often assesses the observed delay at the endpoints of a full
end-to-end connection, i.e. from Network Termination Point to Network Termination Point., while IETF is concerned
with network delays among arbitrary points in the network. When setting upper limits for e.g. network planning then the
desired application (e.g. VoIP) as well as effects on QoS due to codecs and de-jitter buffers should be taken into
account for the assessment of the needed network QoS.
The two definitions from IETF and ITU-T for one way delay can be considered compatible, as for both definitions the
relevant events are (a) the time just before the packet is being put on the wire and (b) the time after complete reception
of the packet at the destination. Even though the RFC 2330 [i.3] definition of wire time delay has no direct equivalent in
ITU-T terminology, it can be interpreted as "visibility of a given packet at both Measurement Points"; to be precise for
the IETF the timing of the first and last bits of a packet on the wire is relevant, while ITU-T defines these events based
on the moment when the packet crosses a point in the sender's or the recipient's IP stack (see note). One can state that
one-way delay for both definitions yields the delay that one bit of the packet takes to travel across the network plus one
time the serialisation delay of the IP packet, depending on packet length and physical link speed. From the ITU-T
definition in ITU-T Recommendation Y.1540 [i.1] it is unclear what further delays inside the Measurement Points
might add to the measured delay.
NOTE: However Y.1540 states "The exact location of the IP Service measurement point in the IP protocol stack
is for further study"
ETSI
13 ETSI EG 202 765-3 V1.1.1 (2009-12)
In the IETF definition corrupted packets are deemed as lost, and their delay is formally defined as an undefined value of
delay, which can informally be designated "infinity". In contrast to that the IP packet transport delay, defined in ITU-T
Recommendation Y.1540 [i.1] applies to the combined set of successfully delivered and corrupted packets. Deciding
whether a packet is corrupted or lost can be difficult to detect in certain circumstances, such as applying hashing
methods to identify packets on reference and observation measurement points through an ID determined on the base of
the packet content. Special care should be taken to detect corrupted packets: In case that packet header or payload fields
are used in the measurement (e.g. serial packet id counter in active probing packets) then all checksums up to the
respective header or payload have to be checked.
Both, RFC 3393 [i.10] and ITU-T Recommendation Y.1540 [i.1], express their metrics on populations that are
conditioned on successful arrival within the waiting time, i.e. both definitions treat packets arriving after the waiting
time as lost packets. It is important to select a reasonably safe threshold to decide when packets are deemed lost. It
should be set so that no significant number of packets is observed as lost just because of being slightly late, i.e. a small
amount over the threshold. Otherwise the derived traffic statistics would be biased. This threshold should be reported
together with the measurement results. In case of fragmentation the time for the complete reception of all fragments
counts. If not all fragments are received, a packet is deemed lost. A detailed comparison of packet treatment for
one-way delay measurements is given in [i.29].
When computing statistics based on a series of delay values it is crucial to decide whether or not to include also the
"lost" (lost or too much delayed) packets in this computation. Both standards assume that for statistics like median or
other percentiles lost packets will be included (with a delay value of undefined or +infinity). For other statistics like
mean delay this is not a useful approach since otherwise the average delay would be undefined or +infinity even if only
one packet was lost in this measurement.
Apart from these details on the measurement of one-way delays and some differences in terminology there are no
significant differences between the definitions of One Way Delay versus IP Packet Transfer Delay.
To measure one-way metrics it is needed to ensure a synchronisation of both transmission ends of the measurement
device. This synchronisation may be done by GPS clocks when the two ends are distant. When ends are co-located
synchronisation may be done directly by the analyser. To assess the metric, the clock accuracy of the analyzer should be
better than 10 ppm.
4.1.4 Active Measurement Method
Active measurement of One-way Delay as defined by the IETF in RFC 2679 [i.5] requires the observation of test
packets transmitted between two endpoints across a network, a "source" host, which sends the test packet, and a
"destination" host, which receives the test packet. The One-way Delay is then calculated as the difference between the
time at which the test packet is received at the destination and the time the test packet is sent.
The procedure to take a One-way Delay measurement involves the following steps:
1) The source host and the destination host are synchronized.
2) The destination host is prepared to receive the test packets sent by the source host.
3) The source host constructs a test packet. Any 'padding' portion of the packet needed only to make the test
packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is
lower than it would otherwise be due to compression techniques along the path.
4) The source host places a timestamp in the prepared packet.
NOTE: Usually it also places a counter or identifier in the test packet, so that the destination host may also
identify the number of lost test packets.
5) The source host sends the test packet to the destination host.
6) The destination host receives the test packet and records its arrival time.
7) The destination host calculates a One-way Delay by subtracting the two timestamps. If the delay between
source host's timestamp and the actual sending of the packet is known, then the estimate could be adjusted by
subtracting this amount. Similarly, if the delay between the actual complete receipt of the packet by the
destination's network interface card and destination host's timestamp is known, then the estimate could be
adjusted by subtracting this amount. If the packet fails to arrive within a reasonable period of time, the
one-way delay is taken to be undefined.
ETSI
14 ETSI EG 202 765-3 V1.1.1 (2009-12)
8) The destination host optionally forwards the result back to the source, if the result is required at the source.
Figure 1: Active One-Way Delay Measurement Method
The IETF has defined the One-Way Active Measurement Protocol (OWAMP) [i.14] for the active measurement of the
one-way delay metric. OWAMP consists of a control protocol to negotiate active performance measurement sessions,
and a test protocol for transmission of actual test packets. OWAMP requires some minimal measurement infrastructure.
It defines five entities, a Control Client, which specifies the test to run and passes that specification using the control
protocol to a Server; this control interaction then causes a Session Sender and Session Receiver to send packets via the
test protocol for the duration of the requested test. The Fetch Client then retrieves the test results from the Server. The
test protocol allows accurate measurement of one-way delay without including processing overhead or other unknown
timing components, and is designed to be resistant to detection and manipulation. In common usage, the Control Client,
Fetch Client, and Session Sender are on one host, and the Server and Session Receiver are on another.
4.1.5 Passive Measurement Method
One-way delay may be measured passively by observing the same packet at two points in the network, and calculating
the difference between the arrival times at these points. Calculating this metric requires the correlation of data from
multiple Observation Points (OPs). The same packet is recognised at different Observation Points; this can be done by
using invariant parts of the header or the payload or by calculating a packet identifier based on the invariant header
fields and/or the packet content. Using the packet identifier reduces the amount of measurement data and can be easily
obtained by calculating CRCs or hash functions. Proper clock synchronization between the observation points is
important.
The passive procedure to take a One-way Delay measurement involves the following steps:
1) The source Observation Point and the destination Observation Point are synchronized.
2) The source and destination OPs are prepared to measure packets sent from the source host.
3) A source host sends a packet to the destination on a path where it is observable by source and destination OP.
4) The source OP observes this packet, records a timestamp of the observation, and identifies it.
5) The source OP forwards information about the observation event, i.e. the packet identification and timestamp
to the destination OP. This operation may be performed in batches, after some specific number of packets have
been observed or a given time interval has passed.
6) The destination OP recognises the packet and records its arrival time.
7) One-way delay is computed as the difference between the two arrival times. There is no strict need to perform
this operation at the destination OP; a fifth host (not shown in figure 2) may also perform this operation when
source and destination OP forward information about the observation event to it.
ETSI
15 ETSI EG 202 765-3 V1.1.1 (2009-12)
These steps are also shown in fi
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...