IP Performance Measurement (ippm) Internet Drafts


      
 A Connectivity Monitoring Metric for IPPM
 
 draft-ietf-ippm-connectivity-monitoring-09.txt
 Date: 27/08/2024
 Authors: Ruediger Geib
 Working Group: IP Performance Measurement (ippm)
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric.
 Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields
 
 draft-ietf-ippm-ioam-data-integrity-12.txt
 Date: 28/08/2024
 Authors: Frank Brockners, Shwetha Bhandari, Tal Mizrahi, Justin Iurman
 Working Group: IP Performance Measurement (ippm)
In Situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features that can provide secure operation. This document describes the integrity protection of IOAM-Data-Fields.
 Test Protocol for One-way IP Capacity Measurement
 
 draft-ietf-ippm-capacity-protocol-10.txt
 Date: 30/09/2024
 Authors: Len Ciavattone, Ruediger Geib
 Working Group: IP Performance Measurement (ippm)
This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC 9097, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This memo defines a simple protocol to perform the RFC 9097 (and other) measurements.
 Responsiveness under Working Conditions
 
 draft-ietf-ippm-responsiveness-05.txt
 Date: 21/10/2024
 Authors: Christoph Paasch, Randall Meyer, Stuart Cheshire, Will Hawkins
 Working Group: IP Performance Measurement (ippm)
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of latency, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality.
 IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option
 
 draft-ietf-ippm-encrypted-pdmv2-09.txt
 Date: 05/10/2024
 Authors: Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid
 Working Group: IP Performance Measurement (ippm)
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined.
 Hybrid Two-Step Performance Measurement Method
 
 draft-ietf-ippm-hybrid-two-step-03.txt
 Date: 19/10/2024
 Authors: Greg Mirsky, Wang Lingqiang, Guo Zhui, Haoyu Song, Pascal Thubert
 Working Group: IP Performance Measurement (ippm)
The development and advancements in network operation automation have brought new measurement methodology requirements. mong them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. That task can be solved using on-path telemetry, also called hybrid measurement. An on-path telemetry method allows the collection of essential information that reflects the operational state and network performance experienced by the packet. This document introduces a method complementary to on-path telemetry that causes the generation of telemetry information. This method, referred to as Hybrid Two-Step (HTS), separates the act of measuring and/or calculating the performance metric from collecting and transporting network state. The HTS packet traverses the same set of nodes and links as the trigger packet, thus simplifying the correlation of informational elements originating on nodes traversed by the trigger packet.
 Alternate Marking Deployment Framework
 
 draft-ietf-ippm-alt-mark-deployment-02.txt
 Date: 09/10/2024
 Authors: Giuseppe Fioccola, Keyi Zhu, Thomas Graf, Massimo Nilo, Lin Zhang
 Working Group: IP Performance Measurement (ippm)
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology.
 Quality of Outcome
 
 draft-ietf-ippm-qoo-01.txt
 Date: 20/09/2024
 Authors: Bjorn Teigen, Magnus Olden
 Working Group: IP Performance Measurement (ippm)
This document describes a new network quality framework named Quality of Outcome (QoO). The QoO framework is unique among network quality frameworks because it is designed to meet the needs of application developers, users and operators. This is achieved by basing the framework on Quality Attenuation, defining a simple format for specifying application requirements, and defining a way to compute a simple and intuitive user-facing metric. The framework proposes a way of sampling network quality, setting network quality requirements and a formula for calculating the probability for the sampled network to satisfy network requirements.
 Performance Measurement with Asymmetrical Packets in STAMP
 
 draft-ietf-ippm-asymmetrical-pkts-02.txt
 Date: 15/10/2024
 Authors: Greg Mirsky, Ernesto Ruffini, Henrik Nydell, Richard Foote
 Working Group: IP Performance Measurement (ippm)
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network.
 Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Headers
 
 draft-ietf-ippm-stamp-ext-hdr-01.txt
 Date: 14/10/2024
 Authors: Rakesh Gandhi, Tianran Zhou, Zhenqiang Li
 Working Group: IP Performance Measurement (ippm)
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers, IPv6 extension headers, and MPLS Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields.


data-group-menu-data-url="/group/groupmenu.json">

Skip to main content

IP Performance Measurement (ippm)

WG Name IP Performance Measurement
Acronym ippm
Area Operations and Management Area (ops)
State Active
Charter charter-ietf-ippm-06 Approved
Status update Show Changed 2018-02-05
Document dependencies
Additional resources GitHub
Wiki, Zulip stream
Personnel Chairs Marcus Ihlar, Tommy Pauly
Area Director Warren "Ace" Kumari
Mailing list Address ippm@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/ippm
Archive https://mailarchive.ietf.org/arch/browse/ippm/
Chat Room address https://zulip.ietf.org/#narrow/stream/ippm

Charter for Working Group

The IP Performance Measurement (IPPM) Working Group develops and maintains
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running over
transport layer protocols (e.g. TCP, UDP) over IP. It also develops and
maintains methodologies and protocols for the measurement of these metrics.
These metrics, protocols, and methodologies are designed such that they can be
used by network operators, end users, or independent testing groups. Metrics
developed by the IPPM WG are intended to provide unbiased quantitative
performance measurements.

The IPPM WG works to foster commonality and comparability of metrics and
measurements across IETF protocols at different layers. Its work is limited to
metrics and methodologies which are applicable over transport-layer protocols
over IP, and does not specify encapsulations required for measurements over
non-IP layers.

The IPPM WG has produced documents that define specific metrics and procedures
for accurately measuring and documenting these metrics. The working group will
continue advancing the most useful of these metrics along the standards track,
using the guidelines stated in RFC 6576. To the extent possible, these metrics
will be used as the basis for future work on metrics in the WG.

The WG will seek to develop new metrics and models to accurately characterize
the network paths under test and/or the performance of transport and application
layer protocols on these paths. The WG will balance the need for new metrics
with the desire to minimize the introduction of new metrics, and will require
that new metric definitions state how the definition improves on an existing
metric definition, or assesses a property of network performance not previously
covered by a defined metric. Metric definitions will follow the template given
in RFC 6390.

Additional methods will be defined for the composition and calibration of
IPPM-defined metrics, as well as active, passive and hybrid measurement methods
for these metrics. In addition, the WG encourages work which describes the
applicability of metrics and measurement methods, especially to improve
understanding of the tradeoffs involved among active, passive, and hybrid
methods.

The WG may update its core framework RFC 2330 as necessary to accommodate these activities.

The WG has produced protocols for communication among test equipment to enable
the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively).
These protocols will be advanced along the standards track. The work of the WG
will take into account the suitability of measurements for automation, in order
to support large-scale measurement efforts. This may result in further
developments in protocols such as OWAMP and TWAMP.

Agreement about the definitions of metrics and methods of measurement enables
accurate, reproducible, and equivalent results across different implementations.
To this end, the WG defines and maintains a registry of metric definitions.

The WG encourages work which assesses the comparability of measurements of IPPM
metrics with metrics developed elsewhere. The WG also encourages work which
improves the availability of information about the context in which measurements
were taken, for example (but not limited to) measurement implementation
information, estimates of confidence in these measurements, conditions on the
network(s) on which measurements are taken, and/or information about the
data-plane topology of these network(s).

In the interest of measurement comparability, the WG may define data formats and
information models for the storage and exchange of the results of measurements
defined within IPPM.

The IPPM WG seeks cooperation with other appropriate standards bodies and forums
to promote consistent approaches and metrics. Within the IETF process, IPPM
metric definitions and measurement protocols 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 intersects
with the requirement of these specific metrics. The WG will, on request, provide
input to other IETF working groups on the use and implementation of these
metrics.

Done milestones

Date Milestone Associated documents
Done Submit a Standards Track document on Metrics and Methods for IP Capacity Measurement
Done Submit a Standards Track document on Direct Export for IOAM
Done Submit a Standards Track draft defining a metric for unidirectional route assessment to the IESG
Done submit a Standards Track draft on inband OAM based measurement methodologies to the IESG
Done Submit draft on core registry for performance metrics to IESG as Proposed Standard
Done Submit a Standards Track drafts defining a simple two-way active measurement protocol based on TWAMP-Test, and a YANG data model to control it, to the IESG
Done submit a Standards Track document to the IESG updating RFC2330 to cover IPv6 rfc8468 (was draft-ietf-ippm-2330-ipv6)
Done submit a Standards Track document to the IESG defining initial contents of performance metric registry
Done Submit a Standards Track draft defining well-known ports for OWAMP and TWAMP to the IESG
Done Submit an Experimental draft on coloring-based hybrid measurement methodologies for loss and delay to the IESG
Done submit a Standards Track document to the IESG for a YANG model for managing TWAMP clients and servers rfc8913 (was draft-ietf-ippm-twamp-yang)