idnits 2.17.1 draft-ietf-ippm-initial-registry-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 675 has weird spacing: '... Src the IP...' == Line 679 has weird spacing: '... Dst the IP...' == Line 700 has weird spacing: '... Src launch...' == Line 703 has weird spacing: '... Dst waits ...' == Line 748 has weird spacing: '...talPkts the c...' == (25 more instances...) -- The document date (October 29, 2017) is 2371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2680' is defined on line 4126, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 4217, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 4225, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 4230, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 4239, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 4270, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track M. Bagnulo 5 Expires: May 2, 2018 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 October 29, 2017 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-05 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. This version includes: 20 * Revised several Poisson streams to Periodic, sections 4 & 5. 22 * Addition of ICMP (ping) metrics in section 9. 24 * First implementation of Passive TCP RTT metrics in section 10. 26 Still need: Add MBM metric entry. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 2, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Registry Categories and Columns . . . . . . . . . . . . . . . 8 70 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 9 71 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 10 73 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 10 76 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 10 77 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 10 78 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 11 79 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 11 80 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 12 81 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 12 82 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 13 83 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 14 84 4.3.3. Traffic Filtering (observation) Details . . . . . . . 14 85 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 15 86 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 15 87 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 16 91 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 17 92 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 17 93 4.5. Administrative items . . . . . . . . . . . . . . . . . . 18 94 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18 95 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 18 96 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 18 97 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 18 98 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 18 99 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 18 100 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 18 102 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 18 103 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 19 104 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 19 105 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 19 106 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 19 107 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 19 108 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 19 109 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 20 110 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 21 111 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 21 112 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 22 113 5.3.3. Traffic Filtering (observation) Details . . . . . . . 22 114 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 23 115 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 23 116 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 23 117 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 23 118 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 24 119 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 24 120 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 24 121 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 25 122 5.5. Administrative items . . . . . . . . . . . . . . . . . . 25 123 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 25 124 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 26 125 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 26 126 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 26 127 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 26 128 6. DNS Response Latency and Loss Registry Entries . . . . . . . 26 129 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 130 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 26 131 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 27 132 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27 133 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 27 134 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 27 135 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 27 136 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 27 137 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 27 138 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 28 139 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 30 140 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 30 141 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 31 142 6.3.3. Traffic Filtering (observation) Details . . . . . . . 32 143 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 32 144 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 32 145 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 33 146 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34 147 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34 148 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 34 149 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 34 150 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 35 151 6.5. Administrative items . . . . . . . . . . . . . . . . . . 35 152 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 35 153 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 35 154 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 35 155 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 35 156 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 35 157 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 36 158 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36 159 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 36 160 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 36 161 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 37 162 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 37 163 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 37 164 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 37 165 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 38 166 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 39 167 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 39 168 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 40 169 7.3.3. Traffic Filtering (observation) Details . . . . . . . 41 170 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 41 171 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 41 172 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 42 173 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 42 174 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 42 175 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 42 176 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 45 177 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 45 178 7.5. Administrative items . . . . . . . . . . . . . . . . . . 46 179 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 46 180 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 46 181 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 46 182 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 46 183 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 46 184 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 47 185 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 47 186 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 47 187 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 47 188 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 48 189 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 48 190 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 48 191 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 48 192 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 49 193 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 50 194 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 50 195 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 51 196 8.3.3. Traffic Filtering (observation) Details . . . . . . . 52 197 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 52 198 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 52 199 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 53 200 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 53 201 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 202 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 53 203 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56 204 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56 205 8.5. Administrative items . . . . . . . . . . . . . . . . . . 57 206 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 57 207 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 57 208 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 57 209 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 57 210 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 57 211 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 57 212 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 58 213 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 58 214 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 58 215 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 58 216 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 58 217 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 59 218 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 59 219 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 59 220 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 59 221 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 60 222 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 61 223 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 61 224 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 62 225 9.3.3. Traffic Filtering (observation) Details . . . . . . . 63 226 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 63 227 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 63 228 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 64 229 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 64 230 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 64 231 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 64 232 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 66 233 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 66 234 9.5. Administrative items . . . . . . . . . . . . . . . . . . 67 235 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 67 236 9.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 67 237 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 67 238 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 67 239 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 67 241 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 67 242 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 67 243 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 68 244 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 68 245 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 68 246 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 68 247 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 69 248 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 69 249 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 69 250 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 69 251 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 71 252 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 72 253 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 72 254 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 74 255 10.3.3. Traffic Filtering (observation) Details . . . . . . 74 256 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 74 257 10.3.5. Run-time Parameters and Data Format . . . . . . . . 74 258 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 75 259 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 75 260 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 75 261 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 76 262 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 78 263 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 78 264 10.5. Administrative items . . . . . . . . . . . . . . . . . . 78 265 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 78 266 10.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . 78 267 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 78 268 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 78 269 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 78 270 11. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 79 271 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 79 272 11.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 79 273 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 79 274 11.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 79 275 11.1.4. Description . . . . . . . . . . . . . . . . . . . . 79 276 11.1.5. Reference . . . . . . . . . . . . . . . . . . . . . 79 277 11.1.6. Change Controller . . . . . . . . . . . . . . . . . 79 278 11.1.7. Version (of Registry Format) . . . . . . . . . . . . 79 279 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 79 280 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 80 281 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 80 282 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 80 283 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 80 284 11.3.2. Packet Stream Generation . . . . . . . . . . . . . . 80 285 11.3.3. Traffic Filtering (observation) Details . . . . . . 80 286 11.3.4. Sampling Distribution . . . . . . . . . . . . . . . 80 287 11.3.5. Run-time Parameters and Data Format . . . . . . . . 80 288 11.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 80 290 11.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 81 291 11.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 81 292 11.4.2. Reference Definition . . . . . . . . . . . . . . . . 81 293 11.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 81 294 11.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 81 295 11.5. Administrative items . . . . . . . . . . . . . . . . . . 81 296 11.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 81 297 11.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 81 298 11.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 81 299 11.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 81 300 11.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 81 301 12. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 82 302 12.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 82 303 12.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 82 304 12.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 82 305 12.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 82 306 12.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 82 307 12.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 82 308 12.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 82 309 12.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 82 310 12.1.8. Description . . . . . . . . . . . . . . . . . . . . 82 311 12.1.9. Reference Specification(s) . . . . . . . . . . . . . 83 312 12.2. Metric Definition . . . . . . . . . . . . . . . . . . . 83 313 12.2.1. Reference Definition . . . . . . . . . . . . . . . . 83 314 12.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 83 315 12.3. Method of Measurement . . . . . . . . . . . . . . . . . 84 316 12.3.1. Reference Method . . . . . . . . . . . . . . . . . . 84 317 12.3.2. Stream Type and Stream Parameters . . . . . . . . . 84 318 12.3.3. Output Type and Data Format . . . . . . . . . . . . 84 319 12.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 84 320 12.3.5. Run-time Parameters and Data Format . . . . . . . . 85 321 12.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 86 322 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 86 323 14. Security Considerations . . . . . . . . . . . . . . . . . . . 87 324 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 325 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87 326 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 327 17.1. Normative References . . . . . . . . . . . . . . . . . . 88 328 17.2. Informative References . . . . . . . . . . . . . . . . . 90 329 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 331 1. Introduction 333 Note: Efforts to synchronize structure and terminology with 334 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 335 drafts are stable. 337 This memo proposes an initial set of entries for the Performance 338 Metric Registry. It uses terms and definitions from the IPPM 339 literature, primarily [RFC2330]. 341 Although there are several standard templates for organizing 342 specifications of performance metrics (see [RFC2679] for an example 343 of the traditional IPPM template, based to large extent on the 344 Benchmarking Methodology Working Group's traditional template in 345 [RFC1242], and see [RFC6390] for a similar template), none of these 346 templates were intended to become the basis for the columns of an 347 IETF-wide registry of metrics. While examinating aspects of metric 348 specifications which need to be registered, it became clear that none 349 of the existing metric templates fully satisfies the particular needs 350 of a registry. 352 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 353 for a Performance Metric Registry. Section 5 of 354 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 355 requesting registration of a Metric, that is the creation of entry(s) 356 in the Performance Metric Registry: "In essence, there needs to be 357 evidence that a candidate Registered Performance Metric has 358 significant industry interest, or has seen deployment, and there is 359 agreement that the candidate Registered Performance Metric serves its 360 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 361 also requires that new entries are administered by IANA through 362 Expert Review, which will ensure that the metrics are tightly 363 defined. 365 2. Scope 367 This document defines the initial set of Performance Metrics Registry 368 entries, for which IETF approval (following development in the IP 369 Performance Metrics (IPPM) Working Group) will satisfy the 370 requirement for Expert Review. Most are Active Performance Metrics, 371 which are based on RFCs prepared in the IPPM working group of the 372 IETF, according to their framework [RFC2330] and its updates. 374 3. Registry Categories and Columns 376 This section provides the categories and columns of the registry, for 377 easy reference. An entry (row) therefore gives a complete 378 description of a Registered Metric. 380 Registry Categories and Columns, shown as 381 Category 382 ------------------ 383 Column | Column | 385 Summary 386 ------------------------------------------------------------------------ 387 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 389 Metric Definition 390 ----------------------------------------- 391 Reference Definition | Fixed Parameters | 393 Method of Measurement 394 --------------------------------------------------------------------- 395 Reference | Packet | Traffic | Sampling | Run-time | Role | 396 Method | Stream | Filter | Distribution | Parameters | | 397 | Generation | 398 Output 399 ----------------------------------------- 400 Type | Reference | Units | Calibration | 401 | Definition | | | 403 Administrative Information 404 ---------------------------------- 405 Status |Request | Rev | Rev.Date | 407 Comments and Remarks 408 -------------------- 410 4. UDP Round-trip Latency and Loss Registry Entries 412 This section specifies an initial registry entry for the UDP Round- 413 trip Latency, and another entry for UDP Round-trip Loss Ratio. 415 Note: Each Registry entry only produces a "raw" output or a 416 statistical summary. To describe both "raw" and one or more 417 statistics efficiently, the Identifier, Name, and Output Categories 418 can be split and a single section can specify two or more closely- 419 related metrics. This section specifies two Registry entries with 420 many common columns. See Section 7 for an example specifying 421 multiple Registry entries with many common columns. 423 All column entries beside the ID, Name, Description, and Output 424 Reference Method categories are the same, thus this section proposes 425 two closely-related registry entries. As a result, IANA is also 426 asked to assign corresponding URNs and URLs to each Named Metric. 428 4.1. Summary 430 This category includes multiple indexes to the registry entry: the 431 element ID and metric name. 433 4.1.1. ID (Identifier) 435 437 IANA is asked to assign different numeric identifiers to each of the 438 two Named Metrics. 440 4.1.2. Name 442 444 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 446 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio 448 4.1.3. URIs 450 URN: Prefix urn:ietf:metrics:perf: 452 URL: http:/// 454 4.1.4. Description 456 RTDelay: This metric assesses the delay of a stream of packets 457 exchanged between two hosts (which are the two measurement points), 458 and the Output is the Round-trip delay for all successfully exchanged 459 packets expressed as the 95th percentile of their conditional delay 460 distribution. 462 RTLoss: This metric assesses the loss ratio of a stream of packets 463 exchanged between two hosts (which are the two measurement points), 464 and the Output is the Round-trip loss ratio for all successfully 465 exchanged packets expressed as a percentage. 467 4.1.5. Change Controller 469 IETF 471 4.1.6. Version (of Registry Format) 473 1.0 475 4.2. Metric Definition 477 This category includes columns to prompt the entry of all necessary 478 details related to the metric definition, including the RFC reference 479 and values of input factors, called fixed parameters. 481 4.2.1. Reference Definition 483 485 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 486 Metric for IPPM", RFC 2681, September 1999. 488 [RFC2681] 490 492 Section 2.4 of [RFC2681] provides the reference definition of the 493 singleton (single value) Round-trip delay metric. Section 3.4 of 494 [RFC2681] provides the reference definition expanded to cover a 495 multi-singleton sample. Note that terms such as singleton and sample 496 are defined in Section 11 of [RFC2330]. 498 Note that although the [RFC2681] definition of "Round-trip-Delay 499 between Src and Dst" is directionally ambiguous in the text, this 500 metric tightens the definition further to recognize that the host in 501 the "Src" role will send the first packet to "Dst", and ultimately 502 receive the corresponding return packet from "Dst" (when neither are 503 lost). 505 Finally, note that the variable "dT" is used in [RFC2681] to refer to 506 the value of Round-trip delay in metric definitions and methods. The 507 variable "dT" has been re-used in other IPPM literature to refer to 508 different quantities, and cannot be used as a global variable name. 510 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 512 [RFC6673] 514 Both delay and loss metrics employ a maximum waiting time for 515 received packets, so the count of lost packets to total packets sent 516 is the basis for the loss ratio calculation as per Section 6.1 of 517 [RFC6673]. 519 4.2.2. Fixed Parameters 521 525 Type-P as defined in Section 13 of [RFC2330]: 527 o IPv4 header values: 529 * DSCP: set to 0 531 * TTL: set to 255 533 * Protocol: Set to 17 (UDP) 535 o IPv6 header values: 537 * DSCP: set to 0 539 * Hop Count: set to 255 541 * Protocol: Set to 17 (UDP) 543 o UDP header values: 545 * Checksum: the checksum MUST be calculated and included in the 546 header 548 o UDP Payload 550 * total of 100 bytes 552 Other measurement parameters: 554 o Tmax: a loss threshold waiting time 556 * 3.0, expressed in units of seconds, as a positive value of type 557 decimal64 with fraction digits = 4 (see section 9.3 of 558 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 559 lossless conversion to/from the 32-bit NTP timestamp as per 560 section 6 of [RFC5905]. 562 4.3. Method of Measurement 564 This category includes columns for references to relevant sections of 565 the RFC(s) and any supplemental information needed to ensure an 566 unambiguous methods for implementations. 568 4.3.1. Reference Method 570 573 The methodology for this metric is defined as Type-P-Round-trip- 574 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 575 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 576 Fixed Parameters. However, the Periodic stream will be generated 577 according to [RFC3432]. 579 The reference method distinguishes between long-delayed packets and 580 lost packets by implementing a maximum waiting time for packet 581 arrival. Tmax is the waiting time used as the threshold to declare a 582 packet lost. Lost packets SHALL be designated as having undefined 583 delay, and counted for the RTLoss metric. 585 The calculations on the delay (RTT) SHALL be performed on the 586 conditional distribution, conditioned on successful packet arrival 587 within Tmax. Also, when all packet delays are stored, the process 588 which calculates the RTT value MAY enforce the Tmax threshold on 589 stored values before calculations. See section 4.1 of [RFC3393] for 590 details on the conditional distribution to exclude undefined values 591 of delay, and Section 5 of [RFC6703] for background on this analysis 592 choice. 594 The reference method requires some way to distinguish between 595 different packets in a stream to establish correspondence between 596 sending times and receiving times for each successfully-arriving 597 packet. Sequence numbers or other send-order identification MUST be 598 retained at the Src or included with each packet to disambiguate 599 packet reordering if it occurs. 601 If a standard measurement protocol is employed, then the measurement 602 process will determine the sequence numbers or timestamps applied to 603 test packets after the Fixed and Runtime parameters are passed to 604 that process. The chosen measurement protocol will dictate the 605 format of sequence numbers and time-stamps, if they are conveyed in 606 the packet payload. 608 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 609 instruction to "send a Type-P packet back to the Src as quickly as 610 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 611 [RFC6673] presents additional requirements which MUST be included in 612 the method of measurement for this metric. 614 4.3.2. Packet Stream Generation 616 618 This section gives the details of the packet traffic which is the 619 basis for measurement. In IPPM metrics, this is called the Stream, 620 and can easily be described by providing the list of stream 621 parameters. 623 Section 3 of [RFC3432] prescribes the method for generating Periodic 624 streams using associated parameters. 626 incT the nominal duration of inter-packet interval, first bit to 627 first bit, with value 0.0200, expressed in units of seconds, as a 628 positive value of type decimal64 with fraction digits = 4 (see 629 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 630 (0.1 ms). 632 dT the duration of the interval for allowed sample start times, with 633 value 1.0, expressed in units of seconds, as a positive value of 634 type decimal64 with fraction digits = 4 (see section 9.3 of 635 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 637 T0 the actual start time of the periodic stream, (format "date-and- 638 time" as specified in Section 5.6 of [RFC3339], see also Section 3 639 of [RFC6991]). 641 NOTE: an initiation process with a number of control exchanges 642 resulting in unpredictable start times (within a time interval) may 643 be sufficient to avoid synchronization of periodic streams, and 644 therefore a valid replacement for selecting a start time at random 645 from a fixed interval. 647 The T0 parameter will be reported as a measured parameter. 648 Parameters incT and dT are Fixed Parameters. 650 4.3.3. Traffic Filtering (observation) Details 652 The measured results based on a filtered version of the packets 653 observed, and this section provides the filter details (when 654 present). 656
. 658 NA 660 4.3.4. Sampling Distribution 662 665 NA 667 4.3.5. Run-time Parameters and Data Format 669 Run-time Parameters are input factors that must be determined, 670 configured into the measurement system, and reported with the results 671 for the context to be complete. 673 675 Src the IP address of the host in the Src Role (format ipv4-address- 676 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 677 see Section 4 of [RFC6991]) 679 Dst the IP address of the host in the Dst Role (format ipv4-address- 680 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 681 see section 4 of [RFC6991]) 683 T0 a time, the start of a measurement interval, (format "date-and- 684 time" as specified in Section 5.6 of [RFC3339], see also Section 3 685 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 686 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 687 and Tf is to be interpreted as the Duration of the measurement 688 interval. The start time is controlled through other means. 690 Tf a time, the end of a measurement interval, (format "date-and-time" 691 as specified in Section 5.6 of [RFC3339], see also Section 3 of 692 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 693 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 694 Tf is interpreted as the Duration of the measurement interval. 696 4.3.6. Roles 698 700 Src launches each packet and waits for return transmissions from 701 Dst. 703 Dst waits for each packet from Src and sends a return packet to Src. 705 4.4. Output 707 This category specifies all details of the Output of measurements 708 using the metric. 710 4.4.1. Type 712 714 Percentile -- for the conditional distribution of all packets with a 715 valid value of Round-trip delay (undefined delays are excluded), a 716 single value corresponding to the 95th percentile, as follows: 718 See section 4.1 of [RFC3393] for details on the conditional 719 distribution to exclude undefined values of delay, and Section 5 of 720 [RFC6703] for background on this analysis choice. 722 The percentile = 95, meaning that the reported delay, "95Percentile", 723 is the smallest value of Round-trip delay for which the Empirical 724 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 725 Round-trip delay values in the conditional distribution. See section 726 11.3 of [RFC2330] for the definition of the percentile statistic 727 using the EDF. 729 LossRatio -- the count of lost packets to total packets sent is the 730 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 732 4.4.2. Reference Definition 734 736 For all outputs --- 738 T0 the start of a measurement interval, (format "date-and-time" as 739 specified in Section 5.6 of [RFC3339], see also Section 3 of 740 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 741 [RFC2330]. 743 Tf the end of a measurement interval, (format "date-and-time" as 744 specified in Section 5.6 of [RFC3339], see also Section 3 of 745 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 746 [RFC2330]. 748 TotalPkts the count of packets sent by the Src to Dst during the 749 measurement interval. 751 For 752 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile: 754 95Percentile The time value of the result is expressed in units of 755 seconds, as a positive value of type decimal64 with fraction 756 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 757 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 758 the 64-bit NTP timestamp as 760 For 762 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio: 764 Percentile The numeric value of the result is expressed in units of 765 lost packets to total packets times 100%, as a positive value of 766 type decimal64 with fraction digits = 9 (see section 9.3 of 767 [RFC6020]) with resolution of 0.0000000001. 769 4.4.3. Metric Units 771 . 774 The 95th Percentile of Round-trip Delay is expressed in seconds. 776 The Round-trip Loss Ratio is expressed as a percentage of lost 777 packets to total packets sent. 779 4.4.4. Calibration 781 Section 3.7.3 of [RFC7679] provides a means to quantify the 782 systematic and random errors of a time measurement. In-situ 783 calibration could be enabled with an internal loopback at the Source 784 host that includes as much of the measurement system as possible, 785 performs address manipulation as needed, and provides some form of 786 isolation (e.g., deterministic delay) to avoid send-receive interface 787 contention. Some portion of the random and systematic error can be 788 characterized this way. 790 When a measurement controller requests a calibration measurement, the 791 loopback is applied and the result is output in the same format as a 792 normal measurement with additional indication that it is a 793 calibration result. 795 Both internal loopback calibration and clock synchronization can be 796 used to estimate the *available accuracy* of the Output Metric Units. 797 For example, repeated loopback delay measurements will reveal the 798 portion of the Output result resolution which is the result of system 799 noise, and thus inaccurate. 801 4.5. Administrative items 803 4.5.1. Status 805 807 4.5.2. Requestor (keep?) 809 name or RFC, etc. 811 4.5.3. Revision 813 1.0 815 4.5.4. Revision Date 817 YYYY-MM-DD 819 4.6. Comments and Remarks 821 Additional (Informational) details for this entry 823 5. Packet Delay Variation Registry Entry 825 This section gives an initial registry entry for a Packet Delay 826 Variation metric. 828 Note: If each Registry entry should only produce a "raw" output or a 829 statistical summary, then the "Output" Category can be split and this 830 section can become two closely-related metrics. 832 5.1. Summary 834 This category includes multiple indexes to the registry entries, the 835 element ID and metric name. 837 839 5.1.1. ID (Identifier) 841 843 5.1.2. Name 845 847 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 849 5.1.3. URIs 851 URI: Prefix urn:ietf:metrics:perf: 853 URL: http:/// 855 5.1.4. Description 857 An assessment of packet delay variation with respect to the minimum 858 delay observed on the periodic stream, and the Output is expressed as 859 the 95th percentile of the packet delay variation distribution. 861 5.1.5. Change Controller 863 865 IETF 867 5.1.6. Version (of Registry Format) 869 1.0 871 5.2. Metric Definition 873 This category includes columns to prompt the entry of all necessary 874 details related to the metric definition, including the RFC reference 875 and values of input factors, called fixed parameters. 877 5.2.1. Reference Definition 879 881 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 882 Performance Metrics", RFC 2330, May 1998. [RFC2330] 884 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 885 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 886 [RFC3393] 888 Morton, A. and B. Claise, "Packet Delay Variation Applicability 889 Statement", RFC 5481, March 2009. [RFC5481] 891 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 892 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 893 June 2010.[RFC5905] 895 896 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 897 measured are referred to by the variable name "ddT" (applicable to 898 all forms of delay variation). However, this metric entry specifies 899 the PDV form defined in section 4.2 of [RFC5481], where the singleton 900 PDV for packet i is referred to by the variable name "PDV(i)". 902 5.2.2. Fixed Parameters 904 908 o IPv4 header values: 910 * DSCP: set to 0 912 * TTL: set to 255 914 * Protocol: Set to 17 (UDP) 916 o IPv6 header values: 918 * DSCP: set to 0 920 * Hop Count: set to 255 922 * Protocol: Set to 17 (UDP) 924 o UDP header values: 926 * Checksum: the checksum MUST be calculated and included in the 927 header 929 o UDP Payload 931 * total of 200 bytes 933 Other measurement parameters: 935 Tmax: a loss threshold waiting time with value 3.0, expressed in 936 units of seconds, as a positive value of type decimal64 with 937 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 938 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 939 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 941 F a selection function unambiguously defining the packets from the 942 stream selected for the metric. See section 4.2 of [RFC5481] for 943 the PDV form. 945 See the Packet Stream generation category for two additional Fixed 946 Parameters. 948 5.3. Method of Measurement 950 This category includes columns for references to relevant sections of 951 the RFC(s) and any supplemental information needed to ensure an 952 unambiguous methods for implementations. 954 5.3.1. Reference Method 956 959 See section 2.6 and 3.6 of [RFC3393] for general singleton element 960 calculations. This metric entry requires implementation of the PDV 961 form defined in section 4.2 of [RFC5481]. Also see measurement 962 considerations in section 8 of [RFC5481]. 964 The reference method distinguishes between long-delayed packets and 965 lost packets by implementing a maximum waiting time for packet 966 arrival. Tmax is the waiting time used as the threshold to declare a 967 packet lost. Lost packets SHALL be designated as having undefined 968 delay. 970 The calculations on the one-way delay SHALL be performed on the 971 conditional distribution, conditioned on successful packet arrival 972 within Tmax. Also, when all packet delays are stored, the process 973 which calculates the one-way delay value MAY enforce the Tmax 974 threshold on stored values before calculations. See section 4.1 of 975 [RFC3393] for details on the conditional distribution to exclude 976 undefined values of delay, and Section 5 of [RFC6703] for background 977 on this analysis choice. 979 The reference method requires some way to distinguish between 980 different packets in a stream to establish correspondence between 981 sending times and receiving times for each successfully-arriving 982 packet. Sequence numbers or other send-order identification MUST be 983 retained at the Src or included with each packet to disambiguate 984 packet reordering if it occurs. 986 If a standard measurement protocol is employed, then the measurement 987 process will determine the sequence numbers or timestamps applied to 988 test packets after the Fixed and Runtime parameters are passed to 989 that process. The chosen measurement protocol will dictate the 990 format of sequence numbers and time-stamps, if they are conveyed in 991 the packet payload. 993 5.3.2. Packet Stream Generation 995 997 This section gives the details of the packet traffic which is the 998 basis for measurement. In IPPM metrics, this is called the Stream, 999 and can easily be described by providing the list of stream 1000 parameters. 1002 Section 3 of [RFC3432] prescribes the method for generating Periodic 1003 streams using associated parameters. 1005 incT the nominal duration of inter-packet interval, first bit to 1006 first bit, with value 0.0200, expressed in units of seconds, as a 1007 positive value of type decimal64 with fraction digits = 4 (see 1008 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 1009 (0.1 ms). 1011 dT the duration of the interval for allowed sample start times, with 1012 value 1.0, expressed in units of seconds, as a positive value of 1013 type decimal64 with fraction digits = 4 (see section 9.3 of 1014 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 1016 T0 the actual start time of the periodic stream, (format "date-and- 1017 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1018 of [RFC6991]). 1020 NOTE: an initiation process with a number of control exchanges 1021 resulting in unpredictable start times (within a time interval) may 1022 be sufficient to avoid synchronization of periodic streams, and 1023 therefore a valid replacement for selecting a start time at random 1024 from a fixed interval. 1026 The T0 parameter will be reported as a measured parameter. 1027 Parameters incT and dT are Fixed Parameters. 1029 5.3.3. Traffic Filtering (observation) Details 1031 . 1035 NA 1037 5.3.4. Sampling Distribution 1039 1042 NA 1044 5.3.5. Run-time Parameters and Data Format 1046 1048 Src the IP address of the host in the Src Role (format ipv4-address- 1049 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1050 see Section 4 of [RFC6991]) 1052 Dst the IP address of the host in the Dst Role (format ipv4-address- 1053 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1054 see section 4 of [RFC6991]) 1056 T0 a time, the start of a measurement interval, (format "date-and- 1057 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1058 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1059 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1060 and Tf is to be interpreted as the Duration of the measurement 1061 interval. The start time is controlled through other means. 1063 Tf a time, the end of a measurement interval, (format "date-and-time" 1064 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1065 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1066 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1067 Tf is interpreted as the Duration of the measurement interval. 1069 5.3.6. Roles 1071 1073 Src launches each packet to Dst. 1075 Dst waits for each packet from Src. 1077 5.4. Output 1079 This category specifies all details of the Output of measurements 1080 using the metric. 1082 5.4.1. Type 1084 1086 Percentile -- for the conditional distribution of all packets with a 1087 valid value of one-way delay (undefined delays are excluded), a 1088 single value corresponding to the 95th percentile, as follows: 1090 See section 4.1 of [RFC3393] for details on the conditional 1091 distribution to exclude undefined values of delay, and Section 5 of 1092 [RFC6703] for background on this analysis choice. 1094 The percentile = 95, meaning that the reported delay, "95Percentile", 1095 is the smallest value of one-way PDV for which the Empirical 1096 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1097 one-way PDV values in the conditional distribution. See section 11.3 1098 of [RFC2330] for the definition of the percentile statistic using the 1099 EDF. 1101 5.4.2. Reference Definition 1103 1105 T0 the start of a measurement interval, (format "date-and-time" as 1106 specified in Section 5.6 of [RFC3339], see also Section 3 of 1107 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1108 [RFC2330]. 1110 Tf the end of a measurement interval, (format "date-and-time" as 1111 specified in Section 5.6 of [RFC3339], see also Section 3 of 1112 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1113 [RFC2330]. 1115 95Percentile The time value of the result is expressed in units of 1116 seconds, as a positive value of type decimal64 with fraction 1117 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1118 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1119 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1121 5.4.3. Metric Units 1123 . 1126 The 95th Percentile of one-way PDV is expressed in seconds. 1128 5.4.4. Calibration 1130 Section 3.7.3 of [RFC7679] provides a means to quantify the 1131 systematic and random errors of a time measurement. In-situ 1132 calibration could be enabled with an internal loopback that includes 1133 as much of the measurement system as possible, performs address 1134 manipulation as needed, and provides some form of isolation (e.g., 1135 deterministic delay) to avoid send-receive interface contention. 1136 Some portion of the random and systematic error can be characterized 1137 this way. 1139 For one-way delay measurements, the error calibration must include an 1140 assessment of the internal clock synchronization with its external 1141 reference (this internal clock is supplying timestamps for 1142 measurement). In practice, the time offsets of clocks at both the 1143 source and destination are needed to estimate the systematic error 1144 due to imperfect clock synchronization (the time offsets are 1145 smoothed, thus the random variation is not usually represented in the 1146 results). 1148 time_offset The time value of the result is expressed in units of 1149 seconds, as a signed value of type decimal64 with fraction digits 1150 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1151 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1152 NTP timestamp as per section 6 of RFC [RFC5905] 1154 When a measurement controller requests a calibration measurement, the 1155 loopback is applied and the result is output in the same format as a 1156 normal measurement with additional indication that it is a 1157 calibration result. In any measurement, the measurement function 1158 SHOULD report its current estimate of time offset as an indicator of 1159 the degree of synchronization. 1161 Both internal loopback calibration and clock synchronization can be 1162 used to estimate the *available accuracy* of the Output Metric Units. 1163 For example, repeated loopback delay measurements will reveal the 1164 portion of the Output result resolution which is the result of system 1165 noise, and thus inaccurate. 1167 5.5. Administrative items 1169 5.5.1. Status 1171 1173 5.5.2. Requestor (keep?) 1175 1177 5.5.3. Revision 1179 1.0 1181 5.5.4. Revision Date 1183 YYYY-MM-DD 1185 5.6. Comments and Remarks 1187 1189 Lost packets represent a challenge for delay variation metrics. See 1190 section 4.1 of [RFC3393] and the delay variation applicability 1191 statement[RFC5481] for extensive analysis and comparison of PDV and 1192 an alternate metric, IPDV. 1194 6. DNS Response Latency and Loss Registry Entries 1196 This section gives initial registry entries for DNS Response Latency 1197 and Loss. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1198 build on that metric by specifying several of the input parameters to 1199 precisely define two metrics for measuring DNS latency and loss. 1201 Note to IANA: Each Registry "Name" below specifies a single registry 1202 entry, whose output format varies in accordance with the name. 1204 All column entries beside the ID, Name, Description, and Output 1205 Reference Method categories are the same, thus this section proposes 1206 two closely-related registry entries. As a result, IANA is also 1207 asked to assign corresponding URNs and URLs to each Named Metric. 1209 6.1. Summary 1211 This category includes multiple indexes to the registry entries, the 1212 element ID and metric name. 1214 1216 6.1.1. ID (Identifier) 1218 1219 IANA is asked to assign different numeric identifiers to each of the 1220 two Named Metrics. 1222 6.1.2. Name 1224 1226 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1228 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw 1230 6.1.3. URI 1232 URI: Prefix urn:ietf:metrics:perf: 1234 URL: http:/// 1236 6.1.4. Description 1238 RTDNS: This metric assesses the response time, the interval from the 1239 query transmission to the response. 1241 RLDNS: This metric indicates that the response was deemed lost. In 1242 other words, the response time exceeded the maximum waiting time. 1244 6.1.5. Change Controller 1246 IETF 1248 6.1.6. Version (of Registry Format) 1250 1.0 1252 6.2. Metric Definition 1254 This category includes columns to prompt the entry of all necessary 1255 details related to the metric definition, including the RFC reference 1256 and values of input factors, called fixed parameters. 1258 6.2.1. Reference Definition 1260 1262 Mockapetris, P., "Domain names - implementation and specification", 1263 STD 13, RFC 1035, November 1987. (and updates) 1265 [RFC1035] 1266 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1267 Metric for IPPM", RFC 2681, September 1999. 1269 [RFC2681] 1271 1273 Section 2.4 of [RFC2681] provides the reference definition of the 1274 singleton (single value) Round-trip delay metric. Section 3.4 of 1275 [RFC2681] provides the reference definition expanded to cover a 1276 multi-singleton sample. Note that terms such as singleton and sample 1277 are defined in Section 11 of [RFC2330]. 1279 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1280 [RFC2681]. The Local Host with its User Program and Resolver take 1281 the role of "Src", and the Foreign Name Server takes the role of 1282 "Dst". 1284 Note that although the [RFC2681] definition of "Round-trip-Delay 1285 between Src and Dst at T" is directionally ambiguous in the text, 1286 this metric tightens the definition further to recognize that the 1287 host in the "Src" role will send the first packet to "Dst", and 1288 ultimately receive the corresponding return packet from "Dst" (when 1289 neither are lost). 1291 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1293 [RFC6673] 1295 Both response time and loss metrics employ a maximum waiting time for 1296 received responses, so the count of lost packets to total packets 1297 sent is the basis for the loss determination as per Section 4.3 of 1298 [RFC6673]. 1300 6.2.2. Fixed Parameters 1302 1306 Type-P as defined in Section 13 of [RFC2330]: 1308 o IPv4 header values: 1310 * DSCP: set to 0 1312 * TTL set to 255 1313 * Protocol: Set to 17 (UDP) 1315 o IPv6 header values: 1317 * DSCP: set to 0 1319 * Hop Count: set to 255 1321 * Protocol: Set to 17 (UDP) 1323 o UDP header values: 1325 * Source port: 53 1327 * Destination port: 53 1329 * Checksum: the checksum must be calculated and included in the 1330 header 1332 o Payload: The payload contains a DNS message as defined in RFC 1035 1333 [RFC1035] with the following values: 1335 * The DNS header section contains: 1337 + Identification (see the Run-time column) 1339 + QR: set to 0 (Query) 1341 + OPCODE: set to 0 (standard query) 1343 + AA: not set 1345 + TC: not set 1347 + RD: set to one (recursion desired) 1349 + RA: not set 1351 + RCODE: not set 1353 + QDCOUNT: set to one (only one entry) 1355 + ANCOUNT: not set 1357 + NSCOUNT: not set 1359 + ARCOUNT: not set 1361 * The Question section contains: 1363 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1364 input for the test, see the Run-time column 1366 + QTYPE: the query type provided as input for the test, see 1367 the Run-time column 1369 + QCLASS: set to 1 for IN 1371 * The other sections do not contain any Resource Records. 1373 Other measurement parameters: 1375 o Tmax: a loss threshold waiting time (and to help disambiguate 1376 queries) 1378 * 5.0, expressed in units of seconds, as a positive value of type 1379 decimal64 with fraction digits = 4 (see section 9.3 of 1380 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1381 lossless conversion to/from the 32-bit NTP timestamp as per 1382 section 6 of [RFC5905]. 1384 Observation: reply packets will contain a DNS response and may 1385 contain RRs. 1387 6.3. Method of Measurement 1389 This category includes columns for references to relevant sections of 1390 the RFC(s) and any supplemental information needed to ensure an 1391 unambiguous methods for implementations. 1393 6.3.1. Reference Method 1395 1398 The methodology for this metric is defined as Type-P-Round-trip- 1399 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1400 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1401 Fixed Parameters. 1403 The reference method distinguishes between long-delayed packets and 1404 lost packets by implementing a maximum waiting time for packet 1405 arrival. Tmax is the waiting time used as the threshold to declare a 1406 packet lost. Lost packets SHALL be designated as having undefined 1407 delay, and counted for the RLDNS metric. 1409 The calculations on the delay (RTT) SHALL be performed on the 1410 conditional distribution, conditioned on successful packet arrival 1411 within Tmax. Also, when all packet delays are stored, the process 1412 which calculates the RTT value MAY enforce the Tmax threshold on 1413 stored values before calculations. See section 4.1 of [RFC3393] for 1414 details on the conditional distribution to exclude undefined values 1415 of delay, and Section 5 of [RFC6703] for background on this analysis 1416 choice. 1418 The reference method requires some way to distinguish between 1419 different packets in a stream to establish correspondence between 1420 sending times and receiving times for each successfully-arriving 1421 reply. Therefore, sequence numbers or other send-order 1422 identification MUST be retained at the Src or included with each 1423 packet to disambiguate packet reordering if it occurs. Sequence 1424 number is part of the payload described under Fixed Parameters. 1426 DNS Messages bearing Queries provide for random ID Numbers in the 1427 Identification header field, so more than one query may be launched 1428 while a previous request is outstanding when the ID Number is used. 1430 IF a DNS response does not arrive within Tmax, the response time is 1431 undefined, and RTDNS = 1. The Message ID SHALL be used to 1432 disambiguate the successive queries. 1434 @@@@ This would require support of ID generation and population in 1435 the Message. An alternative would be to use a random Source port on 1436 the Query Message, but we would choose ONE before proceeding. 1438 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1439 instruction to "send a Type-P packet back to the Src as quickly as 1440 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1441 [RFC6673] presents additional requirements which shall be included in 1442 the method of measurement for this metric. 1444 In addition to operations described in [RFC2681], the Src MUST parse 1445 the DNS headers of the reply and prepare the information for 1446 subsequent reporting as a measured result, along with the Round-Trip 1447 Delay. 1449 6.3.2. Packet Stream Generation 1451 This section gives the details of the packet traffic which is the 1452 basis for measurement. In IPPM metrics, this is called the Stream, 1453 and can easily be described by providing the list of stream 1454 parameters. 1456 1457 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1458 generate Poisson sampling intervals. The reciprocal of lambda is the 1459 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1460 = 1/lambda, in seconds. 1462 Method 3 is used, where given a start time (Run-time Parameter), the 1463 subsequent send times are all computed prior to measurement by 1464 computing the pseudo-random distribution of inter-packet send times, 1465 (truncating the distribution as specified in the Run-time 1466 Parameters), and the Src sends each packet at the computed times. 1468 Note that Trunc is the upper limit on inter-packet times in the 1469 Poisson distribution. A random value greater than Trunc is set equal 1470 to Trunc instead. 1472 6.3.3. Traffic Filtering (observation) Details 1474 The measured results based on a filtered version of the packets 1475 observed, and this section provides the filter details (when 1476 present). 1478
. 1480 NA 1482 6.3.4. Sampling Distribution 1484 1487 NA 1489 6.3.5. Run-time Parameters and Data Format 1491 Run-time Parameters are input factors that must be determined, 1492 configured into the measurement system, and reported with the results 1493 for the context to be complete. 1495 1497 Src the IP address of the host in the Src Role (format ipv4-address- 1498 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1499 see Section 4 of [RFC6991]) 1501 Dst the IP address of the host in the Dst Role (format ipv4-address- 1502 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1503 see section 4 of [RFC6991]) 1505 T0 a time, the start of a measurement interval, (format "date-and- 1506 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1507 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1508 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1509 and Tf is to be interpreted as the Duration of the measurement 1510 interval. The start time is controlled through other means. 1512 Tf a time, the end of a measurement interval, (format "date-and-time" 1513 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1514 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1515 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1516 Tf is interpreted as the Duration of the measurement interval. 1518 Reciprocal_lambda average packet interval for Poisson Streams 1519 expressed in units of seconds, as a positive value of type 1520 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1521 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1522 conversion to/from the 32-bit NTP timestamp as per section 6 of 1523 [RFC5905]. 1525 Trunc Upper limit on Poisson distribution expressed in units of 1526 seconds, as a positive value of type decimal64 with fraction 1527 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1528 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1529 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1530 this limit will be clipped and set to the limit value). (if fixed, 1531 Trunc = 30.0000 seconds.) 1533 ID The 16-bit identifier assigned by the program that generates the 1534 query, and which must vary in successive queries, see 1535 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1536 corresponding reply and can be used by the requester (Src) to 1537 match-up replies to outstanding queries. 1539 QNAME The domain name of the Query, formatted as specified in 1540 section 4 of [RFC6991]. 1542 QTYPE The Query Type, which will correspond to the IP address family 1543 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1544 uint16, as per section 9.2 of [RFC6020]. 1546 6.3.6. Roles 1548 1550 Src launches each packet and waits for return transmissions from 1551 Dst. 1553 Dst waits for each packet from Src and sends a return packet to Src. 1555 6.4. Output 1557 This category specifies all details of the Output of measurements 1558 using the metric. 1560 6.4.1. Type 1562 1564 Raw -- for each DNS Query packet sent, sets of values as defined in 1565 the next column, including the status of the response, only assigning 1566 delay values to successful query-response pairs. 1568 6.4.2. Reference Definition 1570 1572 For all outputs: 1574 T the time the DNS Query was sent during the measurement interval, 1575 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1576 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1577 by Section 6.1 of [RFC2330]. 1579 dT The time value of the round-trip delay to receive the DNS 1580 response, expressed in units of seconds, as a positive value of 1581 type decimal64 with fraction digits = 9 (see section 9.3 of 1582 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1583 with lossless conversion to/from the 64-bit NTP timestamp as per 1584 section 6 of RFC [RFC5905]. This value is undefined when the 1585 response packet is not received at Src within waiting time Tmax 1586 seconds. 1588 Rcode The value of the Rcode field in the DNS response header, 1589 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1590 Non-zero values convey errors in the response, and such replies 1591 must be analyzed separately from successful requests. 1593 6.4.3. Metric Units 1595 . 1598 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1600 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1602 6.4.4. Calibration 1604 Section 3.7.3 of [RFC7679] provides a means to quantify the 1605 systematic and random errors of a time measurement. In-situ 1606 calibration could be enabled with an internal loopback at the Source 1607 host that includes as much of the measurement system as possible, 1608 performs address and payload manipulation as needed, and provides 1609 some form of isolation (e.g., deterministic delay) to avoid send- 1610 receive interface contention. Some portion of the random and 1611 systematic error can be characterized this way. 1613 When a measurement controller requests a calibration measurement, the 1614 loopback is applied and the result is output in the same format as a 1615 normal measurement with additional indication that it is a 1616 calibration result. 1618 Both internal loopback calibration and clock synchronization can be 1619 used to estimate the *available accuracy* of the Output Metric Units. 1620 For example, repeated loopback delay measurements will reveal the 1621 portion of the Output result resolution which is the result of system 1622 noise, and thus inaccurate. 1624 6.5. Administrative items 1626 6.5.1. Status 1628 1630 6.5.2. Requestor 1632 name or RFC, etc. 1634 6.5.3. Revision 1636 1.0 1638 6.5.4. Revision Date 1640 YYYY-MM-DD 1642 6.6. Comments and Remarks 1644 Additional (Informational) details for this entry 1646 7. UDP Poisson One-way Delay and Loss Registry Entries 1648 This section specifies five initial registry entries for the UDP 1649 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1651 IANA Note: Registry "Name" below specifies a single registry entry, 1652 whose output format varies according to the element of 1653 the name that specifies one form of statistical summary. There is an 1654 additional metric name for the Loss metric. 1656 All column entries beside the ID, Name, Description, and Output 1657 Reference Method categories are the same, thus this section proposes 1658 six closely-related registry entries. As a result, IANA is also 1659 asked to assign corresponding URNs and URLs to each Named Metric. 1661 7.1. Summary 1663 This category includes multiple indexes to the registry entries, the 1664 element ID and metric name. 1666 7.1.1. ID (Identifier) 1668 1671 IANA is asked to assign different numeric identifiers to each of the 1672 six Metrics. 1674 7.1.2. Name 1676 1678 OWDelay_Active_IP-UDP-Poisson- 1679 Payload250B_RFCXXXXsecY_Seconds_ 1681 where is one of: 1683 o 95Percentile 1685 o Mean 1687 o Min 1689 o Max 1691 o StdDev 1692 OWLoss_Active_IP-UDP-Poisson- 1693 Payload250B_RFCXXXXsecY_Percent_LossRatio 1695 7.1.3. URI and URL 1697 URI: Prefix urn:ietf:metrics:perf: 1699 URL: http:\\www.iana.org\ ... 1701 7.1.4. Description 1703 OWDelay: This metric assesses the delay of a stream of packets 1704 exchanged between two hosts (or measurement points), and reports the 1705 One-way delay for all successfully exchanged packets 1706 based on their conditional delay distribution. 1708 where is one of: 1710 o 95Percentile 1712 o Mean 1714 o Min 1716 o Max 1718 o StdDev 1720 OWLoss: This metric assesses the loss ratio of a stream of packets 1721 exchanged between two hosts (which are the two measurement points), 1722 and the Output is the One-way loss ratio for all successfully 1723 received packets expressed as a percentage. 1725 7.2. Metric Definition 1727 This category includes columns to prompt the entry of all necessary 1728 details related to the metric definition, including the RFC reference 1729 and values of input factors, called fixed parameters. 1731 7.2.1. Reference Definition 1733 1735 For Delay: 1737 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1738 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1739 7679, DOI 10.17487/RFC7679, January 2016, . 1742 [RFC7679] 1744 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1745 6049, January 2011. 1747 [RFC6049] 1749 1751 Section 3.4 of [RFC7679] provides the reference definition of the 1752 singleton (single value) One-way delay metric. Section 4.4 of 1753 [RFC7679] provides the reference definition expanded to cover a 1754 multi-value sample. Note that terms such as singleton and sample are 1755 defined in Section 11 of [RFC2330]. 1757 Only successful packet transfers with finite delay are included in 1758 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1760 For loss: 1762 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1763 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1764 10.17487/RFC7680, January 2016, . 1767 Section 2.4 of [RFC7680] provides the reference definition of the 1768 singleton (single value) one-way loss metric. Section 3.4 of 1769 [RFC7680] provides the reference definition expanded to cover a 1770 multi-singleton sample. Note that terms such as singleton and sample 1771 are defined in Section 11 of [RFC2330]. 1773 7.2.2. Fixed Parameters 1775 1779 Type-P: 1781 o IPv4 header values: 1783 * DSCP: set to 0 1785 * TTL: set to 255 1786 * Protocol: Set to 17 (UDP) 1788 o IPv6 header values: 1790 * DSCP: set to 0 1792 * Hop Count: set to 255 1794 * Protocol: Set to 17 (UDP) 1796 o UDP header values: 1798 * Checksum: the checksum MUST be calculated and included in the 1799 header 1801 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1803 * Security features in use influence the number of Padding 1804 octets. 1806 * 250 octets total, including the TWAMP format 1808 Other measurement parameters: 1810 Tmax: a loss threshold waiting time with value 3.0, expressed in 1811 units of seconds, as a positive value of type decimal64 with 1812 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1813 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1814 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1816 See the Packet Stream generation category for two additional Fixed 1817 Parameters. 1819 7.3. Method of Measurement 1821 This category includes columns for references to relevant sections of 1822 the RFC(s) and any supplemental information needed to ensure an 1823 unambiguous methods for implementations. 1825 7.3.1. Reference Method 1827 1830 The methodology for this metric is defined as Type-P-One-way-Delay- 1831 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1832 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1834 The reference method distinguishes between long-delayed packets and 1835 lost packets by implementing a maximum waiting time for packet 1836 arrival. Tmax is the waiting time used as the threshold to declare a 1837 packet lost. Lost packets SHALL be designated as having undefined 1838 delay, and counted for the OWLoss metric. 1840 The calculations on the one-way delay SHALL be performed on the 1841 conditional distribution, conditioned on successful packet arrival 1842 within Tmax. Also, when all packet delays are stored, the process 1843 which calculates the one-way delay value MAY enforce the Tmax 1844 threshold on stored values before calculations. See section 4.1 of 1845 [RFC3393] for details on the conditional distribution to exclude 1846 undefined values of delay, and Section 5 of [RFC6703] for background 1847 on this analysis choice. 1849 The reference method requires some way to distinguish between 1850 different packets in a stream to establish correspondence between 1851 sending times and receiving times for each successfully-arriving 1852 packet. Sequence numbers or other send-order identification MUST be 1853 retained at the Src or included with each packet to disambiguate 1854 packet reordering if it occurs. 1856 Since a standard measurement protocol is employed [RFC5357], then the 1857 measurement process will determine the sequence numbers or timestamps 1858 applied to test packets after the Fixed and Runtime parameters are 1859 passed to that process. The measurement protocol dictates the format 1860 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1861 payload. 1863 7.3.2. Packet Stream Generation 1865 This section gives the details of the packet traffic which is the 1866 basis for measurement. In IPPM metrics, this is called the Stream, 1867 and can easily be described by providing the list of stream 1868 parameters. 1870 1872 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1873 generate Poisson sampling intervals. The reciprocal of lambda is the 1874 average packet spacing, thus the Run-time Parameter is 1875 Reciprocal_lambda = 1/lambda, in seconds. 1877 Method 3 SHALL be used, where given a start time (Run-time 1878 Parameter), the subsequent send times are all computed prior to 1879 measurement by computing the pseudo-random distribution of inter- 1880 packet send times, (truncating the distribution as specified in the 1881 Parameter Trunc), and the Src sends each packet at the computed 1882 times. 1884 Note that Trunc is the upper limit on inter-packet times in the 1885 Poisson distribution. A random value greater than Trunc is set equal 1886 to Trunc instead. 1888 Reciprocal_lambda average packet interval for Poisson Streams 1889 expressed in units of seconds, as a positive value of type 1890 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1891 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1892 conversion to/from the 32-bit NTP timestamp as per section 6 of 1893 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1895 Trunc Upper limit on Poisson distribution expressed in units of 1896 seconds, as a positive value of type decimal64 with fraction 1897 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1898 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1899 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1900 this limit will be clipped and set to the limit value). Trunc = 1901 30.0000 seconds. 1903 7.3.3. Traffic Filtering (observation) Details 1905 NA 1907 7.3.4. Sampling Distribution 1909 NA 1911 7.3.5. Run-time Parameters and Data Format 1913 Run-time Parameters are input factors that must be determined, 1914 configured into the measurement system, and reported with the results 1915 for the context to be complete. 1917 1919 Src the IP address of the host in the Src Role (format ipv4-address- 1920 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1921 see Section 4 of [RFC6991]) 1923 Dst the IP address of the host in the Dst Role (format ipv4-address- 1924 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1925 see section 4 of [RFC6991]) 1927 T0 a time, the start of a measurement interval, (format "date-and- 1928 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1929 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1930 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1931 and Tf is to be interpreted as the Duration of the measurement 1932 interval. The start time is controlled through other means. 1934 Tf a time, the end of a measurement interval, (format "date-and-time" 1935 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1936 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1937 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1938 Tf is interpreted as the Duration of the measurement interval. 1940 7.3.6. Roles 1942 1944 Src launches each packet and waits for return transmissions from 1945 Dst. This is the TWAMP Session-Sender. 1947 Dst waits for each packet from Src and sends a return packet to Src. 1948 This is the TWAMP Session-Reflector. 1950 7.4. Output 1952 This category specifies all details of the Output of measurements 1953 using the metric. 1955 7.4.1. Type 1957 1959 See subsection titles below for Types. 1961 7.4.2. Reference Definition 1963 1965 For all output types --- 1967 T0 the start of a measurement interval, (format "date-and-time" as 1968 specified in Section 5.6 of [RFC3339], see also Section 3 of 1969 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1970 [RFC2330]. 1972 Tf the end of a measurement interval, (format "date-and-time" as 1973 specified in Section 5.6 of [RFC3339], see also Section 3 of 1974 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1975 [RFC2330]. 1977 For LossRatio -- the count of lost packets to total packets sent is 1978 the basis for the loss ratio calculation as per Section 4.1 of 1979 [RFC7680]. 1981 For each , one of the following sub-sections apply: 1983 7.4.2.1. Percentile95 1985 The 95th percentile SHALL be calculated using the conditional 1986 distribution of all packets with a finite value of One-way delay 1987 (undefined delays are excluded), a single value as follows: 1989 See section 4.1 of [RFC3393] for details on the conditional 1990 distribution to exclude undefined values of delay, and Section 5 of 1991 [RFC6703] for background on this analysis choice. 1993 See section 4.3 of [RFC3393] for details on the percentile statistic 1994 (where Round-trip delay should be substituted for "ipdv"). 1996 The percentile = 95, meaning that the reported delay, "95Percentile", 1997 is the smallest value of one-way delay for which the Empirical 1998 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1999 one-way delay values in the conditional distribution. See section 2000 11.3 of [RFC2330] for the definition of the percentile statistic 2001 using the EDF. 2003 95Percentile The time value of the result is expressed in units of 2004 seconds, as a positive value of type decimal64 with fraction 2005 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2006 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2007 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2009 7.4.2.2. Mean 2011 The mean SHALL be calculated using the conditional distribution of 2012 all packets with a finite value of One-way delay (undefined delays 2013 are excluded), a single value as follows: 2015 See section 4.1 of [RFC3393] for details on the conditional 2016 distribution to exclude undefined values of delay, and Section 5 of 2017 [RFC6703] for background on this analysis choice. 2019 See section 4.2.2 of [RFC6049] for details on calculating this 2020 statistic, and 4.2.3 of [RFC6049]. 2022 Mean The time value of the result is expressed in units of seconds, 2023 as a positive value of type decimal64 with fraction digits = 9 2024 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2025 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2026 NTP timestamp as per section 6 of RFC [RFC5905] 2028 7.4.2.3. Min 2030 The minimum SHALL be calculated using the conditional distribution of 2031 all packets with a finite value of One-way delay (undefined delays 2032 are excluded), a single value as follows: 2034 See section 4.1 of [RFC3393] for details on the conditional 2035 distribution to exclude undefined values of delay, and Section 5 of 2036 [RFC6703] for background on this analysis choice. 2038 See section 4.3.2 of [RFC6049] for details on calculating this 2039 statistic, and 4.3.3 of [RFC6049]. 2041 Min The time value of the result is expressed in units of seconds, 2042 as a positive value of type decimal64 with fraction digits = 9 2043 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2044 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2045 NTP timestamp as per section 6 of RFC [RFC5905] 2047 7.4.2.4. Max 2049 The maximum SHALL be calculated using the conditional distribution of 2050 all packets with a finite value of One-way delay (undefined delays 2051 are excluded), a single value as follows: 2053 See section 4.1 of [RFC3393] for details on the conditional 2054 distribution to exclude undefined values of delay, and Section 5 of 2055 [RFC6703] for background on this analysis choice. 2057 See section 4.3.2 of [RFC6049] for a closely related method for 2058 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2059 as follows: 2061 Max = (FiniteDelay [j]) 2063 such that for some index, j, where 1 <= j <= N 2064 FiniteDelay[j] >= FiniteDelay[n] for all n 2066 Max The time value of the result is expressed in units of seconds, 2067 as a positive value of type decimal64 with fraction digits = 9 2068 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2069 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2070 NTP timestamp as per section 6 of RFC [RFC5905] 2072 7.4.2.5. Std_Dev 2074 The Std_Dev SHALL be calculated using the conditional distribution of 2075 all packets with a finite value of One-way delay (undefined delays 2076 are excluded), a single value as follows: 2078 See section 4.1 of [RFC3393] for details on the conditional 2079 distribution to exclude undefined values of delay, and Section 5 of 2080 [RFC6703] for background on this analysis choice. 2082 See section 4.3.2 of [RFC6049] for a closely related method for 2083 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2084 the classic calculation for standard deviation of a population. 2086 Std_Dev The time value of the result is expressed in units of 2087 seconds, as a positive value of type decimal64 with fraction 2088 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2089 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2090 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2092 7.4.3. Metric Units 2094 . 2097 The of One-way Delay is expressed in seconds. 2099 The One-way Loss Ratio is expressed as a percentage of lost packets 2100 to total packets sent. 2102 7.4.4. Calibration 2104 Section 3.7.3 of [RFC7679] provides a means to quantify the 2105 systematic and random errors of a time measurement. In-situ 2106 calibration could be enabled with an internal loopback that includes 2107 as much of the measurement system as possible, performs address 2108 manipulation as needed, and provides some form of isolation (e.g., 2109 deterministic delay) to avoid send-receive interface contention. 2110 Some portion of the random and systematic error can be characterized 2111 this way. 2113 For one-way delay measurements, the error calibration must include an 2114 assessment of the internal clock synchronization with its external 2115 reference (this internal clock is supplying timestamps for 2116 measurement). In practice, the time offsets of clocks at both the 2117 source and destination are needed to estimate the systematic error 2118 due to imperfect clock synchronization (the time offsets are 2119 smoothed, thus the random variation is not usually represented in the 2120 results). 2122 time_offset The time value of the result is expressed in units of 2123 seconds, as a signed value of type decimal64 with fraction digits 2124 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2125 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2126 NTP timestamp as per section 6 of RFC [RFC5905] 2128 When a measurement controller requests a calibration measurement, the 2129 loopback is applied and the result is output in the same format as a 2130 normal measurement with additional indication that it is a 2131 calibration result. In any measurement, the measurement function 2132 SHOULD report its current estimate of time offset as an indicator of 2133 the degree of synchronization. 2135 Both internal loopback calibration and clock synchronization can be 2136 used to estimate the *available accuracy* of the Output Metric Units. 2137 For example, repeated loopback delay measurements will reveal the 2138 portion of the Output result resolution which is the result of system 2139 noise, and thus inaccurate. 2141 7.5. Administrative items 2143 7.5.1. Status 2145 2147 7.5.2. Requestor (keep?) 2149 name or RFC, etc. 2151 7.5.3. Revision 2153 1.0 2155 7.5.4. Revision Date 2157 YYYY-MM-DD 2159 7.6. Comments and Remarks 2161 Additional (Informational) details for this entry 2163 8. UDP Periodic One-way Delay and Loss Registry Entries 2165 This section specifies five initial registry entries for the UDP 2166 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 2168 IANA Note: Registry "Name" below specifies a single registry entry, 2169 whose output format varies according to the element of 2170 the name that specifies one form of statistical summary. There is an 2171 additional metric name for the Loss metric. 2173 All column entries beside the ID, Name, Description, and Output 2174 Reference Method categories are the same, thus this section proposes 2175 six closely-related registry entries. As a result, IANA is also 2176 asked to assign corresponding URNs and URLs to each Named Metric. 2178 8.1. Summary 2180 This category includes multiple indexes to the registry entries, the 2181 element ID and metric name. 2183 8.1.1. ID (Identifier) 2185 2188 IANA is asked to assign a different numeric identifiers to each of 2189 the six Metrics. 2191 8.1.2. Name 2193 2195 OWDelay_Active_IP-UDP-Periodic- 2196 Payload142B_RFCXXXXsecY_Seconds_ 2198 where is one of: 2200 o 95Percentile 2202 o Mean 2204 o Min 2206 o Max 2208 o StdDev 2209 OWLoss_Active_IP-UDP-Periodic- 2210 Payload142B_RFCXXXXsecY_Percent_LossRatio 2212 8.1.3. URIs 2214 URI: Prefix urn:ietf:metrics:perf: 2216 URL: http:\\www.iana.org\ ... 2218 8.1.4. Description 2220 OWDelay: This metric assesses the delay of a stream of packets 2221 exchanged between two hosts (or measurement points), and reports the 2222 One-way delay for all successfully exchanged packets 2223 based on their conditional delay distribution. 2225 where is one of: 2227 o 95Percentile 2229 o Mean 2231 o Min 2233 o Max 2235 o StdDev 2237 OWLoss: This metric assesses the loss ratio of a stream of packets 2238 exchanged between two hosts (which are the two measurement points), 2239 and the Output is the One-way loss ratio for all successfully 2240 received packets expressed as a percentage. 2242 8.2. Metric Definition 2244 This category includes columns to prompt the entry of all necessary 2245 details related to the metric definition, including the RFC reference 2246 and values of input factors, called fixed parameters. 2248 8.2.1. Reference Definition 2250 2252 For Delay: 2254 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2255 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2256 7679, DOI 10.17487/RFC7679, January 2016, . 2259 [RFC7679] 2261 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2262 6049, January 2011. 2264 [RFC6049] 2266 2268 Section 3.4 of [RFC7679] provides the reference definition of the 2269 singleton (single value) One-way delay metric. Section 4.4 of 2270 [RFC7679] provides the reference definition expanded to cover a 2271 multi-value sample. Note that terms such as singleton and sample are 2272 defined in Section 11 of [RFC2330]. 2274 Only successful packet transfers with finite delay are included in 2275 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2277 For loss: 2279 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2280 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2281 10.17487/RFC7680, January 2016, . 2284 Section 2.4 of [RFC7680] provides the reference definition of the 2285 singleton (single value) one-way loss metric. Section 3.4 of 2286 [RFC7680] provides the reference definition expanded to cover a 2287 multi-singleton sample. Note that terms such as singleton and sample 2288 are defined in Section 11 of [RFC2330]. 2290 8.2.2. Fixed Parameters 2292 2296 Type-P: 2298 o IPv4 header values: 2300 * DSCP: set to 0 2302 * TTL: set to 255 2303 * Protocol: Set to 17 (UDP) 2305 o IPv6 header values: 2307 * DSCP: set to 0 2309 * Hop Count: set to 255 2311 * Protocol: Set to 17 (UDP) 2313 o UDP header values: 2315 * Checksum: the checksum MUST be calculated and included in the 2316 header 2318 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2320 * Security features in use influence the number of Padding 2321 octets. 2323 * 142 octets total, including the TWAMP format 2325 Other measurement parameters: 2327 Tmax: a loss threshold waiting time with value 3.0, expressed in 2328 units of seconds, as a positive value of type decimal64 with 2329 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2330 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2331 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2333 See the Packet Stream generation category for two additional Fixed 2334 Parameters. 2336 8.3. Method of Measurement 2338 This category includes columns for references to relevant sections of 2339 the RFC(s) and any supplemental information needed to ensure an 2340 unambiguous methods for implementations. 2342 8.3.1. Reference Method 2344 2347 The methodology for this metric is defined as Type-P-One-way-Delay- 2348 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2349 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2350 However, a Periodic stream is used, as defined in [RFC3432]. 2352 The reference method distinguishes between long-delayed packets and 2353 lost packets by implementing a maximum waiting time for packet 2354 arrival. Tmax is the waiting time used as the threshold to declare a 2355 packet lost. Lost packets SHALL be designated as having undefined 2356 delay, and counted for the OWLoss metric. 2358 The calculations on the one-way delay SHALL be performed on the 2359 conditional distribution, conditioned on successful packet arrival 2360 within Tmax. Also, when all packet delays are stored, the process 2361 which calculates the one-way delay value MAY enforce the Tmax 2362 threshold on stored values before calculations. See section 4.1 of 2363 [RFC3393] for details on the conditional distribution to exclude 2364 undefined values of delay, and Section 5 of [RFC6703] for background 2365 on this analysis choice. 2367 The reference method requires some way to distinguish between 2368 different packets in a stream to establish correspondence between 2369 sending times and receiving times for each successfully-arriving 2370 packet. Sequence numbers or other send-order identification MUST be 2371 retained at the Src or included with each packet to disambiguate 2372 packet reordering if it occurs. 2374 Since a standard measurement protocol is employed [RFC5357], then the 2375 measurement process will determine the sequence numbers or timestamps 2376 applied to test packets after the Fixed and Runtime parameters are 2377 passed to that process. The measurement protocol dictates the format 2378 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2379 payload. 2381 8.3.2. Packet Stream Generation 2383 2385 This section gives the details of the packet traffic which is the 2386 basis for measurement. In IPPM metrics, this is called the Stream, 2387 and can easily be described by providing the list of stream 2388 parameters. 2390 Section 3 of [RFC3432] prescribes the method for generating Periodic 2391 streams using associated parameters. 2393 incT the nominal duration of inter-packet interval, first bit to 2394 first bit 2396 dT the duration of the interval for allowed sample start times 2398 T0 the actual start time of the periodic stream 2399 NOTE: an initiation process with a number of control exchanges 2400 resulting in unpredictable start times (within a time interval) may 2401 be sufficient to avoid synchronization of periodic streams, and 2402 therefore a valid replacement for selecting a start time at random 2403 from a fixed interval. 2405 These stream parameters will be specified as Run-time parameters. 2407 8.3.3. Traffic Filtering (observation) Details 2409 NA 2411 8.3.4. Sampling Distribution 2413 NA 2415 8.3.5. Run-time Parameters and Data Format 2417 Run-time Parameters are input factors that must be determined, 2418 configured into the measurement system, and reported with the results 2419 for the context to be complete. 2421 2423 Src the IP address of the host in the Src Role (format ipv4-address- 2424 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2425 see Section 4 of [RFC6991]) 2427 Dst the IP address of the host in the Dst Role (format ipv4-address- 2428 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2429 see section 4 of [RFC6991]) 2431 T0 a time, the start of a measurement interval, (format "date-and- 2432 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2433 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2434 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2435 and Tf is to be interpreted as the Duration of the measurement 2436 interval. The start time is controlled through other means. 2438 Tf a time, the end of a measurement interval, (format "date-and-time" 2439 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2440 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2441 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2442 Tf is interpreted as the Duration of the measurement interval. 2444 @@@@ should Periodic run-time params be fixed instead? Probably yes 2445 if modeling a specific version of tests. Note in the NAME, i.e. 2446 Poisson3.3 2448 8.3.6. Roles 2450 2452 Src launches each packet and waits for return transmissions from 2453 Dst. This is the TWAMP Session-Sender. 2455 Dst waits for each packet from Src and sends a return packet to Src. 2456 This is the TWAMP Session-Reflector. 2458 8.4. Output 2460 This category specifies all details of the Output of measurements 2461 using the metric. 2463 8.4.1. Type 2465 2467 See subsection titles in Reference Definition for Latency Types. 2469 8.4.2. Reference Definition 2471 2473 For all output types --- 2475 T0 the start of a measurement interval, (format "date-and-time" as 2476 specified in Section 5.6 of [RFC3339], see also Section 3 of 2477 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2478 [RFC2330]. 2480 Tf the end of a measurement interval, (format "date-and-time" as 2481 specified in Section 5.6 of [RFC3339], see also Section 3 of 2482 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2483 [RFC2330]. 2485 For LossRatio -- the count of lost packets to total packets sent is 2486 the basis for the loss ratio calculation as per Section 4.1 of 2487 [RFC7680]. 2489 For each , one of the following sub-sections apply: 2491 8.4.2.1. Percentile95 2493 The 95th percentile SHALL be calculated using the conditional 2494 distribution of all packets with a finite value of One-way delay 2495 (undefined delays are excluded), a single value as follows: 2497 See section 4.1 of [RFC3393] for details on the conditional 2498 distribution to exclude undefined values of delay, and Section 5 of 2499 [RFC6703] for background on this analysis choice. 2501 See section 4.3 of [RFC3393] for details on the percentile statistic 2502 (where Round-trip delay should be substituted for "ipdv"). 2504 The percentile = 95, meaning that the reported delay, "95Percentile", 2505 is the smallest value of one-way delay for which the Empirical 2506 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2507 one-way delay values in the conditional distribution. See section 2508 11.3 of [RFC2330] for the definition of the percentile statistic 2509 using the EDF. 2511 95Percentile The time value of the result is expressed in units of 2512 seconds, as a positive value of type decimal64 with fraction 2513 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2514 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2515 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2517 8.4.2.2. Mean 2519 The mean SHALL be calculated using the conditional distribution of 2520 all packets with a finite value of One-way delay (undefined delays 2521 are excluded), a single value as follows: 2523 See section 4.1 of [RFC3393] for details on the conditional 2524 distribution to exclude undefined values of delay, and Section 5 of 2525 [RFC6703] for background on this analysis choice. 2527 See section 4.2.2 of [RFC6049] for details on calculating this 2528 statistic, and 4.2.3 of [RFC6049]. 2530 Mean The time value of the result is expressed in units of seconds, 2531 as a positive value of type decimal64 with fraction digits = 9 2532 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2533 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2534 NTP timestamp as per section 6 of RFC [RFC5905] 2536 8.4.2.3. Min 2538 The minimum SHALL be calculated using the conditional distribution of 2539 all packets with a finite value of One-way delay (undefined delays 2540 are excluded), a single value as follows: 2542 See section 4.1 of [RFC3393] for details on the conditional 2543 distribution to exclude undefined values of delay, and Section 5 of 2544 [RFC6703] for background on this analysis choice. 2546 See section 4.3.2 of [RFC6049] for details on calculating this 2547 statistic, and 4.3.3 of [RFC6049]. 2549 Min The time value of the result is expressed in units of seconds, 2550 as a positive value of type decimal64 with fraction digits = 9 2551 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2552 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2553 NTP timestamp as per section 6 of RFC [RFC5905] 2555 8.4.2.4. Max 2557 The maximum SHALL be calculated using the conditional distribution of 2558 all packets with a finite value of One-way delay (undefined delays 2559 are excluded), a single value as follows: 2561 See section 4.1 of [RFC3393] for details on the conditional 2562 distribution to exclude undefined values of delay, and Section 5 of 2563 [RFC6703] for background on this analysis choice. 2565 See section 4.3.2 of [RFC6049] for a closely related method for 2566 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2567 as follows: 2569 Max = (FiniteDelay [j]) 2571 such that for some index, j, where 1 <= j <= N 2572 FiniteDelay[j] >= FiniteDelay[n] for all n 2574 Max The time value of the result is expressed in units of seconds, 2575 as a positive value of type decimal64 with fraction digits = 9 2576 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2577 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2578 NTP timestamp as per section 6 of RFC [RFC5905] 2580 8.4.2.5. Std_Dev 2582 The Std_Dev SHALL be calculated using the conditional distribution of 2583 all packets with a finite value of One-way delay (undefined delays 2584 are excluded), a single value as follows: 2586 See section 4.1 of [RFC3393] for details on the conditional 2587 distribution to exclude undefined values of delay, and Section 5 of 2588 [RFC6703] for background on this analysis choice. 2590 See section 4.3.2 of [RFC6049] for a closely related method for 2591 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2592 the classic calculation for standard deviation of a population. 2594 Std_Dev The time value of the result is expressed in units of 2595 seconds, as a positive value of type decimal64 with fraction 2596 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2597 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2598 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2600 8.4.3. Metric Units 2602 . 2605 The of One-way Delay is expressed in seconds, where 2606 is one of: 2608 o 95Percentile 2610 o Mean 2612 o Min 2614 o Max 2616 o StdDev 2618 The One-way Loss Ratio is expressed as a percentage of lost packets 2619 to total packets sent. 2621 8.4.4. Calibration 2623 Section 3.7.3 of [RFC7679] provides a means to quantify the 2624 systematic and random errors of a time measurement. In-situ 2625 calibration could be enabled with an internal loopback that includes 2626 as much of the measurement system as possible, performs address 2627 manipulation as needed, and provides some form of isolation (e.g., 2628 deterministic delay) to avoid send-receive interface contention. 2629 Some portion of the random and systematic error can be characterized 2630 this way. 2632 For one-way delay measurements, the error calibration must include an 2633 assessment of the internal clock synchronization with its external 2634 reference (this internal clock is supplying timestamps for 2635 measurement). In practice, the time offsets of clocks at both the 2636 source and destination are needed to estimate the systematic error 2637 due to imperfect clock synchronization (the time offsets are 2638 smoothed, thus the random variation is not usually represented in the 2639 results). 2641 time_offset The time value of the result is expressed in units of 2642 seconds, as a signed value of type decimal64 with fraction digits 2643 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2644 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2645 NTP timestamp as per section 6 of RFC [RFC5905] 2647 When a measurement controller requests a calibration measurement, the 2648 loopback is applied and the result is output in the same format as a 2649 normal measurement with additional indication that it is a 2650 calibration result. In any measurement, the measurement function 2651 SHOULD report its current estimate of time offset as an indicator of 2652 the degree of synchronization. 2654 Both internal loopback calibration and clock synchronization can be 2655 used to estimate the *available accuracy* of the Output Metric Units. 2656 For example, repeated loopback delay measurements will reveal the 2657 portion of the Output result resolution which is the result of system 2658 noise, and thus inaccurate. 2660 8.5. Administrative items 2662 8.5.1. Status 2664 2666 8.5.2. Requestor (keep?) 2668 name or RFC, etc. 2670 8.5.3. Revision 2672 1.0 2674 8.5.4. Revision Date 2676 YYYY-MM-DD 2678 8.6. Comments and Remarks 2680 Additional (Informational) details for this entry 2682 9. ICMP Round-trip Latency and Loss Registry Entries 2684 This section specifies three initial registry entries for the ICMP 2685 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2687 This section specifies four Registry entries with many common 2688 columns. 2690 All column entries beside the ID, Name, Description, and Output 2691 Reference Method categories are the same, thus this section proposes 2692 two closely-related registry entries. As a result, IANA is also 2693 asked to assign four corresponding URNs and URLs to each Named 2694 Metric. 2696 9.1. Summary 2698 This category includes multiple indexes to the registry entry: the 2699 element ID and metric name. 2701 9.1.1. ID (Identifier) 2703 2705 IANA is asked to assign different numeric identifiers to each of the 2706 four Named Metrics. 2708 9.1.2. Name 2710 2712 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Seconds_ 2714 where is one of: 2716 o Mean 2718 o Min 2720 o Max 2722 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Percent_LossRatio 2724 9.1.3. URIs 2726 URN: Prefix urn:ietf:metrics:perf: 2728 URL: http:/// 2730 9.1.4. Description 2732 RTDelay: This metric assesses the delay of a stream of ICMP packets 2733 exchanged between two hosts (which are the two measurement points), 2734 and the Output is the Round-trip delay for all successfully exchanged 2735 packets expressed as the of their conditional delay 2736 distribution, where is one of: 2738 o Mean 2740 o Min 2742 o Max 2744 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2745 packets exchanged between two hosts (which are the two measurement 2746 points), and the Output is the Round-trip loss ratio for all 2747 successfully exchanged packets expressed as a percentage. 2749 9.1.5. Change Controller 2751 IETF 2753 9.1.6. Version (of Registry Format) 2755 1.0 2757 9.2. Metric Definition 2759 This category includes columns to prompt the entry of all necessary 2760 details related to the metric definition, including the RFC reference 2761 and values of input factors, called fixed parameters. 2763 9.2.1. Reference Definition 2765 2767 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2768 Metric for IPPM", RFC 2681, September 1999. 2770 [RFC2681] 2772 2774 Section 2.4 of [RFC2681] provides the reference definition of the 2775 singleton (single value) Round-trip delay metric. Section 3.4 of 2776 [RFC2681] provides the reference definition expanded to cover a 2777 multi-singleton sample. Note that terms such as singleton and sample 2778 are defined in Section 11 of [RFC2330]. 2780 Note that although the [RFC2681] definition of "Round-trip-Delay 2781 between Src and Dst" is directionally ambiguous in the text, this 2782 metric tightens the definition further to recognize that the host in 2783 the "Src" role will send the first packet to "Dst", and ultimately 2784 receive the corresponding return packet from "Dst" (when neither are 2785 lost). 2787 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2788 the value of Round-trip delay in metric definitions and methods. The 2789 variable "dT" has been re-used in other IPPM literature to refer to 2790 different quantities, and cannot be used as a global variable name. 2792 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2794 [RFC6673] 2796 Both delay and loss metrics employ a maximum waiting time for 2797 received packets, so the count of lost packets to total packets sent 2798 is the basis for the loss ratio calculation as per Section 6.1 of 2799 [RFC6673]. 2801 9.2.2. Fixed Parameters 2803 2807 Type-P as defined in Section 13 of [RFC2330]: 2809 o IPv4 header values: 2811 * DSCP: set to 0 2813 * TTL: set to 255 2815 * Protocol: Set to 01 (ICMP) 2817 o IPv6 header values: 2819 * DSCP: set to 0 2821 * Hop Limit: set to 255 2823 * Protocol: Set to 01 (ICMP) 2825 o ICMP header values: 2827 * Type: 8 (Echo Request) 2829 * Code: 0 2831 * Checksum: the checksum MUST be calculated and included in the 2832 header 2834 * (Identifier and Sequence Number set at Run-Time) 2836 o ICMP Payload 2838 * total of 32 bytes of random info 2840 Other measurement parameters: 2842 o Tmax: a loss threshold waiting time 2844 * 3.0, expressed in units of seconds, as a positive value of type 2845 decimal64 with fraction digits = 4 (see section 9.3 of 2846 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2847 lossless conversion to/from the 32-bit NTP timestamp as per 2848 section 6 of [RFC5905]. 2850 9.3. Method of Measurement 2852 This category includes columns for references to relevant sections of 2853 the RFC(s) and any supplemental information needed to ensure an 2854 unambiguous methods for implementations. 2856 9.3.1. Reference Method 2858 2861 The methodology for this metric is defined as Type-P-Round-trip- 2862 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2863 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2864 Fixed Parameters. 2866 The reference method distinguishes between long-delayed packets and 2867 lost packets by implementing a maximum waiting time for packet 2868 arrival. Tmax is the waiting time used as the threshold to declare a 2869 packet lost. Lost packets SHALL be designated as having undefined 2870 delay, and counted for the RTLoss metric. 2872 The calculations on the delay (RTD) SHALL be performed on the 2873 conditional distribution, conditioned on successful packet arrival 2874 within Tmax. Also, when all packet delays are stored, the process 2875 which calculates the RTD value MAY enforce the Tmax threshold on 2876 stored values before calculations. See section 4.1 of [RFC3393] for 2877 details on the conditional distribution to exclude undefined values 2878 of delay, and Section 5 of [RFC6703] for background on this analysis 2879 choice. 2881 The reference method requires some way to distinguish between 2882 different packets in a stream to establish correspondence between 2883 sending times and receiving times for each successfully-arriving 2884 packet. Sequence numbers or other send-order identification MUST be 2885 retained at the Src or included with each packet to disambiguate 2886 packet reordering if it occurs. 2888 The measurement process will determine the sequence numbers applied 2889 to test packets after the Fixed and Runtime parameters are passed to 2890 that process. The ICMP measurement process and protocol will dictate 2891 the format of sequence numbers and other identifiers. 2893 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2894 instruction to "send a Type-P packet back to the Src as quickly as 2895 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2896 [RFC6673] presents additional requirements which MUST be included in 2897 the method of measurement for this metric. 2899 9.3.2. Packet Stream Generation 2901 This section gives the details of the packet traffic which is the 2902 basis for measurement. In IPPM metrics, this is called the Stream, 2903 and can easily be described by providing the list of stream 2904 parameters. 2906 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2907 On Receive. This is a modification of Section 3 of [RFC3432], which 2908 prescribes the method for generating Periodic streams using 2909 associated parameters: 2911 incT the nominal duration of inter-packet interval, first bit to 2912 first bit 2914 dT the duration of the interval for allowed sample start times 2916 T0 the actual start time of the periodic stream 2918 The incT and T0 stream parameters will be specified as Run-time 2919 parameters, dT is not used in SendOnRcv. 2921 A SendOnRcv sender behaves exactly like a Periodic stream generator 2922 while all reply packets arrive with RTD < incT, and the inter-packet 2923 interval will be constant. 2925 If a reply packet arrives with RTD >= incT, then the inter-packet 2926 interval for the next sending time is nominally RTD. 2928 If a reply packet fails to arrive within Tmax, then the inter-packet 2929 interval for the next sending time is nominally Tmax. 2931 If an immediate send on reply arrival is desired, then set incT=0. 2933 9.3.3. Traffic Filtering (observation) Details 2935 The measured results based on a filtered version of the packets 2936 observed, and this section provides the filter details (when 2937 present). 2939
. 2941 NA 2943 9.3.4. Sampling Distribution 2945 2948 NA 2950 9.3.5. Run-time Parameters and Data Format 2952 Run-time Parameters are input factors that must be determined, 2953 configured into the measurement system, and reported with the results 2954 for the context to be complete. 2956 2958 Src the IP address of the host in the Src Role (format ipv4-address- 2959 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2960 see Section 4 of [RFC6991]) 2962 Dst the IP address of the host in the Dst Role (format ipv4-address- 2963 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2964 see section 4 of [RFC6991]) 2966 T0 a time, the start of a measurement interval, (format "date-and- 2967 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2968 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2969 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2970 and Tf is to be interpreted as the Duration of the measurement 2971 interval. The start time is controlled through other means. 2973 Count The total count of ICMP Echo Requests to send, formatted as a 2974 uint16, as per section 9.2 of [RFC6020]. 2976 (see the Packet Stream Generation section for additional Run-time 2977 parameters) 2979 9.3.6. Roles 2981 2983 Src launches each packet and waits for return transmissions from 2984 Dst. 2986 Dst waits for each packet from Src and sends a return packet to Src. 2988 9.4. Output 2990 This category specifies all details of the Output of measurements 2991 using the metric. 2993 9.4.1. Type 2995 2997 See subsection titles in Reference Definition for Latency Types. 2999 LossRatio -- the count of lost packets to total packets sent is the 3000 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 3002 9.4.2. Reference Definition 3004 3006 For all output types --- 3008 T0 the start of a measurement interval, (format "date-and-time" as 3009 specified in Section 5.6 of [RFC3339], see also Section 3 of 3010 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3011 [RFC2330]. 3013 Tf the end of a measurement interval, (format "date-and-time" as 3014 specified in Section 5.6 of [RFC3339], see also Section 3 of 3015 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3016 [RFC2330]. 3018 TotalCount the count of packets actually sent by the Src to Dst 3019 during the measurement interval. 3021 For LossRatio -- the count of lost packets to total packets sent is 3022 the basis for the loss ratio calculation as per Section 4.1 of 3023 [RFC7680]. 3025 For each , one of the following sub-sections apply: 3027 9.4.2.1. Mean 3029 The mean SHALL be calculated using the conditional distribution of 3030 all packets with a finite value of Round-trip delay (undefined delays 3031 are excluded), a single value as follows: 3033 See section 4.1 of [RFC3393] for details on the conditional 3034 distribution to exclude undefined values of delay, and Section 5 of 3035 [RFC6703] for background on this analysis choice. 3037 See section 4.2.2 of [RFC6049] for details on calculating this 3038 statistic, and 4.2.3 of [RFC6049]. 3040 Mean The time value of the result is expressed in units of seconds, 3041 as a positive value of type decimal64 with fraction digits = 9 3042 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3043 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3044 NTP timestamp as per section 6 of RFC [RFC5905] 3046 9.4.2.2. Min 3048 The minimum SHALL be calculated using the conditional distribution of 3049 all packets with a finite value of Round-trip delay (undefined delays 3050 are excluded), a single value as follows: 3052 See section 4.1 of [RFC3393] for details on the conditional 3053 distribution to exclude undefined values of delay, and Section 5 of 3054 [RFC6703] for background on this analysis choice. 3056 See section 4.3.2 of [RFC6049] for details on calculating this 3057 statistic, and 4.3.3 of [RFC6049]. 3059 Min The time value of the result is expressed in units of seconds, 3060 as a positive value of type decimal64 with fraction digits = 9 3061 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3062 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3063 NTP timestamp as per section 6 of RFC [RFC5905] 3065 9.4.2.3. Max 3067 The maximum SHALL be calculated using the conditional distribution of 3068 all packets with a finite value of Round-trip delay (undefined delays 3069 are excluded), a single value as follows: 3071 See section 4.1 of [RFC3393] for details on the conditional 3072 distribution to exclude undefined values of delay, and Section 5 of 3073 [RFC6703] for background on this analysis choice. 3075 See section 4.3.2 of [RFC6049] for a closely related method for 3076 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3077 as follows: 3079 Max = (FiniteDelay [j]) 3081 such that for some index, j, where 1 <= j <= N 3082 FiniteDelay[j] >= FiniteDelay[n] for all n 3084 Max The time value of the result is expressed in units of seconds, 3085 as a positive value of type decimal64 with fraction digits = 9 3086 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3087 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3088 NTP timestamp as per section 6 of RFC [RFC5905] 3090 9.4.3. Metric Units 3092 . 3095 The of Round-trip Delay is expressed in seconds, where 3096 is one of: 3098 o Mean 3100 o Min 3102 o Max 3104 The Round-trip Loss Ratio is expressed as a percentage of lost 3105 packets to total packets sent. 3107 9.4.4. Calibration 3109 Section 3.7.3 of [RFC7679] provides a means to quantify the 3110 systematic and random errors of a time measurement. In-situ 3111 calibration could be enabled with an internal loopback at the Source 3112 host that includes as much of the measurement system as possible, 3113 performs address manipulation as needed, and provides some form of 3114 isolation (e.g., deterministic delay) to avoid send-receive interface 3115 contention. Some portion of the random and systematic error can be 3116 characterized this way. 3118 When a measurement controller requests a calibration measurement, the 3119 loopback is applied and the result is output in the same format as a 3120 normal measurement with additional indication that it is a 3121 calibration result. 3123 Both internal loopback calibration and clock synchronization can be 3124 used to estimate the *available accuracy* of the Output Metric Units. 3125 For example, repeated loopback delay measurements will reveal the 3126 portion of the Output result resolution which is the result of system 3127 noise, and thus inaccurate. 3129 9.5. Administrative items 3131 9.5.1. Status 3133 3135 9.5.2. Requestor (keep?) 3137 name or RFC, etc. 3139 9.5.3. Revision 3141 1.0 3143 9.5.4. Revision Date 3145 YYYY-MM-DD 3147 9.6. Comments and Remarks 3149 Additional (Informational) details for this entry 3151 10. TCP Round-Trip Delay and Loss Registry Entries 3153 This section specifies three initial registry entries for the Passive 3154 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 3155 Round-trip Loss Count. 3157 This section specifies four Registry entries with many common 3158 columns. 3160 All column entries beside the ID, Name, Description, and Output 3161 Reference Method categories are the same, thus this section proposes 3162 four closely-related registry entries. As a result, IANA is also 3163 asked to assign four corresponding URNs and URLs to each Named 3164 Metric. 3166 10.1. Summary 3168 This category includes multiple indexes to the registry entry: the 3169 element ID and metric name. 3171 10.1.1. ID (Identifier) 3173 3175 IANA is asked to assign different numeric identifiers to each of the 3176 four Named Metrics. 3178 10.1.2. Name 3180 3182 RTDelay_Passive_IP-TCP_RFCXXXXsecY_Seconds_ 3184 where is one of: 3186 o Mean 3188 o Min 3190 o Max 3192 RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count 3194 10.1.3. URIs 3196 URN: Prefix urn:ietf:metrics:perf: 3198 URL: http:/// 3200 10.1.4. Description 3202 RTDelay: This metric assesses the round-trip delay of TCP packets 3203 constituting a single connection, exchanged between two hosts. The 3204 Observation Point [RFC7011] is assumed to be in the network at a 3205 remote point from the end hosts. The Output is the Round-trip delay 3206 for all successfully exchanged packets expressed as the 3207 of their conditional delay distribution, where is one of: 3209 o Mean 3211 o Min 3213 o Max 3215 RTLoss: This metric assesses the estimated loss count for TCP packets 3216 constituting a single connection, exchanged between two hosts. The 3217 Observation Point [RFC7011] is assumed to be in the network at a 3218 remote point from the end hosts. The Output is the estimated Loss 3219 Count for the measurement interval. 3221 10.1.5. Change Controller 3223 IETF 3225 10.1.6. Version (of Registry Format) 3227 1.0 3229 10.2. Metric Definition 3231 This category includes columns to prompt the entry of all necessary 3232 details related to the metric definition, including the RFC reference 3233 and values of input factors, called fixed parameters. 3235 10.2.1. Reference Definitions 3237 3239 Although there is no RFC that describes passive measurement of Round- 3240 Trip Delay, 3242 @@@@ is this true??? Searches seem to say so. 3244 the parallel definition for Active measurement is: 3246 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 3247 Metric for IPPM", RFC 2681, September 1999. 3249 [RFC2681] 3251 3253 This metric definition uses the terms singleton and sample as defined 3254 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 3255 reference definition of the singleton (single value) Round-trip delay 3256 metric. Section 3.4 of [RFC2681] provides the reference definition 3257 expanded to cover a multi-singleton sample.) 3259 With the Observation Point [RFC7011] (OP) located between the hosts 3260 participating in the TCP connection, the Round-trip Delay metric 3261 requires two individual measurements between the OP and each host, 3262 such that the Spatial Composition [RFC6049]of the measurements yields 3263 a Round-trip Delay singleton. 3265 Using the direction of TCP SYN transmission to anchor the 3266 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3267 during connection establishment. The direction of SYN transfer is 3268 the Forward direction of transmission, from A through OP to B 3269 (Reverse is B through OP to A). 3271 Traffic filters reduce the packet stream at the OP to a Qualified 3272 bidirectional flow packets. 3274 In the definitions below, Corresponding Packets are transferred in 3275 different directions and convey a common value in a TCP header field 3276 that establishes correspondence (to the extent possible). Examples 3277 may be found in the TCP timestamp fields. 3279 @@@@ Note the first-bit last bit questions in the definitions below. 3281 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3282 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3283 observed (the first bit of ?) a Qualified packet to host B at wire- 3284 time T', that host B received that packet and sent a Corresponding 3285 Packet back to host A, and that OP observed (the last bit of ?) that 3286 packet at wire-time T' + RTD_fwd. 3288 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3289 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3290 OP observed (the first bit of ?) a Qualified packet to host A at 3291 wire-time T'', that host A received that packet and sent a 3292 Corresponding Packet back to host B, and that OP observed (the last 3293 bit of ?) that packet at wire-time T'' + RTD_rev. 3295 Ideally, the packet sent from host B to host A in both definitions 3296 above SHOULD be the same packet (or, when measuring RTD_rev first, 3297 the packet from host A to host B in both definitions should be the 3298 same). 3300 The REQUIRED Composition Function for a singleton of Round-trip Delay 3301 at time T (where T is the earliest of T' and T'' above) is: 3303 RTDelay = RTD_fwd + RTD_rev 3305 Note that when OP is located at host A or host B, one of the terms in 3306 RTDelay will be zero or negligible. 3308 The definition of Round-trip Loss Count uses the nomenclature 3309 developed above, based on observation of the TCP header sequence 3310 numbers and storing the sequence number gaps observed. Packet Losses 3311 can be inferred from: 3313 o Out-of-order segments: TCP segments are normally monotonically 3314 increasing. Section 3 of [RFC4737] describes the notion of "next 3315 expected" sequence numbers which can be adapted to TCP segments 3316 (for the purpose of detecting reordered packets). Observation of 3317 out-of-order segments indicates loss on the path prior to the OP, 3318 and creates a gap. 3320 o Duplicate segments: Section 2 of [RFC5560] defines identical 3321 packets and is suitable for evaluation of TCP packets to detect 3322 duplication. Observation of duplicate segments *without a 3323 corresponding gap* indicates loss on the path following the OP 3324 (because they overlap part of the delivered sequence numbers 3325 already observed at OP). 3327 Each observation of an out-of-order or duplicate infers a singleton 3328 of loss, but composition of Round-trip Loss Counts will be conducted 3329 over a measurement interval which is synonymous with a single TCP 3330 connection. 3332 With the above observations in the Forward direction over a 3333 measurement interval, the count of out-of-order and duplicate 3334 segments is defined as RTL_fwd. Comparable observations in the 3335 Reverse direction are defined as RTL_rev. 3337 For a measurement interval (corresponding to a single TCP 3338 connection), T0 to Tf, the REQUIRED Composition Function for a the 3339 two single-direction counts of inferred loss is: 3341 RTLoss = RTL_fwd + RTL_rev 3343 10.2.2. Fixed Parameters 3345 3349 Traffic Filters: 3351 o IPv4 header values: 3353 * DSCP: set to 0 3355 * Protocol: Set to 06 (TCP) 3357 o IPv6 header values: 3359 * DSCP: set to 0 3360 * Protocol: Set to 06 (TCP) 3362 o TCP header values: 3364 * Flags: ACK, SYN, others?? 3366 * Checksum: the checksum MUST be calculated and included in the 3367 header 3369 * Timestamp Option (TSopt): Set 3371 + Kind: 8 3373 + Length: 10 bytes 3375 o 3377 10.3. Method of Measurement 3379 This category includes columns for references to relevant sections of 3380 the RFC(s) and any supplemental information needed to ensure an 3381 unambiguous methods for implementations. 3383 10.3.1. Reference Methods 3385 3388 The foundation methodology for this metric is defined in Section 4 of 3389 [RFC7323] using the Timestamp Option with modifications that allow 3390 application at a mid-path Observation Point (OP) [RFC7011]. Further 3391 details and applicable heuristics were derived from [Strowes] and 3392 [Trammell-14]. 3394 The Traffic Filter at the OP is configured to observe a single TCP 3395 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3396 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3397 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3398 of RTDelay as RTDelay-SA (SYN-ACK = SA, composed using the forward 3399 and reverse measurement pair). RTDelay-SA SHOULD be treated 3400 separately from other RTDelays on data-bearing packets and their 3401 ACKs. The RTDelay-SA value MAY be used as a sanity check on other 3402 Composed values of RTDelay. 3404 @@@@ Should we add a separate singleton metric for RTDelay-SA ?? 3405 (seems reasonable and useful, but no loss metric however) 3406 For payload bearing packets, the OP measures the time interval 3407 between observation of a packet with Sequence Number s, and the 3408 corresponding ACK with same Sequence number. When the payload is 3409 transferred from host A to host B, the observed interval is RTD_fwd. 3411 Because many data transfers are unidirectional (say, in the Forward 3412 direction from host A to host B), it is necessary to use pure ACK 3413 packets with Timestamp (TSval) and their Timestamp value echo to 3414 perform a RTD_rev measurement. The time interval between observation 3415 of the ACK from B to A, and the corresponding packet with Timestamp 3416 echo (TSecr) is the RTD_rev. 3418 Delay Measurement Filtering Heuristics: 3420 If Data payloads were transferred in both Forward and Reverse 3421 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3422 of [RFC7323] could be applied. This rule essentially excludes any 3423 measurement using a packet unless it makes progress in the transfer 3424 (advances the left edge of the send window, consistent 3425 with[Strowes]). 3427 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3428 that is larger than previously observed values. This would tend to 3429 exclude Reverse measurements taken when the Application has no data 3430 ready to send, because considerable time could be added to RTD_rev 3431 from this source of error. 3433 The statistic calculations to summarize the delay (RTDelay) SHALL be 3434 performed on the conditional distribution, conditioned on successful 3435 Forward and Reverse measurements which follow the Heuristics. 3437 Method for Inferring Loss: 3439 The OP tracks sequence numbers and stores gaps for each direction of 3440 transmission, as well as the next-expected sequence number as in 3441 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3442 segments and Duplicate segments. 3444 Loss Measurement Filtering Heuristics: 3446 [Trammell-14] adds a window of evaluation based on the RTDelay. 3448 Spurious (unneeded) retransmissions (observed as duplicates) can also 3449 be reduced this way, as described in [Trammell-14]. 3451 Sources of Error: 3453 The principal source of RTDelay error is the host processing time to 3454 return a packet that defines the termination of a time interval. The 3455 heuristics above intend to mitigate these errors by excluding 3456 measurements where host processing time is a significant part of 3457 RTD_fwd or RTD_rev. 3459 A key source of RTLoss error is observation loss, described in 3460 section 3 of [Trammell-14]. 3462 10.3.2. Packet Stream Generation 3464 This section gives the details of the packet traffic which is the 3465 basis for measurement. In IPPM metrics, this is called the Stream, 3466 and can easily be described by providing the list of stream 3467 parameters. 3469 NA 3471 10.3.3. Traffic Filtering (observation) Details 3473 The measured results based on a filtered version of the packets 3474 observed, and this section provides the filter details (when 3475 present). 3477 The Fixed Parameters above give a portion of the Traffic Filter. 3478 Other aspects will be supplied as Run-time Parameters (below). 3480 10.3.4. Sampling Distribution 3482 3485 This metric requires a complete sample of all packets that qualify 3486 according to the Traffic Filter criteria. 3488 10.3.5. Run-time Parameters and Data Format 3490 Run-time Parameters are input factors that must be determined, 3491 configured into the measurement system, and reported with the results 3492 for the context to be complete. 3494 3496 Src the IP address of the host in the host A Role (format ipv4- 3497 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3498 IPv6, see Section 4 of [RFC6991]) 3500 Dst the IP address of the host in the host B (format ipv4-address- 3501 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3502 see section 4 of [RFC6991]) 3504 T0 a time, the start of a measurement interval, (format "date-and- 3505 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3506 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3507 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3508 and Td is to be interpreted as the Duration of the measurement 3509 interval. The start time is controlled through other means. 3511 Td Optionally, the end of a measurement interval, (format "date-and- 3512 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3513 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3514 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3515 the measurement interval MAY be controlled by the measured 3516 connection, where the second pair of FIN and ACK packets exchanged 3517 between host A and B effectively ends the interval. 3519 ... ... 3521 10.3.6. Roles 3523 3525 host A launches the SYN packet to open the connection, and 3526 synonymous with an IP address. 3528 host B replies with the SYN-ACK packet to open the connection, and 3529 synonymous with an IP address. 3531 10.4. Output 3533 This category specifies all details of the Output of measurements 3534 using the metric. 3536 10.4.1. Type 3538 3540 See subsection titles in Reference Definition for RTDelay Types. 3542 For RTLoss -- the count of lost packets. 3544 10.4.2. Reference Definition 3546 3548 For all output types --- 3550 T0 the start of a measurement interval, (format "date-and-time" as 3551 specified in Section 5.6 of [RFC3339], see also Section 3 of 3552 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3553 [RFC2330]. 3555 Tf the end of a measurement interval, (format "date-and-time" as 3556 specified in Section 5.6 of [RFC3339], see also Section 3 of 3557 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3558 [RFC2330]. The end of the measurement interval MAY be controlled 3559 by the measured connection, where the second pair of FIN and ACK 3560 packets exchanged between host A and B effectively ends the 3561 interval. 3563 ... ... 3565 For RTLoss -- the count of lost packets. 3567 For each , one of the following sub-sections apply: 3569 10.4.2.1. Mean 3571 The mean SHALL be calculated using the conditional distribution of 3572 all packets with a finite value of Round-trip delay (undefined delays 3573 are excluded), a single value as follows: 3575 See section 4.1 of [RFC3393] for details on the conditional 3576 distribution to exclude undefined values of delay, and Section 5 of 3577 [RFC6703] for background on this analysis choice. 3579 See section 4.2.2 of [RFC6049] for details on calculating this 3580 statistic, and 4.2.3 of [RFC6049]. 3582 Mean The time value of the result is expressed in units of seconds, 3583 as a positive value of type decimal64 with fraction digits = 9 3584 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3585 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3586 NTP timestamp as per section 6 of RFC [RFC5905] 3588 10.4.2.2. Min 3590 The minimum SHALL be calculated using the conditional distribution of 3591 all packets with a finite value of Round-trip delay (undefined delays 3592 are excluded), a single value as follows: 3594 See section 4.1 of [RFC3393] for details on the conditional 3595 distribution to exclude undefined values of delay, and Section 5 of 3596 [RFC6703] for background on this analysis choice. 3598 See section 4.3.2 of [RFC6049] for details on calculating this 3599 statistic, and 4.3.3 of [RFC6049]. 3601 Min The time value of the result is expressed in units of seconds, 3602 as a positive value of type decimal64 with fraction digits = 9 3603 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3604 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3605 NTP timestamp as per section 6 of RFC [RFC5905] 3607 10.4.2.3. Max 3609 The maximum SHALL be calculated using the conditional distribution of 3610 all packets with a finite value of Round-trip delay (undefined delays 3611 are excluded), a single value as follows: 3613 See section 4.1 of [RFC3393] for details on the conditional 3614 distribution to exclude undefined values of delay, and Section 5 of 3615 [RFC6703] for background on this analysis choice. 3617 See section 4.3.2 of [RFC6049] for a closely related method for 3618 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3619 as follows: 3621 Max = (FiniteDelay [j]) 3623 such that for some index, j, where 1 <= j <= N 3624 FiniteDelay[j] >= FiniteDelay[n] for all n 3626 Max The time value of the result is expressed in units of seconds, 3627 as a positive value of type decimal64 with fraction digits = 9 3628 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3629 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3630 NTP timestamp as per section 6 of RFC [RFC5905] 3632 10.4.3. Metric Units 3634 . 3637 The of Round-trip Delay is expressed in seconds, where 3638 is one of: 3640 o Mean 3642 o Min 3644 o Max 3646 The Round-trip Loss Count is expressed as a number of packets. 3648 10.4.4. Calibration 3650 Passive measurements at an OP could be calibrated against an active 3651 measurement (with loss emulation) at host A or B, where the active 3652 measurement represents the ground-truth. 3654 10.5. Administrative items 3656 10.5.1. Status 3658 3660 10.5.2. Requestor (keep?) 3662 name or RFC, etc. 3664 10.5.3. Revision 3666 1.0 3668 10.5.4. Revision Date 3670 YYYY-MM-DD 3672 10.6. Comments and Remarks 3674 Additional (Informational) details for this entry 3676 11. ver08 BLANK Registry Entry 3678 This section gives an initial registry entry for .... 3680 11.1. Summary 3682 This category includes multiple indexes to the registry entries, the 3683 element ID and metric name. 3685 11.1.1. ID (Identifier) 3687 3689 11.1.2. Name 3691 3693 11.1.3. URIs 3695 URI: Prefix urn:ietf:metrics:perf: 3697 URL: 3699 11.1.4. Description 3701 TBD. 3703 11.1.5. Reference 3705 3707 11.1.6. Change Controller 3709 3711 11.1.7. Version (of Registry Format) 3713 3715 11.2. Metric Definition 3717 This category includes columns to prompt the entry of all necessary 3718 details related to the metric definition, including the RFC reference 3719 and values of input factors, called fixed parameters. 3721 11.2.1. Reference Definition 3723 3725 3727 11.2.2. Fixed Parameters 3729 3733 11.3. Method of Measurement 3735 This category includes columns for references to relevant sections of 3736 the RFC(s) and any supplemental information needed to ensure an 3737 unambiguous methods for implementations. 3739 11.3.1. Reference Method 3741 3744 11.3.2. Packet Stream Generation 3746 3748 11.3.3. Traffic Filtering (observation) Details 3750 . 3754 11.3.4. Sampling Distribution 3756 3759 11.3.5. Run-time Parameters and Data Format 3761 . 3763 11.3.6. Roles 3765 3767 11.4. Output 3769 This category specifies all details of the Output of measurements 3770 using the metric. 3772 11.4.1. Type 3774 3776 11.4.2. Reference Definition 3778 3780 11.4.3. Metric Units 3782 . 3785 11.4.4. Calibration 3787 3792 11.5. Administrative items 3794 11.5.1. Status 3796 3798 11.5.2. Requestor 3800 3802 11.5.3. Revision 3804 1.0 3806 11.5.4. Revision Date 3808 YYYY-MM-DD 3810 11.6. Comments and Remarks 3812 Additional (Informational) details for this entry 3814 12. Example RTCP-XR Registry Entry 3816 This section is MAY BE DELETED or adapted before submission. 3818 This section gives an example registry entry for the end-point metric 3819 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 3820 reporting. 3822 12.1. Registry Indexes 3824 This category includes multiple indexes to the registry entries, the 3825 element ID and metric name. 3827 12.1.1. Identifier 3829 An integer having enough digits to uniquely identify each entry in 3830 the Registry. 3832 12.1.2. Name 3834 A metric naming convention is TBD. 3836 12.1.3. URI 3838 Prefix urn:ietf:metrics:param: 3840 12.1.4. Status 3842 current 3844 12.1.5. Requestor 3846 Alcelip Mornuley 3848 12.1.6. Revision 3850 1.0 3852 12.1.7. Revision Date 3854 2014-07-04 3856 12.1.8. Description 3858 TBD. 3860 12.1.9. Reference Specification(s) 3862 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 3864 12.2. Metric Definition 3866 This category includes columns to prompt the entry of all necessary 3867 details related to the metric definition, including the RFC reference 3868 and values of input factors, called fixed parameters. Section 3.2 of 3869 [RFC7003] provides the reference information for this category. 3871 12.2.1. Reference Definition 3873 Packets Discarded in Bursts: 3875 The total number of packets discarded during discard bursts. The 3876 measured value is unsigned value. If the measured value exceeds 3877 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 3878 range measurement. If the measurement is unavailable, the value 3879 0xFFFFFF MUST be reported. 3881 12.2.2. Fixed Parameters 3883 Fixed Parameters are input factors that must be determined and 3884 embedded in the measurement system for use when needed. The values 3885 of these parameters is specified in the Registry. 3887 Threshold: 8 bits, set to value = 3 packets. 3889 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 3890 successive packets that must not be discarded prior to and following 3891 a discard packet in order for this discarded packet to be regarded as 3892 part of a gap. Note that the Threshold is set in accordance with the 3893 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 3895 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 3897 This field is used to indicate whether the burst/gap discard metrics 3898 are Sampled, Interval, or Cumulative metrics [RFC6792]: 3900 I=10: Interval Duration - the reported value applies to the most 3901 recent measurement interval duration between successive metrics 3902 reports. 3904 I=11: Cumulative Duration - the reported value applies to the 3905 accumulation period characteristic of cumulative measurements. 3907 Senders MUST NOT use the values I=00 or I=01. 3909 12.3. Method of Measurement 3911 This category includes columns for references to relevant sections of 3912 the RFC(s) and any supplemental information needed to ensure an 3913 unambiguous methods for implementations. For the Burst/Gap Discard 3914 Metric, it appears that the only guidance on methods of measurement 3915 is in Section 3.0 of [RFC7003] and its supporting references. 3916 Relevant information is repeated below, although there appears to be 3917 no section titled "Method of Measurement" in [RFC7003]. 3919 12.3.1. Reference Method 3921 Metrics in this block report on burst/gap discard in the stream 3922 arriving at the RTP system. Measurements of these metrics are made 3923 at the receiving end of the RTP stream. Instances of this metrics 3924 block use the synchronization source (SSRC) to refer to the separate 3925 auxiliary Measurement Information Block [RFC6776], which describes 3926 measurement periods in use (see [RFC6776], Section 4.2). 3928 This metrics block relies on the measurement period in the 3929 Measurement Information Block indicating the span of the report. 3930 Senders MUST send this block in the same compound RTCP packet as the 3931 Measurement Information Block. Receivers MUST verify that the 3932 measurement period is received in the same compound RTCP packet as 3933 this metrics block. If not, this metrics block MUST be discarded. 3935 12.3.2. Stream Type and Stream Parameters 3937 Since RTCP-XR Measurements are conducted on live RTP traffic, the 3938 complete description of the stream is contained in SDP messages that 3939 proceed the establishment of a compatible stream between two or more 3940 communicating hosts. See Run-time Parameters, below. 3942 12.3.3. Output Type and Data Format 3944 The output type defines the type of result that the metric produces. 3946 o Value: Packets Discarded in Bursts 3948 o Data Format: 24 bits 3950 o Reference: Section 3.2 of [RFC7003] 3952 12.3.4. Metric Units 3954 The measured results are apparently expressed in packets, although 3955 there is no section of [RFC7003] titled "Metric Units". 3957 12.3.5. Run-time Parameters and Data Format 3959 Run-Time Parameters are input factors that must be determined, 3960 configured into the measurement system, and reported with the results 3961 for the context to be complete. However, the values of these 3962 parameters is not specified in the Registry, rather these parameters 3963 are listed as an aid to the measurement system implementor or user 3964 (they must be left as variables, and supplied on execution). 3966 The Data Format of each Run-time Parameter SHALL be specified in this 3967 column, to simplify the control and implementation of measurement 3968 devices. 3970 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 3972 SDP Parameters: As defined in [RFC4566] 3974 Session description v= (protocol version number, currently only 0) 3976 o= (originator and session identifier : username, id, version number, 3977 network address) 3979 s= (session name : mandatory with at least one UTF-8-encoded 3980 character) 3982 i=* (session title or short information) u=* (URI of description) 3984 e=* (zero or more email address with optional name of contacts) 3986 p=* (zero or more phone number with optional name of contacts) 3988 c=* (connection information--not required if included in all media) 3990 b=* (zero or more bandwidth information lines) One or more Time 3991 descriptions ("t=" and "r=" lines; see below) 3993 z=* (time zone adjustments) 3995 k=* (encryption key) 3997 a=* (zero or more session attribute lines) 3999 Zero or more Media descriptions (each one starting by an "m=" line; 4000 see below) 4002 m= (media name and transport address) 4004 i=* (media title or information field) 4005 c=* (connection information -- optional if included at session level) 4007 b=* (zero or more bandwidth information lines) 4009 k=* (encryption key) 4011 a=* (zero or more media attribute lines -- overriding the Session 4012 attribute lines) 4014 An example Run-time SDP description follows: 4016 v=0 4018 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 4020 s=SDP Seminar i=A Seminar on the session description protocol 4022 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 4023 Doe) 4025 c=IN IP4 233.252.0.12/127 4027 t=2873397496 2873404696 4029 a=recvonly 4031 m=audio 49170 RTP/AVP 0 4033 m=video 51372 RTP/AVP 99 4035 a=rtpmap:99 h263-1998/90000 4037 12.4. Comments and Remarks 4039 TBD. 4041 13. Revision History 4043 This section may be removed for publication. It contains overview 4044 information on updates. 4046 This draft replaced draft-mornuley-ippm-initial-registry. 4048 In version 02, Section 4 has been edited to reflect recent discussion 4049 on the ippm-list: * Removed the combination or "Raw" and left 95th 4050 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 4051 use bullet lists and other indenting formats. * Payload format for 4052 measurement has been removed. * Explanation of Conditional delay 4053 distribution. 4055 Version 03 addressed Phil Eardley's comments and suggestions in 4056 sections 1-4. and resolved the definition of Percentiles. 4058 Version 04 * All section 4 parameters reference YANG types for 4059 alternate data formats. * Discussion has concluded that usecase(s) 4060 for machine parse-able registry columns are not needed. 4062 Version 05 * Revised several Poisson streams to Periodic, sections 4 4063 & 5. * Addition of ICMP (ping) metrics in section 9. * First 4064 implementation of Passive TCP RTT metrics in section 10. 4066 14. Security Considerations 4068 These registry entries represent no known security implications for 4069 Internet Security. Each referenced Metric contains a Security 4070 Considerations section. 4072 15. IANA Considerations 4074 IANA is requested to populate The Performance Metric Registry defined 4075 in [I-D.ietf-ippm-metric-registry] with the values defined above. 4077 See the IANA Considerations section of 4078 [I-D.ietf-ippm-metric-registry] for additional requests and 4079 considerations. 4081 16. Acknowledgements 4083 The authors thank Brian Trammell for suggesting the term "Run-time 4084 Parameters", which led to the distinction between run-time and fixed 4085 parameters implemented in this memo, for identifying the IPFIX metric 4086 with Flow Key as an example, for suggesting the Passive TCP RTD 4087 metric and supporting references, and for many other productive 4088 suggestions. Thanks to Peter Koch, who provided several useful 4089 suggestions for disambiguating successive DNS Queries in the DNS 4090 Response time metric. 4092 The authors also acknowledge the constructive reviews and helpful 4093 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 4094 participants in the LMAP working group. Thanks to Michelle Cotton 4095 for her early IANA review, and to Amanda Barber for answering 4096 questions related to the presentation of the registry and 4097 accessibility of the complete template via URL. 4099 17. References 4101 17.1. Normative References 4103 [I-D.ietf-ippm-metric-registry] 4104 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 4105 "Registry for Performance Metrics", Internet Draft (work 4106 in progress) draft-ietf-ippm-metric-registry, 2014. 4108 [RFC1035] Mockapetris, P., "Domain names - implementation and 4109 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4110 November 1987, . 4112 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4113 Requirement Levels", BCP 14, RFC 2119, 4114 DOI 10.17487/RFC2119, March 1997, 4115 . 4117 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 4118 "Framework for IP Performance Metrics", RFC 2330, 4119 DOI 10.17487/RFC2330, May 1998, 4120 . 4122 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 4123 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 4124 September 1999, . 4126 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 4127 Packet Loss Metric for IPPM", RFC 2680, 4128 DOI 10.17487/RFC2680, September 1999, 4129 . 4131 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 4132 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 4133 September 1999, . 4135 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4136 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4137 . 4139 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 4140 Metric for IP Performance Metrics (IPPM)", RFC 3393, 4141 DOI 10.17487/RFC3393, November 2002, 4142 . 4144 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 4145 performance measurement with periodic streams", RFC 3432, 4146 DOI 10.17487/RFC3432, November 2002, 4147 . 4149 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 4150 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 4151 DOI 10.17487/RFC4737, November 2006, 4152 . 4154 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 4155 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 4156 RFC 5357, DOI 10.17487/RFC5357, October 2008, 4157 . 4159 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 4160 RFC 5560, DOI 10.17487/RFC5560, May 2009, 4161 . 4163 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 4164 "Network Time Protocol Version 4: Protocol and Algorithms 4165 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 4166 . 4168 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 4169 the Network Configuration Protocol (NETCONF)", RFC 6020, 4170 DOI 10.17487/RFC6020, October 2010, 4171 . 4173 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 4174 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 4175 . 4177 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 4178 DOI 10.17487/RFC6673, August 2012, 4179 . 4181 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4182 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4183 . 4185 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 4186 "Specification of the IP Flow Information Export (IPFIX) 4187 Protocol for the Exchange of Flow Information", STD 77, 4188 RFC 7011, DOI 10.17487/RFC7011, September 2013, 4189 . 4191 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 4192 Scheffenegger, Ed., "TCP Extensions for High Performance", 4193 RFC 7323, DOI 10.17487/RFC7323, September 2014, 4194 . 4196 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 4197 Ed., "A One-Way Delay Metric for IP Performance Metrics 4198 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 4199 2016, . 4201 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 4202 Ed., "A One-Way Loss Metric for IP Performance Metrics 4203 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 4204 2016, . 4206 17.2. Informative References 4208 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 4209 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 4210 July 1991, . 4212 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 4213 "RTP Control Protocol Extended Reports (RTCP XR)", 4214 RFC 3611, DOI 10.17487/RFC3611, November 2003, 4215 . 4217 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 4218 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 4219 2005, . 4221 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4222 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 4223 July 2006, . 4225 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 4226 Flow Information Export (IPFIX) Applicability", RFC 5472, 4227 DOI 10.17487/RFC5472, March 2009, 4228 . 4230 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 4231 Carle, "Information Model for Packet Sampling Exports", 4232 RFC 5477, DOI 10.17487/RFC5477, March 2009, 4233 . 4235 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 4236 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 4237 March 2009, . 4239 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 4240 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 4241 DOI 10.17487/RFC6248, April 2011, 4242 . 4244 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 4245 Performance Metric Development", BCP 170, RFC 6390, 4246 DOI 10.17487/RFC6390, October 2011, 4247 . 4249 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 4250 IP Network Performance Metrics: Different Points of View", 4251 RFC 6703, DOI 10.17487/RFC6703, August 2012, 4252 . 4254 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 4255 Reporting Using a Source Description (SDES) Item and an 4256 RTCP Extended Report (XR) Block", RFC 6776, 4257 DOI 10.17487/RFC6776, October 2012, 4258 . 4260 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 4261 of the RTP Monitoring Framework", RFC 6792, 4262 DOI 10.17487/RFC6792, November 2012, 4263 . 4265 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 4266 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 4267 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 4268 September 2013, . 4270 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 4271 Aitken, P., and A. Akhter, "A Framework for Large-Scale 4272 Measurement of Broadband Performance (LMAP)", RFC 7594, 4273 DOI 10.17487/RFC7594, September 2015, 4274 . 4276 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times", 4277 September 2013. 4279 [Trammell-14] 4280 Trammell, B., "Inline Data Integrity Signals for Passive 4281 Measurement", March 2014. 4283 Authors' Addresses 4285 Al Morton 4286 AT&T Labs 4287 200 Laurel Avenue South 4288 Middletown,, NJ 07748 4289 USA 4291 Phone: +1 732 420 1571 4292 Fax: +1 732 368 1192 4293 Email: acmorton@att.com 4294 URI: http://home.comcast.net/~acmacm/ 4296 Marcelo Bagnulo 4297 Universidad Carlos III de Madrid 4298 Av. Universidad 30 4299 Leganes, Madrid 28911 4300 SPAIN 4302 Phone: 34 91 6249500 4303 Email: marcelo@it.uc3m.es 4304 URI: http://www.it.uc3m.es 4306 Philip Eardley 4307 BT 4308 Adastral Park, Martlesham Heath 4309 Ipswich 4310 ENGLAND 4312 Email: philip.eardley@bt.com 4314 Kevin D'Souza 4315 AT&T Labs 4316 200 Laurel Avenue South 4317 Middletown,, NJ 07748 4318 USA 4320 Phone: +1 732 420 xxxx 4321 Email: kld@att.com