rfc8912.original   rfc8912.txt 
Network Working Group A. Morton Internet Engineering Task Force (IETF) A. Morton
Internet-Draft AT&T Labs Request for Comments: 8912 AT&T Labs
Intended status: Standards Track M. Bagnulo Category: Standards Track M. Bagnulo
Expires: September 10, 2020 UC3M ISSN: 2070-1721 UC3M
P. Eardley P. Eardley
BT BT
K. D'Souza K. D'Souza
AT&T Labs AT&T Labs
March 9, 2020 November 2021
Initial Performance Metrics Registry Entries Initial Performance Metrics Registry Entries
draft-ietf-ippm-initial-registry-16
Abstract Abstract
This memo defines the set of Initial Entries for the IANA Performance This memo defines the set of initial entries for the IANA Registry of
Metrics Registry. The set includes: UDP Round-trip Latency and Loss, Performance Metrics. The set includes UDP Round-Trip Latency and
Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP
One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,
Round-trip Latency and Loss, and TCP round-trip Latency and Loss. ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 10, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8912.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Requirements Language
3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 2. Scope
4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 3. Registry Categories and Columns
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. UDP Round-Trip Latency and Loss Registry Entries
4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 4.1. Summary
4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. ID (Identifier)
4.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Name
4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. URI
4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 4.1.4. Description
4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 4.1.5. Change Controller
4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 10 4.1.6. Version (of Registry Format)
4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 4.2. Metric Definition
4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 4.2.1. Reference Definition
4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 4.2.2. Fixed Parameters
4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 4.3. Method of Measurement
4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 4.3.1. Reference Methods
4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 4.3.2. Packet Stream Generation
4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 4.3.3. Traffic Filtering (Observation) Details
4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 4.3.4. Sampling Distribution
4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.5. Runtime Parameters and Data Format
4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.6. Roles
4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Output
4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 4.4.1. Type
4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Reference Definition
4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 4.4.3. Metric Units
4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 4.4.4. Calibration
4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Administrative Items
4.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 16 4.5.1. Status
4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 4.5.2. Requester
4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Revision
4.5.4. Revision Date
4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 4.6. Comments and Remarks
5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 5. Packet Delay Variation Registry Entry
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Summary
5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 5.1.1. ID (Identifier)
5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Name
5.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.3. URI
5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Description
5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 5.1.5. Change Controller
5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 5.1.6. Version (of Registry Format)
5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 5.2. Metric Definition
5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 5.2.1. Reference Definition
5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 5.2.2. Fixed Parameters
5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19 5.3. Method of Measurement
5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 5.3.1. Reference Methods
5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 5.3.2. Packet Stream Generation
5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 5.3.3. Traffic Filtering (Observation) Details
5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 5.3.4. Sampling Distribution
5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 5.3.5. Runtime Parameters and Data Format
5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.6. Roles
5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Output
5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4.1. Type
5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21 5.4.2. Reference Definition
5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22 5.4.3. Metric Units
5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 5.4.4. Calibration
5.5. Administrative items . . . . . . . . . . . . . . . . . . 23 5.5. Administrative Items
5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 5.5.1. Status
5.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 23 5.5.2. Requester
5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 5.5.3. Revision
5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 5.5.4. Revision Date
5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 5.6. Comments and Remarks
6. DNS Response Latency and Loss Registry Entries . . . . . . . 23 6. DNS Response Latency and Loss Registry Entries
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Summary
6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24 6.1.1. ID (Identifier)
6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. Name
6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.3. URI
6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 6.1.4. Description
6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24 6.1.5. Change Controller
6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24 6.1.6. Version (of Registry Format)
6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 6.2. Metric Definition
6.2.1. Reference Definition . . . . . . . . . . . . . . . . 24 6.2.1. Reference Definition
6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 6.2.2. Fixed Parameters
6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 6.3. Method of Measurement
6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 6.3.1. Reference Methods
6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28 6.3.2. Packet Stream Generation
6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 6.3.3. Traffic Filtering (Observation) Details
6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 6.3.4. Sampling Distribution
6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 6.3.5. Runtime Parameters and Data Format
6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3.6. Roles
6.4. Output
6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.1. Type
6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.2. Reference Definition
6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31 6.4.3. Metric Units
6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 6.4.4. Calibration
6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31 6.5. Administrative Items
6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 6.5.1. Status
6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 6.5.2. Requester
6.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 32 6.5.3. Revision
6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 6.5.4. Revision Date
6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 6.6. Comments and Remarks
6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 7. UDP Poisson One-Way Delay and Loss Registry Entries
7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32 7.1. Summary
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1.1. ID (Identifier)
7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33 7.1.2. Name
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.3. URI
7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.4. Description
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 7.1.5. Change Controller
7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34 7.1.6. Version (of Registry Format)
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34 7.2. Metric Definition
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 7.2.1. Reference Definition
7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36 7.2.2. Fixed Parameters
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 7.3. Method of Measurement
7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36 7.3.1. Reference Methods
7.3.3. Traffic Filtering (observation) Details . . . . . . . 37 7.3.2. Packet Stream Generation
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37 7.3.3. Traffic Filtering (Observation) Details
7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 7.3.4. Sampling Distribution
7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3.5. Runtime Parameters and Data Format
7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3.6. Roles
7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38 7.4. Output
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38 7.4.1. Type
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41 7.4.2. Reference Definition
7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41 7.4.3. Metric Units
7.5. Administrative items . . . . . . . . . . . . . . . . . . 42 7.4.4. Calibration
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42 7.5. Administrative Items
7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 42 7.5.1. Status
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 7.5.2. Requester
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43 7.5.3. Revision
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43 7.5.4. Revision Date
8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 43 7.6. Comments and Remarks
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. UDP Periodic One-Way Delay and Loss Registry Entries
8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 8.1. Summary
8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1.1. ID (Identifier)
8.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.1.2. Name
8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 44 8.1.3. URI
8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44 8.1.4. Description
8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44 8.1.5. Change Controller
8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45 8.1.6. Version (of Registry Format)
8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46 8.2. Metric Definition
8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46 8.2.1. Reference Definition
8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47 8.2.2. Fixed Parameters
8.3.3. Traffic Filtering (observation) Details . . . . . . . 48 8.3. Method of Measurement
8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48 8.3.1. Reference Methods
8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 8.3.2. Packet Stream Generation
8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 8.3.3. Traffic Filtering (Observation) Details
8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.3.4. Sampling Distribution
8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49 8.3.5. Runtime Parameters and Data Format
8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 8.3.6. Roles
8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52 8.4. Output
8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 8.4.1. Type
8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 8.4.2. Reference Definition
8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 8.4.3. Metric Units
8.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 53 8.4.4. Calibration
8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 8.5. Administrative Items
8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 8.5.1. Status
8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 54 8.5.2. Requester
9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 54 8.5.3. Revision
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.5.4. Revision Date
9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54 8.6. Comments and Remarks
9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 9. ICMP Round-Trip Latency and Loss Registry Entries
9.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1. Summary
9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 55 9.1.1. ID (Identifier)
9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 55 9.1.2. Name
9.1.6. Version (of Registry Format) . . . . . . . . . . . . 55 9.1.3. URI
9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55 9.1.4. Description
9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 9.1.5. Change Controller
9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 56 9.1.6. Version (of Registry Format)
9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 57 9.2. Metric Definition
9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 57 9.2.1. Reference Definition
9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 58 9.2.2. Fixed Parameters
9.3.3. Traffic Filtering (observation) Details . . . . . . . 59 9.3. Method of Measurement
9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 59 9.3.1. Reference Methods
9.3.5. Run-time Parameters and Data Format . . . . . . . . . 59 9.3.2. Packet Stream Generation
9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 9.3.3. Traffic Filtering (Observation) Details
9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.3.4. Sampling Distribution
9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 60 9.3.5. Runtime Parameters and Data Format
9.4.2. Reference Definition . . . . . . . . . . . . . . . . 60 9.3.6. Roles
9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 62 9.4. Output
9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 62 9.4.1. Type
9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 9.4.2. Reference Definition
9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 9.4.3. Metric Units
9.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 63 9.4.4. Calibration
9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 63 9.5. Administrative Items
9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 63 9.5.1. Status
9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 63 9.5.2. Requester
10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 63 9.5.3. Revision
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63 9.5.4. Revision Date
10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 9.6. Comments and Remarks
10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 10. TCP Round-Trip Delay and Loss Registry Entries
10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 64 10.1. Summary
10.1.4. Description . . . . . . . . . . . . . . . . . . . . 64 10.1.1. ID (Identifier)
10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 10.1.2. Name
10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 10.1.3. URI
10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 65 10.1.4. Description
10.2.1. Reference Definitions . . . . . . . . . . . . . . . 65 10.1.5. Change Controller
10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 67 10.1.6. Version (of Registry Format)
10.3. Method of Measurement . . . . . . . . . . . . . . . . . 68 10.2. Metric Definition
10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 68 10.2.1. Reference Definition
10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 70 10.2.2. Fixed Parameters
10.3.3. Traffic Filtering (observation) Details . . . . . . 70 10.3. Method of Measurement
10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 70 10.3.1. Reference Methods
10.3.5. Run-time Parameters and Data Format . . . . . . . . 70 10.3.2. Packet Stream Generation
10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 71 10.3.3. Traffic Filtering (Observation) Details
10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 71 10.3.4. Sampling Distribution
10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 71 10.3.5. Runtime Parameters and Data Format
10.4.2. Reference Definition . . . . . . . . . . . . . . . . 71 10.3.6. Roles
10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 73 10.4. Output
10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 73 10.4.1. Type
10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 10.4.2. Reference Definition
10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 10.4.3. Metric Units
10.5.2. Requester . . . . . . . . . . . . . . . . . . . . . 73 10.4.4. Calibration
10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 74 10.5. Administrative Items
10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 74 10.5.1. Status
10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 74 10.5.2. Requester
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74 10.5.3. Revision
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 10.5.4. Revision Date
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 10.6. Comments and Remarks
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 11. Security Considerations
14.1. Normative References . . . . . . . . . . . . . . . . . . 75 12. IANA Considerations
14.2. Informative References . . . . . . . . . . . . . . . . . 77 13. References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
This memo proposes an initial set of entries for the Performance This memo defines an initial set of entries for the Performance
Metrics Registry. It uses terms and definitions from the IPPM Metrics Registry. It uses terms and definitions from the IP
literature, primarily [RFC2330]. Performance Metrics (IPPM) literature, primarily [RFC2330].
Although there are several standard templates for organizing Although there are several standard templates for organizing
specifications of performance metrics (see [RFC7679] for an example specifications of Performance Metrics (see [RFC7679] for an example
of the traditional IPPM template, based to large extent on the of the traditional IPPM template, based to a large extent on the
Benchmarking Methodology Working Group's traditional template in Benchmarking Methodology Working Group's traditional template in
[RFC1242], and see [RFC6390] for a similar template), none of these [RFC1242], and see [RFC6390] for a similar template), none of these
templates were intended to become the basis for the columns of an templates were intended to become the basis for the columns of an
IETF-wide registry of metrics. While examining aspects of metric IETF-wide Registry of metrics. While examining aspects of metric
specifications which need to be registered, it became clear that none specifications that need to be registered, it became clear that none
of the existing metric templates fully satisfies the particular needs of the existing metric templates fully satisfy the particular needs
of a registry. of a Registry.
Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format Therefore, [RFC8911] defines the overall format for a Performance
for a Performance Metrics Registry. Section 5 of Metrics Registry. Section 5 of [RFC8911] also gives guidelines for
[I-D.ietf-ippm-metric-registry] also gives guidelines for those those requesting registration of a Metric -- that is, the creation of
requesting registration of a Metric, that is the creation of entry(s) one or more entries in the Performance Metrics Registry:
in the Performance Metrics Registry: "In essence, there needs to be
evidence that a candidate Registered Performance Metric has | In essence, there needs to be evidence that (1) a candidate
significant industry interest, or has seen deployment, and there is | Registered Performance Metric has significant industry interest or
agreement that the candidate Registered Performance Metric serves its | has seen deployment and (2) there is agreement that the candidate
intended purpose." The process in [I-D.ietf-ippm-metric-registry] | Registered Performance Metric serves its intended purpose.
also requires that new entries are administered by IANA through
Specification Required policy, which will ensure that the metrics are The process defined in [RFC8911] also requires that new entries be
tightly defined. administered by IANA through the Specification Required policy
[RFC8126], which will ensure that the metrics are tightly defined.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Scope 2. Scope
This document defines a set of initial Performance Metrics Registry This document defines a set of initial Performance Metrics Registry
entries. Most are Active Performance Metrics, which are based on Entries. Most are Active Performance Metrics, which are based on
RFCs prepared in the IPPM working group of the IETF, according to RFCs prepared in the IPPM Working Group of the IETF, according to
their framework [RFC2330] and its updates. their framework [RFC2330] and its updates.
3. Registry Categories and Columns 3. Registry Categories and Columns
This memo uses the terminology defined in This memo uses the terminology defined in [RFC8911].
[I-D.ietf-ippm-metric-registry].
This section provides the categories and columns of the registry, for This section provides the categories and columns of the Registry, for
easy reference. An entry (row) therefore gives a complete easy reference. An entry (row) therefore gives a complete
description of a Registered Metric. description of a Registered Metric.
Legend: Registry Categories and Columns are shown below in this format:
Registry Categories and Columns, shown as
Category
------------------
Column | Column |
Summary Category
Identifier | Name | URI | Desc. | Reference | Change Controller | Ver | ------------------...
Column | Column |...
Metric Definition Summary
Reference Definition | Fixed Parameters | ---------------------------------------------------------------
Identifier | Name | URI | Desc. | Reference | Change | Ver |
| | | | | Controller |
Method of Measurement Metric Definition
Reference | Packet | Traffic | Sampling | Run-time | Role | -----------------------------------------
Method | Stream | Filter | Distribution | Parameters | | Reference Definition | Fixed Parameters |
| Generation |
Output
Type | Reference | Units | Calibration |
| Definition | | |
Administrative Information Method of Measurement
Status |Requester | Rev | Rev.Date | ---------------------------------------------------------------------
Reference | Packet | Traffic | Sampling | Runtime | Role |
Method | Stream | Filter | Distribution | Parameters | |
| Generation |
Output
-----------------------------------------
Type | Reference | Units | Calibration |
| Definition | | |
Comments and Remarks Administrative Information
-------------------------------------
Status |Requester | Rev | Rev. Date |
4. UDP Round-trip Latency and Loss Registry Entries Comments and Remarks
--------------------
This section specifies an initial registry entry for the UDP Round- 4. UDP Round-Trip Latency and Loss Registry Entries
trip Latency, and another entry for UDP Round-trip Loss Ratio.
Note: Each Registry entry only produces a "raw" output or a This section specifies an initial Registry Entry for UDP Round-Trip
statistical summary. To describe both "raw" and one or more Latency and another entry for the UDP Round-Trip Loss Ratio.
statistics efficiently, the Identifier, Name, and Output Categories
can be split and a single section can specify two or more closely-
related metrics. For example, this section specifies two Registry
entries with many common columns. See Section 7 for an example
specifying multiple Registry entries with many common columns.
All column entries beside the ID, Name, Description, and Output Note: Each Registry Entry only produces a "raw" output or a
Reference Method categories are the same, thus this section proposes statistical summary. To describe both "raw" and one or more
two closely-related registry entries. As a result, IANA is also statistics efficiently, the Identifier, Name, and Output
asked to assign a corresponding URL to each Named Metric. categories can be split, and a single section can specify two or
more closely related metrics. For example, this section specifies
two Registry Entries with many common columns. See Section 7 for
an example specifying multiple Registry Entries with many common
columns.
All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same; thus, this section defines
two closely related Registry Entries. As a result, IANA has also
assigned a corresponding URL to each of the two Named Metrics.
4.1. Summary 4.1. Summary
This category includes multiple indexes to the registry entry: the This category includes multiple indexes to the Registry Entries: the
element ID and metric name. element ID and Metric Name.
4.1.1. ID (Identifier) 4.1.1. ID (Identifier)
IANA is asked to assign different numeric identifiers to each of the IANA has allocated the numeric Identifiers 1 and 2 for the two Named
two Named Metrics. Metric Entries in Section 4. See Section 4.1.2 for mapping to Names.
4.1.2. Name 4.1.2. Name
RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile 1: RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile
RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio 2: RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio
4.1.3. URI 4.1.3. URI
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/RTDelay_Active_IP-UDP-
Periodic_RFC8912sec4_Seconds_95Percentile
URL: https://www.iana.org/performance-metrics/RTLoss_Active_IP-UDP-
Periodic_RFC8912sec4_Percent_LossRatio
4.1.4. Description 4.1.4. Description
RTDelay: This metric assesses the delay of a stream of packets RTDelay: This metric assesses the delay of a stream of packets
exchanged between two hosts (which are the two measurement points), exchanged between two hosts (which are the two measurement
and the Output is the Round-trip delay for all successfully exchanged points). The output is the round-trip delay for all successfully
packets expressed as the 95th percentile of their conditional delay exchanged packets expressed as the 95th percentile of their
distribution. conditional delay distribution.
RTLoss: This metric assesses the loss ratio of a stream of packets RTLoss: This metric assesses the loss ratio of a stream of packets
exchanged between two hosts (which are the two measurement points), exchanged between two hosts (which are the two measurement
and the Output is the Round-trip loss ratio for all successfully points). The output is the round-trip loss ratio for all
exchanged packets expressed as a percentage. transmitted packets expressed as a percentage.
4.1.5. Change Controller 4.1.5. Change Controller
IETF IETF
4.1.6. Version (of Registry Format) 4.1.6. Version (of Registry Format)
1.0 1.0
4.2. Metric Definition 4.2. Metric Definition
This category includes columns to prompt the entry of all necessary This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters. and values of input factors, called "Fixed Parameters".
4.2.1. Reference Definition 4.2.1. Reference Definition
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay For delay:
Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
<https://www.rfc-editor.org/info/rfc2681>. [RFC2681]
Section 2.4 of [RFC2681] provides the reference definition of the Section 2.4 of [RFC2681] provides the reference definition of the
singleton (single value) Round-trip delay metric. Section 3.4 of singleton (single value) round-trip delay metric. Section 3.4 of
[RFC2681] provides the reference definition expanded to cover a [RFC2681] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as singleton and sample multi-singleton sample. Note that terms such as "singleton" and
are defined in Section 11 of [RFC2330]. "sample" are defined in Section 11 of [RFC2330].
Note that although the [RFC2681] definition of "Round-trip-Delay Note that although the definition of round-trip delay between the
between Src and Dst" is directionally ambiguous in the text, this Source (Src) and the Destination (Dst) as provided in Section 2.4
metric tightens the definition further to recognize that the host in of [RFC2681] is directionally ambiguous in the text, this metric
the "Src" role will send the first packet to "Dst", and ultimately tightens the definition further to recognize that the host in the
receive the corresponding return packet from "Dst" (when neither are Src Role will send the first packet to the host in the Dst Role
lost). and will ultimately receive the corresponding return packet from
the Dst (when neither is lost).
Finally, note that the variable "dT" is used in [RFC2681] to refer to Finally, note that the variable "dT" is used in [RFC2681] to refer
the value of Round-trip delay in metric definitions and methods. The to the value of round-trip delay in metric definitions and
variable "dT" has been re-used in other IPPM literature to refer to methods. The variable "dT" has been reused in other IPPM
different quantities, and cannot be used as a global variable name. literature to refer to different quantities and cannot be used as
a global variable name.
Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. For loss:
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
rfc6673>. [RFC6673]
Both delay and loss metrics employ a maximum waiting time for Both Delay and Loss metrics employ a maximum waiting time for
received packets, so the count of lost packets to total packets sent received packets, so the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per Section 6.1 of is the basis for the loss ratio calculation as per Section 6.1 of
[RFC6673]. [RFC6673].
4.2.2. Fixed Parameters 4.2.2. Fixed Parameters
Type-P as defined in Section 13 of [RFC2330]: Type-P as defined in Section 13 of [RFC2330]:
IPv4 header values:
DSCP: Set to 0
TTL: Set to 255
Protocol: Set to 17 (UDP)
o IPv4 header values: IPv6 header values:
DSCP: Set to 0
* DSCP: set to 0 Hop Count: Set to 255
* TTL: set to 255 Next Header: Set to 17 (UDP)
Flow Label: Set to 0
* Protocol: set to 17 (UDP) Extension Headers: None
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
o UDP header values:
* Checksum: the checksum MUST be calculated and the non-zero
checksum included in the header
o UDP Payload
* total of 100 bytes
Other measurement parameters: UDP header values:
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header
o Tmax: a loss threshold waiting time UDP Payload:
Total of 100 bytes
* 3.0, expressed in units of seconds, as a positive value of type Other measurement Parameters:
decimal64 with fraction digits = 4 (see section 9.3 of Tmax: A loss threshold waiting time with value 3.0, expressed in
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with units of seconds, as a positive value of type decimal64 with
lossless conversion to/from the 32-bit NTP timestamp as per fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
section 6 of [RFC5905]. resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
4.3. Method of Measurement 4.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
4.3.1. Reference Method 4.3.1. Reference Methods
The methodology for this metric is defined as Type-P-Round-trip- The methodology for this metric (equivalent to Type-P-Round-trip-
Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section Delay and Type-P-Round-trip-Delay-Poisson-Stream) is defined as in
3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under Section 2.6 of [RFC2681] (for singletons) and Section 3.6 of
Fixed Parameters. However, the Periodic stream will be generated [RFC2681] (for samples) using the Type-P and Tmax defined in the
according to [RFC3432]. Fixed Parameters column. However, the Periodic stream will be
generated according to [RFC3432].
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the RTLoss metric. delay and counted for the RTLoss metric [RFC6673].
The calculations on the delay (RTT) SHALL be performed on the The calculations on the delay (RTT) SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MUST enforce the Tmax threshold on that calculates the RTT value MUST enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See Section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and see Section 5 of [RFC6703] for background on this
choice. analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to disambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
If a standard measurement protocol is employed, then the measurement If a standard measurement protocol is employed, then the measurement
process will determine the sequence numbers or timestamps applied to process will determine the sequence numbers or timestamps applied to
test packets after the Fixed and Runtime parameters are passed to test packets after the Fixed and Runtime Parameters are passed to
that process. The chosen measurement protocol will dictate the that process. The chosen measurement protocol will dictate the
format of sequence numbers and time-stamps, if they are conveyed in format of sequence numbers and timestamps, if they are conveyed in
the packet payload. the packet payload.
Refer to Section 4.4 of [RFC6673] for expanded discussion of the Refer to Section 4.4 of [RFC6673] for an expanded discussion of the
instruction to "send a Type-P packet back to the Src as quickly as instruction to "send a Type-P packet back to the Src as quickly as
possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of possible" in Section 2.6 of [RFC2681]. Section 8 of [RFC6673]
[RFC6673] presents additional requirements which MUST be included in presents additional requirements that MUST be included in the Method
the method of measurement for this metric. of Measurement for this metric.
4.3.2. Packet Stream Generation 4.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section provides details regarding packet traffic, which is used
basis for measurement. In IPPM metrics, this is called the Stream, as the basis for measurement. In IPPM Metrics, this is called the
and can easily be described by providing the list of stream "stream"; this stream can easily be described by providing the list
parameters. of stream Parameters.
Section 3 of [RFC3432] prescribes the method for generating Periodic Section 3 of [RFC3432] prescribes the method for generating Periodic
streams using associated parameters. streams using associated Parameters.
incT the nominal duration of inter-packet interval, first bit to incT: The nominal duration of the inter-packet interval, first bit
first bit, with value 0.0200, expressed in units of seconds, as a to first bit, with value 0.0200, expressed in units of seconds, as
positive value of type decimal64 with fraction digits = 4 (see a positive value of type decimal64 with fraction digits = 4 (see
section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds
(0.1 ms). (0.1 ms).
dT the duration of the interval for allowed sample start times, with dT: The duration of the interval for allowed sample start times,
value 1.0, expressed in units of seconds, as a positive value of with value 1.0, expressed in units of seconds, as a positive value
type decimal64 with fraction digits = 4 (see section 9.3 of of type decimal64 with fraction digits = 4 (see Section 9.3 of
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms).
NOTE: an initiation process with a number of control exchanges Note: An initiation process with a number of control exchanges
resulting in unpredictable start times (within a time interval) may resulting in unpredictable start times (within a time interval)
be sufficient to avoid synchronization of periodic streams, and may be sufficient to avoid synchronization of periodic streams and
therefore a valid replacement for selecting a start time at random is a valid replacement for selecting a start time at random from a
from a fixed interval. fixed interval.
The T0 parameter will be reported as a measured parameter. The T0 Parameter will be reported as a measured Parameter.
Parameters incT and dT are Fixed Parameters. Parameters incT and dT are Fixed Parameters.
4.3.3. Traffic Filtering (observation) Details 4.3.3. Traffic Filtering (Observation) Details
NA N/A
4.3.4. Sampling Distribution 4.3.4. Sampling Distribution
NA N/A
4.3.5. Run-time Parameters and Data Format 4.3.5. Runtime Parameters and Data Format
Run-time Parameters are input factors that must be determined, Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
for the context to be complete. for the context to be complete.
Src the IP address of the host in the Src Role (format ipv4-address- Src: The IP address of the host in the Src Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the Dst Role (format ipv4-address-
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see section 4 of [RFC6991])
T0 a time, the start of a measurement interval, (format "date-and- Dst: The IP address of the host in the Dst Role (format
time" as specified in Section 5.6 of [RFC3339], see also Section 3 ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of for IPv6; see Section 4 of [RFC6991]).
[RFC2330]. When T0 is "all-zeros", a start time is unspecified
and Tf is to be interpreted as the Duration of the measurement
interval. The start time is controlled through other means.
Tf a time, the end of a measurement interval, (format "date-and-time" T0: A time, the start of a measurement interval (format "date-time"
as specified in Section 5.6 of [RFC3339], see also Section 3 of as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
in Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
unspecified and Tf is to be interpreted as the duration of the
measurement interval. The start time is controlled through other
means.
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Tf: A time, the end of a measurement interval (format "date-time" as
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
Tf is interpreted as the Duration of the measurement interval. Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time
and date is ignored and Tf is interpreted as the duration of the
measurement interval.
4.3.6. Roles 4.3.6. Roles
Src launches each packet and waits for return transmissions from Src: Launches each packet and waits for return transmissions from
Dst. the Dst.
Dst waits for each packet from Src and sends a return packet to Src. Dst: Waits for each packet from the Src and sends a return packet to
the Src.
4.4. Output 4.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
4.4.1. Type 4.4.1. Type
Percentile -- for the conditional distribution of all packets with a Percentile: For the conditional distribution of all packets with a
valid value of Round-trip delay (undefined delays are excluded), a valid value of round-trip delay (undefined delays are excluded), this
single value corresponding to the 95th percentile, as follows: is a single value corresponding to the 95th percentile, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
The percentile = 95, meaning that the reported delay, "95Percentile", The percentile = 95, meaning that the reported delay, "95Percentile",
is the smallest value of Round-trip delay for which the Empirical is the smallest value of round-trip delay for which the Empirical
Distribution Function (EDF), F(95Percentile) >= 95% of the singleton Distribution Function, EDF(95Percentile), is greater than or equal to
Round-trip delay values in the conditional distribution. See section 95% of the singleton round-trip delay values in the conditional
11.3 of [RFC2330] for the definition of the percentile statistic distribution. See Section 11.3 of [RFC2330] for the definition of
using the EDF. the percentile statistic using the EDF.
LossRatio -- the count of lost packets to total packets sent is the For LossRatio, the count of lost packets to total packets sent is the
basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. basis for the loss ratio calculation as per Section 6.1 of [RFC6673].
4.4.2. Reference Definition 4.4.2. Reference Definition
For all outputs --- For all outputs:
T0 the start of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of
[RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of
[RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330].
TotalPkts the count of packets sent by the Src to Dst during the T0: The start of a measurement interval (format "date-time" as
measurement interval. specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330].
For Tf: The end of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330].
RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile: TotalPkts: The count of packets sent by the Src to the Dst during
the measurement interval.
95Percentile The time value of the result is expressed in units of 95Percentile: The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
0.000000001 seconds (1.0 ns). 0.000000001 seconds (1.0 ns).
For Percent_LossRatio: The numeric value of the result is expressed in
units of lost packets to total packets times 100%, as a positive
RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio: value of type decimal64 with fraction digits = 9 (see Section 9.3
of [RFC6020]) with a resolution of 0.0000000001.
Percentile The numeric value of the result is expressed in units of
lost packets to total packets times 100%, as a positive value of
type decimal64 with fraction digits = 9 (see section 9.3 of
[RFC6020]) with resolution of 0.0000000001.
4.4.3. Metric Units 4.4.3. Metric Units
The 95th Percentile of Round-trip Delay is expressed in seconds. The 95th percentile of round-trip delay is expressed in seconds.
The Round-trip Loss Ratio is expressed as a percentage of lost The round-trip loss ratio is expressed as a percentage of lost
packets to total packets sent. packets to total packets sent.
4.4.4. Calibration 4.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. Calibration in-
calibration could be enabled with an internal loopback at the Source situ could be enabled with an internal loopback at the Source host
host that includes as much of the measurement system as possible, that includes as much of the measurement system as possible, performs
performs address manipulation as needed, and provides some form of address manipulation as needed, and provides some form of isolation
isolation (e.g., deterministic delay) to avoid send-receive interface (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way. characterized in this way.
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement, with an additional indication that it is a
calibration result. calibration result.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the available accuracy of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the output result resolution that is the result of system
noise, and thus inaccurate. noise and is thus inaccurate.
4.5. Administrative items 4.5. Administrative Items
4.5.1. Status 4.5.1. Status
Current Current
4.5.2. Requester 4.5.2. Requester
This RFC number RFC 8912
4.5.3. Revision 4.5.3. Revision
1.0 1.0
4.5.4. Revision Date 4.5.4. Revision Date
YYYY-MM-DD 2021-11-17
4.6. Comments and Remarks 4.6. Comments and Remarks
None. None
5. Packet Delay Variation Registry Entry 5. Packet Delay Variation Registry Entry
This section gives an initial registry entry for a Packet Delay This section gives an initial Registry Entry for a Packet Delay
Variation metric. Variation (PDV) metric.
5.1. Summary 5.1. Summary
This category includes multiple indexes to the registry entries, the This category includes multiple indexes to the Registry Entry: the
element ID and metric name. element ID and Metric Name.
5.1.1. ID (Identifier) 5.1.1. ID (Identifier)
<insert numeric identifier, an integer> IANA has allocated the numeric Identifier 3 for the Named Metric
Entry in Section 5. See Section 5.1.2 for mapping to Name.
5.1.2. Name 5.1.2. Name
OWPDV_Active_IP-UDP-Periodic_RFCXXXXsec5_Seconds_95Percentile 3: OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile
5.1.3. URI 5.1.3. URI
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/OWPDV_Active_IP-UDP-
Periodic_RFC8912sec5_Seconds_95Percentile
5.1.4. Description 5.1.4. Description
An assessment of packet delay variation with respect to the minimum This metric assesses packet delay variation with respect to the
delay observed on the periodic stream, and the Output is expressed as minimum delay observed on the periodic stream. The output is
the 95th percentile of the packet delay variation distribution. expressed as the 95th percentile of the one-way packet delay
variation distribution.
5.1.5. Change Controller 5.1.5. Change Controller
IETF IETF
5.1.6. Version (of Registry Format) 5.1.6. Version (of Registry Format)
1.0 1.0
5.2. Metric Definition 5.2. Metric Definition
This category includes columns to prompt the entry of all necessary This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters. and values of input factors, called "Fixed Parameters".
5.2.1. Reference Definition 5.2.1. Reference Definition
Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP
Performance Metrics", RFC 2330, May 1998. [RFC2330] Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. [RFC2330]
Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric
for IP Performance Metrics (IPPM)", RFC 3393, November 2002. for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393,
[RFC3393] November 2002, <https://www.rfc-editor.org/info/rfc3393>. [RFC3393]
Morton, A. and B. Claise, "Packet Delay Variation Applicability Morton, A. and B. Claise, "Packet Delay Variation Applicability
Statement", RFC 5481, March 2009. [RFC5481] Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009,
<https://www.rfc-editor.org/info/rfc5481>. [RFC5481]
Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time
Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, Protocol Version 4: Protocol and Algorithms Specification", RFC 5905,
June 2010. [RFC5905] DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/
rfc5905>. [RFC5905]
See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences See Sections 2.4 and 3.4 of [RFC3393]. The measured singleton delay
measured are referred to by the variable name "ddT" (applicable to differences are referred to by the variable name "ddT" (applicable to
all forms of delay variation). However, this metric entry specifies all forms of delay variation). However, this Metric Entry specifies
the PDV form defined in section 4.2 of [RFC5481], where the singleton the PDV form defined in Section 4.2 of [RFC5481], where the singleton
PDV for packet i is referred to by the variable name "PDV(i)". PDV for packet i is referred to by the variable name "PDV(i)".
5.2.2. Fixed Parameters 5.2.2. Fixed Parameters
o IPv4 header values: IPv4 header values:
DSCP: Set to 0
* DSCP: set to 0 TTL: Set to 255
Protocol: Set to 17 (UDP)
* TTL: set to 255
* Protocol: set to 17 (UDP)
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
o UDP header values: IPv6 header values:
DSCP: Set to 0
Hop Count: Set to 255
Next Header: Set to 17 (UDP)
Flow Label: Set to 0
Extension Headers: None
* Checksum: the checksum MUST be calculated and the non-zero UDP header values:
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header checksum included in the header
o UDP Payload UDP Payload:
Total of 200 bytes
* total of 200 bytes
Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in Other measurement Parameters:
units of seconds, as a positive value of type decimal64 with Tmax: A loss threshold waiting time with value 3.0, expressed in
fraction digits = 4 (see section 9.3 of [RFC6020]) and with units of seconds, as a positive value of type decimal64 with
resolution of 0.0001 seconds (0.1 ms), with lossless conversion fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
F a selection function unambiguously defining the packets from the F: A selection function unambiguously defining the packets from
stream selected for the metric. See section 4.2 of [RFC5481] for the stream selected for the metric. See Section 4.2 of
the PDV form. [RFC5481] for the PDV form.
See the Packet Stream generation category for two additional Fixed See the Packet Stream Generation section for two additional Fixed
Parameters. Parameters.
5.3. Method of Measurement 5.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
5.3.1. Reference Method 5.3.1. Reference Methods
See section 2.6 and 3.6 of [RFC3393] for general singleton element See Sections 2.6 and 3.6 of [RFC3393] for general singleton element
calculations. This metric entry requires implementation of the PDV calculations. This Metric Entry requires implementation of the PDV
form defined in section 4.2 of [RFC5481]. Also see measurement form defined in Section 4.2 of [RFC5481]. Also see measurement
considerations in section 8 of [RFC5481]. considerations in Section 8 of [RFC5481].
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay. delay.
The calculations on the one-way delay SHALL be performed on the The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MUST enforce the Tmax that calculates the one-way delay value MUST enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See Section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and see Section 5 of [RFC6703] for
on this analysis choice. background on this analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to disambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
If a standard measurement protocol is employed, then the measurement If a standard measurement protocol is employed, then the measurement
process will determine the sequence numbers or timestamps applied to process will determine the sequence numbers or timestamps applied to
test packets after the Fixed and Runtime parameters are passed to test packets after the Fixed and Runtime Parameters are passed to
that process. The chosen measurement protocol will dictate the that process. The chosen measurement protocol will dictate the
format of sequence numbers and time-stamps, if they are conveyed in format of sequence numbers and timestamps, if they are conveyed in
the packet payload. the packet payload.
5.3.2. Packet Stream Generation 5.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section provides details regarding packet traffic, which is used
basis for measurement. In IPPM metrics, this is called the Stream, as the basis for measurement. In IPPM Metrics, this is called the
and can easily be described by providing the list of stream "stream"; this stream can easily be described by providing the list
parameters. of stream Parameters.
Section 3 of [RFC3432] prescribes the method for generating Periodic Section 3 of [RFC3432] prescribes the method for generating Periodic
streams using associated parameters. streams using associated Parameters.
incT the nominal duration of inter-packet interval, first bit to incT: The nominal duration of the inter-packet interval, first bit
first bit, with value 0.0200, expressed in units of seconds, as a to first bit, with value 0.0200, expressed in units of seconds, as
positive value of type decimal64 with fraction digits = 4 (see a positive value of type decimal64 with fraction digits = 4 (see
section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds
(0.1 ms). (0.1 ms).
dT the duration of the interval for allowed sample start times, with dT: The duration of the interval for allowed sample start times,
value 1.0, expressed in units of seconds, as a positive value of with value 1.0, expressed in units of seconds, as a positive value
type decimal64 with fraction digits = 4 (see section 9.3 of of type decimal64 with fraction digits = 4 (see Section 9.3 of
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms).
NOTE: an initiation process with a number of control exchanges Note: An initiation process with a number of control exchanges
resulting in unpredictable start times (within a time interval) may resulting in unpredictable start times (within a time interval)
be sufficient to avoid synchronization of periodic streams, and may be sufficient to avoid synchronization of periodic streams and
therefore a valid replacement for selecting a start time at random is a valid replacement for selecting a start time at random from a
from a fixed interval. fixed interval.
The T0 parameter will be reported as a measured parameter. The T0 Parameter will be reported as a measured Parameter.
Parameters incT and dT are Fixed Parameters. Parameters incT and dT are Fixed Parameters.
5.3.3. Traffic Filtering (observation) Details 5.3.3. Traffic Filtering (Observation) Details
NA N/A
5.3.4. Sampling Distribution 5.3.4. Sampling Distribution
NA N/A
5.3.5. Run-time Parameters and Data Format 5.3.5. Runtime Parameters and Data Format
Src the IP address of the host in the Src Role (format ipv4-address- Src: The IP address of the host in the Src Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the Dst Role (format ipv4-address- Dst: The IP address of the host in the Dst Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
T0 a time, the start of a measurement interval, (format "date-and- T0: A time, the start of a measurement interval (format "date-time"
time" as specified in Section 5.6 of [RFC3339], see also Section 3 as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of in Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a start time is unspecified Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
and Tf is to be interpreted as the Duration of the measurement unspecified and Tf is to be interpreted as the duration of the
interval. The start time is controlled through other means. measurement interval. The start time is controlled through other
means.
Tf a time, the end of a measurement interval, (format "date-and-time" Tf: A time, the end of a measurement interval (format "date-time" as
as specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time
Tf is interpreted as the Duration of the measurement interval. and date is ignored and Tf is interpreted as the duration of the
measurement interval.
5.3.6. Roles 5.3.6. Roles
Src launches each packet and waits for return transmissions from Src: Launches each packet and waits for return transmissions from
Dst. the Dst.
Dst waits for each packet from Src and sends a return packet to Src. Dst: Waits for each packet from the Src and sends a return packet to
the Src (when required by the test protocol).
5.4. Output 5.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
5.4.1. Type 5.4.1. Type
Percentile -- for the conditional distribution of all packets with a Percentile: For the conditional distribution of all packets with a
valid value of one-way delay (undefined delays are excluded), a valid value of one-way delay (undefined delays are excluded), this is
single value corresponding to the 95th percentile, as follows: a single value corresponding to the 95th percentile, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
The percentile = 95, meaning that the reported delay, "95Percentile", The percentile = 95, meaning that the reported delay, "95Percentile",
is the smallest value of one-way PDV for which the Empirical is the smallest value of one-way PDV for which the Empirical
Distribution Function (EDF), F(95Percentile) >= 95% of the singleton Distribution Function, EDF(95Percentile), is greater than or equal to
one-way PDV values in the conditional distribution. See section 11.3 95% of the singleton one-way PDV values in the conditional
of [RFC2330] for the definition of the percentile statistic using the distribution. See Section 11.3 of [RFC2330] for the definition of
EDF. the percentile statistic using the EDF.
5.4.2. Reference Definition 5.4.2. Reference Definition
T0 the start of a measurement interval, (format "date-and-time" as T0: The start of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as Tf: The end of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
95Percentile The time value of the result is expressed in units of 95Percentile: The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
5.4.3. Metric Units 5.4.3. Metric Units
The 95th Percentile of one-way PDV is expressed in seconds. The 95th percentile of one-way PDV is expressed in seconds.
5.4.4. Calibration 5.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. Calibration in-
calibration could be enabled with an internal loopback that includes situ could be enabled with an internal loopback that includes as much
as much of the measurement system as possible, performs address of the measurement system as possible, performs address manipulation
manipulation as needed, and provides some form of isolation (e.g., as needed, and provides some form of isolation (e.g., deterministic
deterministic delay) to avoid send-receive interface contention. delay) to avoid send-receive interface contention. Some portion of
Some portion of the random and systematic error can be characterized the random and systematic error can be characterized in this way.
this way.
For one-way delay measurements, the error calibration must include an For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets [RFC5905] of clocks at measurement). In practice, the time offsets [RFC5905] of clocks at
both the source and destination are needed to estimate the systematic both the Source and Destination are needed to estimate the systematic
error due to imperfect clock synchronization (the time offsets are error due to imperfect clock synchronization (the time offsets are
smoothed, thus the random variation is not usually represented in the smoothed; thus, the random variation is not usually represented in
results). the results).
time_offset The time value of the result is expressed in units of time_offset: The time value of the result is expressed in units of
seconds, as a signed value of type decimal64 with fraction digits seconds, as a signed value of type decimal64 with fraction
= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement, with an additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset [RFC5905] as an SHOULD report its current estimate of the time offset [RFC5905] as an
indicator of the degree of synchronization. indicator of the degree of synchronization.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the available accuracy of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the output result resolution that is the result of system
noise, and thus inaccurate. noise and is thus inaccurate.
5.5. Administrative items 5.5. Administrative Items
5.5.1. Status 5.5.1. Status
Current Current
5.5.2. Requester 5.5.2. Requester
This RFC number RFC 8912
5.5.3. Revision 5.5.3. Revision
1.0 1.0
5.5.4. Revision Date 5.5.4. Revision Date
YYYY-MM-DD 2021-11-17
5.6. Comments and Remarks 5.6. Comments and Remarks
Lost packets represent a challenge for delay variation metrics. See Lost packets represent a challenge for delay variation metrics. See
section 4.1 of [RFC3393] and the delay variation applicability Section 4.1 of [RFC3393] and the delay variation applicability
statement[RFC5481] for extensive analysis and comparison of PDV and statement [RFC5481] for extensive analysis and comparison of PDV and
an alternate metric, IPDV. an alternate metric, IPDV (Inter-Packet Delay Variation).
6. DNS Response Latency and Loss Registry Entries 6. DNS Response Latency and Loss Registry Entries
This section gives initial registry entries for DNS Response Latency This section gives initial Registry Entries for DNS Response Latency
and Loss from a network user's perspective, for a specific named and Loss from a network user's perspective, for a specific named
resource. The metric can be measured repeatedly using different resource. The metric can be measured repeatedly for different named
names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We resources. [RFC2681] defines a round-trip delay metric. We build on
build on that metric by specifying several of the input parameters to that metric by specifying several of the input Parameters to
precisely define two metrics for measuring DNS latency and loss. precisely define two metrics for measuring DNS latency and loss.
Note to IANA: Each Registry "Name" below specifies a single registry All column entries besides the ID, Name, Description, and Output
entry, whose output format varies in accordance with the name. Reference Method categories are the same; thus, this section defines
two closely related Registry Entries. As a result, IANA has assigned
All column entries beside the ID, Name, Description, and Output corresponding URLs to each of the two Named Metrics.
Reference Method categories are the same, thus this section proposes
two closely-related registry entries. As a result, IANA is also
asked to assign corresponding URLs to each Named Metric.
6.1. Summary 6.1. Summary
This category includes multiple indexes to the registry entries, the This category includes multiple indexes to the Registry Entries: the
element ID and metric name. element ID and Metric Name.
6.1.1. ID (Identifier) 6.1.1. ID (Identifier)
<insert numeric identifier, an integer> IANA has allocated the numeric Identifiers 4 and 5 for the two Named
Metric Entries in Section 6. See Section 6.1.2 for mapping to Names.
IANA is asked to assign different numeric identifiers to each of the
two Named Metrics.
6.1.2. Name 6.1.2. Name
RTDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Seconds_Raw 4: RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw
RLDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Logical_Raw 5: RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw
6.1.3. URI 6.1.3. URI
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/RTDNS_Active_IP-UDP-
Poisson_RFC8912sec6_Seconds_Raw
URL: https://www.iana.org/performance-metrics/RLDNS_Active_IP-UDP-
Poisson_RFC8912sec6_Logical_Raw
6.1.4. Description 6.1.4. Description
This is a metric for DNS Response performance from a network user's This is a metric for DNS Response performance from a network user's
perspective, for a specific named resource. The metric can be perspective, for a specific named resource. The metric can be
measured repeatedly using different resource names. measured repeatedly using different resource names.
RTDNS: This metric assesses the response time, the interval from the RTDNS: This metric assesses the response time, the interval from the
query transmission to the response. query transmission to the response.
RLDNS: This metric indicates that the response was deemed lost. In RLDNS: This metric indicates that the response was deemed lost. In
other words, the response time exceeded the maximum waiting time. other words, the response time exceeded the maximum waiting time.
6.1.5. Change Controller 6.1.5. Change Controller
IETF IETF
6.1.6. Version (of Registry Format) 6.1.6. Version (of Registry Format)
1.0 1.0
6.2. Metric Definition 6.2. Metric Definition
This category includes columns to prompt the entry of all necessary This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters. and values of input factors, called "Fixed Parameters".
6.2.1. Reference Definition 6.2.1. Reference Definition
Mockapetris, P., "Domain names - implementation and specification", For Delay:
STD 13, RFC 1035, November 1987. (and updates)
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November
1987, <https://www.rfc-editor.org/info/rfc1035> (and updates).
[RFC1035]
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999. Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
<https://www.rfc-editor.org/info/rfc2681>. [RFC2681]
[RFC2681] Section 2.4 of [RFC2681] provides the reference definition of the
singleton (single value) round-trip delay metric. Section 3.4 of
[RFC2681] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as "singleton" and
"sample" are defined in Section 11 of [RFC2330].
Section 2.4 of [RFC2681] provides the reference definition of the For DNS Response Latency, the entities in [RFC1035] must be mapped
singleton (single value) Round-trip delay metric. Section 3.4 of to [RFC2681]. The Local Host with its User Program and Resolver
[RFC2681] provides the reference definition expanded to cover a take the Role of "Src", and the Foreign Name Server takes the Role
multi-singleton sample. Note that terms such as singleton and sample of "Dst".
are defined in Section 11 of [RFC2330].
For DNS Response Latency, the entities in [RFC1035] must be mapped to Note that although the definition of round-trip delay between the
[RFC2681]. The Local Host with its User Program and Resolver take Source (Src) and the Destination (Dst) at T as provided in
the role of "Src", and the Foreign Name Server takes the role of Section 2.4 of [RFC2681] is directionally ambiguous in the text,
"Dst". this metric tightens the definition further to recognize that the
host in the Src Role will send the first packet to the host in the
Dst Role and will ultimately receive the corresponding return
packet from the Dst (when neither is lost).
Note that although the [RFC2681] definition of "Round-trip-Delay For Loss:
between Src and Dst at T" is directionally ambiguous in the text,
this metric tightens the definition further to recognize that the
host in the "Src" role will send the first packet to "Dst", and
ultimately receive the corresponding return packet from "Dst" (when
neither are lost).
Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
rfc6673>. [RFC6673]
[RFC6673] For DNS Response Loss, the entities in [RFC1035] must be mapped to
[RFC6673]. The Local Host with its User Program and Resolver take
the Role of "Src", and the Foreign Name Server takes the Role of
"Dst".
Both response time and loss metrics employ a maximum waiting time for Both response time and Loss metrics employ a maximum waiting time
received responses, so the count of lost packets to total packets for received responses, so the count of lost packets to total
sent is the basis for the loss determination as per Section 4.3 of packets sent is the basis for the loss determination as per
[RFC6673]. Section 4.3 of [RFC6673].
6.2.2. Fixed Parameters 6.2.2. Fixed Parameters
Type-P as defined in Section 13 of [RFC2330]: Type-P as defined in Section 13 of [RFC2330]:
IPv4 header values:
DSCP: Set to 0
TTL: Set to 255
Protocol: Set to 17 (UDP)
o IPv4 header values: IPv6 header values:
DSCP: Set to 0
* DSCP: set to 0 Hop Count: Set to 255
Next Header: Set to 17 (UDP)
* TTL set to 255 Flow Label: Set to 0
Extension Headers: None
* Protocol: set to 17 (UDP)
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
o UDP header values:
* Source port: 53
* Destination port: 53
* Checksum: the checksum must be calculated and the non-zero
checksum included in the header
o Payload: The payload contains a DNS message as defined in RFC 1035
[RFC1035] with the following values:
* The DNS header section contains:
+ Identification (see the Run-time column)
+ QR: set to 0 (Query)
+ OPCODE: set to 0 (standard query)
+ AA: not set
+ TC: not set
+ RD: set to one (recursion desired)
+ RA: not set
+ RCODE: not set
+ QDCOUNT: set to one (only one entry)
+ ANCOUNT: not set
+ NSCOUNT: not set
+ ARCOUNT: not set
* The Question section contains: UDP header values:
Source port: 53
Destination port: 53
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header
+ QNAME: the Fully Qualified Domain Name (FQDN) provided as Payload:
input for the test, see the Run-time column The payload contains a DNS message as defined in [RFC1035] with
the following values:
+ QTYPE: the query type provided as input for the test, see The DNS header section contains:
the Run-time column Identification (see the Runtime column)
QR: Set to 0 (Query)
OPCODE: Set to 0 (standard query)
AA: Not set
TC: Not set
RD: Set to 1 (recursion desired)
RA: Not set
RCODE: Not set
QDCOUNT: Set to 1 (only one entry)
ANCOUNT: Not set
NSCOUNT: Not set
ARCOUNT: Not set
+ QCLASS: set to 1 for IN The Question section contains:
QNAME: The Fully Qualified Domain Name (FQDN) provided as
input for the test; see the Runtime column
* The other sections do not contain any Resource Records. QTYPE: The query type provided as input for the test; see
the Runtime column
Other measurement parameters: QCLASS: Set to 1 for IN
o Tmax: a loss threshold waiting time (and to help disambiguate The other sections do not contain any Resource Records
queries) (RRs).
* 5.0, expressed in units of seconds, as a positive value of type Other measurement Parameters:
decimal64 with fraction digits = 4 (see section 9.3 of Tmax: A loss threshold waiting time (and to help disambiguate
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with queries). The value is 5.0, expressed in units of seconds, as
lossless conversion to/from the 32-bit NTP timestamp as per a positive value of type decimal64 with fraction digits = 4
section 6 of [RFC5905]. (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001
seconds (0.1 ms), with lossless conversion to/from the 32-bit
NTP timestamp as per Section 6 of [RFC5905].
Observation: reply packets will contain a DNS response and may Observation: Reply packets will contain a DNS Response and may
contain RRs. contain RRs.
6.3. Method of Measurement 6.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
6.3.1. Reference Method 6.3.1. Reference Methods
The methodology for this metric is defined as Type-P-Round-trip- The methodology for this metric (equivalent to Type-P-Round-trip-
Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section Delay-Poisson-Stream) is defined as in Section 2.6 of [RFC2681] (for
3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under singletons) and Section 3.6 of [RFC2681] (for samples) using the
Fixed Parameters. Type-P and Timeout defined in the Fixed Parameters column.
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
response packet lost. Lost packets SHALL be designated as having response packet lost. Lost packets SHALL be designated as having
undefined delay and counted for the RLDNS metric. undefined delay and counted for the RLDNS metric.
The calculations on the delay (RTT) SHALL be performed on the The calculations on the delay (RTT) SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MUST enforce the Tmax threshold on that calculates the RTT value MUST enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See Section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and see Section 5 of [RFC6703] for background on this
choice. analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
reply. reply.
DNS Messages bearing Queries provide for random ID Numbers in the DNS messages bearing queries provide for random ID Numbers in the
Identification header field, so more than one query may be launched Identification header field, so more than one query may be launched
while a previous request is outstanding when the ID Number is used. while a previous request is outstanding when the ID Number is used.
Therefore, the ID Number MUST be retained at the Src and included Therefore, the ID Number MUST be retained at the Src and included
with each response packet to disambiguate packet reordering if it with each response packet to disambiguate packet reordering if it
occurs. occurs.
IF a DNS response does not arrive within Tmax, the response time If a DNS Response does not arrive within Tmax, the response time
RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to
disambiguate the successive queries that are otherwise identical. disambiguate the successive queries that are otherwise identical.
Since the ID Number field is only 16 bits in length, it places a Since the ID Number field is only 16 bits in length, it places a
limit on the number of simultaneous outstanding DNS queries during a limit on the number of simultaneous outstanding DNS queries during a
stress test from a single Src address. stress test from a single Src address.
Refer to Section 4.4 of [RFC6673] for expanded discussion of the Refer to Section 4.4 of [RFC6673] for an expanded discussion of the
instruction to "send a Type-P packet back to the Src as quickly as instruction to "send a Type-P packet back to the Src as quickly as
possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS possible" in Section 2.6 of [RFC2681]. However, the DNS server is
Server is expected to perform all required functions to prepare and expected to perform all required functions to prepare and send a
send a response, so the response time will include processing time response, so the response time will include processing time and
and network delay. Section 8 of [RFC6673] presents additional network delay. Section 8 of [RFC6673] presents additional
requirements which SHALL be included in the method of measurement for requirements that SHALL be included in the Method of Measurement for
this metric. this metric.
In addition to operations described in [RFC2681], the Src MUST parse In addition to operations described in [RFC2681], the Src MUST parse
the DNS headers of the reply and prepare the query response the DNS headers of the reply and prepare the query response
information for subsequent reporting as a measured result, along with information for subsequent reporting as a measured result, along with
the Round-Trip Delay. the round-trip delay.
6.3.2. Packet Stream Generation 6.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section provides details regarding packet traffic, which is used
basis for measurement. In IPPM metrics, this is called the Stream, as the basis for measurement. In IPPM Metrics, this is called the
and can easily be described by providing the list of stream "stream"; this stream can easily be described by providing the list
parameters. of stream Parameters.
Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to Section 11.1.3 of [RFC2330] provides three methods to generate
generate Poisson sampling intervals. The reciprocal of lambda is the Poisson sampling intervals. The reciprocal of lambda is the average
average packet spacing, thus the Run-time Parameter is packet spacing; thus, the Runtime Parameter is
Reciprocal_lambda = 1/lambda, in seconds. Reciprocal_lambda = 1/lambda, in seconds.
Method 3 is used, where given a start time (Run-time Parameter), the Method 3 SHALL be used. Where given a start time (Runtime
subsequent send times are all computed prior to measurement by Parameter), the subsequent send times are all computed prior to
computing the pseudo-random distribution of inter-packet send times, measurement by computing the pseudorandom distribution of inter-
(truncating the distribution as specified in the Run-time packet send times (truncating the distribution as specified in the
Parameters), and the Src sends each packet at the computed times. Parameter Trunc), and the Src sends each packet at the computed
times.
Note that Trunc is the upper limit on inter-packet times in the Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead. to Trunc instead.
6.3.3. Traffic Filtering (observation) Details 6.3.3. Traffic Filtering (Observation) Details
NA N/A
6.3.4. Sampling Distribution 6.3.4. Sampling Distribution
NA N/A
6.3.5. Run-time Parameters and Data Format 6.3.5. Runtime Parameters and Data Format
Run-time Parameters are input factors that must be determined, Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
for the context to be complete. for the context to be complete.
Src the IP address of the host in the Src Role (format ipv4-address- Src: The IP address of the host in the Src Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the Dst Role (format ipv4-address-
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see section 4 of [RFC6991])
T0 a time, the start of a measurement interval, (format "date-and- Dst: The IP address of the host in the Dst Role (format
time" as specified in Section 5.6 of [RFC3339], see also Section 3 ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of for IPv6; see Section 4 of [RFC6991]).
[RFC2330]. When T0 is "all-zeros", a start time is unspecified
and Tf is to be interpreted as the Duration of the measurement
interval. The start time is controlled through other means.
Tf a time, the end of a measurement interval, (format "date-and-time" T0: A time, the start of a measurement interval (format "date-time"
as specified in Section 5.6 of [RFC3339], see also Section 3 of as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
[RFC6991]). The UTC Time Zone is required by Section 6.1 of in Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
unspecified and Tf is to be interpreted as the duration of the
measurement interval. The start time is controlled through other
means.
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf: A time, the end of a measurement interval (format "date-time" as
Tf is interpreted as the Duration of the measurement interval. specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time
and date is ignored and Tf is interpreted as the duration of the
measurement interval.
Reciprocal_lambda average packet interval for Poisson Streams Reciprocal_lambda: Average packet interval for Poisson streams,
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless with a resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of conversion to/from the 32-bit NTP timestamp as per Section 6 of
[RFC5905]. [RFC5905].
Trunc Upper limit on Poisson distribution expressed in units of Trunc: Upper limit on Poisson distribution, expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 4 (see section 9.3 of [RFC6020]) with resolution of digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of
0.0001 seconds (0.1 ms), and with lossless conversion to/from the 0.0001 seconds (0.1 ms), and with lossless conversion to/from the
32-bit NTP timestamp as per section 6 of [RFC5905] (values above 32-bit NTP timestamp as per Section 6 of [RFC5905] (values above
this limit will be clipped and set to the limit value). this limit will be clipped and set to the limit value).
ID The 16-bit identifier assigned by the program that generates the ID: The 16-bit Identifier assigned by the program that generates the
query, and which must vary in successive queries (a list of IDs is query. The ID value must vary in successive queries (a list of
needed), see Section 4.1.1 of [RFC1035]. This identifier is IDs is needed); see Section 4.1.1 of [RFC1035]. This Identifier
copied into the corresponding reply and can be used by the is copied into the corresponding reply and can be used by the
requester (Src) to match-up replies to outstanding queries. requester (Src) to match replies with any outstanding queries.
QNAME The domain name of the Query, formatted as specified in QNAME: The domain name of the query, formatted as specified in
section 4 of [RFC6991]. Section 4 of [RFC6991].
QTYPE The Query Type, which will correspond to the IP address family QTYPE: The query type, which will correspond to the IP address
of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a family of the query (decimal 1 for IPv4 or 28 for IPv6), formatted
uint16, as per section 9.2 of [RFC6020]. as a uint16, as per Section 9.2 of [RFC6020].
6.3.6. Roles 6.3.6. Roles
Src launches each packet and waits for return transmissions from Src: Launches each packet and waits for return transmissions from
Dst. the Dst.
Dst waits for each packet from Src and sends a return packet to Src. Dst: Waits for each packet from the Src and sends a return packet to
the Src.
6.4. Output 6.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
6.4.1. Type 6.4.1. Type
Raw -- for each DNS Query packet sent, sets of values as defined in Raw: For each DNS query packet sent, sets of values as defined in the
the next column, including the status of the response, only assigning next column, including the status of the response, only assigning
delay values to successful query-response pairs. delay values to successful query-response pairs.
6.4.2. Reference Definition 6.4.2. Reference Definition
For all outputs: For all outputs:
T the time the DNS Query was sent during the measurement interval, T: The time the DNS query was sent during the measurement interval
(format "date-and-time" as specified in Section 5.6 of [RFC3339], (format "date-time" as specified in Section 5.6 of [RFC3339]; see
see also Section 3 of [RFC6991]). The UTC Time Zone is required also "date-and-time" in Section 3 of [RFC6991]). The UTC Time
by Section 6.1 of [RFC2330]. Zone is required by Section 6.1 of [RFC2330].
dT The time value of the round-trip delay to receive the DNS dT: The time value of the round-trip delay to receive the DNS
response, expressed in units of seconds, as a positive value of Response, expressed in units of seconds, as a positive value of
type decimal64 with fraction digits = 9 (see section 9.3 of type decimal64 with fraction digits = 9 (see Section 9.3 of
[RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as per with lossless conversion to/from the 64-bit NTP timestamp as per
section 6 of RFC [RFC5905]. This value is undefined when the Section 6 of [RFC5905]. This value is undefined when the response
response packet is not received at Src within waiting time Tmax packet is not received at the Src within a waiting time of
seconds. Tmax seconds.
Rcode The value of the Rcode field in the DNS response header, RCODE: The value of the RCODE field in the DNS Response header,
expressed as a uint64 as specified in section 9.2 of [RFC6020]. expressed as a uint64 as specified in Section 9.2 of [RFC6020].
Non-zero values convey errors in the response, and such replies Non-zero values convey errors in the response, and such replies
must be analyzed separately from successful requests. must be analyzed separately from successful requests.
Logical: The numeric value of the result is expressed as a Logical
value, where 1 = Lost and 0 = Received, as a positive value of
type uint8 (represents integer values between 0 and 255,
inclusively (see Section 9.2 of [RFC6020]). Note that for queries
with outcome 1 = Lost, dT and RCODE will be set to the maximum for
decimal64 and uint64, respectively.
6.4.3. Metric Units 6.4.3. Metric Units
RTDNS: Round-trip Delay, dT, is expressed in seconds. RTDNS: Round-trip delay, dT, is expressed in seconds.
RTLDNS: the Logical value, where 1 = Lost and 0 = Received. RLDNS: The Logical value, where 1 = Lost and 0 = Received.
6.4.4. Calibration 6.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. Calibration in-
calibration could be enabled with an internal loopback at the Source situ could be enabled with an internal loopback at the Source host
host that includes as much of the measurement system as possible, that includes as much of the measurement system as possible, performs
performs address and payload manipulation as needed, and provides address and payload manipulation as needed, and provides some form of
some form of isolation (e.g., deterministic delay) to avoid send- isolation (e.g., deterministic delay) to avoid send-receive interface
receive interface contention. Some portion of the random and contention. Some portion of the random and systematic error can be
systematic error can be characterized this way. characterized in this way.
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement, with an additional indication that it is a
calibration result. calibration result.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the available accuracy of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the output result resolution that is the result of system
noise, and thus inaccurate. noise and is thus inaccurate.
6.5. Administrative items 6.5. Administrative Items
6.5.1. Status 6.5.1. Status
Current Current
6.5.2. Requester 6.5.2. Requester
This RFC number RFC 8912
6.5.3. Revision 6.5.3. Revision
1.0 1.0
6.5.4. Revision Date 6.5.4. Revision Date
YYYY-MM-DD 2021-11-17
6.6. Comments and Remarks 6.6. Comments and Remarks
None None
7. UDP Poisson One-way Delay and Loss Registry Entries 7. UDP Poisson One-Way Delay and Loss Registry Entries
This section specifies five initial registry entries for the UDP
Poisson One-way Delay, and one for UDP Poisson One-way Loss.
IANA Note: Registry "Name" below specifies multiple registry entries, This section specifies five initial Registry Entries for UDP Poisson
whose output format varies according to the <statistic> element of One-Way Delay and one entry for UDP Poisson One-Way Loss.
the name that specifies one form of statistical summary. There is an
additional metric name for the Loss metric.
All column entries beside the ID, Name, Description, and Output All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same; thus, this section defines
six closely-related registry entries. As a result, IANA is also six closely related Registry Entries. As a result, IANA has assigned
asked to assign corresponding URLs to each Named Metric. corresponding URLs to each of the Named Metrics.
7.1. Summary 7.1. Summary
This category includes multiple indexes to the registry entries, the This category includes multiple indexes to the Registry Entries: the
element ID and metric name. element ID and Metric Name.
7.1.1. ID (Identifier) 7.1.1. ID (Identifier)
IANA is asked to assign different numeric identifiers to each of the IANA has allocated the numeric Identifiers 6-11 for the six Named
six Metrics. Metric Entries in Section 7. See Section 7.1.2 for mapping to Names.
7.1.2. Name 7.1.2. Name
OWDelay_Active_IP-UDP-Poisson- 6:
Payload250B_RFCXXXXsec7_Seconds_<statistic> OWDelay_Active_IP-UDP-Poisson-
Payload250B_RFC8912sec7_Seconds_95Percentile
where <statistic> is one of:
o 95Percentile
o Mean 7: OWDelay_Active_IP-UDP-Poisson-
Payload250B_RFC8912sec7_Seconds_Mean
o Min 8: OWDelay_Active_IP-UDP-Poisson-
Payload250B_RFC8912sec7_Seconds_Min
o Max 9: OWDelay_Active_IP-UDP-Poisson-
Payload250B_RFC8912sec7_Seconds_Max
o StdDev 10:
OWDelay_Active_IP-UDP-Poisson-
Payload250B_RFC8912sec7_Seconds_StdDev
OWLoss_Active_IP-UDP-Poisson- 11:
Payload250B_RFCXXXXsec7_Percent_LossRatio OWLoss_Active_IP-UDP-Poisson-
Payload250B_RFC8912sec7_Percent_LossRatio
7.1.3. URI 7.1.3. URI
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile
7.1.4. Description
OWDelay: This metric assesses the delay of a stream of packets
exchanged between two hosts (or measurement points), and reports the
<statistic> One-way delay for all successfully exchanged packets
based on their conditional delay distribution.
where <statistic> is one of:
o 95Percentile URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Poisson-Payload250B_RFC8912sec7_Seconds_Mean
o Mean URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Poisson-Payload250B_RFC8912sec7_Seconds_Min
o Min URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Poisson-Payload250B_RFC8912sec7_Seconds_Max
o Max URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Poisson-Payload250B_RFC8912sec7_Seconds_StdDev
o StdDev URL: https://www.iana.org/performance-metrics/OWLoss_Active_IP-UDP-
OWLoss: This metric assesses the loss ratio of a stream of packets Poisson-Payload250B_RFC8912sec7_Percent_LossRatio
exchanged between two hosts (which are the two measurement points),
and the Output is the One-way loss ratio for all successfully
received packets expressed as a percentage.
7.2. Metric Definition 7.1.4. Description
This category includes columns to prompt the entry of all necessary OWDelay: This metric assesses the delay of a stream of packets
details related to the metric definition, including the RFC reference exchanged between two hosts (or measurement points) and reports
and values of input factors, called fixed parameters. the <statistic> of one-way delay for all successfully exchanged
packets based on their conditional delay distribution.
7.2.1. Reference Definition where <statistic> is one of:
For Delay: * 95Percentile
Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- * Mean
Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-
editor.org/info/rfc7679>.
[RFC7679] * Min
Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC * Max
6049, January 2011.
[RFC6049] * StdDev
Section 3.4 of [RFC7679] provides the reference definition of the OWLoss: This metric assesses the loss ratio of a stream of packets
singleton (single value) One-way delay metric. Section 4.4 of exchanged between two hosts (which are the two measurement
[RFC7679] provides the reference definition expanded to cover a points). The output is the one-way loss ratio for all transmitted
multi-value sample. Note that terms such as singleton and sample are packets expressed as a percentage.
defined in Section 11 of [RFC2330].
Only successful packet transfers with finite delay are included in 7.1.5. Change Controller
the sample, as prescribed in section 4.1.2 of [RFC6049].
For loss: IETF
Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 7.1.6. Version (of Registry Format)
Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI
10.17487/RFC7680, January 2016, <http://www.rfc-editor.org/info/
rfc7680>.
Section 2.4 of [RFC7680] provides the reference definition of the 1.0
singleton (single value) one-way loss metric. Section 3.4 of
[RFC7680] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as singleton and sample
are defined in Section 11 of [RFC2330].
7.2.2. Fixed Parameters 7.2. Metric Definition
Type-P: This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference
and values of input factors, called "Fixed Parameters".
o IPv4 header values: 7.2.1. Reference Definition
* DSCP: set to 0 For delay:
* TTL: set to 255 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81,
RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-
editor.org/info/rfc7679>. [RFC7679]
* Protocol: Set to 17 (UDP) Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC
6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-
editor.org/info/rfc6049>. [RFC6049]
o IPv6 header values: Section 3.4 of [RFC7679] provides the reference definition of the
singleton (single value) one-way delay metric. Section 4.4 of
[RFC7679] provides the reference definition expanded to cover a
multi-value sample. Note that terms such as "singleton" and
"sample" are defined in Section 11 of [RFC2330].
* DSCP: set to 0 Only successful packet transfers with finite delay are included in
the sample, as prescribed in Section 4.1.2 of [RFC6049].
* Hop Count: set to 255 For loss:
* Next Header: set to 17 (UDP) Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82,
RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-
editor.org/info/rfc7680>. [RFC7680]
* Flow Label: set to zero Section 2.4 of [RFC7680] provides the reference definition of the
singleton (single value) one-way Loss metric. Section 3.4 of
[RFC7680] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as "singleton" and
"sample" are defined in Section 11 of [RFC2330].
* Extension Headers: none 7.2.2. Fixed Parameters
o UDP header values: Type-P:
IPv4 header values:
DSCP: Set to 0
TTL: Set to 255
Protocol: Set to 17 (UDP)
* Checksum: the checksum MUST be calculated and the non-zero IPv6 header values:
checksum included in the header DSCP: Set to 0
Hop Count: Set to 255
Next Header: Set to 17 (UDP)
Flow Label: Set to 0
Extension Headers: None
o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] UDP header values:
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header
* Security features in use influence the number of Padding UDP Payload: TWAMP-Test packet formats (Section 4.1.2 of
octets. [RFC5357])
* 250 octets total, including the TWAMP format type, which MUST Security features in use influence the number of Padding
be reported. octets
Other measurement parameters: 250 octets total, including the TWAMP format type, which
MUST be reported
Tmax: a loss threshold waiting time with value 3.0, expressed in Other measurement Parameters:
units of seconds, as a positive value of type decimal64 with Tmax: A loss threshold waiting time with value 3.0, expressed in
fraction digits = 4 (see section 9.3 of [RFC6020]) and with units of seconds, as a positive value of type decimal64 with
resolution of 0.0001 seconds (0.1 ms), with lossless conversion fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
See the Packet Stream generation category for two additional Fixed See the Packet Stream Generation section for two additional Fixed
Parameters. Parameters.
7.3. Method of Measurement 7.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
7.3.1. Reference Method 7.3.1. Reference Methods
The methodology for this metric is defined as Type-P-One-way-Delay- The methodology for this metric (equivalent to Type-P-One-way-Delay-
Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of Poisson-Stream) is defined as in Section 3.6 of [RFC7679] (for
[RFC7679] using the Type-P and Tmax defined under Fixed Parameters. singletons) and Section 4.6 of [RFC7679] (for samples) using the
Type-P and Tmax defined in the Fixed Parameters column.
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the OWLoss metric. delay and counted for the OWLoss metric.
The calculations on the one-way delay SHALL be performed on the The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MUST enforce the Tmax that calculates the one-way delay value MUST enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See Section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and see Section 5 of [RFC6703] for
on this analysis choice. background on this analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. packet.
Since a standard measurement protocol is employed [RFC5357], then the Since a standard measurement protocol is employed [RFC5357], the
measurement process will determine the sequence numbers or timestamps measurement process will determine the sequence numbers or timestamps
applied to test packets after the Fixed and Runtime parameters are applied to test packets after the Fixed and Runtime Parameters are
passed to that process. The measurement protocol dictates the format passed to that process. The measurement protocol dictates the format
of sequence numbers and time-stamps conveyed in the TWAMP-Test packet of sequence numbers and timestamps conveyed in the TWAMP-Test packet
payload. payload.
7.3.2. Packet Stream Generation 7.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section provides details regarding packet traffic, which is used
basis for measurement. In IPPM metrics, this is called the Stream, as the basis for measurement. In IPPM Metrics, this is called the
and can easily be described by providing the list of stream "stream"; this stream can easily be described by providing the list
parameters. of stream Parameters.
Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to Section 11.1.3 of [RFC2330] provides three methods to generate
generate Poisson sampling intervals. The reciprocal of lambda is the Poisson sampling intervals. The reciprocal of lambda is the average
average packet spacing, thus the Run-time Parameter is packet spacing; thus, the Runtime Parameter is
Reciprocal_lambda = 1/lambda, in seconds. Reciprocal_lambda = 1/lambda, in seconds.
Method 3 SHALL be used, where given a start time (Run-time Method 3 SHALL be used. Where given a start time (Runtime
Parameter), the subsequent send times are all computed prior to Parameter), the subsequent send times are all computed prior to
measurement by computing the pseudo-random distribution of inter- measurement by computing the pseudorandom distribution of inter-
packet send times, (truncating the distribution as specified in the packet send times (truncating the distribution as specified in the
Parameter Trunc), and the Src sends each packet at the computed Parameter Trunc), and the Src sends each packet at the computed
times. times.
Note that Trunc is the upper limit on inter-packet times in the Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead. to Trunc instead.
Reciprocal_lambda average packet interval for Poisson Streams Reciprocal_lambda: Average packet interval for Poisson streams,
expressed in units of seconds, as a positive value of type expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless with a resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of conversion to/from the 32-bit NTP timestamp as per Section 6 of
[RFC5905]. Reciprocal_lambda = 1 second. [RFC5905]. Reciprocal_lambda = 1 second.
Trunc Upper limit on Poisson distribution expressed in units of Trunc: Upper limit on Poisson distribution, expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 4 (see section 9.3 of [RFC6020]) with resolution of digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of
0.0001 seconds (0.1 ms), and with lossless conversion to/from the 0.0001 seconds (0.1 ms), and with lossless conversion to/from the
32-bit NTP timestamp as per section 6 of [RFC5905] (values above 32-bit NTP timestamp as per Section 6 of [RFC5905] (values above
this limit will be clipped and set to the limit value). Trunc = this limit will be clipped and set to the limit value).
30.0000 seconds. Trunc = 30.0000 seconds.
7.3.3. Traffic Filtering (observation) Details 7.3.3. Traffic Filtering (Observation) Details
NA N/A
7.3.4. Sampling Distribution 7.3.4. Sampling Distribution
NA N/A
7.3.5. Run-time Parameters and Data Format 7.3.5. Runtime Parameters and Data Format
Run-time Parameters are input factors that must be determined, Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
for the context to be complete. for the context to be complete.
Src the IP address of the host in the Src Role (format ipv4-address- Src: The IP address of the host in the Src Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the Dst Role (format ipv4-address- Dst: The IP address of the host in the Dst Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
T0 a time, the start of a measurement interval, (format "date-and- T0: A time, the start of a measurement interval (format "date-time"
time" as specified in Section 5.6 of [RFC3339], see also Section 3 as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of in Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a start time is unspecified Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
and Tf is to be interpreted as the Duration of the measurement unspecified and Tf is to be interpreted as the duration of the
interval. The start time is controlled through other means. measurement interval. The start time is controlled through other
means.
Tf a time, the end of a measurement interval, (format "date-and-time" Tf: A time, the end of a measurement interval (format "date-time" as
as specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time
Tf is interpreted as the Duration of the measurement interval. and date is ignored and Tf is interpreted as the duration of the
measurement interval.
7.3.6. Roles 7.3.6. Roles
Src launches each packet and waits for return transmissions from Src: Launches each packet and waits for return transmissions from
Dst. This is the TWAMP Session-Sender. the Dst. An example is the TWAMP Session-Sender.
Dst waits for each packet from Src and sends a return packet to Src. Dst: Waits for each packet from the Src and sends a return packet to
This is the TWAMP Session-Reflector. the Src. An example is the TWAMP Session-Reflector.
7.4. Output 7.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
7.4.1. Type 7.4.1. Type
See subsection titles below for Types. Types are discussed in the subsections below.
7.4.2. Reference Definition 7.4.2. Reference Definition
For all output types --- For all output types:
T0 the start of a measurement interval, (format "date-and-time" as T0: The start of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as Tf: The end of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
For LossRatio -- the count of lost packets to total packets sent is For LossRatio, the count of lost packets to total packets sent is the
the basis for the loss ratio calculation as per Section 4.1 of basis for the loss ratio calculation as per Section 4.1 of [RFC7680].
[RFC7680].
For each <statistic>, one of the following sub-sections apply: For each <statistic> or Percent_LossRatio, one of the following
subsections applies.
7.4.2.1. Percentile95 7.4.2.1. Percentile95
The 95th percentile SHALL be calculated using the conditional The 95th percentile SHALL be calculated using the conditional
distribution of all packets with a finite value of One-way delay distribution of all packets with a finite value of one-way delay
(undefined delays are excluded), a single value as follows: (undefined delays are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3 of [RFC3393] for details on the percentile statistic See Section 4.3 of [RFC3393] for details on the percentile statistic
(where Round-trip delay should be substituted for "ipdv"). (where round-trip delay should be substituted for "ipdv").
The percentile = 95, meaning that the reported delay, "95Percentile", The percentile = 95, meaning that the reported delay, "95Percentile",
is the smallest value of one-way delay for which the Empirical is the smallest value of one-way delay for which the Empirical
Distribution Function (EDF), F(95Percentile) >= 95% of the singleton Distribution Function, EDF(95Percentile), is greater than or equal to
one-way delay values in the conditional distribution. See section 95% of the singleton one-way delay values in the conditional
11.3 of [RFC2330] for the definition of the percentile statistic distribution. See Section 11.3 of [RFC2330] for the definition of
using the EDF. the percentile statistic using the EDF.
95Percentile The time value of the result is expressed in units of 95Percentile: The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
7.4.2.2. Mean 7.4.2.2. Mean
The mean SHALL be calculated using the conditional distribution of The mean SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of one-way delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.2.2 of [RFC6049] for details on calculating this See Section 4.2.2 of [RFC6049] for details on calculating this
statistic, and 4.2.3 of [RFC6049]. statistic; see also Section 4.2.3 of [RFC6049].
Mean The time value of the result is expressed in units of seconds, Mean: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
7.4.2.3. Min 7.4.2.3. Min
The minimum SHALL be calculated using the conditional distribution of The minimum SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of one-way delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for details on calculating this See Section 4.3.2 of [RFC6049] for details on calculating this
statistic, and 4.3.3 of [RFC6049]. statistic; see also Section 4.3.3 of [RFC6049].
Min The time value of the result is expressed in units of seconds, Min: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
7.4.2.4. Max 7.4.2.4. Max
The maximum SHALL be calculated using the conditional distribution of The maximum SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of one-way delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See Section 4.3.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic; see also Section 4.3.3 of [RFC6049]. The
as follows: formula is as follows:
Max = (FiniteDelay [j]) Max = (FiniteDelay[j])
such that for some index, j, where 1 <= j <= N such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n FiniteDelay[j] >= FiniteDelay[n] for all n
Max The time value of the result is expressed in units of seconds, Max: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
7.4.2.5. Std_Dev 7.4.2.5. Std_Dev
The Std_Dev SHALL be calculated using the conditional distribution of The standard deviation (Std_Dev) SHALL be calculated using the
all packets with a finite value of One-way delay (undefined delays conditional distribution of all packets with a finite value of
are excluded), a single value as follows: one-way delay (undefined delays are excluded) -- a single value, as
follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 6.1.4 of [RFC6049] for a closely related method for See Section 6.1.4 of [RFC6049] for a closely related method for
calculating this statistic. The formula is the classic calculation calculating this statistic. The formula is the classic calculation
for standard deviation of a population. for the standard deviation of a population.
Define Population Std_Dev_Delay as follows: Define Population Std_Dev_Delay as follows:
(where all packets n = 1 through N have a value for Delay[n],
and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the
Square Root function:
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
Std_Dev The time value of the result is expressed in units of _ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
where all packets n = 1 through N have a value for Delay[n],
MeanDelay is calculated per Section 7.4.2.2, and SQRT[] is the Square
Root function:
Std_Dev: The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
7.4.2.6. Percent_LossRatio
Percent_LossRatio: The numeric value of the result is expressed in
units of lost packets to total packets times 100%, as a positive
value of type decimal64 with fraction digits = 9 (see Section 9.3
of [RFC6020]) with a resolution of 0.0000000001.
7.4.3. Metric Units 7.4.3. Metric Units
The <statistic> of One-way Delay is expressed in seconds. The <statistic> of one-way delay is expressed in seconds, where
<statistic> is one of:
The One-way Loss Ratio is expressed as a percentage of lost packets * 95Percentile
* Mean
* Min
* Max
* StdDev
The one-way loss ratio is expressed as a percentage of lost packets
to total packets sent. to total packets sent.
7.4.4. Calibration 7.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. Calibration in-
calibration could be enabled with an internal loopback that includes situ could be enabled with an internal loopback that includes as much
as much of the measurement system as possible, performs address of the measurement system as possible, performs address manipulation
manipulation as needed, and provides some form of isolation (e.g., as needed, and provides some form of isolation (e.g., deterministic
deterministic delay) to avoid send-receive interface contention. delay) to avoid send-receive interface contention. Some portion of
Some portion of the random and systematic error can be characterized the random and systematic error can be characterized in this way.
this way.
For one-way delay measurements, the error calibration must include an For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets [RFC5905] of clocks at measurement). In practice, the time offsets [RFC5905] of clocks at
both the source and destination are needed to estimate the systematic both the Source and Destination are needed to estimate the systematic
error due to imperfect clock synchronization (the time offsets error due to imperfect clock synchronization (the time offsets
[RFC5905] are smoothed, thus the random variation is not usually [RFC5905] are smoothed; thus, the random variation is not usually
represented in the results). represented in the results).
time_offset The time value of the result is expressed in units of time_offset: The time value of the result is expressed in units of
seconds, as a signed value of type decimal64 with fraction digits seconds, as a signed value of type decimal64 with fraction
= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement, with an additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset [RFC5905] as an SHOULD report its current estimate of the time offset [RFC5905] as an
indicator of the degree of synchronization. indicator of the degree of synchronization.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the available accuracy of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the output result resolution that is the result of system
noise, and thus inaccurate. noise and is thus inaccurate.
7.5. Administrative items 7.5. Administrative Items
7.5.1. Status 7.5.1. Status
Current Current
7.5.2. Requester 7.5.2. Requester
This RFC number RFC 8912
7.5.3. Revision 7.5.3. Revision
1.0 1.0
7.5.4. Revision Date 7.5.4. Revision Date
YYYY-MM-DD 2021-11-17
7.6. Comments and Remarks 7.6. Comments and Remarks
None None
8. UDP Periodic One-way Delay and Loss Registry Entries 8. UDP Periodic One-Way Delay and Loss Registry Entries
This section specifies five initial registry entries for the UDP
Periodic One-way Delay, and one for UDP Periodic One-way Loss.
IANA Note: Registry "Name" below specifies multiple registry entries, This section specifies five initial Registry Entries for UDP Periodic
whose output format varies according to the <statistic> element of One-Way Delay and one entry for UDP Periodic One-Way Loss.
the name that specifies one form of statistical summary. There is an
additional metric name for the Loss metric.
All column entries beside the ID, Name, Description, and Output All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same; thus, this section defines
six closely-related registry entries. As a result, IANA is also six closely related Registry Entries. As a result, IANA has assigned
asked to assign corresponding URLs to each Named Metric. corresponding URLs to each of the six Named Metrics.
8.1. Summary 8.1. Summary
This category includes multiple indexes to the registry entries, the This category includes multiple indexes to the Registry Entries: the
element ID and metric name. element ID and Metric Name.
8.1.1. ID (Identifier) 8.1.1. ID (Identifier)
IANA is asked to assign a different numeric identifiers to each of IANA has allocated the numeric Identifiers 12-17 for the six Named
the six Metrics. Metric Entries in Section 8. See Section 8.1.2 for mapping to Names.
8.1.2. Name 8.1.2. Name
OWDelay_Active_IP-UDP-Periodic20m- 12:
Payload142B_RFCXXXXsec8_Seconds_<statistic> OWDelay_Active_IP-UDP-Periodic20m-
Payload142B_RFC8912sec8_Seconds_95Percentile
where <statistic> is one of:
o 95Percentile 13:
OWDelay_Active_IP-UDP-Periodic20m-
Payload142B_RFC8912sec8_Seconds_Mean
o Mean 14:
OWDelay_Active_IP-UDP-Periodic20m-
Payload142B_RFC8912sec8_Seconds_Min
o Min 15:
OWDelay_Active_IP-UDP-Periodic20m-
Payload142B_RFC8912sec8_Seconds_Max
o Max 16:
o StdDev OWDelay_Active_IP-UDP-Periodic20m-
Payload142B_RFC8912sec8_Seconds_StdDev
OWLoss_Active_IP-UDP-Periodic- 17:
Payload142B_RFCXXXXsec8_Percent_LossRatio OWLoss_Active_IP-UDP-Periodic20m-
Payload142B_RFC8912sec8_Percent_LossRatio
8.1.3. URI 8.1.3. URI
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile
8.1.4. Description
OWDelay: This metric assesses the delay of a stream of packets
exchanged between two hosts (or measurement points), and reports the
<statistic> One-way delay for all successfully exchanged packets
based on their conditional delay distribution.
where <statistic> is one of:
o 95Percentile URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Periodic20m-Payload142B_RFC8912sec8_Seconds_Mean
o Mean URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Periodic20m-Payload142B_RFC8912sec8_Seconds_Min
o Min URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Periodic20m-Payload142B_RFC8912sec8_Seconds_Max
o Max URL: https://www.iana.org/performance-metrics/OWDelay_Active_IP-UDP-
Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev
o StdDev URL: https://www.iana.org/performance-metrics/OWLoss_Active_IP-UDP-
Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio
OWLoss: This metric assesses the loss ratio of a stream of packets 8.1.4. Description
exchanged between two hosts (which are the two measurement points),
and the Output is the One-way loss ratio for all successfully
received packets expressed as a percentage.
8.2. Metric Definition OWDelay: This metric assesses the delay of a stream of packets
exchanged between two hosts (or measurement points) and reports
the <statistic> of one-way delay for all successfully exchanged
packets based on their conditional delay distribution.
This category includes columns to prompt the entry of all necessary where <statistic> is one of:
details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.
8.2.1. Reference Definition * 95Percentile
For Delay: * Mean
Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- * Min
Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-
editor.org/info/rfc7679>.
[RFC7679] * Max
Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC * StdDev
6049, January 2011.
[RFC6049] OWLoss: This metric assesses the loss ratio of a stream of packets
exchanged between two hosts (which are the two measurement
points). The output is the one-way loss ratio for all transmitted
packets expressed as a percentage.
Section 3.4 of [RFC7679] provides the reference definition of the 8.1.5. Change Controller
singleton (single value) One-way delay metric. Section 4.4 of
[RFC7679] provides the reference definition expanded to cover a
multi-value sample. Note that terms such as singleton and sample are
defined in Section 11 of [RFC2330].
Only successful packet transfers with finite delay are included in IETF
the sample, as prescribed in section 4.1.2 of [RFC6049].
For loss: 8.1.6. Version (of Registry Format)
Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1.0
Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI
10.17487/RFC7680, January 2016, <http://www.rfc-editor.org/info/
rfc7680>.
Section 2.4 of [RFC7680] provides the reference definition of the 8.2. Metric Definition
singleton (single value) one-way loss metric. Section 3.4 of
[RFC7680] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as singleton and sample
are defined in Section 11 of [RFC2330].
8.2.2. Fixed Parameters This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference
and values of input factors, called "Fixed Parameters".
Type-P: 8.2.1. Reference Definition
o IPv4 header values: For delay:
* DSCP: set to 0 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81,
RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-
editor.org/info/rfc7679>. [RFC7679]
* TTL: set to 255 Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC
6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-
editor.org/info/rfc6049>. [RFC6049]
* Protocol: Set to 17 (UDP) Section 3.4 of [RFC7679] provides the reference definition of the
singleton (single value) one-way delay metric. Section 4.4 of
[RFC7679] provides the reference definition expanded to cover a
multi-value sample. Note that terms such as "singleton" and
"sample" are defined in Section 11 of [RFC2330].
o IPv6 header values: Only successful packet transfers with finite delay are included in
the sample, as prescribed in Section 4.1.2 of [RFC6049].
* DSCP: set to 0 For loss:
* Hop Count: set to 255 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82,
RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-
editor.org/info/rfc7680>. [RFC7680]
* Next Header: set to 17 (UDP) Section 2.4 of [RFC7680] provides the reference definition of the
* Flow Label: set to zero singleton (single value) one-way Loss metric. Section 3.4 of
[RFC7680] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as "singleton" and
"sample" are defined in Section 11 of [RFC2330].
* Extension Headers: none 8.2.2. Fixed Parameters
o UDP header values: Type-P:
IPv4 header values:
DSCP: Set to 0
TTL: Set to 255
Protocol: Set to 17 (UDP)
* Checksum: the checksum MUST be calculated and the non-zero IPv6 header values:
checksum included in the header DSCP: Set to 0
Hop Count: Set to 255
Next Header: Set to 17 (UDP)
Flow Label: Set to 0
Extension Headers: None
o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] UDP header values:
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header
* Security features in use influence the number of Padding UDP Payload: TWAMP-Test packet formats (Section 4.1.2 of
octets. [RFC5357])
* 142 octets total, including the TWAMP format (and format type Security features in use influence the number of Padding
MUST be reported, if used) octets
Other measurement parameters: 142 octets total, including the TWAMP format (and format
type MUST be reported, if used)
Tmax: a loss threshold waiting time with value 3.0, expressed in Other measurement Parameters:
units of seconds, as a positive value of type decimal64 with Tmax: A loss threshold waiting time with value 3.0, expressed in
fraction digits = 4 (see section 9.3 of [RFC6020]) and with units of seconds, as a positive value of type decimal64 with
resolution of 0.0001 seconds (0.1 ms), with lossless conversion fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
See the Packet Stream generation category for two additional Fixed See the Packet Stream Generation section for three additional Fixed
Parameters. Parameters.
8.3. Method of Measurement 8.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
8.3.1. Reference Method 8.3.1. Reference Methods
The methodology for this metric is defined as Type-P-One-way-Delay- The methodology for this metric (equivalent to Type-P-One-way-Delay-
Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of Poisson-Stream) is defined as in Section 3.6 of [RFC7679] (for
[RFC7679] using the Type-P and Tmax defined under Fixed Parameters. singletons) and Section 4.6 of [RFC7679] (for samples) using the
However, a Periodic stream is used, as defined in [RFC3432]. Type-P and Tmax defined in the Fixed Parameters column. However, a
Periodic stream is used, as defined in [RFC3432].
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the OWLoss metric. delay and counted for the OWLoss metric.
The calculations on the one-way delay SHALL be performed on the The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MUST enforce the Tmax that calculates the one-way delay value MUST enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See Section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and see Section 5 of [RFC6703] for
on this analysis choice. background on this analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. packet.
Since a standard measurement protocol is employed [RFC5357], then the Since a standard measurement protocol is employed [RFC5357], the
measurement process will determine the sequence numbers or timestamps measurement process will determine the sequence numbers or timestamps
applied to test packets after the Fixed and Runtime parameters are applied to test packets after the Fixed and Runtime Parameters are
passed to that process. The measurement protocol dictates the format passed to that process. The measurement protocol dictates the format
of sequence numbers and time-stamps conveyed in the TWAMP-Test packet of sequence numbers and timestamps conveyed in the TWAMP-Test packet
payload. payload.
8.3.2. Packet Stream Generation 8.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section provides details regarding packet traffic, which is used
basis for measurement. In IPPM metrics, this is called the Stream, as the basis for measurement. In IPPM Metrics, this is called the
and can easily be described by providing the list of stream "stream"; this stream can easily be described by providing the list
parameters. of stream Parameters.
Section 3 of [RFC3432] prescribes the method for generating Periodic Section 3 of [RFC3432] prescribes the method for generating Periodic
streams using associated parameters. streams using associated Parameters.
incT the nominal duration of inter-packet interval, first bit to incT: The nominal duration of the inter-packet interval, first bit
first bit, with value 0.0200 expressed in units of seconds, as a to first bit, with value 0.0200, expressed in units of seconds, as
positive value of type decimal64 with fraction digits = 4 (see a positive value of type decimal64 with fraction digits = 4 (see
section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds
(0.1 ms), with lossless conversion to/from the 32-bit NTP (0.1 ms), with lossless conversion to/from the 32-bit NTP
timestamp as per section 6 of [RFC5905]. timestamp as per Section 6 of [RFC5905].
dT the duration of the interval for allowed sample start times, with dT: The duration of the interval for allowed sample start times,
value 1.0000, expressed in units of seconds, as a positive value with value 1.0000, expressed in units of seconds, as a positive
of type decimal64 with fraction digits = 4 (see section 9.3 of value of type decimal64 with fraction digits = 4 (see Section 9.3
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms),
lossless conversion to/from the 32-bit NTP timestamp as per with lossless conversion to/from the 32-bit NTP timestamp as per
section 6 of [RFC5905]. Section 6 of [RFC5905].
T0 the actual start time of the periodic stream, determined from T0 T0: The actual start time of the periodic stream, determined from T0
and dT. and dT.
NOTE: an initiation process with a number of control exchanges Note: An initiation process with a number of control exchanges
resulting in unpredictable start times (within a time interval) may resulting in unpredictable start times (within a time interval)
be sufficient to avoid synchronization of periodic streams, and may be sufficient to avoid synchronization of periodic streams and
therefore a valid replacement for selecting a start time at random is a valid replacement for selecting a start time at random from a
from a fixed interval. fixed interval.
These stream parameters will be specified as Run-time parameters. These stream Parameters will be specified as Runtime Parameters.
8.3.3. Traffic Filtering (observation) Details 8.3.3. Traffic Filtering (Observation) Details
NA N/A
8.3.4. Sampling Distribution 8.3.4. Sampling Distribution
NA N/A
8.3.5. Run-time Parameters and Data Format 8.3.5. Runtime Parameters and Data Format
Run-time Parameters are input factors that must be determined, Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
for the context to be complete. for the context to be complete.
Src the IP address of the host in the Src Role (format ipv4-address- Src: The IP address of the host in the Src Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the Dst Role (format ipv4-address- Dst: The IP address of the host in the Dst Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
T0 a time, the start of a measurement interval, (format "date-and- T0: A time, the start of a measurement interval (format "date-time"
time" as specified in Section 5.6 of [RFC3339], see also Section 3 as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of in Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a start time is unspecified Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
and Tf is to be interpreted as the Duration of the measurement unspecified and Tf is to be interpreted as the duration of the
interval. The start time is controlled through other means. measurement interval. The start time is controlled through other
means.
Tf a time, the end of a measurement interval, (format "date-and-time" Tf: A time, the end of a measurement interval (format "date-time" as
as specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time
Tf is interpreted as the Duration of the measurement interval. and date is ignored and Tf is interpreted as the duration of the
measurement interval.
8.3.6. Roles 8.3.6. Roles
Src launches each packet and waits for return transmissions from Src: Launches each packet and waits for return transmissions from
Dst. This is the TWAMP Session-Sender. the Dst. An example is the TWAMP Session-Sender.
Dst waits for each packet from Src and sends a return packet to Src. Dst: Waits for each packet from the Src and sends a return packet to
This is the TWAMP Session-Reflector. the Src. An example is the TWAMP Session-Reflector.
8.4. Output 8.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
8.4.1. Type 8.4.1. Type
See subsection titles in Reference Definition for Latency Types. Latency and Loss Types are discussed in the subsections below.
8.4.2. Reference Definition 8.4.2. Reference Definition
For all output types --- For all output types:
T0 the start of a measurement interval, (format "date-and-time" as T0: The start of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as Tf: The end of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
For LossRatio -- the count of lost packets to total packets sent is For LossRatio, the count of lost packets to total packets sent is the
the basis for the loss ratio calculation as per Section 4.1 of basis for the loss ratio calculation as per Section 4.1 of [RFC7680].
[RFC7680].
For each <statistic>, one of the following sub-sections apply: For each <statistic> or Percent_LossRatio, one of the following
subsections applies.
8.4.2.1. Percentile95 8.4.2.1. Percentile95
The 95th percentile SHALL be calculated using the conditional The 95th percentile SHALL be calculated using the conditional
distribution of all packets with a finite value of One-way delay distribution of all packets with a finite value of one-way delay
(undefined delays are excluded), a single value as follows: (undefined delays are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3 of [RFC3393] for details on the percentile statistic See Section 4.3 of [RFC3393] for details on the percentile statistic
(where Round-trip delay should be substituted for "ipdv"). (where round-trip delay should be substituted for "ipdv").
The percentile = 95, meaning that the reported delay, "95Percentile", The percentile = 95, meaning that the reported delay, "95Percentile",
is the smallest value of one-way delay for which the Empirical is the smallest value of one-way delay for which the Empirical
Distribution Function (EDF), F(95Percentile) >= 95% of the singleton Distribution Function, EDF(95Percentile), is greater than or equal to
one-way delay values in the conditional distribution. See section 95% of the singleton one-way delay values in the conditional
11.3 of [RFC2330] for the definition of the percentile statistic distribution. See Section 11.3 of [RFC2330] for the definition of
using the EDF. the percentile statistic using the EDF.
95Percentile The time value of the result is expressed in units of 95Percentile: The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
8.4.2.2. Mean 8.4.2.2. Mean
The mean SHALL be calculated using the conditional distribution of The mean SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of one-way delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.2.2 of [RFC6049] for details on calculating this See Section 4.2.2 of [RFC6049] for details on calculating this
statistic, and 4.2.3 of [RFC6049]. statistic; see also Section 4.2.3 of [RFC6049].
Mean The time value of the result is expressed in units of seconds, Mean: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
8.4.2.3. Min 8.4.2.3. Min
The minimum SHALL be calculated using the conditional distribution of The minimum SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of one-way delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for details on calculating this See Section 4.3.2 of [RFC6049] for details on calculating this
statistic, and 4.3.3 of [RFC6049]. statistic; see also Section 4.3.3 of [RFC6049].
Min The time value of the result is expressed in units of seconds, Min: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
8.4.2.4. Max 8.4.2.4. Max
The maximum SHALL be calculated using the conditional distribution of The maximum SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of one-way delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See Section 4.3.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic; see also Section 4.3.3 of [RFC6049]. The
as follows: formula is as follows:
Max = (FiniteDelay [j]) Max = (FiniteDelay[j])
such that for some index, j, where 1 <= j <= N such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n FiniteDelay[j] >= FiniteDelay[n] for all n
Max The time value of the result is expressed in units of seconds, Max: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
8.4.2.5. Std_Dev 8.4.2.5. Std_Dev
The Std_Dev SHALL be calculated using the conditional distribution of Std_Dev SHALL be calculated using the conditional distribution of all
all packets with a finite value of One-way delay (undefined delays packets with a finite value of one-way delay (undefined delays are
are excluded), a single value as follows: excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See Section 6.1.4 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic. The formula is the classic calculation
the classic calculation for standard deviation of a population. for the standard deviation of a population.
Define Population Std_Dev_Delay as follows: Define Population Std_Dev_Delay as follows:
(where all packets n = 1 through N have a value for Delay[n],
and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the
Square Root function:
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
Std_Dev The time value of the result is expressed in units of _ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
where all packets n = 1 through N have a value for Delay[n],
MeanDelay is calculated per Section 8.4.2.2, and SQRT[] is the Square
Root function:
Std_Dev: The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
8.4.2.6. Percent_LossRatio
Percent_LossRatio: The numeric value of the result is expressed in
units of lost packets to total packets times 100%, as a positive
value of type decimal64 with fraction digits = 9 (see Section 9.3
of [RFC6020] with a resolution of 0.0000000001.
8.4.3. Metric Units 8.4.3. Metric Units
The <statistic> of One-way Delay is expressed in seconds, where The <statistic> of one-way delay is expressed in seconds, where
<statistic> is one of: <statistic> is one of:
o 95Percentile * 95Percentile
o Mean * Mean
o Min * Min
o Max * Max
o StdDev * StdDev
The One-way Loss Ratio is expressed as a percentage of lost packets The one-way loss ratio is expressed as a percentage of lost packets
to total packets sent. to total packets sent.
8.4.4. Calibration 8.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. Calibration in-
calibration could be enabled with an internal loopback that includes situ could be enabled with an internal loopback that includes as much
as much of the measurement system as possible, performs address of the measurement system as possible, performs address manipulation
manipulation as needed, and provides some form of isolation (e.g., as needed, and provides some form of isolation (e.g., deterministic
deterministic delay) to avoid send-receive interface contention. delay) to avoid send-receive interface contention. Some portion of
Some portion of the random and systematic error can be characterized the random and systematic error can be characterized in this way.
this way.
For one-way delay measurements, the error calibration must include an For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets [RFC5905] of clocks at measurement). In practice, the time offsets [RFC5905] of clocks at
both the source and destination are needed to estimate the systematic both the Source and Destination are needed to estimate the systematic
error due to imperfect clock synchronization (the time offsets error due to imperfect clock synchronization (the time offsets
[RFC5905] are smoothed, thus the random variation is not usually [RFC5905] are smoothed; thus, the random variation is not usually
represented in the results). represented in the results).
time_offset The time value of the result is expressed in units of time_offset: The time value of the result is expressed in units of
seconds, as a signed value of type decimal64 with fraction digits seconds, as a signed value of type decimal64 with fraction
= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement, with an additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset [RFC5905] as an SHOULD report its current estimate of the time offset [RFC5905] as an
indicator of the degree of synchronization. indicator of the degree of synchronization.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the available accuracy of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the output result resolution that is the result of system
noise, and thus inaccurate. noise and is thus inaccurate.
8.5. Administrative items 8.5. Administrative Items
8.5.1. Status 8.5.1. Status
Current Current
8.5.2. Requester 8.5.2. Requester
This RFC number RFC 8912
8.5.3. Revision 8.5.3. Revision
1.0 1.0
8.5.4. Revision Date 8.5.4. Revision Date
YYYY-MM-DD 2021-11-17
8.6. Comments and Remarks 8.6. Comments and Remarks
None. None
9. ICMP Round-trip Latency and Loss Registry Entries
This section specifies three initial registry entries for the ICMP 9. ICMP Round-Trip Latency and Loss Registry Entries
Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio.
IANA Note: Registry "Name" below specifies multiple registry entries, This section specifies three initial Registry Entries for ICMP
whose output format varies according to the <statistic> element of Round-Trip Latency and another entry for the ICMP Round-Trip Loss
the name that specifies one form of statistical summary. There is an Ratio.
additional metric name for the Loss metric.
All column entries beside the ID, Name, Description, and Output All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same; thus, this section defines
two closely-related registry entries. As a result, IANA is also four closely related Registry Entries. As a result, IANA has
asked to assign corresponding URLs to each Named Metric. assigned corresponding URLs to each of the four Named Metrics.
9.1. Summary 9.1. Summary
This category includes multiple indexes to the registry entry: the This category includes multiple indexes to the Registry Entries: the
element ID and metric name. element ID and Metric Name.
9.1.1. ID (Identifier) 9.1.1. ID (Identifier)
IANA is asked to assign different numeric identifiers to each of the IANA has allocated the numeric Identifiers 18-21 for the four Named
four Named Metrics. Metric Entries in Section 9. See Section 9.1.2 for mapping to Names.
9.1.2. Name 9.1.2. Name
RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_<statistic> 18: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean
where <statistic> is one of: 19: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min
o Mean 20: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max
o Min 21: RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio
o Max 9.1.3. URI
RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio URL: https://www.iana.org/performance-metrics/RTDelay_Active_IP-ICMP-
SendOnRcv_RFC8912sec9_Seconds_Mean
9.1.3. URI URL: https://www.iana.org/performance-metrics/RTDelay_Active_IP-ICMP-
SendOnRcv_RFC8912sec9_Seconds_Min
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/RTDelay_Active_IP-ICMP-
SendOnRcv_RFC8912sec9_Seconds_Max
URL: https://www.iana.org/performance-metrics/RTLoss_Active_IP-ICMP-
SendOnRcv_RFC8912sec9_Percent_LossRatio
9.1.4. Description 9.1.4. Description
RTDelay: This metric assesses the delay of a stream of ICMP packets RTDelay: This metric assesses the delay of a stream of ICMP packets
exchanged between two hosts (which are the two measurement points), exchanged between two hosts (which are the two measurement
and the Output is the Round-trip delay for all successfully exchanged points). The output is the round-trip delay for all successfully
packets expressed as the <statistic> of their conditional delay exchanged packets expressed as the <statistic> of their
distribution, where <statistic> is one of: conditional delay distribution, where <statistic> is one of:
o Mean * Mean
o Min * Min
o Max * Max
RTLoss: This metric assesses the loss ratio of a stream of ICMP RTLoss: This metric assesses the loss ratio of a stream of ICMP
packets exchanged between two hosts (which are the two measurement packets exchanged between two hosts (which are the two measurement
points), and the Output is the Round-trip loss ratio for all points). The output is the round-trip loss ratio for all
successfully exchanged packets expressed as a percentage. transmitted packets expressed as a percentage.
9.1.5. Change Controller 9.1.5. Change Controller
IETF IETF
9.1.6. Version (of Registry Format) 9.1.6. Version (of Registry Format)
1.0 1.0
9.2. Metric Definition 9.2. Metric Definition
This category includes columns to prompt the entry of all necessary This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters. and values of input factors, called "Fixed Parameters".
9.2.1. Reference Definition 9.2.1. Reference Definition
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay For delay:
Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
<https://www.rfc-editor.org/info/rfc2681>. [RFC2681]
Section 2.4 of [RFC2681] provides the reference definition of the Section 2.4 of [RFC2681] provides the reference definition of the
singleton (single value) Round-trip delay metric. Section 3.4 of singleton (single value) round-trip delay metric. Section 3.4 of
[RFC2681] provides the reference definition expanded to cover a [RFC2681] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as singleton and sample multi-singleton sample. Note that terms such as "singleton" and
are defined in Section 11 of [RFC2330]. "sample" are defined in Section 11 of [RFC2330].
Note that although the [RFC2681] definition of "Round-trip-Delay Note that although the definition of round-trip delay between the
between Src and Dst" is directionally ambiguous in the text, this Source (Src) and the Destination (Dst) as provided in Section 2.4
metric tightens the definition further to recognize that the host in of [RFC2681] is directionally ambiguous in the text, this metric
the "Src" role will send the first packet to "Dst", and ultimately tightens the definition further to recognize that the host in the
receive the corresponding return packet from "Dst" (when neither are Src Role will send the first packet to the host in the Dst Role
lost). and will ultimately receive the corresponding return packet from
the Dst (when neither is lost).
Finally, note that the variable "dT" is used in [RFC2681] to refer to Finally, note that the variable "dT" is used in [RFC2681] to refer
the value of Round-trip delay in metric definitions and methods. The to the value of round-trip delay in metric definitions and
variable "dT" has been re-used in other IPPM literature to refer to methods. The variable "dT" has been reused in other IPPM
different quantities, and cannot be used as a global variable name. literature to refer to different quantities and cannot be used as
a global variable name.
Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. For loss:
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
rfc6673>. [RFC6673]
Both delay and loss metrics employ a maximum waiting time for Both Delay and Loss metrics employ a maximum waiting time for
received packets, so the count of lost packets to total packets sent received packets, so the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per Section 6.1 of is the basis for the loss ratio calculation as per Section 6.1 of
[RFC6673]. [RFC6673].
9.2.2. Fixed Parameters 9.2.2. Fixed Parameters
Type-P as defined in Section 13 of [RFC2330]: Type-P as defined in Section 13 of [RFC2330]:
IPv4 header values:
DSCP: Set to 0
TTL: Set to 255
Protocol: Set to 01 (ICMP)
o IPv4 header values: IPv6 header values:
DSCP: Set to 0
* DSCP: set to 0 Hop Count: Set to 255
Next Header: Set to 128 decimal (ICMP)
* TTL: set to 255 Flow Label: Set to 0
Extension Headers: None
* Protocol: Set to 01 (ICMP)
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Next Header: set to 128 decimal (ICMP)
* Flow Label: set to zero
* Extension Headers: none
o ICMP header values:
* Type: 8 (Echo Request)
* Code: 0
* Checksum: the checksum MUST be calculated and the non-zero
checksum included in the header
* (Identifier and Sequence Number set at Run-Time)
o ICMP Payload
* total of 32 bytes of random info, constant per test.
Other measurement parameters: ICMP header values:
Type: 8 (Echo Request)
Code: 0
Checksum: The checksum MUST be calculated and the non-zero
checksum included in the header
(Identifier and sequence number set at runtime)
o Tmax: a loss threshold waiting time ICMP Payload:
Total of 32 bytes of random information, constant per test
* 3.0, expressed in units of seconds, as a positive value of type Other measurement Parameters:
decimal64 with fraction digits = 4 (see section 9.3 of Tmax: A loss threshold waiting time with value 3.0, expressed in
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with units of seconds, as a positive value of type decimal64 with
lossless conversion to/from the 32-bit NTP timestamp as per fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a
section 6 of [RFC5905]. resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].
9.3. Method of Measurement 9.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
9.3.1. Reference Method 9.3.1. Reference Methods
The methodology for this metric is defined as Type-P-Round-trip- The methodology for this metric (equivalent to Type-P-Round-trip-
Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section Delay-Poisson-Stream) is defined as in Section 2.6 of [RFC2681] (for
3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under singletons) and Section 3.6 of [RFC2681] (for samples) using the
Fixed Parameters. Type-P and Tmax defined in the Fixed Parameters column.
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the RTLoss metric. delay and counted for the RTLoss metric.
The calculations on the delay (RTD) SHALL be performed on the The calculations on the delay (RTD) SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTD value MUST enforce the Tmax threshold on that calculates the RTD value MUST enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See Section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and see Section 5 of [RFC6703] for background on this
choice. analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to disambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
The measurement process will determine the sequence numbers applied The measurement process will determine the sequence numbers applied
to test packets after the Fixed and Runtime parameters are passed to to test packets after the Fixed and Runtime Parameters are passed to
that process. The ICMP measurement process and protocol will dictate that process. The ICMP measurement process and protocol will dictate
the format of sequence numbers and other identifiers. the format of sequence numbers and other Identifiers.
Refer to Section 4.4 of [RFC6673] for expanded discussion of the Refer to Section 4.4 of [RFC6673] for an expanded discussion of the
instruction to "send a Type-P packet back to the Src as quickly as instruction to "send a Type-P packet back to the Src as quickly as
possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of possible" in Section 2.6 of [RFC2681]. Section 8 of [RFC6673]
[RFC6673] presents additional requirements which MUST be included in presents additional requirements that MUST be included in the Method
the method of measurement for this metric. of Measurement for this metric.
9.3.2. Packet Stream Generation 9.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section provides details regarding packet traffic, which is used
basis for measurement. In IPPM metrics, this is called the Stream, as the basis for measurement. In IPPM Metrics, this is called the
and can easily be described by providing the list of stream "stream"; this stream can easily be described by providing the list
parameters. of stream Parameters.
The ICMP metrics use a sending discipline called "SendOnRcv" or Send The ICMP metrics use a sending discipline called "SendOnRcv" or Send
On Receive. This is a modification of Section 3 of [RFC3432], which On Receive. This is a modification of Section 3 of [RFC3432], which
prescribes the method for generating Periodic streams using prescribes the method for generating Periodic streams using
associated parameters as defined below for this description: associated Parameters as defined below for this description:
incT the nominal duration of inter-packet interval, first bit to incT: The nominal duration of the inter-packet interval, first bit
first bit to first bit.
dT the duration of the interval for allowed sample start times dT: The duration of the interval for allowed sample start times.
The incT stream parameter will be specified as a Run-time parameter, The incT stream Parameter will be specified as a Runtime Parameter,
and dT is not used in SendOnRcv. and dT is not used in SendOnRcv.
A SendOnRcv sender behaves exactly like a Periodic stream generator A SendOnRcv sender behaves exactly like a Periodic stream generator
while all reply packets arrive with RTD < incT, and the inter-packet while all reply packets arrive with RTD < incT, and the inter-packet
interval will be constant. interval will be constant.
If a reply packet arrives with RTD >= incT, then the inter-packet If a reply packet arrives with RTD >= incT, then the inter-packet
interval for the next sending time is nominally RTD. interval for the next sending time is nominally RTD.
If a reply packet fails to arrive within Tmax, then the inter-packet If a reply packet fails to arrive within Tmax, then the inter-packet
interval for the next sending time is nominally Tmax. interval for the next sending time is nominally Tmax.
If an immediate send on reply arrival is desired, then set incT=0. If an immediate Send On Reply arrival is desired, then set incT = 0.
9.3.3. Traffic Filtering (observation) Details 9.3.3. Traffic Filtering (Observation) Details
NA N/A
9.3.4. Sampling Distribution 9.3.4. Sampling Distribution
NA N/A
9.3.5. Run-time Parameters and Data Format 9.3.5. Runtime Parameters and Data Format
Run-time Parameters are input factors that must be determined, Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
for the context to be complete. for the context to be complete.
Src the IP address of the host in the Src Role (format ipv4-address- Src: The IP address of the host in the Src Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the Dst Role (format ipv4-address- Dst: The IP address of the host in the Dst Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
incT the nominal duration of inter-packet interval, first bit to incT: The nominal duration of the inter-packet interval, first bit
first bit, expressed in units of seconds, as a positive value of to first bit, expressed in units of seconds, as a positive value
type decimal64 with fraction digits = 4 (see section 9.3 of of type decimal64 with fraction digits = 4 (see Section 9.3 of
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms).
T0 a time, the start of a measurement interval, (format "date-and- T0: A time, the start of a measurement interval (format "date-time"
time" as specified in Section 5.6 of [RFC3339], see also Section 3 as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of in Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a start time is unspecified Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
and Tf is to be interpreted as the Duration of the measurement unspecified and Tf is to be interpreted as the duration of the
interval. The start time is controlled through other means. measurement interval. The start time is controlled through other
means.
Count The total count of ICMP Echo Requests to send, formatted as a Count: The total count of ICMP Echo Requests to send, formatted as a
uint16, as per section 9.2 of [RFC6020]. uint16, as per Section 9.2 of [RFC6020].
(see the Packet Stream Generation section for additional Run-time See the Packet Stream Generation section for additional Runtime
parameters) Parameters.
9.3.6. Roles 9.3.6. Roles
Src launches each packet and waits for return transmissions from Src: Launches each packet and waits for return transmissions from
Dst. the Dst.
Dst waits for each packet from Src and sends a return packet to Src. Dst: Waits for each packet from the Src and sends a return packet to
the Src (ICMP Echo Reply, Type 0).
9.4. Output 9.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
9.4.1. Type 9.4.1. Type
See subsection titles in Reference Definition for Latency Types. Latency and Loss Types are discussed in the subsections below.
LossRatio -- the count of lost packets to total packets sent is the
basis for the loss ratio calculation as per Section 6.1 of [RFC6673].
9.4.2. Reference Definition 9.4.2. Reference Definition
For all output types --- For all output types:
T0 the start of a measurement interval, (format "date-and-time" as T0: The start of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as Tf: The end of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. Section 6.1 of [RFC2330].
TotalCount the count of packets actually sent by the Src to Dst TotalCount: The count of packets actually sent by the Src to the Dst
during the measurement interval. during the measurement interval.
For LossRatio -- the count of lost packets to total packets sent is For each <statistic> or Percent_LossRatio, one of the following
the basis for the loss ratio calculation as per Section 4.1 of subsections applies.
[RFC7680].
For each <statistic>, one of the following sub-sections apply:
9.4.2.1. Mean 9.4.2.1. Mean
The mean SHALL be calculated using the conditional distribution of The mean SHALL be calculated using the conditional distribution of
all packets with a finite value of Round-trip delay (undefined delays all packets with a finite value of round-trip delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.2.2 of [RFC6049] for details on calculating this See Section 4.2.2 of [RFC6049] for details on calculating this
statistic, and 4.2.3 of [RFC6049]. statistic; see also Section 4.2.3 of [RFC6049].
Mean The time value of the result is expressed in units of seconds, Mean: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
9.4.2.2. Min 9.4.2.2. Min
The minimum SHALL be calculated using the conditional distribution of The minimum SHALL be calculated using the conditional distribution of
all packets with a finite value of Round-trip delay (undefined delays all packets with a finite value of round-trip delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for details on calculating this See Section 4.3.2 of [RFC6049] for details on calculating this
statistic, and 4.3.3 of [RFC6049]. statistic; see also Section 4.3.3 of [RFC6049].
Min The time value of the result is expressed in units of seconds, Min: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
9.4.2.3. Max 9.4.2.3. Max
The maximum SHALL be calculated using the conditional distribution of The maximum SHALL be calculated using the conditional distribution of
all packets with a finite value of Round-trip delay (undefined delays all packets with a finite value of round-trip delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See Section 4.3.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic; see also Section 4.3.3 of [RFC6049]. The
as follows: formula is as follows:
Max = (FiniteDelay [j]) Max = (FiniteDelay[j])
such that for some index, j, where 1 <= j <= N such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n FiniteDelay[j] >= FiniteDelay[n] for all n
Max The time value of the result is expressed in units of seconds, Max: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
9.4.2.4. Percent_LossRatio
For LossRatio, the count of lost packets to total packets sent is the
basis for the loss ratio calculation as per Section 4.1 of [RFC7680].
Percent_LossRatio: The numeric value of the result is expressed in
units of lost packets to total packets times 100%, as a positive
value of type decimal64 with fraction digits = 9 (see Section 9.3
of [RFC6020]) with a resolution of 0.0000000001.
9.4.3. Metric Units 9.4.3. Metric Units
The <statistic> of Round-trip Delay is expressed in seconds, where The <statistic> of round-trip delay is expressed in seconds, where
<statistic> is one of: <statistic> is one of:
o Mean * Mean
o Min * Min
o Max * Max
The Round-trip Loss Ratio is expressed as a percentage of lost The round-trip loss ratio is expressed as a percentage of lost
packets to total packets sent. packets to total packets sent.
9.4.4. Calibration 9.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. Calibration in-
calibration could be enabled with an internal loopback at the Source situ could be enabled with an internal loopback at the Source host
host that includes as much of the measurement system as possible, that includes as much of the measurement system as possible, performs
performs address manipulation as needed, and provides some form of address manipulation as needed, and provides some form of isolation
isolation (e.g., deterministic delay) to avoid send-receive interface (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way. characterized in this way.
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement, with an additional indication that it is a
calibration result. calibration result.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the available accuracy of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the output result resolution that is the result of system
noise, and thus inaccurate. noise and is thus inaccurate.
9.5. Administrative items 9.5. Administrative Items
9.5.1. Status 9.5.1. Status
Current Current
9.5.2. Requester 9.5.2. Requester
This RFC number RFC 8912
9.5.3. Revision 9.5.3. Revision
1.0 1.0
9.5.4. Revision Date 9.5.4. Revision Date
YYYY-MM-DD 2021-11-17
9.6. Comments and Remarks 9.6. Comments and Remarks
None None
10. TCP Round-Trip Delay and Loss Registry Entries 10. TCP Round-Trip Delay and Loss Registry Entries
This section specifies three initial registry entries for the Passive This section specifies four initial Registry Entries for the Passive
assessment of TCP Round-Trip Delay (RTD) and another entry for TCP assessment of TCP Round-Trip Delay (RTD) and another entry for the
Round-trip Loss Count. TCP Round-Trip Loss Count.
IANA Note: Registry "Name" below specifies multiple registry entries,
whose output format varies according to the <statistic> element of
the name that specifies one form of statistical summary. There are
two additional metric names for Singleton RT Delay and Packet Count
metrics.
All column entries beside the ID, Name, Description, and Output All column entries besides the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same; thus, this section defines
four closely-related registry entries. As a result, IANA is also four closely related Registry Entries. As a result, IANA has
asked to assign corresponding URLs to each Named Metric. assigned corresponding URLs to each of the four Named Metrics.
10.1. Summary 10.1. Summary
This category includes multiple indexes to the registry entry: the This category includes multiple indexes to the Registry Entries: the
element ID and metric name. element ID and Metric Name.
10.1.1. ID (Identifier) 10.1.1. ID (Identifier)
IANA is asked to assign different numeric identifiers to each of the IANA has allocated the numeric Identifiers 22-26 for the five Named
four Named Metrics. Metric Entries in Section 10. See Section 10.1.2 for mapping to
Names.
10.1.2. Name 10.1.2. Name
RTDelay_Passive_IP-TCP_RFCXXXXsec10_Seconds_<statistic> 22: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean
where <statistic> is one of: 23: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min
o Mean 24: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max
o Min 25: RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton
o Max Note that a midpoint observer only has the opportunity to compose a
single RTDelay on the TCP handshake.
RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton 26: RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count
Note that a mid-point observer only has the opportunity to compose a 10.1.3. URI
single RTDelay on the TCP Hand Shake.
RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count URL: https://www.iana.org/performance-metrics/RTDelay_Passive_IP-
TCP_RFC8912sec10_Seconds_Mean
10.1.3. URI URL: https://www.iana.org/performance-metrics/RTDelay_Passive_IP-
TCP_RFC8912sec10_Seconds_Min
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/performance-metrics/RTDelay_Passive_IP-
TCP_RFC8912sec10_Seconds_Max
URL: https://www.iana.org/performance-metrics/RTDelay_Passive_IP-TCP-
HS_RFC8912sec10_Seconds_Singleton
URL: https://www.iana.org/performance-metrics/RTLoss_Passive_IP-
TCP_RFC8912sec10_Packet_Count
10.1.4. Description 10.1.4. Description
RTDelay: This metric assesses the round-trip delay of TCP packets RTDelay: This metric assesses the round-trip delay of TCP packets
constituting a single connection, exchanged between two hosts. We constituting a single connection, exchanged between two hosts. We
consider the measurement of round-trip delay based on a single consider the measurement of round-trip delay based on a single
Observation Point [RFC7011] somewhere in the network. The Output is Observation Point (OP) [RFC7011] somewhere in the network. The
the Round-trip delay for all successfully exchanged packets expressed output is the round-trip delay for all successfully exchanged
as the <statistic> of their conditional delay distribution, where packets expressed as the <statistic> of their conditional delay
<statistic> is one of: distribution, where <statistic> is one of:
o Mean * Mean
o Min * Min
o Max * Max
RTLoss: This metric assesses the estimated loss count for TCP packets RTDelay Singleton: This metric assesses the round-trip delay of TCP
constituting a single connection, exchanged between two hosts. We packets initiating a single connection (or 3-way handshake),
consider the measurement of round-trip delay based on a single exchanged between two hosts. We consider the measurement of
Observation Point [RFC7011] somewhere in the network. The Output is round-trip delay based on a single Observation Point (OP)
the estimated Loss Count for the measurement interval. [RFC7011] somewhere in the network. The output is the single
measurement of Round-trip delay, or Singleton.
RTLoss: This metric assesses the estimated loss count for TCP
packets constituting a single connection, exchanged between two
hosts. We consider the measurement of round-trip delay based on a
single OP [RFC7011] somewhere in the network. The output is the
estimated loss count for the measurement interval.
10.1.5. Change Controller 10.1.5. Change Controller
IETF IETF
10.1.6. Version (of Registry Format) 10.1.6. Version (of Registry Format)
1.0 1.0
10.2. Metric Definition 10.2. Metric Definition
This category includes columns to prompt the entry of all necessary This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters. and values of input factors, called "Fixed Parameters".
10.2.1. Reference Definitions
Although there is no RFC that describes passive measurement of Round- 10.2.1. Reference Definition
Trip Delay, the parallel definition for Active measurement is:
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999. Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
<https://www.rfc-editor.org/info/rfc2681>. [RFC2681]
[RFC2681] Although there is no RFC that describes Passive Measurement of round-
trip delay, the parallel definition for Active Measurement is
provided in [RFC2681].
This metric definition uses the terms singleton and sample as defined This metric definition uses the term "wire time" as defined in
in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the Section 10.2 of [RFC2330], and the terms "singleton" and "sample" as
reference definition of the singleton (single value) Round-trip delay defined in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681]
metric. Section 3.4 of [RFC2681] provides the reference definition provides the reference definition of the singleton (single value)
expanded to cover a multi-singleton sample.) round-trip delay metric. Section 3.4 of [RFC2681] provides the
reference definition expanded to cover a multi-singleton sample.)
With the Observation Point [RFC7011] (OP) typically located between With the OP [RFC7011] typically located between the hosts
the hosts participating in the TCP connection, the Round-trip Delay participating in the TCP connection, the round-trip delay metric
metric requires two individual measurements between the OP and each requires two individual measurements between the OP and each host,
host, such that the Spatial Composition [RFC6049]of the measurements such that the Spatial Composition [RFC6049] of the measurements
yields a Round-trip Delay singleton (we are extending the composition yields a round-trip delay singleton (we are extending the composition
of one-way subpath delays to subpath round-trip delay). of one-way subpath delays to subpath round-trip delay).
Using the direction of TCP SYN transmission to anchor the Using the direction of TCP SYN transmission to anchor the
nomenclature, host A sends the SYN and host B replies with SYN-ACK nomenclature, host A sends the SYN, and host B replies with SYN-ACK
during connection establishment. The direction of SYN transfer is during connection establishment. The direction of SYN transfer is
considered the Forward direction of transmission, from A through OP considered the Forward direction of transmission, from A through the
to B (Reverse is B through OP to A). OP to B (the Reverse direction is B through the OP to A).
Traffic filters reduce the packet stream at the OP to a Qualified Traffic Filters reduce the packet streams at the OP to a Qualified
bidirectional flow of packets. bidirectional flow of packets.
In the definitions below, Corresponding Packets are transferred in In the definitions below, Corresponding Packets are transferred in
different directions and convey a common value in a TCP header field different directions and convey a common value in a TCP header field
that establishes correspondence (to the extent possible). Examples that establishes correspondence (to the extent possible). Examples
may be found in the TCP timestamp fields. may be found in the TCP timestamp fields.
For a real number, RTD_fwd, >> the Round-trip Delay in the Forward For a real number, RTD_fwd, >> the round-trip delay in the Forward
direction from OP to host B at time T' is RTD_fwd << it is REQUIRED direction from the OP to host B at time T' is RTD_fwd << it is
that OP observed a Qualified Packet to host B at wire-time T', that REQUIRED that the OP observed a Qualified Packet to host B at wire
host B received that packet and sent a Corresponding Packet back to time T', that host B received that packet and sent a Corresponding
host A, and OP observed the Corresponding Packet at wire-time T' + Packet back to host A, and the OP observed the Corresponding Packet
RTD_fwd. at wire time T' + RTD_fwd.
For a real number, RTD_rev, >> the Round-trip Delay in the Reverse For a real number, RTD_rev, >> the round-trip delay in the Reverse
direction from OP to host A at time T'' is RTD_rev << it is REQUIRED direction from the OP to host A at time T'' is RTD_rev << it is
that OP observed a Qualified Packet to host A at wire-time T'', that REQUIRED that the OP observed a Qualified Packet to host A at wire
host A received that packet and sent a Corresponding Packet back to time T'', that host A received that packet and sent a Corresponding
host B, and that OP observed the Corresponding Packet at wire-time Packet back to host B, and that the OP observed the Corresponding
T'' + RTD_rev. Packet at wire time T'' + RTD_rev.
Ideally, the packet sent from host B to host A in both definitions Ideally, the packet sent from host B to host A in both definitions
above SHOULD be the same packet (or, when measuring RTD_rev first, above SHOULD be the same packet (or, when measuring RTD_rev first,
the packet from host A to host B in both definitions should be the the packet from host A to host B in both definitions should be the
same). same).
The REQUIRED Composition Function for a singleton of Round-trip Delay The REQUIRED Composition Function for a singleton of round-trip delay
at time T (where T is the earliest of T' and T'' above) is: at time T (where T is the earliest of T' and T'' above) is:
RTDelay = RTD_fwd + RTD_rev RTDelay = RTD_fwd + RTD_rev
Note that when OP is located at host A or host B, one of the terms Note that when the OP is located at host A or host B, one of the
composing RTDelay will be zero or negligible. terms composing RTDelay will be zero or negligible.
When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- Using the abbreviation HS to refer to the TCP handshake: when the
SYN-ACK, then RTD_fwd == RTD_HS_fwd. Qualified and Corresponding Packets are a TCP-SYN and a TCP-SYN-ACK,
RTD_fwd == RTD_HS_fwd.
When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a
TCP-ACK, then RTD_rev == RTD_HS_rev. TCP-ACK, RTD_rev == RTD_HS_rev.
The REQUIRED Composition Function for a singleton of Round-trip Delay The REQUIRED Composition Function for a singleton of round-trip delay
for the connection Hand Shake: for the connection handshake is:
RTDelay_HS = RTD_HS_fwd + RTD_HS_rev RTDelay_HS = RTD_HS_fwd + RTD_HS_rev
The definition of Round-trip Loss Count uses the nomenclature The definition of round-trip loss count uses the nomenclature
developed above, based on observation of the TCP header sequence developed above, based on observation of the TCP header sequence
numbers and storing the sequence number gaps observed. Packet Losses numbers and storing the sequence number gaps observed. Packet losses
can be inferred from: can be inferred from:
o Out-of-order segments: TCP segments are transmitted with Out-of-order segments: TCP segments are transmitted with
monotonically increasing sequence numbers, but these segments may monotonically increasing sequence numbers, but these segments may
be received out of order. Section 3 of [RFC4737] describes the be received out of order. Section 3 of [RFC4737] describes the
notion of "next expected" sequence numbers which can be adapted to notion of "next expected" sequence numbers, which can be adapted
TCP segments (for the purpose of detecting reordered packets). to TCP segments (for the purpose of detecting reordered packets).
Observation of out-of-order segments indicates loss on the path Observation of out-of-order segments indicates loss on the path
prior to the OP, and creates a gap. prior to the OP and creates a gap.
o Duplicate segments: Section 2 of [RFC5560] defines identical Duplicate segments: Section 2 of [RFC5560] defines identical packets
packets and is suitable for evaluation of TCP packets to detect and is suitable for evaluation of TCP packets to detect
duplication. Observation of duplicate segments *without a duplication. Observation of a segment duplicates a segment
corresponding gap* indicates loss on the path following the OP previously observed (and thus no corresponding observed segment
(because they overlap part of the delivered sequence numbers gap) indicates loss on the path following the OP (e.g., the
already observed at OP). segment overlaps part of the octet stream already observed at the
OP).
Each observation of an out-of-order or duplicate infers a singleton Each observation of an out-of-order or duplicate segment infers a
of loss, but composition of Round-trip Loss Counts will be conducted singleton of loss, but the composition of round-trip loss counts will
over a measurement interval which is synonymous with a single TCP be conducted over a measurement interval that is synonymous with a
connection. single TCP connection.
With the above observations in the Forward direction over a With the above observations in the Forward direction over a
measurement interval, the count of out-of-order and duplicate measurement interval, the count of out-of-order and duplicate
segments is defined as RTL_fwd. Comparable observations in the segments is defined as RTL_fwd. Comparable observations in the
Reverse direction are defined as RTL_rev. Reverse direction are defined as RTL_rev.
For a measurement interval (corresponding to a single TCP For a measurement interval (corresponding to a single TCP connection)
connection), T0 to Tf, the REQUIRED Composition Function for a the T0 to Tf, the REQUIRED Composition Function for the two single-
two single-direction counts of inferred loss is: direction counts of inferred loss is:
RTLoss = RTL_fwd + RTL_rev RTLoss = RTL_fwd + RTL_rev
10.2.2. Fixed Parameters 10.2.2. Fixed Parameters
Traffic Filters: Traffic Filters:
IPv4 header values:
DSCP: Set to 0
Protocol: Set to 06 (TCP)
o IPv4 header values: IPv6 header values:
DSCP: Set to 0
* DSCP: set to 0 Hop Count: Set to 255
Next Header: Set to 6 (TCP)
* Protocol: Set to 06 (TCP) Flow Label: Set to 0
Extension Headers: None
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Next Header: set to 6 (TCP)
* Flow Label: set to zero
* Extension Headers: none
o TCP header values:
* Flags: ACK, SYN, FIN, set as required
* Timestamp Option (TSopt): Set
+ Section 3.2 of [RFC7323] TCP header values:
Flags: ACK, SYN, FIN, set as required
Timestamps Option (TSopt): Set. See Section 3.2 of [RFC7323]
10.3. Method of Measurement 10.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous method for implementations.
10.3.1. Reference Methods 10.3.1. Reference Methods
The foundation methodology for this metric is defined in Section 4 of The foundational methodology for this metric is defined in Section 4
[RFC7323] using the Timestamp Option with modifications that allow of [RFC7323] using the Timestamps option with modifications that
application at a mid-path Observation Point (OP) [RFC7011]. Further allow application at a mid-path OP [RFC7011]. Further details and
details and applicable heuristics were derived from [Strowes] and applicable heuristics were derived from [Strowes] and [Trammell-14].
[Trammell-14].
The Traffic Filter at the OP is configured to observe a single TCP The Traffic Filter at the OP is configured to observe a single TCP
connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers connection. When the SYN/SYN-ACK/ACK handshake occurs, it offers the
the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK
pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton
of RTDelay as RTDelay_HS (composed using the forward and reverse of RTDelay as RTDelay_HS (composed using the Forward and Reverse
measurement pair). RTDelay_HS SHALL be treated separately from other measurement pair). RTDelay_HS SHALL be treated separately from other
RTDelays on data-bearing packets and their ACKs. The RTDelay_HS RTDelays on data-bearing packets and their ACKs. The RTDelay_HS
value MAY be used as a sanity check on other Composed values of value MAY be used as a consistency check on the composed values of
RTDelay. RTDelay for payload-bearing packets.
For payload bearing packets, the OP measures the time interval For payload-bearing packets, the OP measures the time interval
between observation of a packet with Sequence Number s, and the between observation of a packet with sequence number "s" and the
corresponding ACK with same Sequence number. When the payload is corresponding ACK with the same sequence number. When the payload is
transferred from host A to host B, the observed interval is RTD_fwd. transferred from host A to host B, the observed interval is RTD_fwd.
For payload-bearing packets, each observation of an out-of-order or
duplicate segment infers a loss count, but the composition of round-
trip loss counts will be conducted over a measurement interval that
is synonymous with a single TCP connection.
Because many data transfers are unidirectional (say, in the Forward Because many data transfers are unidirectional (say, in the Forward
direction from host A to host B), it is necessary to use pure ACK direction from host A to host B), it is necessary to use pure ACK
packets with Timestamp (TSval) and their Timestamp value echo to packets with Timestamp (TSval) and packets with the Timestamp value
perform a RTD_rev measurement. The time interval between observation echo to perform a RTD_rev measurement. The time interval between
of the ACK from B to A, and the corresponding packet with Timestamp observation of the ACK from B to A, and the Corresponding Packet with
echo (TSecr) is the RTD_rev. a Timestamp Echo Reply (TSecr) field [RFC7323], is the RTD_rev.
Delay Measurement Filtering Heuristics: Delay Measurement Filtering Heuristics:
If Data payloads were transferred in both Forward and Reverse * If data payloads were transferred in both Forward and Reverse
directions, then the Round-Trip Time Measurement Rule in Section 4.1 directions, then the Round-Trip Time Measurement rule in
of [RFC7323] could be applied. This rule essentially excludes any Section 4.1 of [RFC7323] could be applied. This rule essentially
measurement using a packet unless it makes progress in the transfer excludes any measurement using a packet unless it makes progress
(advances the left edge of the send window, consistent with in the transfer (advances the left edge of the send window,
[Strowes]). consistent with [Strowes]).
A different heuristic from [Trammell-14] is to exclude any RTD_rev * A different heuristic from [Trammell-14] is to exclude any RTD_rev
that is larger than previously observed values. This would tend to that is larger than previously observed values. This would tend
exclude Reverse measurements taken when the Application has no data to exclude Reverse measurements taken when the application has no
ready to send, because considerable time could be added to RTD_rev data ready to send, because considerable time could be added to
from this source of error. RTD_rev from this source of error.
Note that the above Heuristic assumes that host A is sending data. * Note that the above heuristic assumes that host A is sending data.
Host A expecting a download would mean that this heuristic should be Host A expecting a download would mean that this heuristic should
applied to RTD_fwd. be applied to RTD_fwd.
The statistic calculations to summarize the delay (RTDelay) SHALL be * The statistic calculations to summarize the delay (RTDelay) SHALL
performed on the conditional distribution, conditioned on successful be performed on the conditional distribution, conditioned on
Forward and Reverse measurements which follow the Heuristics. successful Forward and Reverse measurements that follow the
heuristics.
Method for Inferring Loss: Method for Inferring Loss:
The OP tracks sequence numbers and stores gaps for each direction of * The OP tracks sequence numbers and stores gaps for each direction
transmission, as well as the next-expected sequence number as in of transmission, as well as the next expected sequence number as
[Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order discussed in [Trammell-14] and [RFC4737]. Loss is inferred from
segments and Duplicate segments. out-of-order segments and duplicate segments.
Loss Measurement Filtering Heuristics: Loss Measurement Filtering Heuristics:
[Trammell-14] adds a window of evaluation based on the RTDelay. * [Trammell-14] adds a window of evaluation based on the RTDelay.
Distinguish Re-ordered from OOO due to loss, because sequence number * Distinguish reordered packets from out-of-order segments due to
gap is filled during the same RTDelay window. Segments detected as loss, because the sequence number gap is filled during the same
re-ordered according to [RFC4737] MUST reduce the Loss Count inferred RTDelay window. Segments detected as reordered according to
from Out-of-order segments. [RFC4737] MUST reduce the loss count inferred from out-of-order
segments.
Spurious (unneeded) retransmissions (observed as duplicates) can also * Spurious (unneeded) retransmissions (observed as duplicates) can
be reduced this way, as described in [Trammell-14]. also be reduced in this way, as described in [Trammell-14].
Sources of Error: Sources of Error:
The principal source of RTDelay error is the host processing time to * The principal source of RTDelay error is the host processing time
return a packet that defines the termination of a time interval. The to return a packet that defines the termination of a time
heuristics above intend to mitigate these errors by excluding interval. The heuristics above intend to mitigate these errors by
measurements where host processing time is a significant part of excluding measurements where host processing time is a significant
RTD_fwd or RTD_rev. part of RTD_fwd or RTD_rev.
A key source of RTLoss error is observation loss, described in * A key source of RTLoss error is observation loss, as described in
section 3 of [Trammell-14]. Section 3 of [Trammell-14].
10.3.2. Packet Stream Generation 10.3.2. Packet Stream Generation
NA N/A
10.3.3. Traffic Filtering (observation) Details 10.3.3. Traffic Filtering (Observation) Details
The Fixed Parameters above give a portion of the Traffic Filter. The Fixed Parameters above give a portion of the Traffic Filter.
Other aspects will be supplied as Run-time Parameters (below). Other aspects will be supplied as Runtime Parameters (below).
10.3.4. Sampling Distribution 10.3.4. Sampling Distribution
This metric requires a complete sample of all packets that qualify This metric requires a complete sample of all packets that qualify
according to the Traffic Filter criteria. according to the Traffic Filter criteria.
10.3.5. Run-time Parameters and Data Format 10.3.5. Runtime Parameters and Data Format
Run-time Parameters are input factors that must be determined, Runtime Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
for the context to be complete. for the context to be complete.
Src the IP address of the host in the host A Role (format ipv4- Src: The IP address of the host in the host A Role (format
address-no-zone value for IPv4, or ipv6-address-no-zone value for ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
IPv6, see Section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
Dst the IP address of the host in the host B (format ipv4-address- Dst: The IP address of the host in the host B Role (format
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value
see section 4 of [RFC6991]) for IPv6; see Section 4 of [RFC6991]).
T0 a time, the start of a measurement interval, (format "date-and- T0: A time, the start of a measurement interval (format "date-time"
time" as specified in Section 5.6 of [RFC3339], see also Section 3 as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
of [RFC6991]). The UTC Time Zone is required by Section 6.1 of in Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. When T0 is "all-zeros", a start time is unspecified Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
and Td is to be interpreted as the Duration of the measurement unspecified and Tf is to be interpreted as the duration of the
interval. The start time is controlled through other means. measurement interval. The start time is controlled through other
means.
Td Optionally, the end of a measurement interval, (format "date-and- Tf: Optionally, the end of a measurement interval (format
time" as specified in Section 5.6 of [RFC3339], see also Section 3 "date-time" as specified in Section 5.6 of [RFC3339]; see also
of [RFC6991]), or the duration (see T0). The UTC Time Zone is "date-and-time" in Section 3 of [RFC6991]), or the duration (see
required by Section 6.1 of [RFC2330]. Alternatively, the end of T0). The UTC Time Zone is required by Section 6.1 of [RFC2330].
the measurement interval MAY be controlled by the measured Alternatively, the end of the measurement interval MAY be
connection, where the second pair of FIN and ACK packets exchanged controlled by the measured connection, where the second pair of
between host A and B effectively ends the interval. FIN and ACK packets exchanged between host A and host B
effectively ends the interval.
TTL or Hop Limit Set at desired value. TTL or Hop Limit: Set at desired value.
10.3.6. Roles 10.3.6. Roles
host A launches the SYN packet to open the connection, and host A: Launches the SYN packet to open the connection. The Role of
synonymous with an IP address. "host A" is synonymous with the IP address used at host A.
host B replies with the SYN-ACK packet to open the connection, and host B: Replies with the SYN-ACK packet to open the connection. The
synonymous with an IP address. Role of "host B" is synonymous with the IP address used at host B.
10.4. Output 10.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the output of measurements
using the metric. using the metric.
10.4.1. Type 10.4.1. Type
See subsection titles in Reference Definition for RTDelay Types. RTDelay Types are discussed in the subsections below.
For RTLoss -- the count of lost packets. For RTLoss: The count of lost packets.
10.4.2. Reference Definition 10.4.2. Reference Definition
For all output types --- For all output types:
T0 the start of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of
[RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as T0: The start of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
[RFC6991]). The UTC Time Zone is required by Section 6.1 of Section 3 of [RFC6991]). The UTC Time Zone is required by
[RFC2330]. The end of the measurement interval MAY be controlled Section 6.1 of [RFC2330].
by the measured connection, where the second pair of FIN and ACK
packets exchanged between host A and B effectively ends the
interval.
... ... Tf: The end of a measurement interval (format "date-time" as
specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. The end of the measurement interval MAY
be controlled by the measured connection, where the second pair of
FIN and ACK packets exchanged between host A and host B
effectively ends the interval.
For RTDelay_HS -- the Round trip delay of the Handshake. RTDelay_Passive_IP-TCP-HS: The round-trip delay of the handshake is
a Singleton.
For RTLoss -- the count of lost packets. RTLoss: The count of lost packets.
For each <statistic>, one of the following sub-sections apply: For each <statistic>, Singleton, or Loss Count, one of the following
subsections applies.
10.4.2.1. Mean 10.4.2.1. Mean
The mean SHALL be calculated using the conditional distribution of The mean SHALL be calculated using the conditional distribution of
all packets with a finite value of Round-trip delay (undefined delays all packets with a finite value of round-trip delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.2.2 of [RFC6049] for details on calculating this See Section 4.2.2 of [RFC6049] for details on calculating this
statistic, and 4.2.3 of [RFC6049]. statistic; see also Section 4.2.3 of [RFC6049].
Mean The time value of the result is expressed in units of seconds, Mean: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
10.4.2.2. Min 10.4.2.2. Min
The minimum SHALL be calculated using the conditional distribution of The minimum SHALL be calculated using the conditional distribution of
all packets with a finite value of Round-trip delay (undefined delays all packets with a finite value of round-trip delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for details on calculating this See Section 4.3.2 of [RFC6049] for details on calculating this
statistic, and 4.3.3 of [RFC6049]. statistic; see also Section 4.3.3 of [RFC6049].
Min The time value of the result is expressed in units of seconds, Min: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
10.4.2.3. Max 10.4.2.3. Max
The maximum SHALL be calculated using the conditional distribution of The maximum SHALL be calculated using the conditional distribution of
all packets with a finite value of Round-trip delay (undefined delays all packets with a finite value of round-trip delay (undefined delays
are excluded), a single value as follows: are excluded) -- a single value, as follows:
See section 4.1 of [RFC3393] for details on the conditional See Section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and see Section 5
[RFC6703] for background on this analysis choice. of [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See Section 4.3.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic; see also Section 4.3.3 of [RFC6049]. The
as follows: formula is as follows:
Max = (FiniteDelay [j]) Max = (FiniteDelay[j])
such that for some index, j, where 1 <= j <= N such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n FiniteDelay[j] >= FiniteDelay[n] for all n
Max The time value of the result is expressed in units of seconds, Max: The time value of the result is expressed in units of seconds,
as a positive value of type decimal64 with fraction digits = 9 as a positive value of type decimal64 with fraction digits = 9
(see section 9.3 of [RFC6020]) with resolution of 0.000000001 (see Section 9.3 of [RFC6020]) with a resolution of
seconds (1.0 ns), and with lossless conversion to/from the 64-bit 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per Section 6 of [RFC5905].
10.4.2.4. Singleton
The singleton SHALL be calculated using the successful RTD_fwd (on
the SYN to SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair),
see Section 10.3.1.
The singleton time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction digits =
9 (see Section 9.3 of [RFC6020]) with resolution of 0.000000001
seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP
timestamp as per Section 6 of [RFC5905].
10.4.2.5. Loss Counts
RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count: The count of lost
packets.
Observation of an out-of-order segment or duplicate segment infers a
loss count, after application of the Definitions of Section 10.2.1
and the Loss Measurement Filtering Heuristics of Section 10.3.1. The
composition of round-trip loss counts will be conducted over a
measurement interval that is synonymous with a single TCP connection.
For a measurement interval (corresponding to a single TCP connection)
T0 to Tf, the REQUIRED Composition Function for the two single-
direction counts of inferred loss is:
RTLoss = RTL_fwd + RTL_rev
Packet count: The numeric value of the result is expressed in units
of lost packets, as a positive value of type uint64 (represents
integer values between 0 and 18446744073709551615, inclusively
(see Section 9.2 of [RFC6020]).
10.4.3. Metric Units 10.4.3. Metric Units
The <statistic> of Round-trip Delay is expressed in seconds, where The <statistic> of round-trip delay is expressed in seconds, where
<statistic> is one of: <statistic> is one of:
o Mean * Mean
o Min * Min
o Max * Max
The Round-trip Delay of the Hand Shake is expressed in seconds. The round-trip delay of the TCP handshake singleton is expressed in
seconds.
The Round-trip Loss Count is expressed as a number of packets. The round-trip loss count is expressed as a number of packets.
10.4.4. Calibration 10.4.4. Calibration
Passive measurements at an OP could be calibrated against an active Passive Measurements at an OP could be calibrated against an Active
measurement (with loss emulation) at host A or B, where the active Measurement (with loss emulation) at host A or host B, where the
measurement represents the ground-truth. Active Measurement represents the ground truth.
10.5. Administrative items 10.5. Administrative Items
10.5.1. Status 10.5.1. Status
Current Current
10.5.2. Requester 10.5.2. Requester
This RFC number RFC 8912
10.5.3. Revision 10.5.3. Revision
1.0 1.0
10.5.4. Revision Date 10.5.4. Revision Date
YYYY-MM-DD 2021-11-17
10.6. Comments and Remarks 10.6. Comments and Remarks
None. None
11. Security Considerations 11. Security Considerations
These registry entries represent no known implications for Internet These Registry Entries represent no known implications for Internet
Security. Each RFC referenced above contains a Security security. With the exception of [RFC1035], each RFC referenced above
Considerations section. Further, the LMAP Framework [RFC7594] contains a Security Considerations section. Further, the Large-scale
Measurement of Broadband Performance (LMAP) framework [RFC7594]
provides both security and privacy considerations for measurements. provides both security and privacy considerations for measurements.
There are potential privacy considerations for observed traffic, There are potential privacy considerations for observed traffic,
particularly for passive metrics in section 10. An attacker that particularly for Passive Metrics as discussed in Section 10. An
knows that its TCP connection is being measured can modify its attacker that knows that its TCP connection is being measured can
behavior to skew the measurement results. modify its behavior to skew the measurement results.
12. IANA Considerations 12. IANA Considerations
IANA is requested to populate The Performance Metrics Registry IANA has populated the Performance Metrics Registry defined in
defined in [I-D.ietf-ippm-metric-registry] with the values defined in [RFC8911] with the values defined in Sections 4 through 10.
sections 4 through 10.
See the IANA Considerations section of See the IANA Considerations section of [RFC8911] for additional
[I-D.ietf-ippm-metric-registry] for additional requests and
considerations. considerations.
13. Acknowledgements 13. References
The authors thank Brian Trammell for suggesting the term "Run-time
Parameters", which led to the distinction between run-time and fixed
parameters implemented in this memo, for identifying the IPFIX metric
with Flow Key as an example, for suggesting the Passive TCP RTD
metric and supporting references, and for many other productive
suggestions. Thanks to Peter Koch, who provided several useful
suggestions for disambiguating successive DNS Queries in the DNS
Response time metric.
The authors also acknowledge the constructive reviews and helpful
suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey,
Yaakov Stein, and participants in the LMAP working group. Thanks to
Michelle Cotton for her early IANA reviews, and to Amanda Barber for
answering questions related to the presentation of the registry and
accessibility of the complete template via URL.
14. References
14.1. Normative References
[I-D.ietf-ippm-metric-registry] 13.1. Normative References
Bagnulo, M., Claise, B., Eardley, P., and A. Morton,
"Registry for Performance Metrics", Internet Draft (work
in progress) draft-ietf-ippm-metric-registry, 2019.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 77, line 24 skipping to change at line 3655
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, [RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Communications of the ACM, Vol. 56 No. 10, Pages 57-64", Akhter, "Registry for Performance Metrics", RFC 8911,
September 2013. DOI 10.17487/RFC8911, November 2021,
<https://www.rfc-editor.org/info/rfc8911>.
[Strowes] Strowes, S., "Passively Measuring TCP Round-Trip Times",
Communications of the ACM, Vol. 56 No. 10, Pages 57-64,
DOI 10.1145/2507771.2507781, October 2013,
<https://dl.acm.org/doi/10.1145/2507771.2507781>.
[Trammell-14] [Trammell-14]
Trammell, B., "Inline Data Integrity Signals for Passive Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data
Measurement, In: Dainotti A., Mahanti A., Uhlig S. (eds) Integrity Signals for Passive Measurement", In: Dainotti
Traffic Monitoring and Analysis. TMA 2014. Lecture Notes A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and
in Computer Science, vol 8406. Springer, Berlin, Analysis. TMA 2014. Lecture Notes in Computer Science,
Heidelberg https://link.springer.com/ vol 8406. Springer, Berlin, Heidelberg,
chapter/10.1007/978-3-642-54999-1_2", March 2014. DOI 10.1007/978-3-642-54999-1_2, March 2014,
<https://link.springer.com/
chapter/10.1007/978-3-642-54999-1_2>.
14.2. Informative References 13.2. Informative References
[RFC1242] Bradner, S., "Benchmarking Terminology for Network [RFC1242] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
July 1991, <https://www.rfc-editor.org/info/rfc1242>. July 1991, <https://www.rfc-editor.org/info/rfc1242>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011, DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>. <https://www.rfc-editor.org/info/rfc6390>.
skipping to change at page 78, line 11 skipping to change at line 3697
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, DOI 10.17487/RFC6703, August 2012, RFC 6703, DOI 10.17487/RFC6703, August 2012,
<https://www.rfc-editor.org/info/rfc6703>. <https://www.rfc-editor.org/info/rfc6703>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgments
The authors thank Brian Trammell for suggesting the term "Runtime
Parameters", which led to the distinction between Runtime and Fixed
Parameters implemented in this memo, for identifying the IP Flow
Information Export (IPFIX) metric with Flow Key as an example, for
suggesting the Passive TCP RTD Metric and supporting references, and
for many other productive suggestions. Thanks to Peter Koch, who
provided several useful suggestions for disambiguating successive DNS
queries in the DNS Response time metric.
The authors also acknowledge the constructive reviews and helpful
suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey,
Yaakov Stein, and participants in the LMAP Working Group. Thanks to
Michelle Cotton for her early IANA reviews, and to Amanda Baber for
answering questions related to the presentation of the Registry and
accessibility of the complete template via URL.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown, NJ 07748
USA United States of America
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Universidad Carlos III de Madrid
Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 28911 Leganes Madrid
SPAIN Spain
Phone: 34 91 6249500 Phone: 34 91 6249500
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es URI: http://www.it.uc3m.es
Philip Eardley Philip Eardley
BT BT
Adastral Park, Martlesham Heath Adastral Park, Martlesham Heath
Ipswich Ipswich
ENGLAND United Kingdom
Email: philip.eardley@bt.com Email: philip.eardley@bt.com
Kevin D'Souza Kevin D'Souza
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown, NJ 07748
USA United States of America
Phone: +1 732 420 xxxx Phone: +1 732 420 2514
Email: kld@att.com Email: kld@att.com
 End of changes. 737 change blocks. 
2013 lines changed or deleted 2105 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/