draft-ietf-ippm-initial-registry-14.txt   draft-ietf-ippm-initial-registry-15.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: May 30, 2020 UC3M Expires: June 13, 2020 UC3M
P. Eardley P. Eardley
BT BT
K. D'Souza K. D'Souza
AT&T Labs AT&T Labs
November 27, 2019 December 11, 2019
Initial Performance Metrics Registry Entries Initial Performance Metrics Registry Entries
draft-ietf-ippm-initial-registry-14 draft-ietf-ippm-initial-registry-15
Abstract Abstract
This memo defines the set of Initial Entries for the IANA Performance This memo defines the set of Initial Entries for the IANA Performance
Metrics Registry. The set includes, UDP Round-trip Latency and Loss, Metrics Registry. The set includes: UDP Round-trip Latency and Loss,
Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson
One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP
Round-trip Latency and Loss, and TCP round-trip Latency and Loss. Round-trip Latency and Loss, and TCP round-trip Latency and Loss.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all 14[RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 https://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 30, 2020. This Internet-Draft will expire on June 13, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7
4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9
4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9
4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9
4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9
4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10
4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10
4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11
4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11
4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12
4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13
4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13
4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13
4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14
4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15
4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15
4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16
4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16
4.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 16 4.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 16
4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16
4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16
4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16
5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16
5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17
5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17
5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17
5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17
5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 17 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18
5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 18 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19
5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 18 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19
5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19
5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20
5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20
5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20
5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21
5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 21 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22
5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22
5.5. Administrative items . . . . . . . . . . . . . . . . . . 22 5.5. Administrative items . . . . . . . . . . . . . . . . . . 23
5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 22 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23
5.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 23 5.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 23
5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23
5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23
5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23
6. DNS Response Latency and Loss Registry Entries . . . . . . . 23 6. DNS Response Latency and Loss Registry Entries . . . . . . . 23
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 23 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24
6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24
6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24
6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24
6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24
6.2.1. Reference Definition . . . . . . . . . . . . . . . . 24 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 24
6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25
6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27
6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27
6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28
6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 6.3.3. Traffic Filtering (observation) Details . . . . . . . 29
6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29
6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29
6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.2. Reference Definition . . . . . . . . . . . . . . . . 30 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31
6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31
6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31
6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 6.5. Administrative items . . . . . . . . . . . . . . . . . . 32
6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32
6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 32 6.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 32
6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32
6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32
6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32
7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 32 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33
7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35
7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 35 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36
7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36
7.3.3. Traffic Filtering (observation) Details . . . . . . . 37 7.3.3. Traffic Filtering (observation) Details . . . . . . . 37
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37
7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37
7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38
7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41
7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41
7.5. Administrative items . . . . . . . . . . . . . . . . . . 42 7.5. Administrative items . . . . . . . . . . . . . . . . . . 42
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42
7.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 42 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 42
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 42 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 42 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43
8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 42 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 43
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43
8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 43 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 44
8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44
8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44
8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45
8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46
8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46
8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47
8.3.3. Traffic Filtering (observation) Details . . . . . . . 47 8.3.3. Traffic Filtering (observation) Details . . . . . . . 48
8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 47 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48
8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48
8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49
8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 51 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52
8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52
8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53
8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53
8.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 53 8.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 53
8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53
8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53
8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 54
9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 53 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 54
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 53 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54
9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 55
9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 54 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 55
9.1.6. Version (of Registry Format) . . . . . . . . . . . . 54 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 55
9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55
9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55
9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 56
9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 56 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 57
9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 56 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 57
9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 57 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 58
9.3.3. Traffic Filtering (observation) Details . . . . . . . 58 9.3.3. Traffic Filtering (observation) Details . . . . . . . 59
9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 58 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 59
9.3.5. Run-time Parameters and Data Format . . . . . . . . . 58 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 59
9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59
9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 59 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4.2. Reference Definition . . . . . . . . . . . . . . . . 59 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 60
9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 61 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 62
9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 61 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 62
9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 9.5. Administrative items . . . . . . . . . . . . . . . . . . 62
9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62
9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 62 9.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 63
9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 62 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 63
9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 62 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 63
9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 62 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 63
10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 62 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 63
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63
10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63
10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63
10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 63 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1.4. Description . . . . . . . . . . . . . . . . . . . . 63 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 64
10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64
10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64
10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 64 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 65
10.2.1. Reference Definitions . . . . . . . . . . . . . . . 64 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 65
10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 66 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 67
10.3. Method of Measurement . . . . . . . . . . . . . . . . . 67 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 68
10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 67 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 68
10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 69 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 69
10.3.3. Traffic Filtering (observation) Details . . . . . . 69 10.3.3. Traffic Filtering (observation) Details . . . . . . 70
10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 69 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 70
10.3.5. Run-time Parameters and Data Format . . . . . . . . 69 10.3.5. Run-time Parameters and Data Format . . . . . . . . 70
10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 70 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 70
10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 70 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 70 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 71
10.4.2. Reference Definition . . . . . . . . . . . . . . . . 70 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 71
10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 72 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 73
10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 72 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 73
10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 10.5. Administrative items . . . . . . . . . . . . . . . . . . 73
10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73
10.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 73 10.5.2. Requester . . . . . . . . . . . . . . . . . . . . . 73
10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 73 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 73
10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 73 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 73
10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 73 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 73
11. Security Considerations . . . . . . . . . . . . . . . . . . . 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.1. Normative References . . . . . . . . . . . . . . . . . . 74 14.1. Normative References . . . . . . . . . . . . . . . . . . 74
14.2. Informative References . . . . . . . . . . . . . . . . . 76 14.2. Informative References . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
This memo proposes an initial set of entries for the Performance This memo proposes an initial set of entries for the Performance
Metrics Registry. It uses terms and definitions from the IPPM Metrics Registry. It uses terms and definitions from the IPPM
literature, primarily [RFC2330]. literature, primarily [RFC2330].
Although there are several standard templates for organizing Although there are several standard templates for organizing
specifications of performance metrics (see [RFC7679] for an example specifications of performance metrics (see [RFC7679] for an example
skipping to change at page 7, line 18 skipping to change at page 7, line 18
Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format
for a Performance Metrics Registry. Section 5 of for a Performance Metrics Registry. Section 5 of
[I-D.ietf-ippm-metric-registry] also gives guidelines for those [I-D.ietf-ippm-metric-registry] also gives guidelines for those
requesting registration of a Metric, that is the creation of entry(s) requesting registration of a Metric, that is the creation of entry(s)
in the Performance Metrics Registry: "In essence, there needs to be in the Performance Metrics Registry: "In essence, there needs to be
evidence that a candidate Registered Performance Metric has evidence that a candidate Registered Performance Metric has
significant industry interest, or has seen deployment, and there is significant industry interest, or has seen deployment, and there is
agreement that the candidate Registered Performance Metric serves its agreement that the candidate Registered Performance Metric serves its
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 or IETF Standards action, which will ensure that the Specification Required policy, which includes Expert Review, which
metrics are tightly defined. will ensure that the metrics are tightly defined.
2. Scope 2. Scope
This document defines the initial set of Performance Metrics Registry This document defines a set of initial Performance Metrics Registry
entries, for which IETF approval (following development in the IP entries. Most are Active Performance Metrics, which are based on
Performance Metrics (IPPM) Working Group) will satisfy the RFCs prepared in the IPPM working group of the IETF, according to
requirement for Expert Review. Most are Active Performance Metrics, their framework [RFC2330] and its updates.
which are based on RFCs prepared in the IPPM working group of the
IETF, according to their framework [RFC2330] and its updates.
3. Registry Categories and Columns 3. Registry Categories and Columns
This memo uses the terminology defined in This memo uses the terminology defined in
[I-D.ietf-ippm-metric-registry]. [I-D.ietf-ippm-metric-registry].
This section provides the categories and columns of the registry, for This section provides the categories and columns of the registry, for
easy reference. An entry (row) therefore gives a complete easy reference. An entry (row) therefore gives a complete
description of a Registered Metric. description of a Registered Metric.
Legend:
Registry Categories and Columns, shown as Registry Categories and Columns, shown as
Category Category
------------------ ------------------
Column | Column | Column | Column |
Summary Summary
------------------------------------------------------------------------ ------------------------------------------------------------------------
Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver |
Metric Definition Metric Definition
skipping to change at page 10, line 46 skipping to change at page 11, line 4
is the basis for the loss ratio calculation as per Section 6.1 of is the basis for the loss ratio calculation as per Section 6.1 of
[RFC6673]. [RFC6673].
4.2.2. Fixed Parameters 4.2.2. Fixed Parameters
Type-P as defined in Section 13 of [RFC2330]: Type-P as defined in Section 13 of [RFC2330]:
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL: set to 255 * TTL: set to 255
* Protocol: Set to 17 (UDP) * Protocol: set to 17 (UDP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
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 the non-zero
header checksum included in the header
o UDP Payload o UDP Payload
* total of 100 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
skipping to change at page 12, line 4 skipping to change at page 12, line 14
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 MUST enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and 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 disambiguate retained at the Src or included with each packet to disambiguate
skipping to change at page 13, line 16 skipping to change at page 13, line 23
resulting in unpredictable start times (within a time interval) may resulting in unpredictable start times (within a time interval) may
be sufficient to avoid synchronization of periodic streams, and be sufficient to avoid synchronization of periodic streams, and
therefore a valid replacement for selecting a start time at random therefore a valid replacement for selecting a start time at random
from a fixed interval. from a fixed interval.
The T0 parameter will be reported as a measured parameter. The T0 parameter will be reported as a measured parameter.
Parameters incT and dT are Fixed Parameters. Parameters incT and dT are Fixed Parameters.
4.3.3. Traffic Filtering (observation) Details 4.3.3. Traffic Filtering (observation) Details
The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).
NA NA
4.3.4. Sampling Distribution 4.3.4. Sampling Distribution
NA NA
4.3.5. Run-time Parameters and Data Format 4.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
skipping to change at page 15, line 12 skipping to change at page 15, line 18
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_RFCXXXXsec4_Seconds_95Percentile: RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_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).
the 64-bit NTP timestamp as
For For
RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio: RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_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.
skipping to change at page 15, line 48 skipping to change at page 16, line 6
isolation (e.g., deterministic delay) to avoid send-receive interface isolation (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way. characterized this way.
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement with additional indication that it is a
calibration result. calibration result.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the Output result resolution which is the result of system
noise, and thus inaccurate. noise, and thus inaccurate.
4.5. Administrative items 4.5. Administrative items
4.5.1. Status 4.5.1. Status
Current Current
4.5.2. Requestor 4.5.2. Requester
This RFC numner This RFC number
4.5.3. Revision 4.5.3. Revision
1.0 1.0
4.5.4. Revision Date 4.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
4.6. Comments and Remarks 4.6. Comments and Remarks
skipping to change at page 18, line 4 skipping to change at page 18, line 10
measured are referred to by the variable name "ddT" (applicable to measured are referred to by the variable name "ddT" (applicable to
all forms of delay variation). However, this metric entry specifies all forms of delay variation). However, this metric entry specifies
the PDV form defined in section 4.2 of [RFC5481], where the singleton the PDV form defined in section 4.2 of [RFC5481], where the singleton
PDV for packet i is referred to by the variable name "PDV(i)". PDV for packet i is referred to by the variable name "PDV(i)".
5.2.2. Fixed Parameters 5.2.2. Fixed Parameters
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL: set to 255 * TTL: set to 255
* Protocol: Set to 17 (UDP) * Protocol: set to 17 (UDP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
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 the non-zero
header checksum included in the header
o UDP Payload o UDP Payload
* total of 200 bytes * total of 200 bytes
Other measurement parameters: Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in Tmax: a loss threshold waiting time with value 3.0, expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 4 (see section 9.3 of [RFC6020]) and with fraction digits = 4 (see section 9.3 of [RFC6020]) and with
skipping to change at page 19, line 14 skipping to change at page 19, line 27
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay. delay.
The calculations on the one-way delay SHALL be performed on the The calculations on the one-way delay SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the one-way delay value MAY enforce the Tmax which calculates the one-way delay value MUST enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and 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 disambiguate retained at the Src or included with each packet to disambiguate
skipping to change at page 22, line 19 skipping to change at page 22, line 29
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
manipulation as needed, and provides some form of isolation (e.g., manipulation as needed, and provides some form of isolation (e.g.,
deterministic delay) to avoid send-receive interface contention. deterministic delay) to avoid send-receive interface contention.
Some portion of the random and systematic error can be characterized Some portion of the random and systematic error can be characterized
this way. this way.
For one-way delay measurements, the error calibration must include an For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets of clocks at both the measurement). In practice, the time offsets [RFC5905] of clocks at
source and destination are needed to estimate the systematic error both the source and destination are needed to estimate the systematic
due to imperfect clock synchronization (the time offsets are error due to imperfect clock synchronization (the time offsets are
smoothed, thus the random variation is not usually represented in the smoothed, thus the random variation is not usually represented in the
results). results).
time_offset The time value of the result is expressed in units of time_offset The time value of the result is expressed in units of
seconds, as a signed value of type decimal64 with fraction digits seconds, as a signed value of type decimal64 with fraction digits
= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 = 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 seconds (1.0 ns), and with lossless conversion to/from the 64-bit
NTP timestamp as per section 6 of RFC [RFC5905] NTP timestamp as per section 6 of RFC [RFC5905]
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement with additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset as an indicator of SHOULD report its current estimate of time offset [RFC5905] as an
the degree of synchronization. indicator of the degree of synchronization.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the Output result resolution 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 Current
5.5.2. Requestor 5.5.2. Requester
This RFC number This RFC number
5.5.3. Revision 5.5.3. Revision
1.0 1.0
5.5.4. Revision Date 5.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
skipping to change at page 25, line 41 skipping to change at page 25, line 49
6.2.2. Fixed Parameters 6.2.2. Fixed Parameters
Type-P as defined in Section 13 of [RFC2330]: Type-P as defined in Section 13 of [RFC2330]:
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL set to 255 * TTL set to 255
* Protocol: Set to 17 (UDP) * Protocol: set to 17 (UDP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
o UDP header values: o UDP header values:
* Source port: 53 * Source port: 53
* Destination port: 53 * Destination port: 53
* Checksum: the checksum must be calculated and included in the * Checksum: the checksum must be calculated and the non-zero
header checksum included in the header
o Payload: The payload contains a DNS message as defined in RFC 1035 o Payload: The payload contains a DNS message as defined in RFC 1035
[RFC1035] with the following values: [RFC1035] with the following values:
* The DNS header section contains: * The DNS header section contains:
+ Identification (see the Run-time column) + Identification (see the Run-time column)
+ QR: set to 0 (Query) + QR: set to 0 (Query)
skipping to change at page 27, line 41 skipping to change at page 28, line 4
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
response packet lost. Lost packets SHALL be designated as having response packet lost. Lost packets SHALL be designated as having
undefined delay and counted for the RLDNS metric. undefined delay and counted for the RLDNS metric.
The calculations on the delay (RTT) SHALL be performed on the The calculations on the delay (RTT) SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTT value MAY enforce the Tmax threshold on which calculates the RTT value MUST enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and 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. reply.
DNS Messages bearing Queries provide for random ID Numbers in the DNS Messages bearing Queries provide for random ID Numbers in the
Identification header field, so more than one query may be launched Identification header field, so more than one query may be launched
while a previous request is outstanding when the ID Number is used. while a previous request is outstanding when the ID Number is used.
Therefore, the ID Number MUST be retained at the Src or included with Therefore, the ID Number MUST be retained at the Src and included
each response packet to disambiguate packet reordering if it occurs. with each response packet to disambiguate packet reordering if it
occurs.
IF a DNS response does not arrive within Tmax, the response time IF a DNS response does not arrive within Tmax, the response time
RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to
disambiguate the successive queries that are otherwise identical. disambiguate the successive queries that are otherwise identical.
Since the ID Number filed is only 16 bits in length, it places a Since the ID Number field is only 16 bits in length, it places a
limit on the number of simultaneous outstanding DNS queries during a limit on the number of simultaneous outstanding DNS queries during a
stress test from a single Src address. stress test from a single Src address.
Refer to Section 4.4 of [RFC6673] for expanded discussion of the Refer to Section 4.4 of [RFC6673] for expanded discussion of the
instruction to "send a Type-P packet back to the Src as quickly as instruction to "send a Type-P packet back to the Src as quickly as
possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS
Server is expected to perform all required functions to prepare and Server is expected to perform all required functions to prepare and
send a response, so the response time will include processing time send a response, so the response time will include processing time
and network delay. Section 8 of [RFC6673] presents additional and network delay. Section 8 of [RFC6673] presents additional
requirements which SHALL be included in the method of measurement for requirements which SHALL be included in the method of measurement for
this metric. this metric.
In addition to operations described in [RFC2681], the Src MUST parse In addition to operations described in [RFC2681], the Src MUST parse
the DNS headers of the reply and prepare the information for the DNS headers of the reply and prepare the query response
subsequent reporting as a measured result, along with the Round-Trip information for subsequent reporting as a measured result, along with
Delay. the Round-Trip Delay.
6.3.2. Packet Stream Generation 6.3.2. Packet Stream Generation
This section gives the details of the packet traffic which is the This section 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 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 packets per second.
Method 3 is used, where given a start time (Run-time Parameter), the Method 3 is used, where given a start time (Run-time Parameter), the
subsequent send times are all computed prior to measurement by subsequent send times are all computed prior to measurement by
computing the pseudo-random distribution of inter-packet send times, computing the pseudo-random distribution of inter-packet send times,
(truncating the distribution as specified in the Run-time (truncating the distribution as specified in the Run-time
Parameters), and the Src sends each packet at the computed times. Parameters), and the Src sends each packet at the computed times.
Note that Trunc is the upper limit on inter-packet times in the Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal Poisson distribution. A random value greater than Trunc is set equal
to Trunc instead. to Trunc instead.
6.3.3. Traffic Filtering (observation) Details 6.3.3. Traffic Filtering (observation) Details
The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).
NA NA
6.3.4. Sampling Distribution 6.3.4. Sampling Distribution
NA NA
6.3.5. Run-time Parameters and Data Format 6.3.5. Run-time Parameters and Data Format
Run-time Parameters are input factors that must be determined, Run-time Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results configured into the measurement system, and reported with the results
skipping to change at page 30, line 12 skipping to change at page 30, line 20
decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020])
with resolution of 0.0001 seconds (0.1 ms), and with lossless with resolution of 0.0001 seconds (0.1 ms), and with lossless
conversion to/from the 32-bit NTP timestamp as per section 6 of conversion to/from the 32-bit NTP timestamp as per section 6 of
[RFC5905]. [RFC5905].
Trunc Upper limit on Poisson distribution expressed in units of Trunc Upper limit on Poisson distribution expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 4 (see section 9.3 of [RFC6020]) with resolution of digits = 4 (see section 9.3 of [RFC6020]) with resolution of
0.0001 seconds (0.1 ms), and with lossless conversion to/from the 0.0001 seconds (0.1 ms), and with lossless conversion to/from the
32-bit NTP timestamp as per section 6 of [RFC5905] (values above 32-bit NTP timestamp as per section 6 of [RFC5905] (values above
this limit will be clipped and set to the limit value). (if fixed, this limit will be clipped and set to the limit value).
Trunc = 30.0000 seconds.)
ID The 16-bit identifier assigned by the program that generates the ID The 16-bit identifier assigned by the program that generates the
query, and which must vary in successive queries, see query, and which must vary in successive queries (a list of IDs is
Section 4.1.1 of [RFC1035]. This identifier is copied into the needed), see Section 4.1.1 of [RFC1035]. This identifier is
corresponding reply and can be used by the requester (Src) to copied into the corresponding reply and can be used by the
match-up replies to outstanding queries. requester (Src) to match-up replies to outstanding queries.
QNAME The domain name of the Query, formatted as specified in QNAME The domain name of the Query, formatted as specified in
section 4 of [RFC6991]. section 4 of [RFC6991].
QTYPE The Query Type, which will correspond to the IP address family QTYPE The Query Type, which will correspond to the IP address family
of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a
uint16, as per section 9.2 of [RFC6020]. uint16, as per section 9.2 of [RFC6020].
6.3.6. Roles 6.3.6. Roles
skipping to change at page 31, line 44 skipping to change at page 31, line 51
some form of isolation (e.g., deterministic delay) to avoid send- some form of isolation (e.g., deterministic delay) to avoid send-
receive interface contention. Some portion of the random and receive interface contention. Some portion of the random and
systematic error can be characterized this way. systematic error can be characterized this way.
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement with additional indication that it is a
calibration result. calibration result.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the Output result resolution which is the result of system
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 Current
6.5.2. Requestor 6.5.2. Requester
This RFC number This RFC number
6.5.3. Revision 6.5.3. Revision
1.0 1.0
6.5.4. Revision Date 6.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
skipping to change at page 35, line 23 skipping to change at page 35, line 23
* TTL: set to 255 * TTL: set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
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 the non-zero
header checksum included in the header
o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]
* Security features in use influence the number of Padding * Security features in use influence the number of Padding
octets. octets.
* 250 octets total, including the TWAMP format * 250 octets total, including the TWAMP format type, which MUST
be reported.
Other measurement parameters: Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in Tmax: a loss threshold waiting time with value 3.0, expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 4 (see section 9.3 of [RFC6020]) and with fraction digits = 4 (see section 9.3 of [RFC6020]) and with
resolution of 0.0001 seconds (0.1 ms), with lossless conversion resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].
See the Packet Stream generation category for two additional Fixed See the Packet Stream generation category for two additional Fixed
skipping to change at page 36, line 20 skipping to change at page 36, line 26
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 MUST enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and 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.
retained at the Src or included with each packet to disambiguate
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 described by providing the list of stream and can easily be described by providing the list of stream
parameters. parameters.
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 rate, thus the Run-time Parameter is Reciprocal_lambda
Reciprocal_lambda = 1/lambda, in seconds. = 1/lambda, in packets per second.
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.
Note that Trunc is the upper limit on inter-packet times in the Note that Trunc is the upper limit on inter-packet times in the
Poisson distribution. A random value greater than Trunc is set equal Poisson distribution. A random value greater than Trunc is set equal
skipping to change at page 41, line 15 skipping to change at page 41, line 15
7.4.2.5. Std_Dev 7.4.2.5. Std_Dev
The Std_Dev SHALL be calculated using the conditional distribution of The Std_Dev SHALL be calculated using the conditional distribution of
all packets with a finite value of One-way delay (undefined delays all packets with a finite value of One-way delay (undefined delays
are excluded), a single value as follows: are excluded), a single value as follows:
See section 4.1 of [RFC3393] for details on the conditional See section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and Section 5 of
[RFC6703] for background on this analysis choice. [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See section 6.1.4 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic. The formula is the classic calculation
the classic calculation for standard deviation of a population. for standard deviation of a population.
Define Population Std_Dev_Delay as follows:
(where all packets n = 1 through N have a value for Delay[n],
and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the
Square Root function:
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
Std_Dev The time value of the result is expressed in units of Std_Dev The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see section 9.3 of [RFC6020]) with 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]
7.4.3. Metric Units 7.4.3. Metric Units
The <statistic> of One-way Delay is expressed in seconds. The <statistic> of One-way Delay is expressed in seconds.
skipping to change at page 41, line 46 skipping to change at page 42, line 11
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
manipulation as needed, and provides some form of isolation (e.g., manipulation as needed, and provides some form of isolation (e.g.,
deterministic delay) to avoid send-receive interface contention. deterministic delay) to avoid send-receive interface contention.
Some portion of the random and systematic error can be characterized Some portion of the random and systematic error can be characterized
this way. this way.
For one-way delay measurements, the error calibration must include an For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets of clocks at both the measurement). In practice, the time offsets [RFC5905] of clocks at
source and destination are needed to estimate the systematic error both the source and destination are needed to estimate the systematic
due to imperfect clock synchronization (the time offsets are error due to imperfect clock synchronization (the time offsets
smoothed, thus the random variation is not usually represented in the [RFC5905] are smoothed, thus the random variation is not usually
results). represented in the results).
time_offset The time value of the result is expressed in units of time_offset The time value of the result is expressed in units of
seconds, as a signed value of type decimal64 with fraction digits seconds, as a signed value of type decimal64 with fraction digits
= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 = 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 seconds (1.0 ns), and with lossless conversion to/from the 64-bit
NTP timestamp as per section 6 of RFC [RFC5905] NTP timestamp as per section 6 of RFC [RFC5905]
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement with additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset as an indicator of SHOULD report its current estimate of time offset [RFC5905] as an
the degree of synchronization. indicator of the degree of synchronization.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the Output result resolution 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 Current
7.5.2. Requestor 7.5.2. Requester
This REFC number This RFC number
7.5.3. Revision 7.5.3. Revision
1.0 1.0
7.5.4. Revision Date 7.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
7.6. Comments and Remarks 7.6. Comments and Remarks
skipping to change at page 45, line 36 skipping to change at page 45, line 52
* TTL: set to 255 * TTL: set to 255
* Protocol: Set to 17 (UDP) * Protocol: Set to 17 (UDP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Count: set to 255 * Hop Count: set to 255
* Protocol: Set to 17 (UDP) * Next Header: set to 17 (UDP)
* Flow Label: set to zero
* Extension Headers: none
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 the non-zero
header checksum included in the header
o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]
* Security features in use influence the number of Padding * Security features in use influence the number of Padding
octets. octets.
* 142 octets total, including the TWAMP format (if used) * 142 octets total, including the TWAMP format (and format type
MUST be reported, if used)
Other measurement parameters: Other measurement parameters:
Tmax: a loss threshold waiting time with value 3.0, expressed in Tmax: a loss threshold waiting time with value 3.0, expressed in
units of seconds, as a positive value of type decimal64 with units of seconds, as a positive value of type decimal64 with
fraction digits = 4 (see section 9.3 of [RFC6020]) and with fraction digits = 4 (see section 9.3 of [RFC6020]) and with
resolution of 0.0001 seconds (0.1 ms), with lossless conversion resolution of 0.0001 seconds (0.1 ms), with lossless conversion
to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].
See the Packet Stream generation category for two additional Fixed See the Packet Stream generation category for two additional Fixed
skipping to change at page 46, line 36 skipping to change at page 47, line 8
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 MUST enforce the Tmax
threshold on stored values before calculations. See section 4.1 of threshold on stored values before calculations. See section 4.1 of
[RFC3393] for details on the conditional distribution to exclude [RFC3393] for details on the conditional distribution to exclude
undefined values of delay, and Section 5 of [RFC6703] for background undefined values of delay, and 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.
retained at the Src or included with each packet to disambiguate
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 34 skipping to change at page 52, line 5
are excluded), a single value as follows: are excluded), a single value as follows:
See section 4.1 of [RFC3393] for details on the conditional See section 4.1 of [RFC3393] for details on the conditional
distribution to exclude undefined values of delay, and Section 5 of distribution to exclude undefined values of delay, and Section 5 of
[RFC6703] for background on this analysis choice. [RFC6703] for background on this analysis choice.
See section 4.3.2 of [RFC6049] for a closely related method for See section 4.3.2 of [RFC6049] for a closely related method for
calculating this statistic, and 4.3.3 of [RFC6049]. The formula is calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
the classic calculation for standard deviation of a population. the classic calculation for standard deviation of a population.
Define Population Std_Dev_Delay as follows:
(where all packets n = 1 through N have a value for Delay[n],
and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the
Square Root function:
_ _
| N |
| --- |
| 1 \ 2 |
Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) |
| (N) / |
| --- |
| n = 1 |
|_ _|
Std_Dev The time value of the result is expressed in units of Std_Dev The time value of the result is expressed in units of
seconds, as a positive value of type decimal64 with fraction seconds, as a positive value of type decimal64 with fraction
digits = 9 (see section 9.3 of [RFC6020]) with resolution of digits = 9 (see section 9.3 of [RFC6020]) with 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
The <statistic> of One-way Delay is expressed in seconds, where The <statistic> of One-way Delay is expressed in seconds, where
<statistic> is one of: <statistic> is one of:
skipping to change at page 52, line 23 skipping to change at page 53, line 8
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
manipulation as needed, and provides some form of isolation (e.g., manipulation as needed, and provides some form of isolation (e.g.,
deterministic delay) to avoid send-receive interface contention. deterministic delay) to avoid send-receive interface contention.
Some portion of the random and systematic error can be characterized Some portion of the random and systematic error can be characterized
this way. this way.
For one-way delay measurements, the error calibration must include an For one-way delay measurements, the error calibration must include an
assessment of the internal clock synchronization with its external assessment of the internal clock synchronization with its external
reference (this internal clock is supplying timestamps for reference (this internal clock is supplying timestamps for
measurement). In practice, the time offsets of clocks at both the measurement). In practice, the time offsets [RFC5905] of clocks at
source and destination are needed to estimate the systematic error both the source and destination are needed to estimate the systematic
due to imperfect clock synchronization (the time offsets are error due to imperfect clock synchronization (the time offsets
smoothed, thus the random variation is not usually represented in the [RFC5905] are smoothed, thus the random variation is not usually
results). represented in the results).
time_offset The time value of the result is expressed in units of time_offset The time value of the result is expressed in units of
seconds, as a signed value of type decimal64 with fraction digits seconds, as a signed value of type decimal64 with fraction digits
= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 = 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 seconds (1.0 ns), and with lossless conversion to/from the 64-bit
NTP timestamp as per section 6 of RFC [RFC5905] NTP timestamp as per section 6 of RFC [RFC5905]
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement with additional indication that it is a
calibration result. In any measurement, the measurement function calibration result. In any measurement, the measurement function
SHOULD report its current estimate of time offset as an indicator of SHOULD report its current estimate of time offset [RFC5905] as an
the degree of synchronization. indicator of the degree of synchronization.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the Output result resolution 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 Current
8.5.2. Requestor 8.5.2. Requester
This RFC number This RFC number
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
skipping to change at page 53, line 40 skipping to change at page 54, line 22
Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio.
IANA Note: Registry "Name" below specifies multiple registry entries, IANA Note: Registry "Name" below specifies multiple registry entries,
whose output format varies according to the <statistic> element of whose output format varies according to the <statistic> element of
the name that specifies one form of statistical summary. There is an the name that specifies one form of statistical summary. There is an
additional metric name for the Loss metric. additional metric name for the Loss metric.
All column entries beside the ID, Name, Description, and Output All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same, thus this section proposes
two closely-related registry entries. As a result, IANA is also two closely-related registry entries. As a result, IANA is also
asked to assign four corresponding URLs to each Named Metric. asked to assign corresponding URLs to each Named Metric.
9.1. Summary 9.1. Summary
This category includes multiple indexes to the registry entry: the This category includes multiple indexes to the registry entry: the
element ID and metric name. element ID and metric name.
9.1.1. ID (Identifier) 9.1.1. ID (Identifier)
IANA is asked to assign different numeric identifiers to each of the IANA is asked to assign different numeric identifiers to each of the
four Named Metrics. four Named Metrics.
skipping to change at page 56, line 4 skipping to change at page 56, line 30
is the basis for the loss ratio calculation as per Section 6.1 of is the basis for the loss ratio calculation as per Section 6.1 of
[RFC6673]. [RFC6673].
9.2.2. Fixed Parameters 9.2.2. Fixed Parameters
Type-P as defined in Section 13 of [RFC2330]: Type-P as defined in Section 13 of [RFC2330]:
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* TTL: set to 255 * TTL: set to 255
* Protocol: Set to 01 (ICMP) * Protocol: Set to 01 (ICMP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Hop Limit: set to 255 * Hop Count: set to 255
* Protocol: Set to 01 (ICMP) * Next Header: set to 128 decimal (ICMP)
* Flow Label: set to zero
* Extension Headers: none
o ICMP header values: o ICMP header values:
* Type: 8 (Echo Request) * Type: 8 (Echo Request)
* Code: 0 * Code: 0
* Checksum: the checksum MUST be calculated and the non-zero
* Checksum: the checksum MUST be calculated and included in the checksum included in the header
header
* (Identifier and Sequence Number set at Run-Time) * (Identifier and Sequence Number set at Run-Time)
o ICMP Payload o ICMP Payload
* total of 32 bytes of random info * total of 32 bytes of random info, constant per test.
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 57, line 16 skipping to change at page 57, line 45
The reference method distinguishes between long-delayed packets and The reference method distinguishes between long-delayed packets and
lost packets by implementing a maximum waiting time for packet lost packets by implementing a maximum waiting time for packet
arrival. Tmax is the waiting time used as the threshold to declare a arrival. Tmax is the waiting time used as the threshold to declare a
packet lost. Lost packets SHALL be designated as having undefined packet lost. Lost packets SHALL be designated as having undefined
delay, and counted for the RTLoss metric. delay, and counted for the RTLoss metric.
The calculations on the delay (RTD) SHALL be performed on the The calculations on the delay (RTD) SHALL be performed on the
conditional distribution, conditioned on successful packet arrival conditional distribution, conditioned on successful packet arrival
within Tmax. Also, when all packet delays are stored, the process within Tmax. Also, when all packet delays are stored, the process
which calculates the RTD value MAY enforce the Tmax threshold on which calculates the RTD value MUST enforce the Tmax threshold on
stored values before calculations. See section 4.1 of [RFC3393] for stored values before calculations. See section 4.1 of [RFC3393] for
details on the conditional distribution to exclude undefined values details on the conditional distribution to exclude undefined values
of delay, and Section 5 of [RFC6703] for background on this analysis of delay, and 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 disambiguate retained at the Src or included with each packet to disambiguate
skipping to change at page 58, line 27 skipping to change at page 59, line 9
If a reply packet arrives with RTD >= incT, then the inter-packet If a reply packet arrives with RTD >= incT, then the inter-packet
interval for the next sending time is nominally RTD. interval for the next sending time is nominally RTD.
If a reply packet fails to arrive within Tmax, then the inter-packet If a reply packet fails to arrive within Tmax, then the inter-packet
interval for the next sending time is nominally Tmax. interval for the next sending time is nominally Tmax.
If an immediate send on reply arrival is desired, then set incT=0. If an immediate send on reply arrival is desired, then set incT=0.
9.3.3. Traffic Filtering (observation) Details 9.3.3. Traffic Filtering (observation) Details
The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).
NA NA
9.3.4. Sampling Distribution 9.3.4. Sampling Distribution
NA NA
9.3.5. Run-time Parameters and Data Format 9.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
skipping to change at page 62, line 13 skipping to change at page 62, line 38
isolation (e.g., deterministic delay) to avoid send-receive interface isolation (e.g., deterministic delay) to avoid send-receive interface
contention. Some portion of the random and systematic error can be contention. Some portion of the random and systematic error can be
characterized this way. characterized this way.
When a measurement controller requests a calibration measurement, the When a measurement controller requests a calibration measurement, the
loopback is applied and the result is output in the same format as a loopback is applied and the result is output in the same format as a
normal measurement with additional indication that it is a normal measurement with additional indication that it is a
calibration result. calibration result.
Both internal loopback calibration and clock synchronization can be Both internal loopback calibration and clock synchronization can be
used to estimate the *available accuracy* of the Output Metric Units. used to estimate the available accuracy of the Output Metric Units.
For example, repeated loopback delay measurements will reveal the For example, repeated loopback delay measurements will reveal the
portion of the Output result resolution which is the result of system portion of the Output result resolution which is the result of system
noise, and thus inaccurate. noise, and thus inaccurate.
9.5. Administrative items 9.5. Administrative items
9.5.1. Status 9.5.1. Status
Current Current
9.5.2. Requestor 9.5.2. Requester
This RFC number This RFC number
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
skipping to change at page 63, line 8 skipping to change at page 63, line 36
IANA Note: Registry "Name" below specifies multiple registry entries, IANA Note: Registry "Name" below specifies multiple registry entries,
whose output format varies according to the <statistic> element of whose output format varies according to the <statistic> element of
the name that specifies one form of statistical summary. There are the name that specifies one form of statistical summary. There are
two additional metric names for Singleton RT Delay and Packet Count two additional metric names for Singleton RT Delay and Packet Count
metrics. metrics.
All column entries beside the ID, Name, Description, and Output All column entries beside the ID, Name, Description, and Output
Reference Method categories are the same, thus this section proposes Reference Method categories are the same, thus this section proposes
four closely-related registry entries. As a result, IANA is also four closely-related registry entries. As a result, IANA is also
asked to assign four corresponding URLs to each Named Metric. asked to assign corresponding URLs to each Named Metric.
10.1. Summary 10.1. Summary
This category includes multiple indexes to the registry entry: the This category includes multiple indexes to the registry entry: the
element ID and metric name. element ID and metric name.
10.1.1. ID (Identifier) 10.1.1. ID (Identifier)
IANA is asked to assign different numeric identifiers to each of the IANA is asked to assign different numeric identifiers to each of the
four Named Metrics. four Named Metrics.
skipping to change at page 63, line 34 skipping to change at page 64, line 13
where <statistic> is one of: where <statistic> is one of:
o Mean o Mean
o Min o Min
o Max o Max
RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton
Note that a mid-point observer only has the opportuinty to compose a Note that a mid-point observer only has the opportunity to compose a
single RTDelay on the TCP Hand Shake. single RTDelay on the TCP Hand Shake.
RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count
10.1.3. URIs 10.1.3. URIs
URL: https://www.iana.org/ ... <name> URL: https://www.iana.org/ ... <name>
10.1.4. Description 10.1.4. Description
skipping to change at page 65, line 12 skipping to change at page 65, line 41
yields a Round-trip Delay singleton (we are extending the composition yields a Round-trip Delay singleton (we are extending the composition
of one-way subpath delays to subpath round-trip delay). of one-way subpath delays to subpath round-trip delay).
Using the direction of TCP SYN transmission to anchor the Using the direction of TCP SYN transmission to anchor the
nomenclature, host A sends the SYN and host B replies with SYN-ACK nomenclature, host A sends the SYN and host B replies with SYN-ACK
during connection establishment. The direction of SYN transfer is during connection establishment. The direction of SYN transfer is
considered the Forward direction of transmission, from A through OP considered the Forward direction of transmission, from A through OP
to B (Reverse is B through OP to A). to B (Reverse is B through OP to A).
Traffic filters reduce the packet stream at the OP to a Qualified Traffic filters reduce the packet stream at the OP to a Qualified
bidirectional flow packets. bidirectional flow of packets.
In the definitions below, Corresponding Packets are transferred in In the definitions below, Corresponding Packets are transferred in
different directions and convey a common value in a TCP header field different directions and convey a common value in a TCP header field
that establishes correspondence (to the extent possible). Examples that establishes correspondence (to the extent possible). Examples
may be found in the TCP timestamp fields. may be found in the TCP timestamp fields.
For a real number, RTD_fwd, >> the Round-trip Delay in the Forward For a real number, RTD_fwd, >> the Round-trip Delay in the Forward
direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP
observed a Qualified Packet to host B at wire-time T', that host B observed 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, received that packet and sent a Corresponding Packet back to host A,
skipping to change at page 67, line 9 skipping to change at page 67, line 37
o IPv4 header values: o IPv4 header values:
* DSCP: set to 0 * DSCP: set to 0
* Protocol: Set to 06 (TCP) * Protocol: Set to 06 (TCP)
o IPv6 header values: o IPv6 header values:
* DSCP: set to 0 * DSCP: set to 0
* Protocol: Set to 06 (TCP) * Hop Count: set to 255
* Next Header: set to 6 (TCP)
* Flow Label: set to zero
* Extension Headers: none
o TCP header values: o TCP header values:
* Flags: ACK, SYN, FIN, set as required * Flags: ACK, SYN, FIN, set as required
* Timestamp Option (TSopt): Set * Timestamp Option (TSopt): Set
+ Section 3.2 of [RFC7323] + Section 3.2 of [RFC7323]
10.3. Method of Measurement 10.3. Method of Measurement
skipping to change at page 68, line 13 skipping to change at page 68, line 47
perform a RTD_rev measurement. The time interval between observation perform a RTD_rev measurement. The time interval between observation
of the ACK from B to A, and the corresponding packet with Timestamp of the ACK from B to A, and the corresponding packet with Timestamp
echo (TSecr) is the RTD_rev. echo (TSecr) is the RTD_rev.
Delay Measurement Filtering Heuristics: Delay Measurement Filtering Heuristics:
If Data payloads were transferred in both Forward and Reverse If Data payloads were transferred in both Forward and Reverse
directions, then the Round-Trip Time Measurement Rule in Section 4.1 directions, then the Round-Trip Time Measurement Rule in Section 4.1
of [RFC7323] could be applied. This rule essentially excludes any of [RFC7323] could be applied. This rule essentially excludes any
measurement using a packet unless it makes progress in the transfer measurement using a packet unless it makes progress in the transfer
(advances the left edge of the send window, consistent (advances the left edge of the send window, consistent with
with[Strowes]). [Strowes]).
A different heuristic from [Trammell-14] is to exclude any RTD_rev A different heuristic from [Trammell-14] is to exclude any RTD_rev
that is larger than previously observed values. This would tend to that is larger than previously observed values. This would tend to
exclude Reverse measurements taken when the Application has no data exclude Reverse measurements taken when the Application has no data
ready to send, because considerable time could be added to RTD_rev ready to send, because considerable time could be added to RTD_rev
from this source of error. from this source of error.
Note that the above Heuristic assumes that host A is sending data. Note that the above Heuristic assumes that host A is sending data.
Host A expecting a download would mean that this heuristic should be Host A expecting a download would mean that this heuristic should be
applied to RTD_fwd. applied to RTD_fwd.
skipping to change at page 69, line 16 skipping to change at page 69, line 47
return a packet that defines the termination of a time interval. The return a packet that defines the termination of a time interval. The
heuristics above intend to mitigate these errors by excluding heuristics above intend to mitigate these errors by excluding
measurements where host processing time is a significant part of measurements where host processing time is a significant part of
RTD_fwd or RTD_rev. RTD_fwd or RTD_rev.
A key source of RTLoss error is observation loss, described in A key source of RTLoss error is observation loss, described in
section 3 of [Trammell-14]. section 3 of [Trammell-14].
10.3.2. Packet Stream Generation 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 NA
10.3.3. Traffic Filtering (observation) Details 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. The Fixed Parameters above give a portion of the Traffic Filter.
Other aspects will be supplied as Run-time Parameters (below). Other aspects will be supplied as Run-time Parameters (below).
10.3.4. Sampling Distribution 10.3.4. Sampling Distribution
This metric requires a complete sample of all packets that qualify This metric requires a complete sample of all packets that qualify
according to the Traffic Filter criteria. according to the Traffic Filter criteria.
10.3.5. Run-time Parameters and Data Format 10.3.5. Run-time Parameters and Data Format
skipping to change at page 73, line 11 skipping to change at page 73, line 34
Passive measurements at an OP could be calibrated against an active Passive measurements at an OP could be calibrated against an active
measurement (with loss emulation) at host A or B, where the active measurement (with loss emulation) at host A or B, where the active
measurement represents the ground-truth. measurement represents the ground-truth.
10.5. Administrative items 10.5. Administrative items
10.5.1. Status 10.5.1. Status
Current Current
10.5.2. Requestor 10.5.2. Requester
This RFC This RFC number
10.5.3. Revision 10.5.3. Revision
1.0 1.0
10.5.4. Revision Date 10.5.4. Revision Date
YYYY-MM-DD YYYY-MM-DD
10.6. Comments and Remarks 10.6. Comments and Remarks
None. None.
11. Security Considerations 11. Security Considerations
These registry entries represent no known implications for Internet These registry entries represent no known implications for Internet
Security. Each referenced Metric contains a Security Considerations Security. Each IETF Metric definition referenced above contains a
section. Security Considerations section. Further, the LMAP Framework
[RFC7594] provides both security and privacy considerations for
measurements.
There are potential privacy considerations for observed traffic,
particularly for passive metrics in section 10. An attacker that
knows that its TCP connection is being measured can modify its
behavior to skew the measurement results.
12. IANA Considerations 12. IANA Considerations
IANA is requested to populate The Performance Metrics Registry IANA is requested to populate The Performance Metrics Registry
defined in [I-D.ietf-ippm-metric-registry] with the values defined in defined in [I-D.ietf-ippm-metric-registry] with the values defined in
sections 4 through 10. sections 4 through 10.
See the IANA Considerations section of See the IANA Considerations section of
[I-D.ietf-ippm-metric-registry] for additional requests and [I-D.ietf-ippm-metric-registry] for additional requests and
considerations. considerations.
skipping to change at page 77, line 5 skipping to change at page 77, line 41
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011, DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>. <https://www.rfc-editor.org/info/rfc6390>.
[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,
<https://www.rfc-editor.org/info/rfc6703>. <https://www.rfc-editor.org/info/rfc6703>.
Authors' Addresses [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>.
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
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
 End of changes. 115 change blocks. 
210 lines changed or deleted 254 lines changed or added

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