|
|
|
|
|
|
|
|
|
|
| Last Update: Aug 23, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2330
05/1998
(40 p.)
pdf(2p)
|
V. Paxson
G. Almes
J. Mahdavi
M. Mathis |
|
Framework for IP Performance Metrics |
|
The purpose of this memo is to define a general framework for
particular metrics to be developed by the IETF's IP Performance
Metrics effort, begun by the Benchmarking Methodology Working Group
(BMWG) of the Operational Requirements Area, and being continued by
the IP Performance Metrics Working Group (IPPM) of the Transport
Area.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC2678
09/1999
(10 p.)
pdf(2p)
|
J. Mahdavi
V. Paxson |
|
IPPM Metrics for Measuring Connectivity |
Connectivity is the basic stuff from which the Internet is made.
Therefore, metrics determining whether pairs of hosts (IP addresses)
can reach each other must form the base of a measurement suite. We
define several such metrics, some of which serve mainly as building
blocks for the others.
This memo defines a series of metrics for connectivity between a pair
of Internet hosts. It builds on notions introduced and discussed in
RFC 2330, the IPPM framework document. The reader is assumed to be
familiar with that document.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC2679
09/1999
(20 p.)
pdf(2p)
|
G. Almes
S. Kalidindi
M. Zekauskas |
|
A One-way Delay Metric for IPPM |
This memo defines a metric for one-way delay of packets across
Internet paths. It builds on notions introduced and discussed in the
IPPM Framework document, RFC 2330; the reader is assumed to be
familiar with that document.
This memo is intended to be parallel in structure to a companion
document for Packet Loss ("A One-way Packet Loss Metric for IPPM").
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC2680
09/1999
(15 p.)
pdf(2p)
|
G. Almes
S. Kalidindi
M. Zekauskas |
|
A One-way Packet Loss Metric for IPPM |
This memo defines a metric for one-way packet loss across Internet
paths. It builds on notions introduced and discussed in the IPPM
Framework document, RFC 2330; the reader is assumed to be
familiar with that document.
This memo is intended to be parallel in structure to a companion
document for One-way Delay ("A One-way Delay Metric for IPPM");
the reader is assumed to be familiar with that document.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC2681
09/1999
(20 p.)
pdf(2p)
|
G. Almes
S. Kalidindi
M. Zekauskas |
|
A Round-trip Delay Metric for IPPM |
This memo defines a metric for round-trip delay of packets across
Internet paths. It builds on notions introduced and discussed in the
IPPM Framework document, RFC 2330, and follows closely the
corresponding metric for One-way Delay ("A One-way Delay Metric for
IPPM"); the reader is assumed to be familiar with those
documents.
The memo was largely written by copying material from the One-way
Delay metric. The intention is that, where the two metrics are
similar, they will be described with similar or identical text, and
that where the two metrics differ, new or modified text will be used.
This memo is intended to be parallel in structure to a future
companion document for Packet Loss.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3357
08/2002
(15 p.)
pdf(2p)
|
R. Koodli
R. Ravikanth |
|
One-way Loss Pattern Sample Metrics |
|
Using the base loss metric defined in RFC 2680, this document defines
two derived metrics "loss distance" and "loss period", and the
associated statistics that together capture loss patterns experienced
by packet streams on the Internet. The Internet exhibits certain
specific types of behavior (e.g., bursty packet loss) that can affect
the performance seen by the users as well as the operators. The loss
pattern or loss distribution is a key parameter that determines the
performance observed by the users for certain real-time applications
such as packet voice and video. For the same loss rate, two
different loss distributions could potentially produce widely
different perceptions of performance.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3393
11/2002
(21 p.)
pdf(2p)
|
C. Demichelis
P. Chimento |
|
IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) |
This document refers to a metric for variation in delay of packets
across Internet paths. The metric is based on the difference in the
One-Way-Delay of selected packets. This difference in delay is
called "IP Packet Delay Variation (ipdv)".
The metric is valid for measurements between two hosts both in the
case that they have synchronized clocks and in the case that they are
not synchronized. We discuss both in this document.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC3432
11/2002
(23 p.)
pdf(2p)
|
V. Raisanen
G. Grotefeld
A. Morton |
|
Network performance measurement with periodic streams |
|
This memo describes a periodic sampling method and relevant metrics
for assessing the performance of IP networks. First, the memo
motivates periodic sampling and addresses the question of its value
as an alternative to the Poisson sampling described in RFC 2330. The
benefits include applicability to active and passive measurements,
simulation of constant bit rate (CBR) traffic (typical of multimedia
communication, or nearly CBR, as found with voice activity
detection), and several instances in which analysis can be
simplified. The sampling method avoids predictability by mandating
random start times and finite length tests. Following descriptions
of the sampling method and sample metric parameters, measurement
methods and errors are discussed. Finally, we give additional
information on periodic measurements, including security
considerations.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC3763
04/2004
(11 p.)
pdf(2p)
|
S. Shalunov
B. Teitelbaum |
|
One-way Active Measurement Protocol (OWAMP) Requirements |
|
With growing availability of good time sources to network nodes, it
becomes increasingly possible to measure one-way IP performance
metrics with high precision. To do so in an interoperable manner, a
common protocol for such measurements is required. This document
specifies requirements for a one-way active measurement protocol
(OWAMP) standard. The protocol can measure one-way delay, as well as
other unidirectional characteristics, such as one-way loss.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4148
08/2005
(14 p.)
pdf(2p)
|
E. Stephan |
|
IP Performance Metrics (IPPM) Metrics Registry |
This memo defines a registry for IP Performance Metrics (IPPM). It
assigns and registers an initial set of OBJECT IDENTITIES to
currently defined metrics in the IETF.
This memo also defines the rules for adding IP Performance Metrics
that are defined in the future and for encouraging all IP performance
metrics to be registered here.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4656
09/2006
(56 p.)
pdf(2p)
|
S. Shalunov
B. Teitelbaum
A. Karp
J. Boote
M. Zekauskas |
|
A One-way Active Measurement Protocol (OWAMP) |
|
The One-Way Active Measurement Protocol (OWAMP) measures
unidirectional characteristics such as one-way delay and one-way
loss. High-precision measurement of these one-way IP performance
metrics became possible with wider availability of good time sources
(such as GPS and CDMA). OWAMP enables the interoperability of these
measurements.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4737
11/2006
(45 p.)
pdf(2p)
|
A. Morton
L. Ciavattone
G. Ramachandran
S. Shalunov
J. Perser |
|
Packet Reordering Metrics |
|
This memo defines metrics to evaluate whether a network has
maintained packet order on a packet-by-packet basis. It provides
motivations for the new metrics and discusses the measurement issues,
including the context information required for all metrics. The memo
first defines a reordered singleton, and then uses it as the basis
for sample metrics to quantify the extent of reordering in several
useful dimensions for network characterization or receiver design.
Additional metrics quantify the frequency of reordering and the
distance between separate occurrences. We then define a metric
oriented toward assessment of reordering effects on TCP. Several
examples of evaluation using the various sample metrics are included.
An appendix gives extended definitions for evaluating order with
packet fragmentation.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5136
02/2008
(14 p.)
pdf(2p)
|
P. Chimento
J. Ishac |
|
Defining Network Capacity |
|
Measuring capacity is a task that sounds simple, but in reality can
be quite complex. In addition, the lack of a unified nomenclature on
this subject makes it increasingly difficult to properly build, test,
and use techniques and tools built around these constructs. This
document provides definitions for the terms 'Capacity' and 'Available
Capacity' related to IP traffic traveling between a source and
destination in an IP network. By doing so, we hope to provide a
common framework for the discussion and analysis of a diverse set of
current and future estimation techniques.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5357
10/2008
(26 p.)
pdf(2p)
|
K. Hedayat
R. Krzanowski
A. Morton
K. Yum
J. Babiarz |
|
A Two-Way Active Measurement Protocol (TWAMP) |
|
The One-way Active Measurement Protocol (OWAMP), specified in RFC
4656, provides a common protocol for measuring one-way metrics
between network devices. OWAMP can be used bi-directionally to
measure one-way metrics in both directions between two network
elements. However, it does not accommodate round-trip or two-way
measurements. This memo specifies a Two-Way Active Measurement
Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip
measurement capabilities. The TWAMP measurement architecture is
usually comprised of two hosts with specific roles, and this allows
for some protocol simplifications, making it an attractive
alternative in some circumstances.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5388
12/2008
(75 p.)
pdf(2p)
|
S. Niccolini
S. Tartarelli
J. Quittek
T. Dietz
M. Swany |
|
Information Model and XML Data Model for Traceroute Measurements |
|
This document describes a standard way to store the configuration and
the results of traceroute measurements. This document first
describes the terminology used in this document and the traceroute
tool itself; afterwards, the common information model is defined,
dividing the information elements into two semantically separated
groups (configuration elements and results elements). Moreover, an
additional element is defined to relate configuration elements and
results elements by means of a common unique identifier. On the
basis of the information model, a data model based on XML is defined
to store the results of traceroute measurements.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5481
03/2009
(39 p.)
pdf(2p)
|
A. Morton
B. Claise |
|
Packet Delay Variation Applicability Statement |
Packet delay variation metrics appear in many different standards
documents. The metric definition in RFC 3393 has considerable
flexibility, and it allows multiple formulations of delay variation
through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas,
it can make comparisons of independent implementations more
difficult. Two different formulations of delay variation have come
into wide use in the context of active measurements. This memo
examines a range of circumstances for active measurements of delay
variation and their uses, and recommends which of the two forms is
best matched to particular conditions and tasks.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5560
05/2009
(14 p.)
pdf(2p)
|
H. Uijterwaal |
|
A One-Way Packet Duplication Metric |
When a packet is sent from one host to the other, one normally
expects that exactly one copy of the packet that was sent arrives at
the destination. It is, however, possible that a packet is either
lost or that multiple copies arrive.
In earlier work, a metric for packet loss was defined. This metric
quantifies the case where a packet that is sent does not arrive at
its destination within a reasonable time. In this memo, a metric for
another case is defined: a packet is sent, but multiple copies
arrive. The document also discusses streams and methods to summarize
the results of streams.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5618
08/2009
(8 p.)
pdf(2p)
|
A. Morton
K. Hedayat |
|
Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) |
|
This memo describes a simple extension to TWAMP (the Two-Way Active
Measurement Protocol). The extension adds the option to use
different security modes in the TWAMP-Control and TWAMP-Test
protocols simultaneously. The memo also describes a new IANA
registry for additional features, called the TWAMP Modes registry.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5644
10/2009
(57 p.)
pdf(2p)
|
E. Stephan
L. Liang
A. Morton |
|
IP Performance Metrics (IPPM): Spatial and Multicast |
|
The IETF has standardized IP Performance Metrics (IPPM) for measuring
end-to-end performance between two points. This memo defines two new
categories of metrics that extend the coverage to multiple
measurement points. It defines spatial metrics for measuring the
performance of segments of a source to destination path, and metrics
for measuring the performance between a source and many destinations
in multiparty communications (e.g., a multicast tree).
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5835
04/2010
(18 p.)
pdf(2p)
|
A. Morton
S. V.d.Berghe |
|
Framework for Metric Composition |
|
This memo describes a detailed framework for composing and
aggregating metrics (both in time and in space) originally defined by
the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF.
This new framework memo describes the generic composition and
aggregation mechanisms. The memo provides a basis for additional
documents that implement the framework to define detailed
compositions and aggregations of metrics that are useful in
practice.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5938
08/2010
(17 p.)
pdf(2p)
|
A. Morton
M. Chiba |
|
Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) |
|
The IETF has completed its work on the core specification of TWAMP --
the Two-Way Active Measurement Protocol. This memo describes an
OPTIONAL feature for TWAMP, that gives the controlling host the
ability to start and stop one or more individual test sessions using
Session Identifiers. The base capability of the TWAMP protocol
requires all test sessions that were previously requested and
accepted to start and stop at the same time.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
