draft-ietf-ippm-initial-registry-02.txt   draft-ietf-ippm-initial-registry-03.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: May 2, 2017 UC3M Expires: September 10, 2017 UC3M
P. Eardley P. Eardley
BT BT
K. D'Souza K. D'Souza
AT&T Labs AT&T Labs
October 29, 2016 March 9, 2017
Initial Performance Metric Registry Entries Initial Performance Metric Registry Entries
draft-ietf-ippm-initial-registry-02 draft-ietf-ippm-initial-registry-03
Abstract Abstract
This memo defines the Initial Entries for the Performance Metrics This memo defines the Initial Entries for the Performance Metrics
Registry. This version includes: Registry. This version includes:
* All section 4 and 5 parameters reference YANG types for alternate * All section 4, 5, 6, 7, and 8 parameters reference YANG types for
data formats. alternate data formats.
* implementation of standard naming format for parameters. * implementation of standard naming format for parameters.
Still need: * revisions that follow section 4 changes in proposed * implementation of many IANA early-review comments.
metrics defined in sections 6, 7, 8.
Still need: Add MBM metric entry.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2017. This Internet-Draft will expire on September 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9
4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9
4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9
4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9
4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10
4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11
4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11
4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12
4.3.3. Traffic Filtering (observation) Details . . . . . . . 12 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13
4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13
4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13
4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 15
4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15
4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15
4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16
4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16
4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16
4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16
4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16
4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16
5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 17
5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17
5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17
5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17
5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17
5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18
5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19
5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19
5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 20 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 20
5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 5.3.3. Traffic Filtering (observation) Details . . . . . . . 21
5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 21
5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 21
5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4.2. Reference Definition . . . . . . . . . . . . . . . . 22 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 22
5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23
5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23
5.5. Administrative items . . . . . . . . . . . . . . . . . . 24 5.5. Administrative items . . . . . . . . . . . . . . . . . . 24
5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24
5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 24 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 24
5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 47 skipping to change at page 3, line 47
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24
6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 25 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 25
6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 25 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 25
6.1.6. Version (of Registry Format) . . . . . . . . . . . . 25 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 25
6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 25 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 25
6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25
6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 26 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 26
6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 28
6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 28
6.3.2. Packet Generation Stream . . . . . . . . . . . . . . 28 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 29
6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 6.3.3. Traffic Filtering (observation) Details . . . . . . . 30
6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 30
6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 30
6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. Type/Value (two diff terms used) . . . . . . . . . . 30 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 32
6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 32
6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 32 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 32
6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 6.5. Administrative items . . . . . . . . . . . . . . . . . . 33
6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 32 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 33
6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 33
6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 33
6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 33
7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 32 7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 33
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 34
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 34
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 34
7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 33 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 35
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 33 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 35
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 34 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35
7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 35 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 35 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36
7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 35 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 37
7.3.3. Traffic Filtering (observation) Details . . . . . . . 36 7.3.3. Traffic Filtering (observation) Details . . . . . . . 38
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 36 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 38
7.3.5. Run-time Parameters and Data Format . . . . . . . . . 36 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 38
7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 37 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 39
7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.1. Type/Value (two diff terms used) . . . . . . . . . . 37 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 37 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 39
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 39 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 42
7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 39 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 42
7.5. Administrative items . . . . . . . . . . . . . . . . . . 39 7.5. Administrative items . . . . . . . . . . . . . . . . . . 43
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 39 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 43
7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 40 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 43
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 40 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 43
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 40 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 40 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43
8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 40 8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 43
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 40 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 44
8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 41 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 41 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 45
8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 41 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 45
8.2.1. Reference Definition . . . . . . . . . . . . . . . . 41 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 45
8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 42 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 46
8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 42 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 47
8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 43 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 47
8.3.2. Packet Generation Stream . . . . . . . . . . . . . . 43 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 48
8.3.3. Traffic Filtering (observation) Details . . . . . . . 43 8.3.3. Traffic Filtering (observation) Details . . . . . . . 48
8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 44 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48
8.3.5. Run-time Parameters and Data Format . . . . . . . . . 44 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48
8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 44 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.1. Type/Value (two diff terms used) . . . . . . . . . . 45 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 45 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49
8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 47 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52
8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 47 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52
8.5. Administrative items . . . . . . . . . . . . . . . . . . 47 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53
8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 47 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 47 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 53
8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 47 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53
8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 48 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53
8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 48 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53
9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 48 9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 54
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 48 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54
9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 48 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54
9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 48 9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 54
9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 48 9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 54
9.1.7. Version (of Registry Format) . . . . . . . . . . . . 48 9.1.7. Version (of Registry Format) . . . . . . . . . . . . 54
9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 49 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 54
9.2.1. Reference Definition . . . . . . . . . . . . . . . . 49 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55
9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 49 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55
9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 49 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 55
9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 49 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 55
9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 49 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 55
9.3.3. Traffic Filtering (observation) Details . . . . . . . 49 9.3.3. Traffic Filtering (observation) Details . . . . . . . 55
9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 49 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 55
9.3.5. Run-time Parameters and Data Format . . . . . . . . . 50 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 55
9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 50 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 50 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 50 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 56
9.4.2. Reference Definition . . . . . . . . . . . . . . . . 50 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 56
9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 50 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56
9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 50 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56
9.5. Administrative items . . . . . . . . . . . . . . . . . . 50 9.5. Administrative items . . . . . . . . . . . . . . . . . . 56
9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 50 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 56
9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 50 9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 56
9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 50 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 56
9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 51 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 56
9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 51 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 56
10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 51 10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 57
10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 51 10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 57
10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 51 10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 57
10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 51 10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 57
10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 51 10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 57
10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 51 10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 57
10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 52 10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 57
10.1.8. Description . . . . . . . . . . . . . . . . . . . . 52 10.1.8. Description . . . . . . . . . . . . . . . . . . . . 57
10.1.9. Reference Specification(s) . . . . . . . . . . . . . 52 10.1.9. Reference Specification(s) . . . . . . . . . . . . . 58
10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 52 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 58
10.2.1. Reference Definition . . . . . . . . . . . . . . . . 52 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 58
10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 52 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 58
10.3. Method of Measurement . . . . . . . . . . . . . . . . . 53 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 59
10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 53 10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 59
10.3.2. Stream Type and Stream Parameters . . . . . . . . . 53 10.3.2. Stream Type and Stream Parameters . . . . . . . . . 59
10.3.3. Output Type and Data Format . . . . . . . . . . . . 53 10.3.3. Output Type and Data Format . . . . . . . . . . . . 59
10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 54 10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 59
10.3.5. Run-time Parameters and Data Format . . . . . . . . 54 10.3.5. Run-time Parameters and Data Format . . . . . . . . 60
10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 55 10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 61
11. Revision History . . . . . . . . . . . . . . . . . . . . . . 56 11. Revision History . . . . . . . . . . . . . . . . . . . . . . 61
12. Security Considerations . . . . . . . . . . . . . . . . . . . 56 12. Security Considerations . . . . . . . . . . . . . . . . . . . 62
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
15.1. Normative References . . . . . . . . . . . . . . . . . . 57 15.1. Normative References . . . . . . . . . . . . . . . . . . 63
15.2. Informative References . . . . . . . . . . . . . . . . . 59 15.2. Informative References . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
Note: Efforts to synchronize structure and terminology with Note: Efforts to synchronize structure and terminology with
[I-D.ietf-ippm-metric-registry] will likely be incomplete until both [I-D.ietf-ippm-metric-registry] will likely be incomplete until both
drafts are stable. drafts are stable.
This memo proposes an initial set of entries for the Performance This memo proposes an initial set of entries for the Performance
Metric Registry. It uses terms and definitions from the IPPM Metric Registry. It uses terms and definitions from the IPPM
literature, primarily [RFC2330]. Proponents of Passive Performance literature, primarily [RFC2330]. Proponents of Passive Performance
skipping to change at page 8, line 43 skipping to change at page 8, line 43
-------------------- --------------------
4. UDP Round-trip Latency Registry Entry 4. UDP Round-trip Latency Registry Entry
This section gives an initial registry entry for the UDP Round-trip This section gives an initial registry entry for the UDP Round-trip
Latency. Latency.
Note: Each Registry entry only produces a "raw" output or a Note: Each Registry entry only produces a "raw" output or a
statistical summary. To describe both "raw" and one or more statistical summary. To describe both "raw" and one or more
statistics efficiently, the Identifier, Name, and Output Categories statistics efficiently, the Identifier, Name, and Output Categories
can be split and this section can become two or more closely-related can be split and a single section can specify two or more closely-
metrics. See Section 7 for an example specifying multiple Registry related metrics. See Section 7 for an example specifying multiple
entries with many common columns. Registry entries with many common columns.
4.1. Summary 4.1. Summary
This category includes multiple indexes to the registry entry: the This category includes multiple indexes to the registry entry: the
element ID and metric name. element ID and metric name.
4.1.1. ID (Identifier) 4.1.1. ID (Identifier)
<insert a numeric identifier, an integer, TBD> <insert a numeric identifier, an integer, TBD>
4.1.2. Name 4.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile
4.1.3. URIs 4.1.3. URIs
URN: Prefix urn:ietf:params:performance:metric:<name> URN: Prefix urn:ietf:metrics:perf:<name>
URL: http://<TBD by IANA>/<name> URL: http://<TBD by IANA>/<name>
4.1.4. Description 4.1.4. Description
This metric assesses the delay of a stream of packets exchanged This metric assesses the delay of a stream of packets exchanged
between two hosts (which are the two measurement points), and the between two hosts (which are the two measurement points), and the
Output is the Round-trip delay for all successfully exchanged packets Output is the Round-trip delay for all successfully exchanged packets
expressed as the 95th percentile of their conditional delay expressed as the 95th percentile of their conditional delay
distribution. distribution.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
[RFC2681] [RFC2681]
<specific section reference and additional clarifications, if needed> <specific section reference and additional clarifications, if needed>
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 sample
are defined in Section 11 of [RFC2330]. are defined in Section 11 of [RFC2330].
Note that although the definition of "Round-trip-Delay between Src Note that although the [RFC2681] definition of "Round-trip-Delay
and Dst" is directionally ambiguous in the text, this metric tightens between Src and Dst" is directionally ambiguous in the text, this
the definition further to recognize that the host in the "Src" role metric tightens the definition further to recognize that the host in
will send the first packet to "Dst", and ultimately receive the the "Src" role will send the first packet to "Dst", and ultimately
corresponding return packet from "Dst" (when neither are lost). receive the corresponding return packet from "Dst" (when neither are
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 to
the value of Round-trip delay in metric definitions and methods. The the value of Round-trip delay in metric definitions and methods. The
variable "dT" has been re-used in other IPPM literature to refer to variable "dT" has been re-used in other IPPM literature to refer to
different quantities, and cannot be used as a global variable name. different quantities, and cannot be used as a global variable name.
4.2.2. Fixed Parameters 4.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be <list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when determined and embedded in the measurement system for use when
skipping to change at page 10, line 47 skipping to change at page 10, line 48
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o UDP header values: o UDP header values:
* Checksum: the checksum MUST be calculated * Checksum: the checksum MUST be calculated and included in the
header
o UDP Payload o UDP Payload
* total of 9 bytes * total of 9 bytes
Other measurement parameters: Other measurement parameters:
o Tmax: a loss threshold waiting time o Tmax: a loss threshold waiting time
* 3.0, expressed in units of seconds, as a positive value of type * 3.0, expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 5 (see section 9.3 of decimal64 with fraction digits = 5 (see section 9.3 of
[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with
lossless conversion to/from the 32-bit NTP timestamp as per lossless conversion to/from the 32-bit NTP timestamp as per
skipping to change at page 15, line 35 skipping to change at page 15, line 42
<insert units for the measured results, and the reference <insert units for the measured results, and the reference
specification>. specification>.
The 95th Percentile of Round-trip Delay is expressed in seconds. The 95th Percentile of Round-trip Delay is expressed in seconds.
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. In-situ
calibration could be enabled with an internal loopback that includes calibration could be enabled with an internal loopback at the Source
as much of the measurement system as possible, performs address host that includes as much of the measurement system as possible,
manipulation as needed, and provides some form of isolation (e.g., performs address manipulation as needed, and provides some form of
deterministic delay) to avoid send-receive interface contention. isolation (e.g., deterministic delay) to avoid send-receive interface
Some portion of the random and systematic error can be characterized contention. Some portion of the random and systematic error can be
this way. characterized 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 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 which is the result of system
skipping to change at page 17, line 7 skipping to change at page 17, line 17
<insert numeric identifier, an integer> <insert numeric identifier, an integer>
5.1.2. Name 5.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile
5.1.3. URIs 5.1.3. URIs
URI: Prefix urn:ietf:metric:<name> URI: Prefix urn:ietf:metrics:perf:<name>
URL: http://<TBD by IANA>/<name> URL: http://<TBD by IANA>/<name>
5.1.4. Description 5.1.4. Description
An assessment of packet delay variation with respect to the minimum An assessment of packet delay variation with respect to the minimum
delay observed on the stream, and the Output is expressed as the 95th delay observed on the stream, and the Output is expressed as the 95th
percentile of the packet delay variation distribution. percentile of the packet delay variation distribution.
5.1.5. Change Controller 5.1.5. Change Controller
<org or person > <org or person >
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.
skipping to change at page 18, line 32 skipping to change at page 18, line 43
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o UDP header values: o UDP header values:
* Checksum: the checksum MUST be calculated * Checksum: the checksum MUST be calculated and included in the
header
o UDP Payload o UDP Payload
* total of 200 bytes * total of 200 bytes
Other measurement parameters: Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in Tmax: a loss threshold waiting time with value 3.0, expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 5 (see section 9.3 of [RFC6020]) and with fraction digits = 5 (see section 9.3 of [RFC6020]) and with
resolution of 0.0001 seconds (0.1 ms), with lossless conversion resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 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 the
stream selected for the metric. See section 4.2 of [RFC5481] for stream selected for the metric. See section 4.2 of [RFC5481] for
the PDV form. the PDV form.
See the Packet Stream generation category for two additional Fixed
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 methods for implementations.
5.3.1. Reference Method 5.3.1. Reference Method
<for metric, insert relevant section references and supplemental <for metric, insert relevant section references and supplemental
info> info>
skipping to change at page 20, line 20 skipping to change at page 20, line 29
Poisson sampling intervals. the reciprocal of lambda is the average Poisson sampling intervals. the reciprocal of lambda is the average
packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/
lambda, in seconds. lambda, in seconds.
>>> Check with Sam, most likely it is this... >>> Check with Sam, most likely it is this...
Method 3 SHALL be used, where given a start time (Run-time Method 3 SHALL be used, where given a start time (Run-time
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 pseudo-random distribution of inter-
packet send times, (truncating the distribution as specified in the packet send times, (truncating the distribution as specified in the
Run-time Parameter, Trunc), and the Src sends each packet at the Parameter Trunc), and the Src sends each packet at the computed
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.
o lambda, a rate in reciprocal seconds (for Poisson Streams). Reciprocal_lambda average packet interval for Poisson Streams
lambda = 1 packet per second expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of
[RFC5905]. Reciprocal_lambda = 1 packet per second.
o Upper limit on Poisson distribution (values above this limit will Trunc Upper limit on Poisson distribution expressed in units of
be clipped and set to the limit value). Upper limit = 30 seconds. seconds, as a positive value of type decimal64 with fraction
digits = 5 (see section 9.3 of [RFC6020]) with resolution of
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
this limit will be clipped and set to the limit value). Trunc =
30.0000 seconds.
5.3.3. Traffic Filtering (observation) Details 5.3.3. Traffic Filtering (observation) Details
<insert the measured results based on a filtered version of the <insert the measured results based on a filtered version of the
packets observed, and this section provides the filter details (when packets observed, and this section provides the filter details (when
present), and section reference>. present), and section reference>.
NA NA
5.3.4. Sampling Distribution 5.3.4. Sampling Distribution
skipping to change at page 21, line 25 skipping to change at page 21, line 45
[RFC2330]. When T0 is "all-zeros", a start time is unspecified [RFC2330]. When T0 is "all-zeros", a start time is unspecified
and Tf is to be interpreted as the Duration of the measurement and Tf is to be interpreted as the Duration of the measurement
interval. The start time is controlled through other means. 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-and-time"
as specified in Section 5.6 of [RFC3339], see also Section 3 of 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 [RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and [RFC2330]. When T0 is "all-zeros", a end time date is ignored and
Tf is interpreted as the Duration of the measurement interval. Tf is interpreted as the Duration of the measurement interval.
Reciprocal_lambda average packet interval for Poisson Streams
expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of
[RFC5905].
Trunc Upper limit on Poisson distribution expressed in units of
seconds, as a positive value of type decimal64 with fraction
digits = 5 (see section 9.3 of [RFC6020]) with resolution of
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
this limit will be clipped and set to the limit value). (if fixed,
Trunc = 30.0000 seconds.)
>>> should Poisson run-time params be fixed instead? probably yes if
modeling a specific version of MBA tests.
5.3.6. Roles 5.3.6. Roles
<lists the names of the different roles from the measurement method> <lists the names of the different roles from the measurement method>
Src launches each packet to Dst. Src launches each packet to Dst.
Dst waits for each packet from Src. Dst waits for each packet from Src.
5.4. Output 5.4. Output
skipping to change at page 25, line 9 skipping to change at page 25, line 9
<skipping some admin columns for now> <skipping some admin columns for now>
6.1.1. ID (Identifier) 6.1.1. ID (Identifier)
<insert numeric identifier, an integer> <insert numeric identifier, an integer>
6.1.2. Name 6.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw
6.1.3. URI 6.1.3. URI
URI: Prefix urn:ietf:metric:<name> URI: Prefix urn:ietf:metrics:perf:<name>
URL: http://<TBD by IANA>/<name> URL: http://<TBD by IANA>/<name>
6.1.4. Description 6.1.4. Description
This metric assesses the response time, the interval from the query This metric assesses the response time, the interval from the query
transmission to the response. transmission to the response.
6.1.5. Change Controller 6.1.5. Change Controller
skipping to change at page 26, line 7 skipping to change at page 26, line 7
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, September 1999.
[RFC2681] [RFC2681]
<specific section reference and additional clarifications, if needed> <specific section reference and additional clarifications, if needed>
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-value sample. Note that terms such as singleton and sample are multi-singleton sample. Note that terms such as singleton and sample
defined in Section 11 of [RFC2330]. are defined in Section 11 of [RFC2330].
For DNS Response Latency, the entities in [RFC1035] must be mapped to For DNS Response Latency, the entities in [RFC1035] must be mapped to
[RFC2681]. The Local Host with its User Program and Resolver take [RFC2681]. The Local Host with its User Program and Resolver take
the role of "Src", and the Foreign Name Server takes the role of the role of "Src", and the Foreign Name Server takes the role of
"Dst". "Dst".
Note that although the definition of "Round-trip-Delay between Src Note that although the [RFC2681] definition of "Round-trip-Delay
and Dst at T" is directionally ambiguous in the text, this metric between Src and Dst at T" is directionally ambiguous in the text,
tightens the definition further to recognize that the host in the this metric tightens the definition further to recognize that the
"Src" role will send the first packet to "Dst", and ultimately host in the "Src" role will send the first packet to "Dst", and
receive the corresponding return packet from "Dst" (when neither are ultimately receive the corresponding return packet from "Dst" (when
lost). neither are lost).
6.2.2. Fixed Parameters 6.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be <list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when determined and embedded in the measurement system for use when
needed> needed>
Type-P: Type-P as defined in Section 13 of [RFC2330]:
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL set to 255 * TTL set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Protocol: Set to 17 (UDP)
o UDP header values: o UDP header values:
* Source port: 53 * Source port: 53
* Destination port: 53 * Destination port: 53
* Checksum: the checksum must be calculated and included in the
* Checksum: the checksum must be calculated header
o Payload: The payload contains a DNS message as defined in RFC 1035 o Payload: The payload contains a DNS message as defined in RFC 1035
[RFC1035] with the following values: [RFC1035] with the following values:
* The DNS header section contains: * The DNS header section contains:
+ Identification (see the Run-time column)
+ QR: set to 0 (Query) + QR: set to 0 (Query)
+ OPCODE: set to 0 (standard query) + OPCODE: set to 0 (standard query)
+ AA: not set + AA: not set
+ TC: not set + TC: not set
+ RD: set to one (recursion desired) + RD: set to one (recursion desired)
+ RA: not set + RA: not set
skipping to change at page 27, line 26 skipping to change at page 27, line 38
+ QDCOUNT: set to one (only one entry) + QDCOUNT: set to one (only one entry)
+ ANCOUNT: not set + ANCOUNT: not set
+ NSCOUNT: not set + NSCOUNT: not set
+ ARCOUNT: not set + ARCOUNT: not set
* The Question section contains: * The Question section contains:
+ QNAME: the FQDN provided as input for the test + QNAME: the Fully Qualified Domain Name (FQDN) provided as
input for the test, see the Run-time column
+ QTYPE: the query type provided as input for the test + QTYPE: the query type provided as input for the test, see
the Run-time column
+ QCLASS: set to IN + QCLASS: set to 1 for IN
* The other sections do not contain any Resource Records. * The other sections do not contain any Resource Records.
Other measurement parameters:
o Tmax: a loss threshold waiting time (and to help disambiguate
queries)
* 5.0, expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 5 (see section 9.3 of
[RFC6020]) and with 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.
Timeout: Tmax = 5 seconds (to help disambiguate queries)
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 methods for implementations.
6.3.1. Reference Method 6.3.1. Reference Method
<for metric, insert relevant section references and supplemental <for metric, insert relevant section references and supplemental
info> info>
The methodology for this metric is defined as Type-P-Round-trip- The methodology for this metric is defined as Type-P-Round-trip-
Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section
3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under
Fixed Parameters. Fixed Parameters.
The method requires sequence numbers or other send-order information The reference method distinguishes between long-delayed packets and
to be retained at the Src or included with each packet to dis- lost packets by implementing a maximum waiting time for packet
ambiguate packet reordering if it occurs. Sequence number is part of arrival. Tmax is the waiting time used as the threshold to declare a
the payload described under Fixed Parameters. packet lost. Lost packets SHALL be designated as having undefined
delay.
DNS Messages bearing Queries provide for random ID Numbers, so more The calculations on the delay (RTT) SHALL be performed on the
than one query may be launched while a previous request is conditional distribution, conditioned on successful packet arrival
outstanding when the ID Number is used. within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MAY enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis
choice.
The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving
reply. Therefore, sequence numbers or other send-order
identification MUST be retained at the Src or included with each
packet to dis-ambiguate packet reordering if it occurs. Sequence
number is part of the payload described under Fixed Parameters.
DNS Messages bearing Queries provide for random ID Numbers in the
Identification header field, so more than one query may be launched
while a previous request is outstanding when the ID Number is used.
IF a DNS response does not arrive within Tmax, the result is IF a DNS response does not arrive within Tmax, the result is
undefined. The Message ID SHALL be used to disambiguate the undefined. The Message ID SHALL be used to disambiguate the
successive queries. successive queries.
>>> This would require support of ID generation and population in the >>> This would require support of ID generation and population in the
Message. An alternative would be to use a random Source port on the Message. An alternative would be to use a random Source port on the
Query Message, but we would choose ONE before proceding. Query Message, but we would choose ONE before proceding.
Refer to Section 4.4 of [RFC6673] for expanded discussion of the Refer to Section 4.4 of [RFC6673] for 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 RFC 2681 [RFC2681]. Section 8 of
[RFC6673] presents additional requirements which shall be included in [RFC6673] presents additional requirements which shall be included in
the method of measurement for this metric. the method of measurement for this metric.
6.3.2. Packet Generation Stream In addition to operations described in [RFC2681], the Src MUST parse
the DNS headers of the reply and prepare the information for
subsequent reporting as a measured result, along with the Round-Trip
Delay.
6.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream, basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be dscribed by providing the list of stream and can easily be dscribed by providing the list of stream
parameters. parameters.
<list of generation parameters and section/spec references if needed> <list of generation parameters and section/spec references if needed>
Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to
generate Poisson sampling intervals. the reciprocal of lambda is the generate Poisson sampling intervals. The reciprocal of lambda is the
average packet rate, thus the Run-time Parameter is 1/lambda. average packet rate, thus the Run-time Parameter is Reciprocal_lambda
= 1/lambda, in seconds.
>>> Check with Sam, most likely it is this...
Method 3 is used, where given a start time (Run-time Parameter), the Method 3 is used, where given a start time (Run-time Parameter), the
subsequent send times are all computed prior to measurement by subsequent send times are all computed prior to measurement by
computing the pseudo-random distribution of inter-packet send times, computing the pseudo-random distribution of inter-packet send times,
(truncating the distribution as specified in the Run-time (truncating the distribution as specified in the Run-time
Parameters), and the Src sends each packet at the computed times. Parameters), and the Src sends each packet at the computed times.
Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead.
6.3.3. Traffic Filtering (observation) Details 6.3.3. Traffic Filtering (observation) Details
The measured results based on a filtered version of the packets The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when observed, and this section provides the filter details (when
present). present).
<section reference>. <section reference>.
NA NA
skipping to change at page 29, line 30 skipping to change at page 30, line 30
NA NA
6.3.5. Run-time Parameters and Data Format 6.3.5. Run-time Parameters and Data Format
Run-time Parameters are input factors that must be determined, Run-time 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.
<list of run-time parameters, and their data formats> <list of run-time parameters, and their data formats>
o Src, the IP address of a host (32-bit value for IPv4, 128-bit Src the IP address of the host in the Src Role (format ipv4-address-
value for IPv6) no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see Section 4 of [RFC6991])
o Dst, the IP address of a host (32-bit value for IPv4, 128-bit Dst the IP address of the host in the Dst Role (format ipv4-address-
value for IPv6) no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see section 4 of [RFC6991])
o T0, a time (start of measurement interval, 128-bit NTP Date T0 a time, the start of a measurement interval, (format "date-and-
Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a time" as specified in Section 5.6 of [RFC3339], see also Section 3
start time is unspecified and Tf is to be interpreted as the of [RFC6991]). The UTC Time Zone is required by Section 6.1 of
Duration of the measurement interval. [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.
o Tf, a time (end of measurement interval, 128-bit NTP Date Format, Tf a time, the end of a measurement interval, (format "date-and-time"
see section 6 of [RFC5905]), interpreted as the Duration of the as specified in Section 5.6 of [RFC3339], see also Section 3 of
measurement interval. [RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and
Tf is interpreted as the Duration of the measurement interval.
o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = Reciprocal_lambda average packet interval for Poisson Streams
0.1 packet per second, if fixed) expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of
[RFC5905].
o Upper limit on Poisson distribution (values above this limit will Trunc Upper limit on Poisson distribution expressed in units of
be clipped and set to the limit value). (if fixed, Upper limit = seconds, as a positive value of type decimal64 with fraction
300 seconds.) digits = 5 (see section 9.3 of [RFC6020]) with resolution of
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
this limit will be clipped and set to the limit value). (if fixed,
Trunc = 30.0000 seconds.)
o ID, the 16-bit identifier assigned by the program that generates ID The 16-bit identifier assigned by the program that generates the
the query, and which must vary in successive queries, see query, and which must vary in successive queries, see
Section 4.1.1 of [RFC1035]. This identifier is copied into the Section 4.1.1 of [RFC1035]. This identifier is copied into the
corresponding reply and can be used by the requester to match-up corresponding reply and can be used by the requester (Src) to
replies to outstanding queries. match-up replies to outstanding queries.
The format for 1/lambda and Upper limit of Poisson Dist. are the QNAME The domain name of the Query, formatted as specified in
short format in [RFC5905] (32 bits) and is as follows: the first 16 section 4 of [RFC6991].
bits represent the integer number of seconds; the next 16 bits
represent the fractional part of a second.
>>> should Poisson run-time params be fixed instead? probably yes if QTYPE The Query Type, which will correspond to the IP address family
modeling a specific version of MBA tests. of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a
uint16, as per section 9.2 of [RFC6020].
6.3.6. Roles 6.3.6. Roles
<lists the names of the different roles from the measurement method> <lists the names of the different roles from the measurement method>
Src - launches each packet and waits for return transmissions from Src launches each packet and waits for return transmissions from
Dst. Dst.
Dst - waits for each packet from Src and sends a return packet to Dst waits for each packet from Src and sends a return packet to Src.
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/Value (two diff terms used) 6.4.1. Type
<insert name of the output type, raw or a selected summary statistic> <insert name of the output type, raw or a selected summary statistic>
For all output types: Raw -- for each DNS Query packet sent, sets of values as defined in
the next column, including the status of the response, only assigning
o T0, a time (start of measurement interval, 128-bit NTP Date delay values to successful query-response pairs.
Format, see section 6 of [RFC5905])
o Tf, a time (end of measurement interval, 128-bit NTP Date Format,
see section 6 of [RFC5905])
Raw -- for each packet sent, pairs of values.
>>> and the status of the response, only assigning values to
successful query-response pairs.
Percentile -- for the conditional distribution of all packets with a
valid value of Round-trip delay (undefined delays are excluded), a
single value corresponding to the 95th percentile.
6.4.2. Reference Definition 6.4.2. Reference Definition
<describe the data format for each type of result> <describe the data format for each type of result>
Raw -- for each packet sent, pairs of values as follows: For all outputs:
o T, the time when the packet was sent from Src, 128-bit NTP Date
Format, see section 6 of [RFC5905])
o dT, a value of Round-trip delay, format is *similar to* the 32-bit
short NTP Time format in Section 6 of [RFC5905] and is as follows:
the first 16 bits represent the *signed* integer number of
seconds; the next 16 bits represent the fractional part of a
second.
o dT is undefined when the packet is not received at Src in waiting
time Tmxax seconds (need undefined code for no-response or un-
successful response)
Percentile -- for the conditional distribution of all packets with a
valid value of Round-trip delay (undefined delays are excluded), a
single value as follows:
See section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of
[RFC6703] for background on this analysis choice.
See section 4.3 of [RFC3393] for details on the percentile statistic T the time the DNS Query was sent during the measurement interval,
(where Round-trip delay should be substituted for "ipdv"). (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].
The percentile = 95. dT The time value of the round-trip delay to receive the DNS
response, 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 RFC [RFC5905]. This value is undefined when the
response packet is not received at Src within waiting time Tmxax
seconds.
Data format is a 32-bit signed floating point value, *similar to* the Rcode The value of the Rcode field in the DNS response header,
32-bit short NTP Time format in Section 6 of [RFC5905] and is as expressed as a uint64 as specified in section 9.2 of [RFC6020].
follows: the first 16 bits represent the *signed* integer number of Non-zero values convey errors in the response, and such replies
seconds; the next 16 bits represent the fractional part of a second. must be analyzed separately from successful requests.
6.4.3. Metric Units 6.4.3. Metric Units
<insert units for the measured results, and the reference <insert units for the measured results, and the reference
specification>. specification>.
Round-trip Delay, dT, is expressed in seconds. Round-trip Delay, dT, is expressed in seconds.
The 95th Percentile of Round-trip Delay is expressed in seconds.
6.4.4. Calibration 6.4.4. Calibration
<pointer to > Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ
calibration could be enabled with an internal loopback at the Source
host that includes as much of the measurement system as possible,
performs address and payload manipulation as needed, and provides
some form of isolation (e.g., deterministic delay) to avoid send-
receive interface contention. Some portion of the random and
systematic error can be characterized this way.
When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a
calibration result.
Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system
noise, and thus inaccurate.
6.5. Administrative items 6.5. Administrative items
6.5.1. Status 6.5.1. Status
<current or depricated> <current or depricated>
6.5.2. Requestor (keep?) 6.5.2. Requestor
name or RFC, etc. name or RFC, etc.
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 YYYY-MM-DD
6.6. Comments and Remarks 6.6. Comments and Remarks
Additional (Informational) details for this entry Additional (Informational) details for this entry
7. UDP Poisson One-way Delay Registry Entries 7. UDP Poisson One-way Delay Registry Entries
This section gives an initial registry entry for the UDP Poisson One- This section specifies five initial registry entries for the UDP
way Delay. Poisson One-way Delay.
Note: Each Registry "Name" below specifies a single registry entry, Note: Each Registry "Name" below specifies a single registry entry,
whose output format varies according to a component of the name that whose output format varies according to the <statistic> element of
specifies one form of statistical summary. the name that specifies one form of statistical summary.
IANA is asked to assign a different numeric identifiers to each Name. IANA is asked to assign a different numeric identifiers to each of
All column entries beside the Summary and Output categories are the the five Metrics. All column entries beside the ID, Name,
same, thus this section proposes five closely-related registry Description, and Output Reference Method categories are the same,
entries. As a result, IANA is also asked to assign corresponding thus this section proposes five closely-related registry entries. As
URIs and URLs. a result, IANA is also asked to assign corresponding URNs and URLs to
each Named Metric.
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)
<insert numeric identifier, an integer, one corresponding to each <insert numeric identifier, an integer, one corresponding to each
name below> name below>
7.1.2. Name 7.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
OWDelay_Active_IP-UDP-Poisson- OWDelay_Active_IP-UDP-Poisson-
Payload250B_RFCXXXXsecY_Seconds_<statistic> Payload250B_RFCXXXXsecY_Seconds_<statistic>
OWDelay_Active_IP-UDP-Poisson- where <statistic> is one of:
Payload250B_RFCXXXXsecY_Seconds_95Percentile
OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean o 95Percentile
OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Min o Mean
OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Max o Min
OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_StdDev o Max
o StdDev
7.1.3. URI and URL 7.1.3. URI and URL
URI: Prefix urn:ietf:params:performance:metric...<name> URI: Prefix urn:ietf:metrics:perf:<name>
URL: http:\\www.iana.org\ ... <name> URL: http:\\www.iana.org\ ... <name>
7.1.4. Description 7.1.4. Description
This metric assesses the delay of a stream of packets exchanged This metric assesses the delay of a stream of packets exchanged
between two hosts (or measurement points), and reports the between two hosts (or measurement points), and reports the
<statistic> One-way delay for all successfully exchanged packets <statistic> One-way delay for all successfully exchanged packets
based on their conditional delay distribution. based on their conditional delay distribution.
where <statistic> is one of:
o 95Percentile
o Mean
o Min
o Max
o StdDev
7.2. Metric Definition 7.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.
7.2.1. Reference Definition 7.2.1. Reference Definition
<Full bibliographic reference to an immutable doc.> <Full bibliographic reference to an immutable doc.>
Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-
Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc- 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-
editor.org/info/rfc7679>. editor.org/info/rfc7679>.
[RFC2679] [RFC7679]
Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC
6049, January 2011. 6049, January 2011.
[RFC6049] [RFC6049]
<specific section reference and additional clarifications, if needed> <specific section reference and additional clarifications, if needed>
Section 3.4 of [RFC2679] provides the reference definition of the Section 3.4 of [RFC7679] provides the reference definition of the
singleton (single value) One-way delay metric. Section 4.4 of singleton (single value) One-way delay metric. Section 4.4 of
[RFC2679] provides the reference definition expanded to cover a [RFC7679] provides the reference definition expanded to cover a
multi-value sample. Note that terms such as singleton and sample are multi-value sample. Note that terms such as singleton and sample are
defined in Section 11 of [RFC2330]. defined in Section 11 of [RFC2330].
Only successful packet transfers with finite delay are included in Only successful packet transfers with finite delay are included in
the sample, as prescribed in section 4.1.2 of [RFC6049]. the sample, as prescribed in section 4.1.2 of [RFC6049].
NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft-
ietf-ippm-2679-bis-01.
7.2.2. Fixed Parameters 7.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be <list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when determined and embedded in the measurement system for use when
needed> needed>
Type-P: Type-P:
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL set to 255 * TTL: set to 255
* Protocol: Set to 17 (UDP)
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o UDP header values: o UDP header values:
* Checksum: the checksum must be calculated * Checksum: the checksum MUST be calculated and included in the
header
o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]
* Security features in use influence the number of Padding * Security features in use influence the number of Padding
octets. octets.
* 250 octets total, including the TWAMP format * 250 octets total, including the TWAMP format
Timeout, Tmax: 3 seconds Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in
units of seconds, as a positive value of type decimal64 with
fraction digits = 5 (see section 9.3 of [RFC6020]) and with
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
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 methods for implementations.
7.3.1. Reference Method 7.3.1. Reference Method
<for metric, insert relevant section references and supplemental <for metric, insert relevant section references and supplemental
skipping to change at page 35, line 19 skipping to change at page 37, line 4
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 methods for implementations.
7.3.1. Reference Method 7.3.1. Reference Method
<for metric, insert relevant section references and supplemental <for metric, insert relevant section references and supplemental
info> info>
The methodology for this metric is defined as Type-P-One-way-Delay- The methodology for this metric is defined as Type-P-One-way-Delay-
Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of
[RFC2679] using the Type-P and Timeout defined under Fixed [RFC7679] using the Type-P and Tmax defined under Fixed Parameters.
Parameters.
The method requires sequence numbers or other send-order information The reference method distinguishes between long-delayed packets and
to be retained at the Src or included with each packet to dis- lost packets by implementing a maximum waiting time for packet
ambiguate packet reordering if it occurs. Sequence number is part of arrival. Tmax is the waiting time used as the threshold to declare a
the TWAMP payload described under Fixed Parameters. packet lost. Lost packets SHALL be designated as having undefined
delay.
7.3.2. Packet Generation Stream The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MAY enforce the Tmax
threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background
on this analysis choice.
The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving
packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to dis-ambiguate
packet reordering if it occurs.
Since a standard measurement protocol is employed [RFC5357], then the
measurement process will determine the sequence numbers or timestamps
applied to test packets after the Fixed and Runtime parameters are
passed to that process. The measurement protocol dictates the format
of sequence numbers and time-stamps conveyed in the TWAMP-Test packet
payload.
7.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream, basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be dscribed by providing the list of stream and can easily be dscribed by providing the list of stream
parameters. parameters.
<list of generation parameters and section/spec references if needed> <list of generation parameters and section/spec references if needed>
Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to
generate Poisson sampling intervals. The reciprocal of lambda is the generate Poisson sampling intervals. the reciprocal of lambda is the
average packet rate, thus the Run-time Parameter is 1/lambda. average packet spacing, thus the Run-time Parameter is
Reciprocal_lambda = 1/lambda, in seconds.
Method 3 or equivalent SHALL used, where given a start time (Run-time Method 3 SHALL be used, where given a start time (Run-time
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 pseudo-random distribution of inter-
packet send times, (truncating the distribution as specified in the packet send times, (truncating the distribution as specified in the
Run-time Parameters), 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
Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead.
Reciprocal_lambda average packet interval for Poisson Streams
expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of
[RFC5905]. Reciprocal_lambda = 1 packet per second.
Trunc Upper limit on Poisson distribution expressed in units of
seconds, as a positive value of type decimal64 with fraction
digits = 5 (see section 9.3 of [RFC6020]) with resolution of
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
this limit will be clipped and set to the limit value). Trunc =
30.0000 seconds.
7.3.3. Traffic Filtering (observation) Details 7.3.3. Traffic Filtering (observation) Details
NA NA
7.3.4. Sampling Distribution 7.3.4. Sampling Distribution
NA NA
7.3.5. Run-time Parameters and Data Format 7.3.5. Run-time Parameters and Data Format
Run-time Parameters are input factors that must be determined, Run-time 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.
<list of run-time parameters, and their data formats> <list of run-time parameters, and their data formats>
o Src, the IP address of a host (32-bit value for IPv4, 128-bit Src the IP address of the host in the Src Role (format ipv4-address-
value for IPv6) no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see Section 4 of [RFC6991])
o Dst, the IP address of a host (32-bit value for IPv4, 128-bit
value for IPv6)
o T0, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a
start time is unspecified and Tf is to be interpreted as the
Duration of the measurement interval.
o Tf, a time (end of measurement interval, 128-bit NTP Date Format,
see section 6 of [RFC5905]), interpreted as the Duration of the
measurement interval.
o 1/lambda, average packet rate (for Poisson Streams). (1/lambda =
1 packet per second, if fixed)
o Upper limit on Poisson distribution (values above this limit will Dst the IP address of the host in the Dst Role (format ipv4-address-
be clipped and set to the limit value). (if fixed, Upper limit = no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
30 seconds.) see section 4 of [RFC6991])
The format for 1/lambda and Upper limit of Poisson Dist. are the T0 a time, the start of a measurement interval, (format "date-and-
short format in [RFC5905] (32 bits) and is as follows: the first 16 time" as specified in Section 5.6 of [RFC3339], see also Section 3
bits represent the integer number of seconds; the next 16 bits of [RFC6991]). The UTC Time Zone is required by Section 6.1 of
represent the fractional part of a second. [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.
>>> should Poisson run-time params be fixed instead? probably yes if Tf a time, the end of a measurement interval, (format "date-and-time"
modeling a specific version of tests. Note in the NAME, i.e. as specified in Section 5.6 of [RFC3339], see also Section 3 of
Poisson3.3 [RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330]. When T0 is "all-zeros", a end time date is ignored and
Tf is interpreted as the Duration of the measurement interval.
7.3.6. Roles 7.3.6. Roles
<lists the names of the different roles from the measurement method> <lists the names of the different roles from the measurement method>
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. Dst. This is the TWAMP Session-Sender.
Dst - waits for each packet from Src and sends a return packet to Dst waits for each packet from Src and sends a return packet to Src.
Src. This is the TWAMP Session-Reflector. This 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/Value (two diff terms used) 7.4.1. Type
<insert name of the output type, raw or a selected summary statistic> <insert name of the output type, raw or a selected summary statistic>
See subsection titles below for Types. See subsection titles below for Types.
7.4.2. Reference Definition 7.4.2. Reference Definition
<describe the data format for each type of result> <describe the data format for each type of result>
For all output types --- For all output types ---
o T0, a time (start of measurement interval, 128-bit NTP Date T0 the start of a measurement interval, (format "date-and-time" as
Format, see section 6 of [RFC5905]) 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].
o Tf, a time (end of measurement interval, 128-bit NTP Date Format, Tf the end of a measurement interval, (format "date-and-time" as
see section 6 of [RFC5905]) 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].
For each <statistic>, one of the following sub-sections apply:
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 Section 5 of
[RFC6703] for background on this analysis choice. [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. The percentile = 95, meaning that the reported delay, "95Percentile",
is the smallest value of one-way delay for which the Empirical
Distribution Function (EDF), F(95Percentile) >= 95% of the singleton
one-way delay values in the conditional distribution. See section
11.3 of [RFC2330] for the definition of the percentile statistic
using the EDF.
The time value of the result is expressed in units of seconds, as a 95Percentile The time value of the result is expressed in units of
positive value of type decimal64 with fraction digits = 9 (see seconds, as a positive value of type decimal64 with fraction
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 digits = 9 (see section 9.3 of [RFC6020]) with resolution of
ns), and with lossless conversion to/from the 64-bit NTP timestamp as 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
per section 6 of RFC [RFC5905]. the 64-bit NTP timestamp as per section 6 of RFC [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 Section 5 of
[RFC6703] for background on this analysis choice. [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, and 4.2.3 of [RFC6049].
The time value of the result is expressed in units of seconds, as a Mean The time value of the result is expressed in units of seconds,
positive value of type decimal64 with fraction digits = 9 (see as a positive value of type decimal64 with fraction digits = 9
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
ns), and with lossless conversion to/from the 64-bit NTP timestamp as seconds (1.0 ns), and with lossless conversion to/from the 64-bit
per section 6 of RFC [RFC5905]. NTP timestamp as per section 6 of RFC [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 Section 5 of
[RFC6703] for background on this analysis choice. [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, and 4.3.3 of [RFC6049].
The time value of the result is expressed in units of seconds, as a Min The time value of the result is expressed in units of seconds,
positive value of type decimal64 with fraction digits = 9 (see as a positive value of type decimal64 with fraction digits = 9
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
ns), and with lossless conversion to/from the 64-bit NTP timestamp as seconds (1.0 ns), and with lossless conversion to/from the 64-bit
per section 6 of RFC [RFC5905]. NTP timestamp as per section 6 of RFC [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 Section 5 of
[RFC6703] for background on this analysis choice. [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, and 4.3.3 of [RFC6049]. The formula is
as follows: 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
The time value of the result is expressed in units of seconds, as a Max The time value of the result is expressed in units of seconds,
positive value of type decimal64 with fraction digits = 9 (see as a positive value of type decimal64 with fraction digits = 9
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
ns), and with lossless conversion to/from the 64-bit NTP timestamp as seconds (1.0 ns), and with lossless conversion to/from the 64-bit
per section 6 of RFC [RFC5905]. NTP timestamp as per section 6 of RFC [RFC5905]
7.4.2.5. Std_Dev 7.4.2.5. Std_Dev
The Std_Dev SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays
are excluded), a single value as follows:
See section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of
[RFC6703] for background on this analysis choice.
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
the classic calculation for standard deviation of a population.
Std_Dev The 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 RFC [RFC5905]
7.4.3. Metric Units 7.4.3. Metric Units
<insert units for the measured results, and the reference <insert units for the measured results, and the reference
specification>. specification>.
The <statistic> of One-way Delay is expressed in seconds. The <statistic> of One-way Delay is expressed in seconds.
The 95th Percentile of One-way Delay is expressed in seconds.
7.4.4. Calibration 7.4.4. Calibration
<pointer to > Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ
calibration could be enabled with an internal loopback that includes
as much of the measurement system as possible, performs address
manipulation as needed, and provides some form of isolation (e.g.,
deterministic delay) to avoid send-receive interface contention.
Some portion of the random and systematic error can be characterized
this way.
For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets of clocks at both the
source and destination are needed to estimate the systematic error
due to imperfect clock synchronization (the time offsets are
smoothed, thus the random variation is not usually represented in the
results).
time_offset The time value of the result is expressed in units of
seconds, as a signed 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 RFC [RFC5905]
When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a
calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset as an indicator of
the degree of synchronization.
Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system
noise, and thus inaccurate.
7.5. Administrative items 7.5. Administrative items
7.5.1. Status 7.5.1. Status
<current or depricated> <current or depricated>
7.5.2. Requestor (keep?) 7.5.2. Requestor (keep?)
name or RFC, etc. name or RFC, etc.
skipping to change at page 40, line 23 skipping to change at page 43, line 48
7.5.4. Revision Date 7.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
7.6. Comments and Remarks 7.6. Comments and Remarks
Additional (Informational) details for this entry Additional (Informational) details for this entry
8. UDP Periodic One-way Delay Registry Entries 8. UDP Periodic One-way Delay Registry Entries
This section gives an initial registry entry for the UDP Periodic This section specifies five initial registry entries for the UDP
One-way Delay. Periodic One-way Delay.
Note: Each Registry "Name" below specifies a single registry entry, Note: Each Registry "Name" below specifies a single registry entry,
whose output format varies according to a component of the name that whose output format varies according to the <statistic> element of
specifies one form of statistical summary. the name that specifies one form of statistical summary.
IANA is asked to assign a different numeric identifiers to each Name. IANA is asked to assign a different numeric identifiers to each of
All other column entries are the same, thus this section is proposes the five Metrics. All column entries beside the ID, Name,
five closely-related registry entries. As a result, IANA is also Description, and Output Reference Method categories are the same,
asked to assign corresponding URIs and URLs. thus this section proposes five closely-related registry entries. As
a result, IANA is also asked to assign corresponding URNs and URLs to
each Named Metric.
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)
<insert numeric identifier, an integer, one corresponding to each <insert numeric identifier, an integer, one corresponding to each
name below> name below>
8.1.2. Name 8.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
OWDelay_Active_IP-UDP-Periodic- OWDelay_Active_IP-UDP-Periodic-
Payload142B_RFCXXXXsecY_Seconds_<statistic> Payload142B_RFCXXXXsecY_Seconds_<statistic>
OWDelay_Active_IP-UDP-Periodic-
Payload142B_RFCXXXXsecY_Seconds_95Percentile
OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Mean where <statistic> is one of:
OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Min o 95Percentile
OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Max o Mean
OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_StdDev o Min
8.1.3. URI and URL o Max
URI: Prefix urn:ietf:metric...<name> o StdDev
8.1.3. URIs
URI: Prefix urn:ietf:metrics:perf:<name>
URL: http:\\www.iana.org\ ... <name> URL: http:\\www.iana.org\ ... <name>
8.1.4. Description 8.1.4. Description
This metric assesses the delay of a stream of packets exchanged This metric assesses the delay of a stream of packets exchanged
between two hosts (or measurement points), and reports the between two hosts (or measurement points), and reports the
<statistic> One-way delay for all successfully exchanged packets <statistic> One-way delay for all successfully exchanged packets
based on their conditional delay distribution. based on their conditional delay distribution.
where <statistic> is one of:
o 95Percentile
o Mean
o Min
o Max
o StdDev
8.2. Metric Definition 8.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.
8.2.1. Reference Definition 8.2.1. Reference Definition
<Full bibliographic reference to an immutable doc.> <Full bibliographic reference to an immutable doc.>
Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-
for IPPM", RFC 2679, September 1999. 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>.
[RFC2679] [RFC7679]
Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC
6049, January 2011. 6049, January 2011.
[RFC6049] [RFC6049]
<specific section reference and additional clarifications, if needed> <specific section reference and additional clarifications, if needed>
Section 3.4 of [RFC2679] provides the reference definition of the Section 3.4 of [RFC7679] provides the reference definition of the
singleton (single value) One-way delay metric. Section 4.4 of singleton (single value) One-way delay metric. Section 4.4 of
[RFC7679] provides the reference definition expanded to cover a
[RFC2679] provides the reference definition expanded to cover a
multi-value sample. Note that terms such as singleton and sample are multi-value sample. Note that terms such as singleton and sample are
defined in Section 11 of [RFC2330]. defined in Section 11 of [RFC2330].
Only successful packet transfers with finite delay are included in Only successful packet transfers with finite delay are included in
the sample, as prescribed in section 4.1.2 of [RFC6049]. the sample, as prescribed in section 4.1.2 of [RFC6049].
NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft-
ietf-ippm-2679-bis-01.
ANY other conditions, ...
8.2.2. Fixed Parameters 8.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be <list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when determined and embedded in the measurement system for use when
needed> needed>
Type-P: Type-P:
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL set to 255 * TTL: set to 255
* Protocol: Set to 17 (UDP)
o IPv6 header values:
* DSCP: set to 0
* Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o UDP header values: o UDP header values:
* Checksum: the checksum must be calculated * Checksum: the checksum MUST be calculated and included in the
header
o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]
* Security features in use influence the number of Padding * Security features in use influence the number of Padding
octets. octets.
* 142 octets total, including the TWAMP format * 142 octets total, including the TWAMP format
Timeout, Tmax: 3 seconds Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in
units of seconds, as a positive value of type decimal64 with
fraction digits = 5 (see section 9.3 of [RFC6020]) and with
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
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 methods for implementations.
8.3.1. Reference Method 8.3.1. Reference Method
<for metric, insert relevant section references and supplemental <for metric, insert relevant section references and supplemental
info> info>
The methodology for this metric is defined as Type-P-One-way-Delay- The methodology for this metric is defined as Type-P-One-way-Delay-
Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of
[RFC2679] using the Type-P and Timeout defined under Fixed [RFC7679] using the Type-P and Tmax defined under Fixed Parameters.
Parameters.
The method requires sequence numbers or other send-order information The reference method distinguishes between long-delayed packets and
to be retained at the Src or included with each packet to dis- lost packets by implementing a maximum waiting time for packet
ambiguate packet reordering if it occurs. Sequence number is part of arrival. Tmax is the waiting time used as the threshold to declare a
the TWAMP payload described under Fixed Parameters. packet lost. Lost packets SHALL be designated as having undefined
delay.
8.3.2. Packet Generation Stream The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MAY enforce the Tmax
threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background
on this analysis choice.
The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving
packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to dis-ambiguate
packet reordering if it occurs.
Since a standard measurement protocol is employed [RFC5357], then the
measurement process will determine the sequence numbers or timestamps
applied to test packets after the Fixed and Runtime parameters are
passed to that process. The measurement protocol dictates the format
of sequence numbers and time-stamps conveyed in the TWAMP-Test packet
payload.
8.3.2. Packet Stream Generation
<list of generation parameters and section/spec references if needed>
This section gives the details of the packet traffic which is the This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream, basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be dscribed by providing the list of stream and can easily be described by providing the list of stream
parameters. parameters.
<list of generation parameters and section/spec references if needed>
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.
o incT, the nominal duration of inter-packet interval, first bit to incT the nominal duration of inter-packet interval, first bit to
first bit first bit
o dT, the duration of the interval for allowed sample start times dT the duration of the interval for allowed sample start times
o T0, the actual start time T0 the actual start time of the periodic stream
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) may
be sufficient to avoid synchronization of periodic streams, and be sufficient to avoid synchronization of periodic streams, and
therefore a valid replacement for selecting a start time at random therefore a valid replacement for selecting a start time at random
from a fixed interval. from a fixed interval.
These stream parameters will be specified as Run-time parameters. These stream parameters will be specified as Run-time parameters.
8.3.3. Traffic Filtering (observation) Details 8.3.3. Traffic Filtering (observation) Details
skipping to change at page 44, line 17 skipping to change at page 48, line 48
NA NA
8.3.5. Run-time Parameters and Data Format 8.3.5. Run-time Parameters and Data Format
Run-time Parameters are input factors that must be determined, Run-time 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.
<list of run-time parameters, and their data formats> <list of run-time parameters, and their data formats>
o Src, the IP address of a host (32-bit value for IPv4, 128-bit Src the IP address of the host in the Src Role (format ipv4-address-
value for IPv6) no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see Section 4 of [RFC6991])
o Dst, the IP address of a host (32-bit value for IPv4, 128-bit
value for IPv6)
o T0, a time (start of measurement interval, 128-bit NTP Date
Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a
start time is unspecified and Tf is to be interpreted as the
Duration of the measurement interval.
o Tf, a time (end of measurement interval, 128-bit NTP Date Format,
see section 6 of [RFC5905]), interpreted as the Duration of the
measurement interval.
o incT, the nominal duration of inter-packet interval, first bit to Dst the IP address of the host in the Dst Role (format ipv4-address-
first bit no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see section 4 of [RFC6991])
o dT, the duration of the interval for allowed sample start times T0 a time, 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]. 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.
The format for incT and dT are the short format in [RFC5905] (32 Tf a time, the end of a measurement interval, (format "date-and-time"
bits) and is as follows: the first 16 bits represent the integer as specified in Section 5.6 of [RFC3339], see also Section 3 of
number of seconds; the next 16 bits represent the fractional part of [RFC6991]). The UTC Time Zone is required by Section 6.1 of
a second. [RFC2330]. When T0 is "all-zeros", a end time date is ignored and
Tf is interpreted as the Duration of the measurement interval.
>>> should Periodic run-time params be fixed instead? probably yes if >>> should Periodic run-time params be fixed instead? probably yes if
modeling a specific version of tests. Note in the NAME, i.e. modeling a specific version of tests. Note in the NAME, i.e.
Poisson3.3 Poisson3.3
8.3.6. Roles 8.3.6. Roles
<lists the names of the different roles from the measurement method> <lists the names of the different roles from the measurement method>
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. Dst. This is the TWAMP Session-Sender.
Dst - waits for each packet from Src and sends a return packet to Dst waits for each packet from Src and sends a return packet to Src.
Src. This is the TWAMP Session-Reflector. This 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/Value (two diff terms used) 8.4.1. Type
<insert name of the output type, raw or a selected summary statistic> <insert name of the output type, raw or a selected summary statistic>
See subsection titles in Data Format for Types. See subsection titles in Data Format for Types.
8.4.2. Data Format 8.4.2. Reference Definition
<describe the data format for each type of result> <describe the data format for each type of result>
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].
o T0, a time (start of measurement interval, 128-bit NTP Date Tf the end of a measurement interval, (format "date-and-time" as
Format, see section 6 of [RFC5905]) 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].
o Tf, a time (end of measurement interval, 128-bit NTP Date Format, For each <statistic>, one of the following sub-sections apply:
see section 6 of [RFC5905])
8.4.2.1. 95Percentile 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 Section 5 of
[RFC6703] for background on this analysis choice. [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. The percentile = 95, meaning that the reported delay, "95Percentile",
is the smallest value of one-way delay for which the Empirical
Data format is a 32-bit signed value, *similar to* the 32-bit short Distribution Function (EDF), F(95Percentile) >= 95% of the singleton
NTP Time format in Section 6 of [RFC5905] and is as follows: the one-way delay values in the conditional distribution. See section
first 16 bits represent the *signed* integer number of seconds; the 11.3 of [RFC2330] for the definition of the percentile statistic
next 16 bits represent the fractional part of a second. using the EDF.
The time value of the result is expressed in units of seconds, as a 95Percentile The time value of the result is expressed in units of
positive value of type decimal64 with fraction digits = 9 (see seconds, as a positive value of type decimal64 with fraction
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 digits = 9 (see section 9.3 of [RFC6020]) with resolution of
ns), and with lossless conversion to/from the 64-bit NTP timestamp as 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
per section 6 of RFC [RFC5905]. the 64-bit NTP timestamp as per section 6 of RFC [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 Section 5 of
[RFC6703] for background on this analysis choice. [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, and 4.2.3 of [RFC6049].
The time value of the result is expressed in units of seconds, as a Mean The time value of the result is expressed in units of seconds,
positive value of type decimal64 with fraction digits = 9 (see as a positive value of type decimal64 with fraction digits = 9
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
ns), and with lossless conversion to/from the 64-bit NTP timestamp as seconds (1.0 ns), and with lossless conversion to/from the 64-bit
per section 6 of RFC [RFC5905]. NTP timestamp as per section 6 of RFC [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 Section 5 of
[RFC6703] for background on this analysis choice. [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, and 4.3.3 of [RFC6049].
The time value of the result is expressed in units of seconds, as a Min The time value of the result is expressed in units of seconds,
positive value of type decimal64 with fraction digits = 9 (see as a positive value of type decimal64 with fraction digits = 9
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
ns), and with lossless conversion to/from the 64-bit NTP timestamp as seconds (1.0 ns), and with lossless conversion to/from the 64-bit
per section 6 of RFC [RFC5905]. NTP timestamp as per section 6 of RFC [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 Section 5 of
[RFC6703] for background on this analysis choice. [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, and 4.3.3 of [RFC6049]. The formula is
as follows: 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
The time value of the result is expressed in units of seconds, as a Max The time value of the result is expressed in units of seconds,
positive value of type decimal64 with fraction digits = 9 (see as a positive value of type decimal64 with fraction digits = 9
section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
ns), and with lossless conversion to/from the 64-bit NTP timestamp as seconds (1.0 ns), and with lossless conversion to/from the 64-bit
per section 6 of RFC [RFC5905]. NTP timestamp as per section 6 of RFC [RFC5905]
8.4.2.5. Std_Dev 8.4.2.5. Std_Dev
The Std_Dev SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays
are excluded), a single value as follows:
See section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of
[RFC6703] for background on this analysis choice.
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
the classic calculation for standard deviation of a population.
Std_Dev The 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 RFC [RFC5905]
8.4.3. Metric Units 8.4.3. Metric Units
<insert units for the measured results, and the reference <insert units for the measured results, and the reference
specification>. specification>.
The <statistic> of One-way Delay is expressed in seconds. The <statistic> of One-way Delay is expressed in seconds.
8.4.4. Calibration 8.4.4. Calibration
<pointer to > Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ
calibration could be enabled with an internal loopback that includes
as much of the measurement system as possible, performs address
manipulation as needed, and provides some form of isolation (e.g.,
deterministic delay) to avoid send-receive interface contention.
Some portion of the random and systematic error can be characterized
this way.
For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets of clocks at both the
source and destination are needed to estimate the systematic error
due to imperfect clock synchronization (the time offsets are
smoothed, thus the random variation is not usually represented in the
results).
time_offset The time value of the result is expressed in units of
seconds, as a signed 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 RFC [RFC5905]
When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a
calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset as an indicator of
the degree of synchronization.
Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system
noise, and thus inaccurate.
8.5. Administrative items 8.5. Administrative items
8.5.1. Status 8.5.1. Status
<current or depricated> <current or depricated>
8.5.2. Requestor (keep?) 8.5.2. Requestor (keep?)
name or RFC, etc. name or RFC, etc.
skipping to change at page 48, line 32 skipping to change at page 54, line 24
9.1.1. ID (Identifier) 9.1.1. ID (Identifier)
<insert numeric identifier, an integer> <insert numeric identifier, an integer>
9.1.2. Name 9.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
9.1.3. URIs 9.1.3. URIs
URI: Prefix urn:ietf:params:performance:metric URI: Prefix urn:ietf:metrics:perf:<name>
URL: URL:
9.1.4. Description 9.1.4. Description
TBD. TBD.
9.1.5. Reference 9.1.5. Reference
<reference to the RFC of spec where the registry entry is defined> <reference to the RFC of spec where the registry entry is defined>
skipping to change at page 51, line 37 skipping to change at page 57, line 29
An integer having enough digits to uniquely identify each entry in An integer having enough digits to uniquely identify each entry in
the Registry. the Registry.
10.1.2. Name 10.1.2. Name
A metric naming convention is TBD. A metric naming convention is TBD.
10.1.3. URI 10.1.3. URI
Prefix urn:ietf:params:performance:metric Prefix urn:ietf:metrics:param:<name>
10.1.4. Status 10.1.4. Status
current current
10.1.5. Requestor 10.1.5. Requestor
Alcelip Mornuley Alcelip Mornuley
10.1.6. Revision 10.1.6. Revision
skipping to change at page 56, line 26 skipping to change at page 62, line 14
measurement has been removed. * Explanation of Conditional delay measurement has been removed. * Explanation of Conditional delay
distribution. distribution.
Version 03 addressed Phil Eardley's comments and suggestions in Version 03 addressed Phil Eardley's comments and suggestions in
sections 1-4. and resolved the definition of Percentiles. sections 1-4. and resolved the definition of Percentiles.
Version 04 * All section 4 parameters reference YANG types for Version 04 * All section 4 parameters reference YANG types for
alternate data formats. * Discussion has concluded that usecase(s) alternate data formats. * Discussion has concluded that usecase(s)
for machine parse-able registry columns are not needed. for machine parse-able registry columns are not needed.
Still need: * suggestion of standard naming format for parameters.
Note: lambda parameter description is correct in section 4, elsewhere
needs fix.
12. Security Considerations 12. Security Considerations
These registry entries represent no known security implications for These registry entries represent no known security implications for
Internet Security. Each referenced Metric contains a Security Internet Security. Each referenced Metric contains a Security
Considerations section. Considerations section.
13. IANA Considerations 13. IANA Considerations
IANA is requested to populate The Performance Metric Registry defined IANA is requested to populate The Performance Metric Registry defined
in [I-D.ietf-ippm-metric-registry] with the values defined above. in [I-D.ietf-ippm-metric-registry] with the values defined above.
<more is needed here> See the IANA Considerations section of
[I-D.ietf-ippm-metric-registry] for additional requests and
considerations.
14. Acknowledgements 14. Acknowledgements
The authors thank Brian Trammell for suggesting the term "Run-time The authors thank Brian Trammell for suggesting the term "Run-time
Parameters", which led to the distinction between run-time and fixed Parameters", which led to the distinction between run-time and fixed
parameters implemented in this memo, for identifying the IPFIX metric parameters implemented in this memo, for identifying the IPFIX metric
with Flow Key as an example, and for many other productive with Flow Key as an example, and for many other productive
suggestions. Thanks to Peter Koch, who provided several useful suggestions. Thanks to Peter Koch, who provided several useful
suggestions for disambiguating successive DNS Queries in the DNS suggestions for disambiguating successive DNS Queries in the DNS
Response time metric. Response time metric.
The authors also acknowledge the constructive reviews and helpful The authors also acknowledge the constructive reviews and helpful
suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and
participants in the LMAP working group. participants in the LMAP working group. Thanks to Michelle Cotton
for her early IANA review, and to Amanda Barber for answering
questions related to the presentation of the registry and
accessibility of the complete template via URL.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-ippm-metric-registry] [I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., and A. Morton, Bagnulo, M., Claise, B., Eardley, P., and A. Morton,
"Registry for Performance Metrics", Internet Draft (work "Registry for Performance Metrics", Internet Draft (work
in progress) draft-ietf-ippm-metric-registry, 2014. in progress) draft-ietf-ippm-metric-registry, 2014.
[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, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
 End of changes. 162 change blocks. 
510 lines changed or deleted 787 lines changed or added

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