draft-ietf-ippm-initial-registry-04.txt   draft-ietf-ippm-initial-registry-05.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: January 1, 2018 UC3M Expires: May 2, 2018 UC3M
P. Eardley P. Eardley
BT BT
K. D'Souza K. D'Souza
AT&T Labs AT&T Labs
June 30, 2017 October 29, 2017
Initial Performance Metric Registry Entries Initial Performance Metric Registry Entries
draft-ietf-ippm-initial-registry-04 draft-ietf-ippm-initial-registry-05
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:
* Addition of Loss Ratio metric in various sections (multiple metrics * Revised several Poisson streams to Periodic, sections 4 & 5.
per section).
* All section 4, 5, 6, 7, and 8 parameters reference YANG types for
alternate data formats.
* implementation of standard naming format for parameters. * Addition of ICMP (ping) metrics in section 9.
* implementation of many IANA early-review comments. * First implementation of Passive TCP RTT metrics in section 10.
Still need: Add MBM metric entry. 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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, 2018.
This Internet-Draft will expire on January 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 3. Registry Categories and Columns . . . . . . . . . . . . . . . 8
4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 9
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 10
4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 10
4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 10
4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 10 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 11
4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 11 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 12
4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 12
4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 12 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 13
4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 13 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 14
4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 4.3.3. Traffic Filtering (observation) Details . . . . . . . 14
4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 15
4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 15
4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2. Reference Definition . . . . . . . . . . . . . . . . 15 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 16
4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 16 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 17
4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 16 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 17
4.5. Administrative items . . . . . . . . . . . . . . . . . . 17 4.5. Administrative items . . . . . . . . . . . . . . . . . . 18
4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 17 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 17 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 18
4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 17 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 18
4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 17 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 18
4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 17 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 18
5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 17 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 18
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 17 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 18
5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 18 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 19
5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 18 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 19
5.1.6. Version (of Registry Format) . . . . . . . . . . . . 18 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 19
5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 18 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Reference Definition . . . . . . . . . . . . . . . . 18 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 19
5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 19 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 20
5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 20 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 21
5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 20 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 21
5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 21 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 22
5.3.3. Traffic Filtering (observation) Details . . . . . . . 21 5.3.3. Traffic Filtering (observation) Details . . . . . . . 22
5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 22 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 23
5.3.5. Run-time Parameters and Data Format . . . . . . . . . 22 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 23
5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.2. Reference Definition . . . . . . . . . . . . . . . . 23 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 24
5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 24
5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 24 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 25
5.5. Administrative items . . . . . . . . . . . . . . . . . . 24 5.5. Administrative items . . . . . . . . . . . . . . . . . . 25
5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 25
5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 25 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 26
5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 25 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 26
5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 25 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 26
5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 25 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 26
6. DNS Response Latency and Loss Registry Entries . . . . . . . 25 6. DNS Response Latency and Loss Registry Entries . . . . . . . 26
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 25 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 26
6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 26 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 27
6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 26 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 27
6.1.6. Version (of Registry Format) . . . . . . . . . . . . 26 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 27
6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 26 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Reference Definition . . . . . . . . . . . . . . . . 26 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 27
6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 27 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 28
6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 30
6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 30
6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 31
6.3.3. Traffic Filtering (observation) Details . . . . . . . 32
6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 32
6.3.5. Run-time Parameters and Data Format . . . . . . . . . 32
6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4.2. Reference Definition . . . . . . . . . . . . . . . . 34
6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 34
6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 35
6.5. Administrative items . . . . . . . . . . . . . . . . . . 35
6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 35
6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 35
6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 35
6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 35
6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 35
7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 36
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 36
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 37
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 37
7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 37
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 37
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 38
7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 39
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 39
7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 40
7.3.3. Traffic Filtering (observation) Details . . . . . . . 41
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 41
7.3.5. Run-time Parameters and Data Format . . . . . . . . . 41
7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 42
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 45
7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 45
7.5. Administrative items . . . . . . . . . . . . . . . . . . 46
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 46
7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 46
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 46
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 46
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 46
8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 47
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 47
8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 48
8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 48
8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 48
8.2.1. Reference Definition . . . . . . . . . . . . . . . . 48
8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 49
8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 50
8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 50
8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 51
8.3.3. Traffic Filtering (observation) Details . . . . . . . 52
8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 52
8.3.5. Run-time Parameters and Data Format . . . . . . . . . 52
8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 53
8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53
8.4.2. Reference Definition . . . . . . . . . . . . . . . . 53
8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56
8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56
8.5. Administrative items . . . . . . . . . . . . . . . . . . 57
8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 57
8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 57
8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 57
8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 57
8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 57
9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 57
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 58
9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 58
9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 59
9.1.6. Version (of Registry Format) . . . . . . . . . . . . 59
9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 59
9.2.1. Reference Definition . . . . . . . . . . . . . . . . 59
9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 60
9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 61
9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 61
9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 62
9.3.3. Traffic Filtering (observation) Details . . . . . . . 63
9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 63
9.3.5. Run-time Parameters and Data Format . . . . . . . . . 63
9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 64
9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 64
9.4.2. Reference Definition . . . . . . . . . . . . . . . . 64
9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 66
9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 66
9.5. Administrative items . . . . . . . . . . . . . . . . . . 67
9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 67
9.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 67
9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 67
9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 67
9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 67
6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 29 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 67
6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 29 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 30 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 68
6.3.3. Traffic Filtering (observation) Details . . . . . . . 31 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 31 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3.5. Run-time Parameters and Data Format . . . . . . . . . 31 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 68
6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 69
6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 69
6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 33 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 69
6.4.2. Reference Definition . . . . . . . . . . . . . . . . 33 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 69
6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 33 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 71
6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 34 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 72
6.5. Administrative items . . . . . . . . . . . . . . . . . . 34 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 72
6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 34 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 74
6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 34 10.3.3. Traffic Filtering (observation) Details . . . . . . 74
6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 34 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 74
6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 34 10.3.5. Run-time Parameters and Data Format . . . . . . . . 74
6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 34 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 75
7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 35 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 35 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 76
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 35 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 78
7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 36 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 78
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 36 10.5. Administrative items . . . . . . . . . . . . . . . . . . 78
7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 36 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 78
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 36 10.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . 78
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 37 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 78
7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 38 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 78
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 38 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 78
7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 39 11. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 79
7.3.3. Traffic Filtering (observation) Details . . . . . . . 40 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 40 11.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 79
7.3.5. Run-time Parameters and Data Format . . . . . . . . . 40 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1.4. Description . . . . . . . . . . . . . . . . . . . . 79
7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1.5. Reference . . . . . . . . . . . . . . . . . . . . . 79
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 41 11.1.6. Change Controller . . . . . . . . . . . . . . . . . 79
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 44 11.1.7. Version (of Registry Format) . . . . . . . . . . . . 79
7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 44 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 79
7.5. Administrative items . . . . . . . . . . . . . . . . . . 45 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 80
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 45 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 80
7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 45 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 80
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 45 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 80
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 45 11.3.2. Packet Stream Generation . . . . . . . . . . . . . . 80
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 45 11.3.3. Traffic Filtering (observation) Details . . . . . . 80
8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 46 11.3.4. Sampling Distribution . . . . . . . . . . . . . . . 80
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.3.5. Run-time Parameters and Data Format . . . . . . . . 80
8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 46 11.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 80
8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 47
8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 47
8.2.1. Reference Definition . . . . . . . . . . . . . . . . 47
8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 48
8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 49
8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 49
8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 50
8.3.3. Traffic Filtering (observation) Details . . . . . . . 51
8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 51
8.3.5. Run-time Parameters and Data Format . . . . . . . . . 51
8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 52
8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 52
8.4.2. Reference Definition . . . . . . . . . . . . . . . . 52
8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 55
8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 55
8.5. Administrative items . . . . . . . . . . . . . . . . . . 56
8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 56
8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 56
8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 56
8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 56
8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 56
9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 56
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 56
9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 56
9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 57
9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 57
9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 57
9.1.7. Version (of Registry Format) . . . . . . . . . . . . 57
9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 57
9.2.1. Reference Definition . . . . . . . . . . . . . . . . 57
9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 57
9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 57
9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 58
9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 58
9.3.3. Traffic Filtering (observation) Details . . . . . . . 58
9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 58
9.3.5. Run-time Parameters and Data Format . . . . . . . . . 58
9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 58
9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 58
9.4.2. Reference Definition . . . . . . . . . . . . . . . . 58
9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 58
9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 59
9.5. Administrative items . . . . . . . . . . . . . . . . . . 59 11.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 59 11.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 81
9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 59 11.4.2. Reference Definition . . . . . . . . . . . . . . . . 81
9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 59 11.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 81
9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 59 11.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 81
9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 59 11.5. Administrative items . . . . . . . . . . . . . . . . . . 81
10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 59 11.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 59 11.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 81
10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 59 11.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 81
10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 60 11.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 81
10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 60 11.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 81
10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 60 12. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 82
10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 60 12.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 82
10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 60 12.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 82
10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 60 12.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 82
10.1.8. Description . . . . . . . . . . . . . . . . . . . . 60 12.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 82
10.1.9. Reference Specification(s) . . . . . . . . . . . . . 60 12.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 82
10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 60 12.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 82
10.2.1. Reference Definition . . . . . . . . . . . . . . . . 60 12.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 82
10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 61 12.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 82
10.3. Method of Measurement . . . . . . . . . . . . . . . . . 61 12.1.8. Description . . . . . . . . . . . . . . . . . . . . 82
10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 61 12.1.9. Reference Specification(s) . . . . . . . . . . . . . 83
10.3.2. Stream Type and Stream Parameters . . . . . . . . . 62 12.2. Metric Definition . . . . . . . . . . . . . . . . . . . 83
10.3.3. Output Type and Data Format . . . . . . . . . . . . 62 12.2.1. Reference Definition . . . . . . . . . . . . . . . . 83
10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 62 12.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 83
10.3.5. Run-time Parameters and Data Format . . . . . . . . 62 12.3. Method of Measurement . . . . . . . . . . . . . . . . . 84
10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 64 12.3.1. Reference Method . . . . . . . . . . . . . . . . . . 84
11. Revision History . . . . . . . . . . . . . . . . . . . . . . 64 12.3.2. Stream Type and Stream Parameters . . . . . . . . . 84
12. Security Considerations . . . . . . . . . . . . . . . . . . . 64 12.3.3. Output Type and Data Format . . . . . . . . . . . . 84
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 12.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 84
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 12.3.5. Run-time Parameters and Data Format . . . . . . . . 85
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 12.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 86
15.1. Normative References . . . . . . . . . . . . . . . . . . 65 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 86
15.2. Informative References . . . . . . . . . . . . . . . . . 67 14. Security Considerations . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
17.1. Normative References . . . . . . . . . . . . . . . . . . 88
17.2. Informative References . . . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
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].
Metrics are encouraged to develop a similar document.
Although there are several standard templates for organizing Although there are several standard templates for organizing
specifications of performance metrics (see [RFC2679] for an example specifications of performance metrics (see [RFC2679] for an example
of the traditional IPPM template, based to large extent on the of the traditional IPPM template, based to large extent on the
Benchmarking Methodology Working Group's traditional template in Benchmarking Methodology Working Group's traditional template in
[RFC1242], and see [RFC6390] for a similar template), none of these [RFC1242], and see [RFC6390] for a similar template), none of these
templates were intended to become the basis for the columns of an templates were intended to become the basis for the columns of an
IETF-wide registry of metrics. While examinating aspects of metric IETF-wide registry of metrics. While examinating aspects of metric
specifications which need to be registered, it became clear that none specifications which need to be registered, it became clear that none
of the existing metric templates fully satisfies the particular needs of the existing metric templates fully satisfies the particular needs
skipping to change at page 7, line 34 skipping to change at page 8, line 38
intended purpose." The process in [I-D.ietf-ippm-metric-registry] intended purpose." The process in [I-D.ietf-ippm-metric-registry]
also requires that new entries are administered by IANA through also requires that new entries are administered by IANA through
Expert Review, which will ensure that the metrics are tightly Expert Review, which will ensure that the metrics are tightly
defined. defined.
2. Scope 2. Scope
This document defines the initial set of Performance Metrics Registry This document defines the initial set of Performance Metrics Registry
entries, for which IETF approval (following development in the IP entries, for which IETF approval (following development in the IP
Performance Metrics (IPPM) Working Group) will satisfy the Performance Metrics (IPPM) Working Group) will satisfy the
requirement for Expert Review. Note that all are Active Performance requirement for Expert Review. Most are Active Performance Metrics,
Metrics, which are based on RFCs prepared in the IPPM working group which are based on RFCs prepared in the IPPM working group of the
of the IETF, according to their framework [RFC2330] and its updates. IETF, according to their framework [RFC2330] and its updates.
3. Registry Categories and Columns 3. Registry Categories and Columns
This section provides the categories and columns of the registry, for This section provides the categories and columns of the registry, for
easy reference. An entry (row) therefore gives a complete easy reference. An entry (row) therefore gives a complete
description of a Registered Metric. description of a Registered Metric.
Registry Categories and Columns, shown as Registry Categories and Columns, shown as
Category Category
------------------ ------------------
skipping to change at page 9, line 21 skipping to change at page 10, line 21
<insert a numeric identifier, an integer, TBD> <insert a numeric identifier, an integer, TBD>
IANA is asked to assign different numeric identifiers to each of the IANA is asked to assign different numeric identifiers to each of the
two Named Metrics. two Named Metrics.
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-Periodic_RFCXXXXsecY_Seconds_95Percentile
RTLoss_Active_IP-UDP-Poisson_RFCXXXXsecY_Percent_LossRatio RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio
4.1.3. URIs 4.1.3. URIs
URN: Prefix urn:ietf:metrics:perf:<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
RTDelay: This metric assesses the delay of a stream of packets RTDelay: This metric assesses the delay of a stream of packets
skipping to change at page 11, line 36 skipping to change at page 12, line 36
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o UDP header values: o UDP header values:
* Checksum: the checksum MUST be calculated and included in the * Checksum: the checksum MUST be calculated and included in the
header header
o UDP Payload o UDP Payload
* total of 9 bytes * total of 100 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 = 4 (see section 9.3 of decimal64 with fraction digits = 4 (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
section 6 of [RFC5905]. section 6 of [RFC5905].
skipping to change at page 12, line 13 skipping to change at page 13, line 13
unambiguous methods for implementations. unambiguous methods for implementations.
4.3.1. Reference Method 4.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 Tmax defined under 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under
Fixed Parameters. Fixed Parameters. However, the Periodic stream will be generated
according to [RFC3432].
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the RTLoss metric. delay, and counted for the RTLoss metric.
The calculations on the delay (RTT) SHALL be performed on the The calculations on the delay (RTT) SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MAY enforce the Tmax threshold on which calculates the RTT value MAY enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and Section 5 of [RFC6703] for background on this analysis
choice. choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully-arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to dis-ambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
If a standard measurement protocol is employed, then the measurement If a standard measurement protocol is employed, then the measurement
process will determine the sequence numbers or timestamps applied to process will determine the sequence numbers or timestamps applied to
test packets after the Fixed and Runtime parameters are passed to test packets after the Fixed and Runtime parameters are passed to
that process. The chosen measurement protocol will dictate the that process. The chosen measurement protocol will dictate the
format of sequence numbers and time-stamps, if they are conveyed in format of sequence numbers and time-stamps, if they are conveyed in
the packet payload. the packet payload.
Refer to Section 4.4 of [RFC6673] for expanded discussion of the Refer to Section 4.4 of [RFC6673] for 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 MUST be included in [RFC6673] presents additional requirements which MUST be included in
the method of measurement for this metric. the method of measurement for this metric.
4.3.2. Packet Stream Generation 4.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 described by providing the list of stream and can easily be described by providing the list of stream
parameters. parameters.
<section/specification references, and description of any new Section 3 of [RFC3432] prescribes the method for generating Periodic
generation parameters, if needed> streams using associated parameters.
Section 11.1.3 of [RFC2330] provides three methods to generate incT the nominal duration of inter-packet interval, first bit to
Poisson sampling intervals. the reciprocal of lambda is the average first bit, with value 0.0200, expressed in units of seconds, as a
packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ positive value of type decimal64 with fraction digits = 4 (see
lambda, in seconds. section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds
(0.1 ms).
Method 3 SHALL be used, where given a start time (Run-time dT the duration of the interval for allowed sample start times, with
Parameter), the subsequent send times are all computed prior to value 1.0, expressed in units of seconds, as a positive value of
measurement by computing the pseudo-random distribution of inter- type decimal64 with fraction digits = 4 (see section 9.3 of
packet send times, (truncating the distribution as specified in the [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms).
Run-time Parameter, Trunc), and the Src sends each packet at the
computed times.
Note that Trunc is the upper limit on inter-packet times in the T0 the actual start time of the periodic stream, (format "date-and-
Poisson distribution. A random value greater than Trunc is set equal time" as specified in Section 5.6 of [RFC3339], see also Section 3
to Trunc instead. of [RFC6991]).
NOTE: an initiation process with a number of control exchanges
resulting in unpredictable start times (within a time interval) may
be sufficient to avoid synchronization of periodic streams, and
therefore a valid replacement for selecting a start time at random
from a fixed interval.
The T0 parameter will be reported as a measured parameter.
Parameters incT and dT are Fixed Parameters.
4.3.3. Traffic Filtering (observation) Details 4.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 14, line 28 skipping to change at page 15, line 41
[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 = 4 (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 = 4 (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.
4.3.6. Roles 4.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 Src. Dst waits for each packet from Src and sends a return packet to Src.
4.4. Output 4.4. Output
skipping to change at page 16, line 6 skipping to change at page 17, line 4
Tf the end of a measurement interval, (format "date-and-time" as Tf the end of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of 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]. [RFC2330].
TotalPkts the count of packets sent by the Src to Dst during the TotalPkts the count of packets sent by the Src to Dst during the
measurement interval. measurement interval.
For For
RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile:
RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile:
95Percentile The time value of the result is expressed in units of 95Percentile The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see section 9.3 of [RFC6020]) with resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as the 64-bit NTP timestamp as
For For
RTLoss_Active_IP-UDP-Poisson_RFCXXXXsecY_Percent_LossRatio: RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio:
Percentile The numeric value of the result is expressed in units of Percentile The numeric value of the result is expressed in units of
lost packets to total packets times 100%, as a positive value of lost packets to total packets times 100%, as a positive value of
type decimal64 with fraction digits = 9 (see section 9.3 of type decimal64 with fraction digits = 9 (see section 9.3 of
[RFC6020]) with resolution of 0.0000000001. [RFC6020]) with resolution of 0.0000000001.
4.4.3. Metric Units 4.4.3. Metric Units
<insert units for the measured results, and the reference <insert units for the measured results, and the reference
specification>. specification>.
skipping to change at page 18, line 9 skipping to change at page 18, line 51
<skipping some Summary columns for now> <skipping some Summary columns for now>
5.1.1. ID (Identifier) 5.1.1. ID (Identifier)
<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-Periodic_RFCXXXXsecY_Seconds_95Percentile
5.1.3. URIs 5.1.3. URIs
URI: Prefix urn:ietf:metrics:perf:<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 periodic stream, and the Output is expressed as
percentile of the packet delay variation distribution. the 95th percentile of the packet delay variation distribution.
5.1.5. Change Controller 5.1.5. Change Controller
<org or person > <org or person >
IETF IETF
5.1.6. Version (of Registry Format) 5.1.6. Version (of Registry Format)
1.0 1.0
skipping to change at page 20, line 49 skipping to change at page 21, line 43
which calculates the one-way delay value MAY enforce the Tmax which calculates the one-way delay value MAY enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and Section 5 of [RFC6703] for background
on this analysis choice. on this analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully-arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to dis-ambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
If a standard measurement protocol is employed, then the measurement If a standard measurement protocol is employed, then the measurement
process will determine the sequence numbers or timestamps applied to process will determine the sequence numbers or timestamps applied to
test packets after the Fixed and Runtime parameters are passed to test packets after the Fixed and Runtime parameters are passed to
that process. The chosen measurement protocol will dictate the that process. The chosen measurement protocol will dictate the
format of sequence numbers and time-stamps, if they are conveyed in format of sequence numbers and time-stamps, if they are conveyed in
the packet payload. the packet payload.
5.3.2. Packet Stream Generation 5.3.2. Packet Stream Generation
<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 [RFC2330] provides three methods to generate This section gives the details of the packet traffic which is the
Poisson sampling intervals. the reciprocal of lambda is the average basis for measurement. In IPPM metrics, this is called the Stream,
packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ and can easily be described by providing the list of stream
lambda, in seconds. parameters.
Method 3 SHALL be used, where given a start time (Run-time Section 3 of [RFC3432] prescribes the method for generating Periodic
Parameter), the subsequent send times are all computed prior to streams using associated parameters.
measurement by computing the pseudo-random distribution of inter-
packet send times, (truncating the distribution as specified in the
Parameter Trunc), and the Src sends each packet at the computed
times.
Note that Trunc is the upper limit on inter-packet times in the incT the nominal duration of inter-packet interval, first bit to
Poisson distribution. A random value greater than Trunc is set equal first bit, with value 0.0200, expressed in units of seconds, as a
to Trunc instead. positive value of type decimal64 with fraction digits = 4 (see
section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds
(0.1 ms).
Reciprocal_lambda average packet interval for Poisson Streams dT the duration of the interval for allowed sample start times, with
expressed in units of seconds, as a positive value of type value 1.0, expressed in units of seconds, as a positive value of
decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) type decimal64 with fraction digits = 4 (see section 9.3 of
with resolution of 0.0001 seconds (0.1 ms), and with lossless [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms).
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 T0 the actual start time of the periodic stream, (format "date-and-
seconds, as a positive value of type decimal64 with fraction time" as specified in Section 5.6 of [RFC3339], see also Section 3
digits = 4 (see section 9.3 of [RFC6020]) with resolution of of [RFC6991]).
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 NOTE: an initiation process with a number of control exchanges
this limit will be clipped and set to the limit value). Trunc = resulting in unpredictable start times (within a time interval) may
30.0000 seconds. be sufficient to avoid synchronization of periodic streams, and
therefore a valid replacement for selecting a start time at random
from a fixed interval.
The T0 parameter will be reported as a measured parameter.
Parameters incT and dT are Fixed Parameters.
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 24, line 48 skipping to change at page 25, line 48
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
noise, and thus inaccurate. noise, and thus inaccurate.
5.5. Administrative items 5.5. Administrative items
5.5.1. Status 5.5.1. Status
<current or depricated> <current or deprecated>
5.5.2. Requestor (keep?) 5.5.2. Requestor (keep?)
<name of individual or RFC, etc.> <name of individual or RFC, etc.>
5.5.3. Revision 5.5.3. Revision
1.0 1.0
5.5.4. Revision Date 5.5.4. Revision Date
skipping to change at page 26, line 26 skipping to change at page 27, line 26
URI: Prefix urn:ietf:metrics:perf:<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
RTDNS: This metric assesses the response time, the interval from the RTDNS: This metric assesses the response time, the interval from the
query transmission to the response. query transmission to the response.
RLDNS: This metric indicates that the respnse was deemed lost. In RLDNS: This metric indicates that the response was deemed lost. In
other words, the response time exceeded the maximum waiting time. other words, the response time exceeded the maximum waiting time.
6.1.5. Change Controller 6.1.5. Change Controller
IETF IETF
6.1.6. Version (of Registry Format) 6.1.6. Version (of Registry Format)
1.0 1.0
skipping to change at page 30, line 19 skipping to change at page 31, line 19
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and Section 5 of [RFC6703] for background on this analysis
choice. choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully-arriving
reply. Therefore, sequence numbers or other send-order reply. Therefore, sequence numbers or other send-order
identification MUST be retained at the Src or included with each identification MUST be retained at the Src or included with each
packet to dis-ambiguate packet reordering if it occurs. Sequence packet to disambiguate packet reordering if it occurs. Sequence
number is part of the payload described under Fixed Parameters. number is part of the payload described under Fixed Parameters.
DNS Messages bearing Queries provide for random ID Numbers in the DNS Messages bearing Queries provide for random ID Numbers in the
Identification header field, so more than one query may be launched Identification header field, so more than one query may be launched
while a previous request is outstanding when the ID Number is used. while a previous request is outstanding when the ID Number is used.
IF a DNS response does not arrive within Tmax, the response time is IF a DNS response does not arrive within Tmax, the response time is
undefined, and RTDNS = 1. The Message ID SHALL be used to undefined, and RTDNS = 1. The Message ID SHALL be used to
disambiguate the successive queries. disambiguate the successive queries.
@@@@ This would require support of ID generation and population in @@@@ 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. the Query Message, but we would choose ONE before proceeding.
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.
In addition to operations described in [RFC2681], the Src MUST parse In addition to operations described in [RFC2681], the Src MUST parse
the DNS headers of the reply and prepare the information for the DNS headers of the reply and prepare the information for
subsequent reporting as a measured result, along with the Round-Trip subsequent reporting as a measured result, along with the Round-Trip
Delay. Delay.
6.3.2. Packet Stream Generation 6.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section 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> <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 Reciprocal_lambda average packet rate, thus the Run-time Parameter is Reciprocal_lambda
= 1/lambda, in seconds. = 1/lambda, in seconds.
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
skipping to change at page 33, line 37 skipping to change at page 34, line 37
(format "date-and-time" as specified in Section 5.6 of [RFC3339], (format "date-and-time" as specified in Section 5.6 of [RFC3339],
see also Section 3 of [RFC6991]). The UTC Time Zone is required see also Section 3 of [RFC6991]). The UTC Time Zone is required
by Section 6.1 of [RFC2330]. by Section 6.1 of [RFC2330].
dT The time value of the round-trip delay to receive the DNS dT The time value of the round-trip delay to receive the DNS
response, expressed in units of seconds, as a positive value of response, expressed in units of seconds, as a positive value of
type decimal64 with fraction digits = 9 (see section 9.3 of type decimal64 with fraction digits = 9 (see section 9.3 of
[RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as per with lossless conversion to/from the 64-bit NTP timestamp as per
section 6 of RFC [RFC5905]. This value is undefined when the section 6 of RFC [RFC5905]. This value is undefined when the
response packet is not received at Src within waiting time Tmxax response packet is not received at Src within waiting time Tmax
seconds. seconds.
Rcode The value of the Rcode field in the DNS response header, Rcode The value of the Rcode field in the DNS response header,
expressed as a uint64 as specified in section 9.2 of [RFC6020]. expressed as a uint64 as specified in section 9.2 of [RFC6020].
Non-zero values convey errors in the response, and such replies Non-zero values convey errors in the response, and such replies
must be analyzed separately from successful requests. must be analyzed separately from successful requests.
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
skipping to change at page 34, line 31 skipping to change at page 35, line 31
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
noise, and thus inaccurate. 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 deprecated>
6.5.2. Requestor 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
skipping to change at page 39, line 24 skipping to change at page 40, line 24
which calculates the one-way delay value MAY enforce the Tmax which calculates the one-way delay value MAY enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and Section 5 of [RFC6703] for background
on this analysis choice. on this analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully-arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to dis-ambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
Since a standard measurement protocol is employed [RFC5357], then the Since a standard measurement protocol is employed [RFC5357], then the
measurement process will determine the sequence numbers or timestamps measurement process will determine the sequence numbers or timestamps
applied to test packets after the Fixed and Runtime parameters are applied to test packets after the Fixed and Runtime parameters are
passed to that process. The measurement protocol dictates the format passed to that process. The measurement protocol dictates the format
of sequence numbers and time-stamps conveyed in the TWAMP-Test packet of sequence numbers and time-stamps conveyed in the TWAMP-Test packet
payload. payload.
7.3.2. Packet Stream Generation 7.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section 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> <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 spacing, thus the Run-time Parameter is average packet spacing, thus the Run-time Parameter is
Reciprocal_lambda = 1/lambda, in seconds. Reciprocal_lambda = 1/lambda, in seconds.
Method 3 SHALL be used, where given a start time (Run-time Method 3 SHALL be used, where given a start time (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
Parameter Trunc), and the Src sends each packet at the computed Parameter Trunc), and the Src sends each packet at the computed
times. times.
skipping to change at page 45, line 30 skipping to change at page 46, line 30
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
noise, and thus inaccurate. 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 deprecated>
7.5.2. Requestor (keep?) 7.5.2. Requestor (keep?)
name or RFC, etc. name or RFC, etc.
7.5.3. Revision 7.5.3. Revision
1.0 1.0
7.5.4. Revision Date 7.5.4. Revision Date
skipping to change at page 50, line 4 skipping to change at page 50, line 51
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 [RFC7679] and section 4.6 of Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of
[RFC7679] using the Type-P and Tmax defined under Fixed Parameters. [RFC7679] using the Type-P and Tmax defined under Fixed Parameters.
However, a Periodic stream is used, as defined in [RFC3432].
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the OWLoss metric. delay, and counted for the OWLoss metric.
The calculations on the one-way delay SHALL be performed on the The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MAY enforce the Tmax which calculates the one-way delay value MAY enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and Section 5 of [RFC6703] for background
on this analysis choice. on this analysis choice.
The reference method requires some way to distinguish between The reference method requires some way to distinguish between
different packets in a stream to establish correspondence between different packets in a stream to establish correspondence between
sending times and receiving times for each successfully-arriving sending times and receiving times for each successfully-arriving
packet. Sequence numbers or other send-order identification MUST be packet. Sequence numbers or other send-order identification MUST be
retained at the Src or included with each packet to dis-ambiguate retained at the Src or included with each packet to disambiguate
packet reordering if it occurs. packet reordering if it occurs.
Since a standard measurement protocol is employed [RFC5357], then the Since a standard measurement protocol is employed [RFC5357], then the
measurement process will determine the sequence numbers or timestamps measurement process will determine the sequence numbers or timestamps
applied to test packets after the Fixed and Runtime parameters are applied to test packets after the Fixed and Runtime parameters are
passed to that process. The measurement protocol dictates the format passed to that process. The measurement protocol dictates the format
of sequence numbers and time-stamps conveyed in the TWAMP-Test packet of sequence numbers and time-stamps conveyed in the TWAMP-Test packet
payload. payload.
8.3.2. Packet Stream Generation 8.3.2. Packet Stream Generation
skipping to change at page 51, line 49 skipping to change at page 52, line 49
[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.
>>> should Periodic run-time params be fixed instead? probably yes if @@@@ should Periodic run-time params be fixed instead? Probably yes
modeling a specific version of tests. Note in the NAME, i.e. if 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 Src. Dst waits for each packet from Src and sends a return packet to Src.
skipping to change at page 52, line 24 skipping to change at page 53, line 24
8.4. Output 8.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the Output of measurements
using the metric. using the metric.
8.4.1. Type 8.4.1. Type
<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 Reference Definition for Latency Types.
8.4.2. Reference Definition 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 T0 the start of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of 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
skipping to change at page 55, line 16 skipping to change at page 56, line 16
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see section 9.3 of [RFC6020]) with resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from 0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] the 64-bit NTP timestamp as per section 6 of 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, where
<statistic> is one of:
o 95Percentile
o Mean
o Min
o Max
o StdDev
The One-way Loss Ratio is expressed as a percentage of lost packets The One-way Loss Ratio is expressed as a percentage of lost packets
to total packets sent. to total packets sent.
8.4.4. Calibration 8.4.4. Calibration
Section 3.7.3 of [RFC7679] provides a means to quantify the Section 3.7.3 of [RFC7679] provides a means to quantify the
systematic and random errors of a time measurement. In-situ systematic and random errors of a time measurement. In-situ
calibration could be enabled with an internal loopback that includes calibration could be enabled with an internal loopback that includes
as much of the measurement system as possible, performs address as much of the measurement system as possible, performs address
skipping to change at page 56, line 15 skipping to change at page 57, line 28
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
noise, and thus inaccurate. 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 deprecated>
8.5.2. Requestor (keep?) 8.5.2. Requestor (keep?)
name or RFC, etc. name or RFC, etc.
8.5.3. Revision 8.5.3. Revision
1.0 1.0
8.5.4. Revision Date 8.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
8.6. Comments and Remarks 8.6. Comments and Remarks
Additional (Informational) details for this entry Additional (Informational) details for this entry
9. ver08 BLANK Registry Entry 9. ICMP Round-trip Latency and Loss Registry Entries
This section gives an initial registry entry for .... This section specifies three initial registry entries for the ICMP
Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio.
This section specifies four Registry entries with many common
columns.
All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes
two closely-related registry entries. As a result, IANA is also
asked to assign four corresponding URNs and URLs to each Named
Metric.
9.1. Summary 9.1. Summary
This category includes multiple indexes to the registry entries, the This category includes multiple indexes to the registry entry: the
element ID and metric name. element ID and metric name.
9.1.1. ID (Identifier) 9.1.1. ID (Identifier)
<insert numeric identifier, an integer> <insert a numeric identifier, an integer, TBD>
IANA is asked to assign different numeric identifiers to each of the
four Named Metrics.
9.1.2. Name 9.1.2. Name
<insert name according to metric naming convention> <insert name according to metric naming convention>
RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Seconds_<statistic>
where <statistic> is one of:
o Mean
o Min
o Max
RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Percent_LossRatio
9.1.3. URIs 9.1.3. URIs
URI: Prefix urn:ietf:metrics:perf:<name> URN: Prefix urn:ietf:metrics:perf:<name>
URL: URL: http://<TBD by IANA>/<name>
9.1.4. Description 9.1.4. Description
TBD. RTDelay: This metric assesses the delay of a stream of ICMP packets
exchanged between two hosts (which are the two measurement points),
and the Output is the Round-trip delay for all successfully exchanged
packets expressed as the <statistic> of their conditional delay
distribution, where <statistic> is one of:
9.1.5. Reference o Mean
<reference to the RFC of spec where the registry entry is defined> o Min
9.1.6. Change Controller o Max
<org or person > RTLoss: This metric assesses the loss ratio of a stream of ICMP
packets exchanged between two hosts (which are the two measurement
points), and the Output is the Round-trip loss ratio for all
successfully exchanged packets expressed as a percentage.
9.1.7. Version (of Registry Format) 9.1.5. Change Controller
<currently 1.0> IETF
9.1.6. Version (of Registry Format)
1.0
9.2. Metric Definition 9.2. Metric Definition
This category includes columns to prompt the entry of all necessary This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters. and values of input factors, called fixed parameters.
9.2.1. Reference Definition 9.2.1. Reference Definition
<Full bibliographic reference to an immutable doc.> <Full bibliographic reference to an immutable doc.>
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.
[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
singleton (single value) Round-trip delay metric. Section 3.4 of
[RFC2681] provides the reference definition expanded to cover a
multi-singleton sample. Note that terms such as singleton and sample
are defined in Section 11 of [RFC2330].
Note that although the [RFC2681] definition of "Round-trip-Delay
between Src and Dst" is directionally ambiguous in the text, this
metric tightens the definition further to recognize that the host in
the "Src" role will send the first packet to "Dst", and ultimately
receive the corresponding return packet from "Dst" (when neither are
lost).
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
variable "dT" has been re-used in other IPPM literature to refer to
different quantities, and cannot be used as a global variable name.
Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012.
[RFC6673]
Both delay and loss metrics employ a maximum waiting time for
received packets, so the count of lost packets to total packets sent
is the basis for the loss ratio calculation as per Section 6.1 of
[RFC6673].
9.2.2. Fixed Parameters 9.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 as defined in Section 13 of [RFC2330]:
o IPv4 header values:
* DSCP: set to 0
* TTL: set to 255
* Protocol: Set to 01 (ICMP)
o IPv6 header values:
* DSCP: set to 0
* Hop Limit: set to 255
* Protocol: Set to 01 (ICMP)
o ICMP header values:
* Type: 8 (Echo Request)
* Code: 0
* Checksum: the checksum MUST be calculated and included in the
header
* (Identifier and Sequence Number set at Run-Time)
o ICMP Payload
* total of 32 bytes of random info
Other measurement parameters:
o Tmax: a loss threshold waiting time
* 3.0, expressed in units of seconds, as a positive value of type
decimal64 with fraction digits = 4 (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].
9.3. Method of Measurement 9.3. Method of Measurement
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations. unambiguous methods for implementations.
9.3.1. Reference Method 9.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-
Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section
3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under
Fixed Parameters.
The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the RTLoss metric.
The calculations on the delay (RTD) 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 RTD 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 disambiguate
packet reordering if it occurs.
The measurement process will determine the sequence numbers applied
to test packets after the Fixed and Runtime parameters are passed to
that process. The ICMP measurement process and protocol will dictate
the format of sequence numbers and other identifiers.
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
possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of
[RFC6673] presents additional requirements which MUST be included in
the method of measurement for this metric.
9.3.2. Packet Stream Generation 9.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
basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be described by providing the list of stream
parameters.
The ICMP metrics use a sending discipline called "SendOnRcv" or Send
On Receive. This is a modification of Section 3 of [RFC3432], which
prescribes the method for generating Periodic streams using
associated parameters:
incT the nominal duration of inter-packet interval, first bit to
first bit
dT the duration of the interval for allowed sample start times
T0 the actual start time of the periodic stream
The incT and T0 stream parameters will be specified as Run-time
parameters, dT is not used in SendOnRcv.
A SendOnRcv sender behaves exactly like a Periodic stream generator
while all reply packets arrive with RTD < incT, and the inter-packet
interval will be constant.
If a reply packet arrives with RTD >= incT, then the inter-packet
interval for the next sending time is nominally RTD.
If a reply packet fails to arrive within Tmax, then the inter-packet
interval for the next sending time is nominally Tmax.
If an immediate send on reply arrival is desired, then set incT=0.
9.3.3. Traffic Filtering (observation) Details 9.3.3. Traffic Filtering (observation) Details
<insert the measured results based on a filtered version of the The measured results based on a filtered version of the packets
packets observed, and this section provides the filter details (when observed, and this section provides the filter details (when
present), and section reference>. present).
<section reference>.
NA
9.3.4. Sampling Distribution 9.3.4. Sampling Distribution
<insert time distribution details, or how this is diff from the <insert time distribution details, or how this is diff from the
filter> filter>
NA
9.3.5. Run-time Parameters and Data Format 9.3.5. Run-time Parameters and Data Format
<list of run-time parameters, and any reference(s)>. Run-time Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results
for the context to be complete.
<list of run-time parameters, and their data formats>
Src the IP address of the host in the Src Role (format ipv4-address-
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see Section 4 of [RFC6991])
Dst the IP address of the host in the Dst Role (format ipv4-address-
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see section 4 of [RFC6991])
T0 a time, the start of a measurement interval, (format "date-and-
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.
Count The total count of ICMP Echo Requests to send, formatted as a
uint16, as per section 9.2 of [RFC6020].
(see the Packet Stream Generation section for additional Run-time
parameters)
9.3.6. Roles 9.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
Dst.
Dst waits for each packet from Src and sends a return packet to Src.
9.4. Output 9.4. Output
This category specifies all details of the Output of measurements This category specifies all details of the Output of measurements
using the metric. using the metric.
9.4.1. Type 9.4.1. Type
<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 Reference Definition for Latency Types.
LossRatio -- the count of lost packets to total packets sent is the
basis for the loss ratio calculation as per Section 6.1 of [RFC6673].
9.4.2. Reference Definition 9.4.2. Reference Definition
<pointer to section/spec where output type/format is defined> <describe the data format for each type of result>
For all output types ---
T0 the start of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of
[RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as
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].
TotalCount the count of packets actually sent by the Src to Dst
during the measurement interval.
For LossRatio -- the count of lost packets to total packets sent is
the basis for the loss ratio calculation as per Section 4.1 of
[RFC7680].
For each <statistic>, one of the following sub-sections apply:
9.4.2.1. Mean
The mean SHALL be calculated using the conditional distribution of
all packets with a finite 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.2.2 of [RFC6049] for details on calculating this
statistic, and 4.2.3 of [RFC6049].
Mean 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]
9.4.2.2. Min
The minimum SHALL be calculated using the conditional distribution of
all packets with a finite 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.2 of [RFC6049] for details on calculating this
statistic, and 4.3.3 of [RFC6049].
Min 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]
9.4.2.3. Max
The maximum SHALL be calculated using the conditional distribution of
all packets with a finite 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.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
as follows:
Max = (FiniteDelay [j])
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n
Max 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]
9.4.3. Metric Units 9.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 Round-trip Delay is expressed in seconds, where
<statistic> is one of:
o Mean
o Min
o Max
The Round-trip Loss Ratio is expressed as a percentage of lost
packets to total packets sent.
9.4.4. Calibration 9.4.4. Calibration
<describe the error calibration, a way to indicate that the results Section 3.7.3 of [RFC7679] provides a means to quantify the
were collected in a calbration mode of operation, and a way to report systematic and random errors of a time measurement. In-situ
internal status metrics related to calibration, such as time offset> calibration could be enabled with an internal loopback at the Source
host 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.
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.
9.5. Administrative items 9.5. Administrative items
9.5.1. Status 9.5.1. Status
<current or depricated> <current or deprecated>
9.5.2. Requestor 9.5.2. Requestor (keep?)
<name of individual or Internet Draft, etc.> name or RFC, etc.
9.5.3. Revision 9.5.3. Revision
1.0 1.0
9.5.4. Revision Date 9.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
9.6. Comments and Remarks 9.6. Comments and Remarks
Additional (Informational) details for this entry Additional (Informational) details for this entry
10. Example RTCP-XR Registry Entry 10. TCP Round-Trip Delay and Loss Registry Entries
This section specifies three initial registry entries for the Passive
assessment of TCP Round-Trip Delay (RTD) and another entry for TCP
Round-trip Loss Count.
This section specifies four Registry entries with many common
columns.
All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes
four closely-related registry entries. As a result, IANA is also
asked to assign four corresponding URNs and URLs to each Named
Metric.
10.1. Summary
This category includes multiple indexes to the registry entry: the
element ID and metric name.
10.1.1. ID (Identifier)
<insert a numeric identifier, an integer, TBD>
IANA is asked to assign different numeric identifiers to each of the
four Named Metrics.
10.1.2. Name
<insert name according to metric naming convention>
RTDelay_Passive_IP-TCP_RFCXXXXsecY_Seconds_<statistic>
where <statistic> is one of:
o Mean
o Min
o Max
RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count
10.1.3. URIs
URN: Prefix urn:ietf:metrics:perf:<name>
URL: http://<TBD by IANA>/<name>
10.1.4. Description
RTDelay: This metric assesses the round-trip delay of TCP packets
constituting a single connection, exchanged between two hosts. The
Observation Point [RFC7011] is assumed to be in the network at a
remote point from the end hosts. The Output is the Round-trip delay
for all successfully exchanged packets expressed as the <statistic>
of their conditional delay distribution, where <statistic> is one of:
o Mean
o Min
o Max
RTLoss: This metric assesses the estimated loss count for TCP packets
constituting a single connection, exchanged between two hosts. The
Observation Point [RFC7011] is assumed to be in the network at a
remote point from the end hosts. The Output is the estimated Loss
Count for the measurement interval.
10.1.5. Change Controller
IETF
10.1.6. Version (of Registry Format)
1.0
10.2. Metric Definition
This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.
10.2.1. Reference Definitions
<Full bibliographic reference to an immutable doc.>
Although there is no RFC that describes passive measurement of Round-
Trip Delay,
@@@@ is this true??? Searches seem to say so.
the parallel definition for Active measurement is:
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999.
[RFC2681]
<specific section reference and additional clarifications, if needed>
This metric definition uses the terms singleton and sample as defined
in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the
reference definition of the singleton (single value) Round-trip delay
metric. Section 3.4 of [RFC2681] provides the reference definition
expanded to cover a multi-singleton sample.)
With the Observation Point [RFC7011] (OP) located between the hosts
participating in the TCP connection, the Round-trip Delay metric
requires two individual measurements between the OP and each host,
such that the Spatial Composition [RFC6049]of the measurements yields
a Round-trip Delay singleton.
Using the direction of TCP SYN transmission to anchor the
nomenclature, host A sends the SYN and host B replies with SYN-ACK
during connection establishment. The direction of SYN transfer is
the Forward direction of transmission, from A through OP to B
(Reverse is B through OP to A).
Traffic filters reduce the packet stream at the OP to a Qualified
bidirectional flow packets.
In the definitions below, Corresponding Packets are transferred in
different directions and convey a common value in a TCP header field
that establishes correspondence (to the extent possible). Examples
may be found in the TCP timestamp fields.
@@@@ Note the first-bit last bit questions in the definitions below.
For a real number, RTD_fwd, >> the Round-trip Delay in the Forward
direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP
observed (the first bit of ?) a Qualified packet to host B at wire-
time T', that host B received that packet and sent a Corresponding
Packet back to host A, and that OP observed (the last bit of ?) that
packet at wire-time T' + RTD_fwd.
For a real number, RTD_rev, >> the Round-trip Delay in the Reverse
direction from OP to host A at time T'' is RTD_rev << REQUIRES that
OP observed (the first bit of ?) a Qualified packet to host A at
wire-time T'', that host A received that packet and sent a
Corresponding Packet back to host B, and that OP observed (the last
bit of ?) that packet at wire-time T'' + RTD_rev.
Ideally, the packet sent from host B to host A in both definitions
above SHOULD be the same packet (or, when measuring RTD_rev first,
the packet from host A to host B in both definitions should be the
same).
The REQUIRED Composition Function for a singleton of Round-trip Delay
at time T (where T is the earliest of T' and T'' above) is:
RTDelay = RTD_fwd + RTD_rev
Note that when OP is located at host A or host B, one of the terms in
RTDelay will be zero or negligible.
The definition of Round-trip Loss Count uses the nomenclature
developed above, based on observation of the TCP header sequence
numbers and storing the sequence number gaps observed. Packet Losses
can be inferred from:
o Out-of-order segments: TCP segments are normally monotonically
increasing. Section 3 of [RFC4737] describes the notion of "next
expected" sequence numbers which can be adapted to TCP segments
(for the purpose of detecting reordered packets). Observation of
out-of-order segments indicates loss on the path prior to the OP,
and creates a gap.
o Duplicate segments: Section 2 of [RFC5560] defines identical
packets and is suitable for evaluation of TCP packets to detect
duplication. Observation of duplicate segments *without a
corresponding gap* indicates loss on the path following the OP
(because they overlap part of the delivered sequence numbers
already observed at OP).
Each observation of an out-of-order or duplicate infers a singleton
of loss, but composition of Round-trip Loss Counts will be conducted
over a measurement interval which is synonymous with a single TCP
connection.
With the above observations in the Forward direction over a
measurement interval, the count of out-of-order and duplicate
segments is defined as RTL_fwd. Comparable observations in the
Reverse direction are defined as RTL_rev.
For a measurement interval (corresponding to a single TCP
connection), T0 to Tf, the REQUIRED Composition Function for a the
two single-direction counts of inferred loss is:
RTLoss = RTL_fwd + RTL_rev
10.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed>
Traffic Filters:
o IPv4 header values:
* DSCP: set to 0
* Protocol: Set to 06 (TCP)
o IPv6 header values:
* DSCP: set to 0
* Protocol: Set to 06 (TCP)
o TCP header values:
* Flags: ACK, SYN, others??
* Checksum: the checksum MUST be calculated and included in the
header
* Timestamp Option (TSopt): Set
+ Kind: 8
+ Length: 10 bytes
o
10.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations.
10.3.1. Reference Methods
<for metric, insert relevant section references and supplemental
info>
The foundation methodology for this metric is defined in Section 4 of
[RFC7323] using the Timestamp Option with modifications that allow
application at a mid-path Observation Point (OP) [RFC7011]. Further
details and applicable heuristics were derived from [Strowes] and
[Trammell-14].
The Traffic Filter at the OP is configured to observe a single TCP
connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers
the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK
pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton
of RTDelay as RTDelay-SA (SYN-ACK = SA, composed using the forward
and reverse measurement pair). RTDelay-SA SHOULD be treated
separately from other RTDelays on data-bearing packets and their
ACKs. The RTDelay-SA value MAY be used as a sanity check on other
Composed values of RTDelay.
@@@@ Should we add a separate singleton metric for RTDelay-SA ??
(seems reasonable and useful, but no loss metric however)
For payload bearing packets, the OP measures the time interval
between observation of a packet with Sequence Number s, and the
corresponding ACK with same Sequence number. When the payload is
transferred from host A to host B, the observed interval is RTD_fwd.
Because many data transfers are unidirectional (say, in the Forward
direction from host A to host B), it is necessary to use pure ACK
packets with Timestamp (TSval) and their Timestamp value echo to
perform a RTD_rev measurement. The time interval between observation
of the ACK from B to A, and the corresponding packet with Timestamp
echo (TSecr) is the RTD_rev.
Delay Measurement Filtering Heuristics:
If Data payloads were transferred in both Forward and Reverse
directions, then the Round-Trip Time Measurement Rule in Section 4.1
of [RFC7323] could be applied. This rule essentially excludes any
measurement using a packet unless it makes progress in the transfer
(advances the left edge of the send window, consistent
with[Strowes]).
A different heuristic from [Trammell-14] is to exclude any RTD_rev
that is larger than previously observed values. This would tend to
exclude Reverse measurements taken when the Application has no data
ready to send, because considerable time could be added to RTD_rev
from this source of error.
The statistic calculations to summarize the delay (RTDelay) SHALL be
performed on the conditional distribution, conditioned on successful
Forward and Reverse measurements which follow the Heuristics.
Method for Inferring Loss:
The OP tracks sequence numbers and stores gaps for each direction of
transmission, as well as the next-expected sequence number as in
[Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order
segments and Duplicate segments.
Loss Measurement Filtering Heuristics:
[Trammell-14] adds a window of evaluation based on the RTDelay.
Spurious (unneeded) retransmissions (observed as duplicates) can also
be reduced this way, as described in [Trammell-14].
Sources of Error:
The principal source of RTDelay error is the host processing time to
return a packet that defines the termination of a time interval. The
heuristics above intend to mitigate these errors by excluding
measurements where host processing time is a significant part of
RTD_fwd or RTD_rev.
A key source of RTLoss error is observation loss, described in
section 3 of [Trammell-14].
10.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the
basis for measurement. In IPPM metrics, this is called the Stream,
and can easily be described by providing the list of stream
parameters.
NA
10.3.3. Traffic Filtering (observation) Details
The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).
The Fixed Parameters above give a portion of the Traffic Filter.
Other aspects will be supplied as Run-time Parameters (below).
10.3.4. Sampling Distribution
<insert time distribution details, or how this is diff from the
filter>
This metric requires a complete sample of all packets that qualify
according to the Traffic Filter criteria.
10.3.5. Run-time Parameters and Data Format
Run-time Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results
for the context to be complete.
<list of run-time parameters, and their data formats>
Src the IP address of the host in the host A Role (format ipv4-
address-no-zone value for IPv4, or ipv6-address-no-zone value for
IPv6, see Section 4 of [RFC6991])
Dst the IP address of the host in the host B (format ipv4-address-
no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
see section 4 of [RFC6991])
T0 a time, the start of a measurement interval, (format "date-and-
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 Td is to be interpreted as the Duration of the measurement
interval. The start time is controlled through other means.
Td Optionally, the end of a measurement interval, (format "date-and-
time" as specified in Section 5.6 of [RFC3339], see also Section 3
of [RFC6991]), or the duration (see T0). The UTC Time Zone is
required by Section 6.1 of [RFC2330]. Alternatively, the end of
the measurement interval MAY be controlled by the measured
connection, where the second pair of FIN and ACK packets exchanged
between host A and B effectively ends the interval.
... ...
10.3.6. Roles
<lists the names of the different roles from the measurement method>
host A launches the SYN packet to open the connection, and
synonymous with an IP address.
host B replies with the SYN-ACK packet to open the connection, and
synonymous with an IP address.
10.4. Output
This category specifies all details of the Output of measurements
using the metric.
10.4.1. Type
<insert name of the output type, raw or a selected summary statistic>
See subsection titles in Reference Definition for RTDelay Types.
For RTLoss -- the count of lost packets.
10.4.2. Reference Definition
<describe the data format for each type of result>
For all output types ---
T0 the start of a measurement interval, (format "date-and-time" as
specified in Section 5.6 of [RFC3339], see also Section 3 of
[RFC6991]). The UTC Time Zone is required by Section 6.1 of
[RFC2330].
Tf the end of a measurement interval, (format "date-and-time" as
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 end of the measurement interval MAY be controlled
by the measured connection, where the second pair of FIN and ACK
packets exchanged between host A and B effectively ends the
interval.
... ...
For RTLoss -- the count of lost packets.
For each <statistic>, one of the following sub-sections apply:
10.4.2.1. Mean
The mean SHALL be calculated using the conditional distribution of
all packets with a finite 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.2.2 of [RFC6049] for details on calculating this
statistic, and 4.2.3 of [RFC6049].
Mean 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]
10.4.2.2. Min
The minimum SHALL be calculated using the conditional distribution of
all packets with a finite 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.2 of [RFC6049] for details on calculating this
statistic, and 4.3.3 of [RFC6049].
Min 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]
10.4.2.3. Max
The maximum SHALL be calculated using the conditional distribution of
all packets with a finite 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.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
as follows:
Max = (FiniteDelay [j])
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n
Max 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]
10.4.3. Metric Units
<insert units for the measured results, and the reference
specification>.
The <statistic> of Round-trip Delay is expressed in seconds, where
<statistic> is one of:
o Mean
o Min
o Max
The Round-trip Loss Count is expressed as a number of packets.
10.4.4. Calibration
Passive measurements at an OP could be calibrated against an active
measurement (with loss emulation) at host A or B, where the active
measurement represents the ground-truth.
10.5. Administrative items
10.5.1. Status
<current or deprecated>
10.5.2. Requestor (keep?)
name or RFC, etc.
10.5.3. Revision
1.0
10.5.4. Revision Date
YYYY-MM-DD
10.6. Comments and Remarks
Additional (Informational) details for this entry
11. ver08 BLANK Registry Entry
This section gives an initial registry entry for ....
11.1. Summary
This category includes multiple indexes to the registry entries, the
element ID and metric name.
11.1.1. ID (Identifier)
<insert numeric identifier, an integer>
11.1.2. Name
<insert name according to metric naming convention>
11.1.3. URIs
URI: Prefix urn:ietf:metrics:perf:<name>
URL:
11.1.4. Description
TBD.
11.1.5. Reference
<reference to the RFC of spec where the registry entry is defined>
11.1.6. Change Controller
<org or person >
11.1.7. Version (of Registry Format)
<currently 1.0>
11.2. Metric Definition
This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.
11.2.1. Reference Definition
<Full bibliographic reference to an immutable doc.>
<specific section reference and additional clarifications, if needed>
11.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed>
11.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations.
11.3.1. Reference Method
<for metric, insert relevant section references and supplemental
info>
11.3.2. Packet Stream Generation
<list of generation parameters and section/spec references if needed>
11.3.3. Traffic Filtering (observation) Details
<insert the measured results based on a filtered version of the
packets observed, and this section provides the filter details (when
present), and section reference>.
11.3.4. Sampling Distribution
<insert time distribution details, or how this is diff from the
filter>
11.3.5. Run-time Parameters and Data Format
<list of run-time parameters, and any reference(s)>.
11.3.6. Roles
<lists the names of the different roles from the measurement method>
11.4. Output
This category specifies all details of the Output of measurements
using the metric.
11.4.1. Type
<insert name of the output type, raw or a selected summary statistic>
11.4.2. Reference Definition
<pointer to section/spec where output type/format is defined>
11.4.3. Metric Units
<insert units for the measured results, and the reference
specification>.
11.4.4. Calibration
<describe the error calibration, a way to indicate that the results
were collected in a calibration mode of operation, and a way to
report internal status metrics related to calibration, such as time
offset>
11.5. Administrative items
11.5.1. Status
<current or deprecated>
11.5.2. Requestor
<name of individual or Internet Draft, etc.>
11.5.3. Revision
1.0
11.5.4. Revision Date
YYYY-MM-DD
11.6. Comments and Remarks
Additional (Informational) details for this entry
12. Example RTCP-XR Registry Entry
This section is MAY BE DELETED or adapted before submission. This section is MAY BE DELETED or adapted before submission.
This section gives an example registry entry for the end-point metric This section gives an example registry entry for the end-point metric
described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric
reporting. reporting.
10.1. Registry Indexes 12.1. Registry Indexes
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.
10.1.1. Identifier 12.1.1. Identifier
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 12.1.2. Name
A metric naming convention is TBD. A metric naming convention is TBD.
10.1.3. URI 12.1.3. URI
Prefix urn:ietf:metrics:param:<name> Prefix urn:ietf:metrics:param:<name>
10.1.4. Status 12.1.4. Status
current current
10.1.5. Requestor 12.1.5. Requestor
Alcelip Mornuley Alcelip Mornuley
10.1.6. Revision 12.1.6. Revision
1.0 1.0
10.1.7. Revision Date 12.1.7. Revision Date
2014-07-04 2014-07-04
10.1.8. Description 12.1.8. Description
TBD. TBD.
10.1.9. Reference Specification(s) 12.1.9. Reference Specification(s)
[RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003]
10.2. Metric Definition 12.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. Section 3.2 of and values of input factors, called fixed parameters. Section 3.2 of
[RFC7003] provides the reference information for this category. [RFC7003] provides the reference information for this category.
10.2.1. Reference Definition 12.2.1. Reference Definition
Packets Discarded in Bursts: Packets Discarded in Bursts:
The total number of packets discarded during discard bursts. The The total number of packets discarded during discard bursts. The
measured value is unsigned value. If the measured value exceeds measured value is unsigned value. If the measured value exceeds
0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over-
range measurement. If the measurement is unavailable, the value range measurement. If the measurement is unavailable, the value
0xFFFFFF MUST be reported. 0xFFFFFF MUST be reported.
10.2.2. Fixed Parameters 12.2.2. Fixed Parameters
Fixed Parameters are input factors that must be determined and Fixed Parameters are input factors that must be determined and
embedded in the measurement system for use when needed. The values embedded in the measurement system for use when needed. The values
of these parameters is specified in the Registry. of these parameters is specified in the Registry.
Threshold: 8 bits, set to value = 3 packets. Threshold: 8 bits, set to value = 3 packets.
The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of
successive packets that must not be discarded prior to and following successive packets that must not be discarded prior to and following
a discard packet in order for this discarded packet to be regarded as a discard packet in order for this discarded packet to be regarded as
skipping to change at page 61, line 33 skipping to change at page 84, line 5
I=10: Interval Duration - the reported value applies to the most I=10: Interval Duration - the reported value applies to the most
recent measurement interval duration between successive metrics recent measurement interval duration between successive metrics
reports. reports.
I=11: Cumulative Duration - the reported value applies to the I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements. accumulation period characteristic of cumulative measurements.
Senders MUST NOT use the values I=00 or I=01. Senders MUST NOT use the values I=00 or I=01.
10.3. Method of Measurement 12.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. For the Burst/Gap Discard unambiguous methods for implementations. For the Burst/Gap Discard
Metric, it appears that the only guidance on methods of measurement Metric, it appears that the only guidance on methods of measurement
is in Section 3.0 of [RFC7003] and its supporting references. is in Section 3.0 of [RFC7003] and its supporting references.
Relevant information is repeated below, although there appears to be Relevant information is repeated below, although there appears to be
no section titled "Method of Measurement" in [RFC7003]. no section titled "Method of Measurement" in [RFC7003].
10.3.1. Reference Method 12.3.1. Reference Method
Metrics in this block report on burst/gap discard in the stream Metrics in this block report on burst/gap discard in the stream
arriving at the RTP system. Measurements of these metrics are made arriving at the RTP system. Measurements of these metrics are made
at the receiving end of the RTP stream. Instances of this metrics at the receiving end of the RTP stream. Instances of this metrics
block use the synchronization source (SSRC) to refer to the separate block use the synchronization source (SSRC) to refer to the separate
auxiliary Measurement Information Block [RFC6776], which describes auxiliary Measurement Information Block [RFC6776], which describes
measurement periods in use (see [RFC6776], Section 4.2). measurement periods in use (see [RFC6776], Section 4.2).
This metrics block relies on the measurement period in the This metrics block relies on the measurement period in the
Measurement Information Block indicating the span of the report. Measurement Information Block indicating the span of the report.
Senders MUST send this block in the same compound RTCP packet as the Senders MUST send this block in the same compound RTCP packet as the
Measurement Information Block. Receivers MUST verify that the Measurement Information Block. Receivers MUST verify that the
measurement period is received in the same compound RTCP packet as measurement period is received in the same compound RTCP packet as
this metrics block. If not, this metrics block MUST be discarded. this metrics block. If not, this metrics block MUST be discarded.
10.3.2. Stream Type and Stream Parameters 12.3.2. Stream Type and Stream Parameters
Since RTCP-XR Measurements are conducted on live RTP traffic, the Since RTCP-XR Measurements are conducted on live RTP traffic, the
complete description of the stream is contained in SDP messages that complete description of the stream is contained in SDP messages that
proceed the establishment of a compatible stream between two or more proceed the establishment of a compatible stream between two or more
communicating hosts. See Run-time Parameters, below. communicating hosts. See Run-time Parameters, below.
10.3.3. Output Type and Data Format 12.3.3. Output Type and Data Format
The output type defines the type of result that the metric produces. The output type defines the type of result that the metric produces.
o Value: Packets Discarded in Bursts o Value: Packets Discarded in Bursts
o Data Format: 24 bits o Data Format: 24 bits
o Reference: Section 3.2 of [RFC7003] o Reference: Section 3.2 of [RFC7003]
10.3.4. Metric Units 12.3.4. Metric Units
The measured results are apparently expressed in packets, although The measured results are apparently expressed in packets, although
there is no section of [RFC7003] titled "Metric Units". there is no section of [RFC7003] titled "Metric Units".
10.3.5. Run-time Parameters and Data Format 12.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. However, the values of these for the context to be complete. However, the values of these
parameters is not specified in the Registry, rather these parameters parameters is not specified in the Registry, rather these parameters
are listed as an aid to the measurement system implementor or user are listed as an aid to the measurement system implementor or user
(they must be left as variables, and supplied on execution). (they must be left as variables, and supplied on execution).
The Data Format of each Run-time Parameter SHALL be specified in this The Data Format of each Run-time Parameter SHALL be specified in this
column, to simplify the control and implementation of measurement column, to simplify the control and implementation of measurement
skipping to change at page 64, line 19 skipping to change at page 86, line 36
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
10.4. Comments and Remarks 12.4. Comments and Remarks
TBD. TBD.
11. Revision History 13. Revision History
This section may be removed for publication. It contains partial This section may be removed for publication. It contains overview
information on updtes. information on updates.
This draft replaced draft-mornuley-ippm-initial-registry. This draft replaced draft-mornuley-ippm-initial-registry.
In version 02, Section 4 has been edited to reflect recent discussion In version 02, Section 4 has been edited to reflect recent discussion
on the ippm-list: * Removed the combination or "Raw" and left 95th on the ippm-list: * Removed the combination or "Raw" and left 95th
percentile. * Hanging Indent on Run-time parameters (Fixed parameters percentile. * Hanging Indent on Run-time parameters (Fixed parameters
use bullet lists and other indenting formats. * Payload format for use bullet lists and other indenting formats. * Payload format for
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.
12. Security Considerations Version 05 * Revised several Poisson streams to Periodic, sections 4
& 5. * Addition of ICMP (ping) metrics in section 9. * First
implementation of Passive TCP RTT metrics in section 10.
14. 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 15. 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.
See the IANA Considerations section of See the IANA Considerations section of
[I-D.ietf-ippm-metric-registry] for additional requests and [I-D.ietf-ippm-metric-registry] for additional requests and
considerations. considerations.
14. Acknowledgements 16. 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, for suggesting the Passive TCP RTD
metric and supporting references, and for many other productive
suggestions. Thanks to Peter Koch, who provided several useful suggestions. 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. Thanks to Michelle Cotton participants in the LMAP working group. Thanks to Michelle Cotton
for her early IANA review, and to Amanda Barber for answering for her early IANA review, and to Amanda Barber for answering
questions related to the presentation of the registry and questions related to the presentation of the registry and
accessibility of the complete template via URL. accessibility of the complete template via URL.
15. References 17. References
15.1. Normative References 17.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, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<http://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679,
September 1999, <http://www.rfc-editor.org/info/rfc2679>. September 1999, <https://www.rfc-editor.org/info/rfc2679>.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, Packet Loss Metric for IPPM", RFC 2680,
DOI 10.17487/RFC2680, September 1999, DOI 10.17487/RFC2680, September 1999,
<http://www.rfc-editor.org/info/rfc2680>. <https://www.rfc-editor.org/info/rfc2680>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <http://www.rfc-editor.org/info/rfc2681>. September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<http://www.rfc-editor.org/info/rfc3393>. <https://www.rfc-editor.org/info/rfc3393>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
DOI 10.17487/RFC3432, November 2002, DOI 10.17487/RFC3432, November 2002,
<http://www.rfc-editor.org/info/rfc3432>. <https://www.rfc-editor.org/info/rfc3432>.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
DOI 10.17487/RFC4737, November 2006, DOI 10.17487/RFC4737, November 2006,
<http://www.rfc-editor.org/info/rfc4737>. <https://www.rfc-editor.org/info/rfc4737>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008, RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>. <https://www.rfc-editor.org/info/rfc5357>.
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",
RFC 5560, DOI 10.17487/RFC5560, May 2009,
<https://www.rfc-editor.org/info/rfc5560>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of
Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
<http://www.rfc-editor.org/info/rfc6049>. <https://www.rfc-editor.org/info/rfc6049>.
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
DOI 10.17487/RFC6673, August 2012, DOI 10.17487/RFC6673, August 2012,
<http://www.rfc-editor.org/info/rfc6673>. <https://www.rfc-editor.org/info/rfc6673>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <http://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <http://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
15.2. Informative References
[Brow00] Brownlee, N., "Packet Matching for NeTraMet 17.2. Informative References
Distributions", March 2000.
[RFC1242] Bradner, S., "Benchmarking Terminology for Network [RFC1242] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
July 1991, <http://www.rfc-editor.org/info/rfc1242>. July 1991, <https://www.rfc-editor.org/info/rfc1242>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August
2005, <http://www.rfc-editor.org/info/rfc4148>. 2005, <https://www.rfc-editor.org/info/rfc4148>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
Flow Information Export (IPFIX) Applicability", RFC 5472, Flow Information Export (IPFIX) Applicability", RFC 5472,
DOI 10.17487/RFC5472, March 2009, DOI 10.17487/RFC5472, March 2009,
<http://www.rfc-editor.org/info/rfc5472>. <https://www.rfc-editor.org/info/rfc5472>.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports", Carle, "Information Model for Packet Sampling Exports",
RFC 5477, DOI 10.17487/RFC5477, March 2009, RFC 5477, DOI 10.17487/RFC5477, March 2009,
<http://www.rfc-editor.org/info/rfc5477>. <https://www.rfc-editor.org/info/rfc5477>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <http://www.rfc-editor.org/info/rfc5481>. March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics
(IPPM) Registry of Metrics Are Obsolete", RFC 6248, (IPPM) Registry of Metrics Are Obsolete", RFC 6248,
DOI 10.17487/RFC6248, April 2011, DOI 10.17487/RFC6248, April 2011,
<http://www.rfc-editor.org/info/rfc6248>. <https://www.rfc-editor.org/info/rfc6248>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011, DOI 10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>. <https://www.rfc-editor.org/info/rfc6390>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, DOI 10.17487/RFC6703, August 2012, RFC 6703, DOI 10.17487/RFC6703, August 2012,
<http://www.rfc-editor.org/info/rfc6703>. <https://www.rfc-editor.org/info/rfc6703>.
[RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information
Reporting Using a Source Description (SDES) Item and an Reporting Using a Source Description (SDES) Item and an
RTCP Extended Report (XR) Block", RFC 6776, RTCP Extended Report (XR) Block", RFC 6776,
DOI 10.17487/RFC6776, October 2012, DOI 10.17487/RFC6776, October 2012,
<http://www.rfc-editor.org/info/rfc6776>. <https://www.rfc-editor.org/info/rfc6776>.
[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
of the RTP Monitoring Framework", RFC 6792, of the RTP Monitoring Framework", RFC 6792,
DOI 10.17487/RFC6792, November 2012, DOI 10.17487/RFC6792, November 2012,
<http://www.rfc-editor.org/info/rfc6792>. <https://www.rfc-editor.org/info/rfc6792>.
[RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003,
September 2013, <http://www.rfc-editor.org/info/rfc7003>. September 2013, <https://www.rfc-editor.org/info/rfc7003>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<http://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times",
September 2013.
[Trammell-14]
Trammell, B., "Inline Data Integrity Signals for Passive
Measurement", March 2014.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
 End of changes. 145 change blocks. 
400 lines changed or deleted 1476 lines changed or added

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