IP Performance Metrics (ippm) Internet Drafts
| IP Performance Metrics (IPPM) for 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). | ||||||||||||||||
| Spatial Composition of Metrics | |||||||||||||||||
|
This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. | ||||||||||||||||
| 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 which are useful in practice. | ||||||||||||||||
| Reporting IP Performance Metrics to Users | |||||||||||||||||
|
The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. | ||||||||||||||||
| 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 of all describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined dividing the information elements in 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. | ||||||||||||||||
| 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 has been 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. | ||||||||||||||||
| 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. | ||||||||||||||||
| More Features for TWAMP | |||||||||||||||||
|
The IETF has completed its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a simple extension to TWAMP, the option to use different security modes in the TWAMP- Control and TWAMP-Test protocols. | ||||||||||||||||
| TWAMP Reflect Octets Feature | |||||||||||||||||
|
The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, and/or ensures that the same test packet sizes are used in both directions. | ||||||||||||||||
| Individual Session Control Feature for TWAMP | |||||||||||||||||
|
The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using their Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
IP Performance Metrics (ippm)
Last Modified: 2008-08-21
Additional information is available at tools.ietf.org/wg/ippm
Chair(s):
Transport Area Director(s):
Transport Area Advisor:
Technical Advisor(s):
Mailing Lists:
General Discussion: ippm@ietf.orgTo Subscribe: https://www1.ietf.org/mailman/listinfo/ippm
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/ippm/index.html
Description of Working Group:
Note: Andy Bierman serves as MIB advisor.The IPPM WG will develop a set of standard metrics that can be applied
to the quality, performance, and reliability of Internet data delivery
services. These metrics will be designed such that they can be
performed by network operators, end users, or independent testing
groups. It is important that the metrics not represent a value
judgment (i.e. define "good" and "bad"), but rather provide unbiased
quantitative measures of performance.
Functions peripheral to Internet data delivery services, such as
NOC/NIC services, are beyond the scope of this working group.
The IPPM WG will produce documents that define specific metrics and
procedures for accurately measuring and documenting these metrics.
The metrics are:
- connectivity
- one-way delay and loss
- round-trip delay and loss
- delay variation
- loss patterns
- packet reordering
- bulk transport capacity
- link bandwidth capacity
This is the cumulative set, including the metricsalready completed
and published.
The working group will closely review and then be guided by an
IESG document on how metrics advance along the standards track within
the IETF. This document will also be relevant to the work of the
benchmarking working group (BMWG). The first draft of this document
was discussed at IETF 51. Additionally, the WG will produce Proposed
Standard AS documents, comparable to applicability statements in RFC
2026, that will focus on procedures for measuring the individual
metrics and how these metrics characterize features that are important
to different service classes, such as bulk transport, periodic
streams,
or multimedia streams. It is specifically out of scope for this
working
group to actually characterize traffic, for example to characterize a
voice-over-IP stream. Each AS document will discuss the performance
characteristics that are pertinent to a specified service class;
clearly identify the set of metrics that aid in the description of
those characteristics; specify the methodologies required to collect
said metrics; and lastly, present the requirements for the common,
unambiguous reporting of testing results. Specific topics of these
AS documents must be approved by the Area Directors as charter
additions.
The WG will produce a protocol to enable communication among test
equipment that implements the one-way metrics. The intent is to create
a protocol that provides a base level of functionality that will allow
different manufacturer's equipment that implements the metrics
according to a standard to interoperate. A protocol requirements
document will guide the protocol design.
The WG will also produce a MIB to retrieve the results of IPPM
metrics, such as one-way delay and loss, to facilitate the
communication of metrics to existing network management systems. Thus,
the group will create a MIB that contains predominantly read only
variables. If, after the protocol requirements document is finished,
the group decides that it is appropriate to add variables that control
the underlying measurements that the metrics report, such a control
structure may be added as a separate document, subject to review by
the IESG.
The intent of the WG is to cooperate with other appropriate standards
bodies and forums (such as T1A1.3, ITU-T SG 12 and SG 13) to promote
consistent approaches and metrics. Within the IETF process, IPPM
metrics definitions will be subject to as rigorous a scrutiny for
usefulness, clarity, and accuracy as other protocol standards. The
IPPM WG will interact with other areas of IETF activity whose scope
intersect with the requirement of these specific metrics. These
include working groups such as BMWG, RMONMIB, and TEWG.
Goals and Milestones:
| Done | Submit drafts of standard metrics for connectivity and treno-bulk-throughput. | |
| Done | Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for publication as an Informational RFC. | |
| Done | Submit documents on delay and loss to IESG for publication as Informational RFCs. | |
| Done | Submit a document on connectivity to IESG for publication as an Informational RFC. | |
| Done | Submit a document on bulk-throughput to IESG for publication as an Informational RFC. | |
| Done | Submit draft on loss pattern sample metrics to the IESG for publication as an Informational RFC. | |
| Done | Submit draft on metrics for periodic streams to the IESG for publication as a Proposed Standard RFC. | |
| Done | Submit draft on IP delay variation to the IESG for publication as a Proposed Standard RFC. | |
| Done | First draft for AS on one-way delay and loss. | |
| Done | Submit draft on One-Way Active Measurement Protocol Requirements to the IESG for consideration as an Informational RFC. | |
| Done | Create initial draft on a MIB for reporting IPPM metrics. | |
| Done | Create initial draft on a packet reordering metric. | |
| Done | Create draft on a One-Way Active Measurement Protocol that satisfies the requirements document. | |
| Done | Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS. | |
| Done | Submit draft on implementation reports for RFCs 2678-2681 to the IESG | |
| Done | Submit initial draft on framework for Composition and Aggregation Metrics | |
| Done | Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS | |
| Done | Submit draft on a packet reordering metric to the IESG for Proposed Standard | |
| Done | Submit initial applicability statement for the IPPM and ITU Jitter Measurements to the WG | |
| Done | Submit link bandwidth capacity definitions draft to the IESG, for consideration as an Informational RFC | |
| Done | Submit draft on storing results of traceroute measurements to the IESG | |
| May 2008 | Submit draft on Two-way active measurements protocol (TWAMP) to the IESG for consideration as proposed standard | |
| May 2008 | Develop new charter text | |
| Jul 2008 | Delay Variation Applicability Statement (Informational) to IESG Review | |
| Nov 2008 | Submit draft on spatial composition of metrics to the IESG | |
| Nov 2008 | Submit draft on Temporal Aggregation of Metrics to the IESG | |
| Nov 2008 | Submit draft on spatial decomposition and multicast metrics to the IESG |
Internet-Drafts:
IP Performance Metrics (IPPM) for spatial and multicast (114131 bytes)Spatial Composition of Metrics (52713 bytes)
Framework for Metric Composition (37438 bytes)
Reporting IP Performance Metrics to Users (61166 bytes)
Information Model and XML Data Model for Traceroute Measurements (163796 bytes)
A One-Way Packet Duplication Metric (27007 bytes)
Packet Delay Variation Applicability Statement (92510 bytes)
More Features for TWAMP (17188 bytes)
TWAMP Reflect Octets Feature (38384 bytes)
Individual Session Control Feature for TWAMP (26685 bytes)
Request For Comments:
Framework for IP Performance Metrics (RFC 2330) (94387 bytes)IPPM Metrics for Measuring Connectivity (RFC 2678) (18087 bytes)
A One-way Delay Metric for IPPM (RFC 2679) (43542 bytes)
A One-way Packet Loss Metric for IPPM (RFC 2680) (32266 bytes)
A Round-trip Delay Metric for IPPM (RFC 2681) (44357 bytes)
A Framework for Defining Empirical Bulk Transfer Capacity Metrics (RFC 3148) (36041 bytes)
One-way Loss Pattern Sample Metrics (RFC 3357) (30570 bytes)
IP Packet Delay Variation Metric for IPPM (RFC 3393) (47731 bytes)
Network performance measurement for periodic streams (RFC 3432) (52493 bytes)
A One-way Active Measurement Protocol Requirements (RFC 3763) (23360 bytes)
IP Performance Metrics (IPPM) metrics registry (RFC 4148) (23074 bytes)
A One-way Active Measurement Protocol (OWAMP) (RFC 4656) (132303 bytes)
Packet Reordering Metrics (RFC 4737) (94699 bytes)
Defining Network Capacity (RFC 5136) (30682 bytes)
A Two-Way Active Measurement Protocol (TWAMP) (RFC 5357) (61960 bytes)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
