"IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, Lei Liang, Al Morton, 15-Oct-08. ( bytes)

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", Al Morton, Emile Stephan, 13-Jul-08. ( bytes)

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", Al Morton, 29-Oct-08. ( bytes)

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", Stanislav Shalunov, Martin Swany, 14-Jul-08. ( bytes)

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", Saverio Niccolini, Sandra Tartarelli, Juergen Quittek, Thomas Dietz, Martin Swany, 23-Oct-08. ( bytes)

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", Henk Uijterwaal, 7-Oct-08. ( bytes)

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", Al Morton, Benoit Claise, 13-Jul-08. ( bytes)

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", Al Morton, Kaynam Hedayat, 20-Oct-08. ( bytes)

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", Al Morton, Len Ciavattone, 26-Oct-08. ( bytes)

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", Al Morton, Murtaza Chiba, 27-Oct-08. ( bytes)

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.

Return to Internet-Draft directory.

Return to IETF home page.