idnits 2.17.1 draft-ietf-ippm-initial-registry-04.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 612 has weird spacing: '... Src the IP...' == Line 616 has weird spacing: '... Dst the IP...' == Line 633 has weird spacing: '..._lambda avera...' == Line 655 has weird spacing: '... Src launch...' == Line 658 has weird spacing: '... Dst waits ...' == (20 more instances...) -- The document date (June 30, 2017) is 2491 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 3068, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 3091, but no explicit reference was found in the text == Unused Reference: 'Brow00' is defined on line 3135, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 3147, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 3155, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 3160, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 3169, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 3200, 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 (~~), 15 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: January 1, 2018 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 June 30, 2017 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-04 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. This version includes: 20 * Addition of Loss Ratio metric in various sections (multiple metrics 21 per section). 23 * All section 4, 5, 6, 7, and 8 parameters reference YANG types for 24 alternate data formats. 26 * implementation of standard naming format for parameters. 28 * implementation of many IANA early-review comments. 30 Still need: Add MBM metric entry. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 1, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 75 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 76 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 78 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 81 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 82 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 83 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 10 84 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 85 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 11 86 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 87 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 12 88 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 13 89 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 90 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 91 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 92 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 15 95 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 15 96 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 16 97 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 16 98 4.5. Administrative items . . . . . . . . . . . . . . . . . . 17 99 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 17 100 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 17 101 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 17 102 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 17 103 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 17 104 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 17 105 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 17 107 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 18 108 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 18 109 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 18 110 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 18 111 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 18 112 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 18 113 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 18 114 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 19 115 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 20 116 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 20 117 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 21 118 5.3.3. Traffic Filtering (observation) Details . . . . . . . 21 119 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 22 120 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 22 121 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 22 122 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22 123 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 23 124 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 23 125 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23 126 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 24 127 5.5. Administrative items . . . . . . . . . . . . . . . . . . 24 128 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24 129 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 25 130 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 25 131 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 25 132 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 25 133 6. DNS Response Latency and Loss Registry Entries . . . . . . . 25 134 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25 135 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 25 136 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 26 137 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 26 138 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 26 139 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 26 140 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 26 141 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 26 142 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 26 143 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 27 145 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 29 146 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 29 147 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 30 148 6.3.3. Traffic Filtering (observation) Details . . . . . . . 31 149 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 31 150 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 31 151 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 32 152 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 33 153 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 33 154 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 33 155 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 33 156 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 34 157 6.5. Administrative items . . . . . . . . . . . . . . . . . . 34 158 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 34 159 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 34 160 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 34 161 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 34 162 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 34 163 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 35 164 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 35 165 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 35 166 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 35 167 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 36 168 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 36 169 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 36 170 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 36 171 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 37 172 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 38 173 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 38 174 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 39 175 7.3.3. Traffic Filtering (observation) Details . . . . . . . 40 176 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 40 177 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 40 178 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 41 179 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 41 180 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 41 181 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 41 182 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 44 183 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 44 184 7.5. Administrative items . . . . . . . . . . . . . . . . . . 45 185 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 45 186 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 45 187 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 45 188 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 45 189 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 45 190 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 46 191 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 46 192 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 46 193 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 46 194 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 47 195 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 47 196 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 47 197 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 47 198 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 48 199 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 49 200 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 49 201 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 50 202 8.3.3. Traffic Filtering (observation) Details . . . . . . . 51 203 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 51 204 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 51 205 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 52 206 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 52 207 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 52 208 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 52 209 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 55 210 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 55 211 8.5. Administrative items . . . . . . . . . . . . . . . . . . 56 212 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 56 213 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 56 214 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 56 215 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 56 216 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 56 217 9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 56 218 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56 219 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 56 220 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 56 221 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 57 222 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 57 223 9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 57 224 9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 57 225 9.1.7. Version (of Registry Format) . . . . . . . . . . . . 57 226 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 57 227 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 57 228 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 57 229 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 57 230 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 58 231 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 58 232 9.3.3. Traffic Filtering (observation) Details . . . . . . . 58 233 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 58 234 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 58 235 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 58 236 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 58 237 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 58 238 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 58 239 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 58 240 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 59 242 9.5. Administrative items . . . . . . . . . . . . . . . . . . 59 243 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 59 244 9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 59 245 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 59 246 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 59 247 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 59 248 10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 59 249 10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 59 250 10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 59 251 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 60 252 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 60 253 10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 60 254 10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 60 255 10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 60 256 10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 60 257 10.1.8. Description . . . . . . . . . . . . . . . . . . . . 60 258 10.1.9. Reference Specification(s) . . . . . . . . . . . . . 60 259 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 60 260 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 60 261 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 61 262 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 61 263 10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 61 264 10.3.2. Stream Type and Stream Parameters . . . . . . . . . 62 265 10.3.3. Output Type and Data Format . . . . . . . . . . . . 62 266 10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 62 267 10.3.5. Run-time Parameters and Data Format . . . . . . . . 62 268 10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 64 269 11. Revision History . . . . . . . . . . . . . . . . . . . . . . 64 270 12. Security Considerations . . . . . . . . . . . . . . . . . . . 64 271 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 272 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 273 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 274 15.1. Normative References . . . . . . . . . . . . . . . . . . 65 275 15.2. Informative References . . . . . . . . . . . . . . . . . 67 276 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 278 1. Introduction 280 Note: Efforts to synchronize structure and terminology with 281 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 282 drafts are stable. 284 This memo proposes an initial set of entries for the Performance 285 Metric Registry. It uses terms and definitions from the IPPM 286 literature, primarily [RFC2330]. Proponents of Passive Performance 287 Metrics are encouraged to develop a similar document. 289 Although there are several standard templates for organizing 290 specifications of performance metrics (see [RFC2679] for an example 291 of the traditional IPPM template, based to large extent on the 292 Benchmarking Methodology Working Group's traditional template in 293 [RFC1242], and see [RFC6390] for a similar template), none of these 294 templates were intended to become the basis for the columns of an 295 IETF-wide registry of metrics. While examinating aspects of metric 296 specifications which need to be registered, it became clear that none 297 of the existing metric templates fully satisfies the particular needs 298 of a registry. 300 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 301 for a Performance Metric Registry. Section 5 of 302 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 303 requesting registration of a Metric, that is the creation of entry(s) 304 in the Performance Metric Registry: "In essence, there needs to be 305 evidence that a candidate Registered Performance Metric has 306 significant industry interest, or has seen deployment, and there is 307 agreement that the candidate Registered Performance Metric serves its 308 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 309 also requires that new entries are administered by IANA through 310 Expert Review, which will ensure that the metrics are tightly 311 defined. 313 2. Scope 315 This document defines the initial set of Performance Metrics Registry 316 entries, for which IETF approval (following development in the IP 317 Performance Metrics (IPPM) Working Group) will satisfy the 318 requirement for Expert Review. Note that all are Active Performance 319 Metrics, which are based on RFCs prepared in the IPPM working group 320 of the IETF, according to their framework [RFC2330] and its updates. 322 3. Registry Categories and Columns 324 This section provides the categories and columns of the registry, for 325 easy reference. An entry (row) therefore gives a complete 326 description of a Registered Metric. 328 Registry Categories and Columns, shown as 329 Category 330 ------------------ 331 Column | Column | 333 Summary 334 ------------------------------------------------------------------------ 335 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 337 Metric Definition 338 ----------------------------------------- 339 Reference Definition | Fixed Parameters | 341 Method of Measurement 342 --------------------------------------------------------------------- 343 Reference | Packet | Traffic | Sampling | Run-time | Role | 344 Method | Stream | Filter | Distribution | Parameters | | 345 | Generation | 346 Output 347 ----------------------------------------- 348 Type | Reference | Units | Calibration | 349 | Definition | | | 351 Administrative Information 352 ---------------------------------- 353 Status |Request | Rev | Rev.Date | 355 Comments and Remarks 356 -------------------- 358 4. UDP Round-trip Latency and Loss Registry Entries 360 This section specifies an initial registry entry for the UDP Round- 361 trip Latency, and another entry for UDP Round-trip Loss Ratio. 363 Note: Each Registry entry only produces a "raw" output or a 364 statistical summary. To describe both "raw" and one or more 365 statistics efficiently, the Identifier, Name, and Output Categories 366 can be split and a single section can specify two or more closely- 367 related metrics. This section specifies two Registry entries with 368 many common columns. See Section 7 for an example specifying 369 multiple Registry entries with many common columns. 371 All column entries beside the ID, Name, Description, and Output 372 Reference Method categories are the same, thus this section proposes 373 two closely-related registry entries. As a result, IANA is also 374 asked to assign corresponding URNs and URLs to each Named Metric. 376 4.1. Summary 378 This category includes multiple indexes to the registry entry: the 379 element ID and metric name. 381 4.1.1. ID (Identifier) 383 385 IANA is asked to assign different numeric identifiers to each of the 386 two Named Metrics. 388 4.1.2. Name 390 392 RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 394 RTLoss_Active_IP-UDP-Poisson_RFCXXXXsecY_Percent_LossRatio 396 4.1.3. URIs 398 URN: Prefix urn:ietf:metrics:perf: 400 URL: http:/// 402 4.1.4. Description 404 RTDelay: This metric assesses the delay of a stream of packets 405 exchanged between two hosts (which are the two measurement points), 406 and the Output is the Round-trip delay for all successfully exchanged 407 packets expressed as the 95th percentile of their conditional delay 408 distribution. 410 RTLoss: This metric assesses the loss ratio of a stream of packets 411 exchanged between two hosts (which are the two measurement points), 412 and the Output is the Round-trip loss ratio for all successfully 413 exchanged packets expressed as a percentage. 415 4.1.5. Change Controller 417 IETF 419 4.1.6. Version (of Registry Format) 421 1.0 423 4.2. Metric Definition 425 This category includes columns to prompt the entry of all necessary 426 details related to the metric definition, including the RFC reference 427 and values of input factors, called fixed parameters. 429 4.2.1. Reference Definition 431 433 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 434 Metric for IPPM", RFC 2681, September 1999. 436 [RFC2681] 438 440 Section 2.4 of [RFC2681] provides the reference definition of the 441 singleton (single value) Round-trip delay metric. Section 3.4 of 442 [RFC2681] provides the reference definition expanded to cover a 443 multi-singleton sample. Note that terms such as singleton and sample 444 are defined in Section 11 of [RFC2330]. 446 Note that although the [RFC2681] definition of "Round-trip-Delay 447 between Src and Dst" is directionally ambiguous in the text, this 448 metric tightens the definition further to recognize that the host in 449 the "Src" role will send the first packet to "Dst", and ultimately 450 receive the corresponding return packet from "Dst" (when neither are 451 lost). 453 Finally, note that the variable "dT" is used in [RFC2681] to refer to 454 the value of Round-trip delay in metric definitions and methods. The 455 variable "dT" has been re-used in other IPPM literature to refer to 456 different quantities, and cannot be used as a global variable name. 458 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 460 [RFC6673] 462 Both delay and loss metrics employ a maximum waiting time for 463 received packets, so the count of lost packets to total packets sent 464 is the basis for the loss ratio calculation as per Section 6.1 of 465 [RFC6673]. 467 4.2.2. Fixed Parameters 469 473 Type-P as defined in Section 13 of [RFC2330]: 475 o IPv4 header values: 477 * DSCP: set to 0 479 * TTL: set to 255 481 * Protocol: Set to 17 (UDP) 483 o IPv6 header values: 485 * DSCP: set to 0 487 * Hop Count: set to 255 489 * Protocol: Set to 17 (UDP) 491 o UDP header values: 493 * Checksum: the checksum MUST be calculated and included in the 494 header 496 o UDP Payload 498 * total of 9 bytes 500 Other measurement parameters: 502 o Tmax: a loss threshold waiting time 504 * 3.0, expressed in units of seconds, as a positive value of type 505 decimal64 with fraction digits = 4 (see section 9.3 of 506 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 507 lossless conversion to/from the 32-bit NTP timestamp as per 508 section 6 of [RFC5905]. 510 4.3. Method of Measurement 512 This category includes columns for references to relevant sections of 513 the RFC(s) and any supplemental information needed to ensure an 514 unambiguous methods for implementations. 516 4.3.1. Reference Method 518 521 The methodology for this metric is defined as Type-P-Round-trip- 522 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 523 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 524 Fixed Parameters. 526 The reference method distinguishes between long-delayed packets and 527 lost packets by implementing a maximum waiting time for packet 528 arrival. Tmax is the waiting time used as the threshold to declare a 529 packet lost. Lost packets SHALL be designated as having undefined 530 delay, and counted for the RTLoss metric. 532 The calculations on the delay (RTT) SHALL be performed on the 533 conditional distribution, conditioned on successful packet arrival 534 within Tmax. Also, when all packet delays are stored, the process 535 which calculates the RTT value MAY enforce the Tmax threshold on 536 stored values before calculations. See section 4.1 of [RFC3393] for 537 details on the conditional distribution to exclude undefined values 538 of delay, and Section 5 of [RFC6703] for background on this analysis 539 choice. 541 The reference method requires some way to distinguish between 542 different packets in a stream to establish correspondence between 543 sending times and receiving times for each successfully-arriving 544 packet. Sequence numbers or other send-order identification MUST be 545 retained at the Src or included with each packet to dis-ambiguate 546 packet reordering if it occurs. 548 If a standard measurement protocol is employed, then the measurement 549 process will determine the sequence numbers or timestamps applied to 550 test packets after the Fixed and Runtime parameters are passed to 551 that process. The chosen measurement protocol will dictate the 552 format of sequence numbers and time-stamps, if they are conveyed in 553 the packet payload. 555 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 556 instruction to "send a Type-P packet back to the Src as quickly as 557 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 558 [RFC6673] presents additional requirements which MUST be included in 559 the method of measurement for this metric. 561 4.3.2. Packet Stream Generation 563 This section gives the details of the packet traffic which is the 564 basis for measurement. In IPPM metrics, this is called the Stream, 565 and can easily be described by providing the list of stream 566 parameters. 568
571 Section 11.1.3 of [RFC2330] provides three methods to generate 572 Poisson sampling intervals. the reciprocal of lambda is the average 573 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 574 lambda, in seconds. 576 Method 3 SHALL be used, where given a start time (Run-time 577 Parameter), the subsequent send times are all computed prior to 578 measurement by computing the pseudo-random distribution of inter- 579 packet send times, (truncating the distribution as specified in the 580 Run-time Parameter, Trunc), and the Src sends each packet at the 581 computed times. 583 Note that Trunc is the upper limit on inter-packet times in the 584 Poisson distribution. A random value greater than Trunc is set equal 585 to Trunc instead. 587 4.3.3. Traffic Filtering (observation) Details 589 The measured results based on a filtered version of the packets 590 observed, and this section provides the filter details (when 591 present). 593
. 595 NA 597 4.3.4. Sampling Distribution 599 602 NA 604 4.3.5. Run-time Parameters and Data Format 606 Run-time Parameters are input factors that must be determined, 607 configured into the measurement system, and reported with the results 608 for the context to be complete. 610 612 Src the IP address of the host in the Src Role (format ipv4-address- 613 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 614 see Section 4 of [RFC6991]) 616 Dst the IP address of the host in the Dst Role (format ipv4-address- 617 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 618 see section 4 of [RFC6991]) 620 T0 a time, the start of a measurement interval, (format "date-and- 621 time" as specified in Section 5.6 of [RFC3339], see also Section 3 622 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 623 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 624 and Tf is to be interpreted as the Duration of the measurement 625 interval. The start time is controlled through other means. 627 Tf a time, the end of a measurement interval, (format "date-and-time" 628 as specified in Section 5.6 of [RFC3339], see also Section 3 of 629 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 630 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 631 Tf is interpreted as the Duration of the measurement interval. 633 Reciprocal_lambda average packet interval for Poisson Streams 634 expressed in units of seconds, as a positive value of type 635 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 636 with resolution of 0.0001 seconds (0.1 ms), and with lossless 637 conversion to/from the 32-bit NTP timestamp as per section 6 of 638 [RFC5905]. 640 Trunc Upper limit on Poisson distribution expressed in units of 641 seconds, as a positive value of type decimal64 with fraction 642 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 643 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 644 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 645 this limit will be clipped and set to the limit value). (if fixed, 646 Trunc = 30.0000 seconds.) 648 >>> should Poisson run-time params be fixed instead? probably yes if 649 modeling a specific version of MBA tests. 651 4.3.6. Roles 653 655 Src launches each packet and waits for return transmissions from 656 Dst. 658 Dst waits for each packet from Src and sends a return packet to Src. 660 4.4. Output 662 This category specifies all details of the Output of measurements 663 using the metric. 665 4.4.1. Type 667 669 Percentile -- for the conditional distribution of all packets with a 670 valid value of Round-trip delay (undefined delays are excluded), a 671 single value corresponding to the 95th percentile, as follows: 673 See section 4.1 of [RFC3393] for details on the conditional 674 distribution to exclude undefined values of delay, and Section 5 of 675 [RFC6703] for background on this analysis choice. 677 The percentile = 95, meaning that the reported delay, "95Percentile", 678 is the smallest value of Round-trip delay for which the Empirical 679 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 680 Round-trip delay values in the conditional distribution. See section 681 11.3 of [RFC2330] for the definition of the percentile statistic 682 using the EDF. 684 LossRatio -- the count of lost packets to total packets sent is the 685 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 687 4.4.2. Reference Definition 689 691 For all outputs --- 693 T0 the start of a measurement interval, (format "date-and-time" as 694 specified in Section 5.6 of [RFC3339], see also Section 3 of 695 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 696 [RFC2330]. 698 Tf the end of a measurement interval, (format "date-and-time" as 699 specified in Section 5.6 of [RFC3339], see also Section 3 of 700 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 701 [RFC2330]. 703 TotalPkts the count of packets sent by the Src to Dst during the 704 measurement interval. 706 For 708 RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile: 710 95Percentile The time value of the result is expressed in units of 711 seconds, as a positive value of type decimal64 with fraction 712 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 713 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 714 the 64-bit NTP timestamp as 716 For 718 RTLoss_Active_IP-UDP-Poisson_RFCXXXXsecY_Percent_LossRatio: 720 Percentile The numeric value of the result is expressed in units of 721 lost packets to total packets times 100%, as a positive value of 722 type decimal64 with fraction digits = 9 (see section 9.3 of 723 [RFC6020]) with resolution of 0.0000000001. 725 4.4.3. Metric Units 727 . 730 The 95th Percentile of Round-trip Delay is expressed in seconds. 732 The Round-trip Loss Ratio is expressed as a percentage of lost 733 packets to total packets sent. 735 4.4.4. Calibration 737 Section 3.7.3 of [RFC7679] provides a means to quantify the 738 systematic and random errors of a time measurement. In-situ 739 calibration could be enabled with an internal loopback at the Source 740 host that includes as much of the measurement system as possible, 741 performs address manipulation as needed, and provides some form of 742 isolation (e.g., deterministic delay) to avoid send-receive interface 743 contention. Some portion of the random and systematic error can be 744 characterized this way. 746 When a measurement controller requests a calibration measurement, the 747 loopback is applied and the result is output in the same format as a 748 normal measurement with additional indication that it is a 749 calibration result. 751 Both internal loopback calibration and clock synchronization can be 752 used to estimate the *available accuracy* of the Output Metric Units. 753 For example, repeated loopback delay measurements will reveal the 754 portion of the Output result resolution which is the result of system 755 noise, and thus inaccurate. 757 4.5. Administrative items 759 4.5.1. Status 761 763 4.5.2. Requestor (keep?) 765 name or RFC, etc. 767 4.5.3. Revision 769 1.0 771 4.5.4. Revision Date 773 YYYY-MM-DD 775 4.6. Comments and Remarks 777 Additional (Informational) details for this entry 779 5. Packet Delay Variation Registry Entry 781 This section gives an initial registry entry for a Packet Delay 782 Variation metric. 784 Note: If each Registry entry should only produce a "raw" output or a 785 statistical summary, then the "Output" Category can be split and this 786 section can become two closely-related metrics. 788 5.1. Summary 790 This category includes multiple indexes to the registry entries, the 791 element ID and metric name. 793 795 5.1.1. ID (Identifier) 797 799 5.1.2. Name 801 803 OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 805 5.1.3. URIs 807 URI: Prefix urn:ietf:metrics:perf: 809 URL: http:/// 811 5.1.4. Description 813 An assessment of packet delay variation with respect to the minimum 814 delay observed on the stream, and the Output is expressed as the 95th 815 percentile of the packet delay variation distribution. 817 5.1.5. Change Controller 819 821 IETF 823 5.1.6. Version (of Registry Format) 825 1.0 827 5.2. Metric Definition 829 This category includes columns to prompt the entry of all necessary 830 details related to the metric definition, including the RFC reference 831 and values of input factors, called fixed parameters. 833 5.2.1. Reference Definition 835 837 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 838 Performance Metrics", RFC 2330, May 1998. [RFC2330] 840 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 841 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 842 [RFC3393] 844 Morton, A. and B. Claise, "Packet Delay Variation Applicability 845 Statement", RFC 5481, March 2009. [RFC5481] 846 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 847 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 848 June 2010.[RFC5905] 850 852 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 853 measured are referred to by the variable name "ddT" (applicable to 854 all forms of delay variation). However, this metric entry specifies 855 the PDV form defined in section 4.2 of [RFC5481], where the singleton 856 PDV for packet i is referred to by the variable name "PDV(i)". 858 5.2.2. Fixed Parameters 860 864 o IPv4 header values: 866 * DSCP: set to 0 868 * TTL: set to 255 870 * Protocol: Set to 17 (UDP) 872 o IPv6 header values: 874 * DSCP: set to 0 876 * Hop Count: set to 255 878 * Protocol: Set to 17 (UDP) 880 o UDP header values: 882 * Checksum: the checksum MUST be calculated and included in the 883 header 885 o UDP Payload 887 * total of 200 bytes 889 Other measurement parameters: 891 Tmax: a loss threshold waiting time with value 3.0, expressed in 892 units of seconds, as a positive value of type decimal64 with 893 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 894 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 895 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 897 F a selection function unambiguously defining the packets from the 898 stream selected for the metric. See section 4.2 of [RFC5481] for 899 the PDV form. 901 See the Packet Stream generation category for two additional Fixed 902 Parameters. 904 5.3. Method of Measurement 906 This category includes columns for references to relevant sections of 907 the RFC(s) and any supplemental information needed to ensure an 908 unambiguous methods for implementations. 910 5.3.1. Reference Method 912 915 See section 2.6 and 3.6 of [RFC3393] for general singleton element 916 calculations. This metric entry requires implementation of the PDV 917 form defined in section 4.2 of [RFC5481]. Also see measurement 918 considerations in section 8 of [RFC5481]. 920 The reference method distinguishes between long-delayed packets and 921 lost packets by implementing a maximum waiting time for packet 922 arrival. Tmax is the waiting time used as the threshold to declare a 923 packet lost. Lost packets SHALL be designated as having undefined 924 delay. 926 The calculations on the one-way delay SHALL be performed on the 927 conditional distribution, conditioned on successful packet arrival 928 within Tmax. Also, when all packet delays are stored, the process 929 which calculates the one-way delay value MAY enforce the Tmax 930 threshold on stored values before calculations. See section 4.1 of 931 [RFC3393] for details on the conditional distribution to exclude 932 undefined values of delay, and Section 5 of [RFC6703] for background 933 on this analysis choice. 935 The reference method requires some way to distinguish between 936 different packets in a stream to establish correspondence between 937 sending times and receiving times for each successfully-arriving 938 packet. Sequence numbers or other send-order identification MUST be 939 retained at the Src or included with each packet to dis-ambiguate 940 packet reordering if it occurs. 942 If a standard measurement protocol is employed, then the measurement 943 process will determine the sequence numbers or timestamps applied to 944 test packets after the Fixed and Runtime parameters are passed to 945 that process. The chosen measurement protocol will dictate the 946 format of sequence numbers and time-stamps, if they are conveyed in 947 the packet payload. 949 5.3.2. Packet Stream Generation 951 953 Section 11.1.3 of [RFC2330] provides three methods to generate 954 Poisson sampling intervals. the reciprocal of lambda is the average 955 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 956 lambda, in seconds. 958 Method 3 SHALL be used, where given a start time (Run-time 959 Parameter), the subsequent send times are all computed prior to 960 measurement by computing the pseudo-random distribution of inter- 961 packet send times, (truncating the distribution as specified in the 962 Parameter Trunc), and the Src sends each packet at the computed 963 times. 965 Note that Trunc is the upper limit on inter-packet times in the 966 Poisson distribution. A random value greater than Trunc is set equal 967 to Trunc instead. 969 Reciprocal_lambda average packet interval for Poisson Streams 970 expressed in units of seconds, as a positive value of type 971 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 972 with resolution of 0.0001 seconds (0.1 ms), and with lossless 973 conversion to/from the 32-bit NTP timestamp as per section 6 of 974 [RFC5905]. Reciprocal_lambda = 1 packet per second. 976 Trunc Upper limit on Poisson distribution expressed in units of 977 seconds, as a positive value of type decimal64 with fraction 978 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 979 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 980 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 981 this limit will be clipped and set to the limit value). Trunc = 982 30.0000 seconds. 984 5.3.3. Traffic Filtering (observation) Details 986 . 990 NA 992 5.3.4. Sampling Distribution 994 997 NA 999 5.3.5. Run-time Parameters and Data Format 1001 1003 Src the IP address of the host in the Src Role (format ipv4-address- 1004 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1005 see Section 4 of [RFC6991]) 1007 Dst the IP address of the host in the Dst Role (format ipv4-address- 1008 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1009 see section 4 of [RFC6991]) 1011 T0 a time, the start of a measurement interval, (format "date-and- 1012 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1013 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1014 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1015 and Tf is to be interpreted as the Duration of the measurement 1016 interval. The start time is controlled through other means. 1018 Tf a time, the end of a measurement interval, (format "date-and-time" 1019 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1020 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1021 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1022 Tf is interpreted as the Duration of the measurement interval. 1024 5.3.6. Roles 1026 1028 Src launches each packet to Dst. 1030 Dst waits for each packet from Src. 1032 5.4. Output 1034 This category specifies all details of the Output of measurements 1035 using the metric. 1037 5.4.1. Type 1039 1041 Percentile -- for the conditional distribution of all packets with a 1042 valid value of one-way delay (undefined delays are excluded), a 1043 single value corresponding to the 95th percentile, as follows: 1045 See section 4.1 of [RFC3393] for details on the conditional 1046 distribution to exclude undefined values of delay, and Section 5 of 1047 [RFC6703] for background on this analysis choice. 1049 The percentile = 95, meaning that the reported delay, "95Percentile", 1050 is the smallest value of one-way PDV for which the Empirical 1051 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1052 one-way PDV values in the conditional distribution. See section 11.3 1053 of [RFC2330] for the definition of the percentile statistic using the 1054 EDF. 1056 5.4.2. Reference Definition 1058 1060 T0 the start of a measurement interval, (format "date-and-time" as 1061 specified in Section 5.6 of [RFC3339], see also Section 3 of 1062 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1063 [RFC2330]. 1065 Tf the end of a measurement interval, (format "date-and-time" as 1066 specified in Section 5.6 of [RFC3339], see also Section 3 of 1067 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1068 [RFC2330]. 1070 95Percentile The time value of the result is expressed in units of 1071 seconds, as a positive value of type decimal64 with fraction 1072 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1073 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1074 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1076 5.4.3. Metric Units 1078 . 1081 The 95th Percentile of one-way PDV is expressed in seconds. 1083 5.4.4. Calibration 1085 Section 3.7.3 of [RFC7679] provides a means to quantify the 1086 systematic and random errors of a time measurement. In-situ 1087 calibration could be enabled with an internal loopback that includes 1088 as much of the measurement system as possible, performs address 1089 manipulation as needed, and provides some form of isolation (e.g., 1090 deterministic delay) to avoid send-receive interface contention. 1091 Some portion of the random and systematic error can be characterized 1092 this way. 1094 For one-way delay measurements, the error calibration must include an 1095 assessment of the internal clock synchronization with its external 1096 reference (this internal clock is supplying timestamps for 1097 measurement). In practice, the time offsets of clocks at both the 1098 source and destination are needed to estimate the systematic error 1099 due to imperfect clock synchronization (the time offsets are 1100 smoothed, thus the random variation is not usually represented in the 1101 results). 1103 time_offset The time value of the result is expressed in units of 1104 seconds, as a signed value of type decimal64 with fraction digits 1105 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1106 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1107 NTP timestamp as per section 6 of RFC [RFC5905] 1109 When a measurement controller requests a calibration measurement, the 1110 loopback is applied and the result is output in the same format as a 1111 normal measurement with additional indication that it is a 1112 calibration result. In any measurement, the measurement function 1113 SHOULD report its current estimate of time offset as an indicator of 1114 the degree of synchronization. 1116 Both internal loopback calibration and clock synchronization can be 1117 used to estimate the *available accuracy* of the Output Metric Units. 1118 For example, repeated loopback delay measurements will reveal the 1119 portion of the Output result resolution which is the result of system 1120 noise, and thus inaccurate. 1122 5.5. Administrative items 1124 5.5.1. Status 1126 1128 5.5.2. Requestor (keep?) 1130 1132 5.5.3. Revision 1134 1.0 1136 5.5.4. Revision Date 1138 YYYY-MM-DD 1140 5.6. Comments and Remarks 1142 1144 Lost packets represent a challenge for delay variation metrics. See 1145 section 4.1 of [RFC3393] and the delay variation applicability 1146 statement[RFC5481] for extensive analysis and comparison of PDV and 1147 an alternate metric, IPDV. 1149 6. DNS Response Latency and Loss Registry Entries 1151 This section gives initial registry entries for DNS Response Latency 1152 and Loss. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1153 build on that metric by specifying several of the input parameters to 1154 precisely define two metrics for measuring DNS latency and loss. 1156 Note to IANA: Each Registry "Name" below specifies a single registry 1157 entry, whose output format varies in accordance with the name. 1159 All column entries beside the ID, Name, Description, and Output 1160 Reference Method categories are the same, thus this section proposes 1161 two closely-related registry entries. As a result, IANA is also 1162 asked to assign corresponding URNs and URLs to each Named Metric. 1164 6.1. Summary 1166 This category includes multiple indexes to the registry entries, the 1167 element ID and metric name. 1169 1171 6.1.1. ID (Identifier) 1173 1174 IANA is asked to assign different numeric identifiers to each of the 1175 two Named Metrics. 1177 6.1.2. Name 1179 1181 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1183 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw 1185 6.1.3. URI 1187 URI: Prefix urn:ietf:metrics:perf: 1189 URL: http:/// 1191 6.1.4. Description 1193 RTDNS: This metric assesses the response time, the interval from the 1194 query transmission to the response. 1196 RLDNS: This metric indicates that the respnse was deemed lost. In 1197 other words, the response time exceeded the maximum waiting time. 1199 6.1.5. Change Controller 1201 IETF 1203 6.1.6. Version (of Registry Format) 1205 1.0 1207 6.2. Metric Definition 1209 This category includes columns to prompt the entry of all necessary 1210 details related to the metric definition, including the RFC reference 1211 and values of input factors, called fixed parameters. 1213 6.2.1. Reference Definition 1215 1217 Mockapetris, P., "Domain names - implementation and specification", 1218 STD 13, RFC 1035, November 1987. (and updates) 1220 [RFC1035] 1221 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1222 Metric for IPPM", RFC 2681, September 1999. 1224 [RFC2681] 1226 1228 Section 2.4 of [RFC2681] provides the reference definition of the 1229 singleton (single value) Round-trip delay metric. Section 3.4 of 1230 [RFC2681] provides the reference definition expanded to cover a 1231 multi-singleton sample. Note that terms such as singleton and sample 1232 are defined in Section 11 of [RFC2330]. 1234 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1235 [RFC2681]. The Local Host with its User Program and Resolver take 1236 the role of "Src", and the Foreign Name Server takes the role of 1237 "Dst". 1239 Note that although the [RFC2681] definition of "Round-trip-Delay 1240 between Src and Dst at T" is directionally ambiguous in the text, 1241 this metric tightens the definition further to recognize that the 1242 host in the "Src" role will send the first packet to "Dst", and 1243 ultimately receive the corresponding return packet from "Dst" (when 1244 neither are lost). 1246 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1248 [RFC6673] 1250 Both response time and loss metrics employ a maximum waiting time for 1251 received responses, so the count of lost packets to total packets 1252 sent is the basis for the loss determination as per Section 4.3 of 1253 [RFC6673]. 1255 6.2.2. Fixed Parameters 1257 1261 Type-P as defined in Section 13 of [RFC2330]: 1263 o IPv4 header values: 1265 * DSCP: set to 0 1267 * TTL set to 255 1268 * Protocol: Set to 17 (UDP) 1270 o IPv6 header values: 1272 * DSCP: set to 0 1274 * Hop Count: set to 255 1276 * Protocol: Set to 17 (UDP) 1278 o UDP header values: 1280 * Source port: 53 1282 * Destination port: 53 1284 * Checksum: the checksum must be calculated and included in the 1285 header 1287 o Payload: The payload contains a DNS message as defined in RFC 1035 1288 [RFC1035] with the following values: 1290 * The DNS header section contains: 1292 + Identification (see the Run-time column) 1294 + QR: set to 0 (Query) 1296 + OPCODE: set to 0 (standard query) 1298 + AA: not set 1300 + TC: not set 1302 + RD: set to one (recursion desired) 1304 + RA: not set 1306 + RCODE: not set 1308 + QDCOUNT: set to one (only one entry) 1310 + ANCOUNT: not set 1312 + NSCOUNT: not set 1314 + ARCOUNT: not set 1316 * The Question section contains: 1318 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1319 input for the test, see the Run-time column 1321 + QTYPE: the query type provided as input for the test, see 1322 the Run-time column 1324 + QCLASS: set to 1 for IN 1326 * The other sections do not contain any Resource Records. 1328 Other measurement parameters: 1330 o Tmax: a loss threshold waiting time (and to help disambiguate 1331 queries) 1333 * 5.0, expressed in units of seconds, as a positive value of type 1334 decimal64 with fraction digits = 4 (see section 9.3 of 1335 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1336 lossless conversion to/from the 32-bit NTP timestamp as per 1337 section 6 of [RFC5905]. 1339 Observation: reply packets will contain a DNS response and may 1340 contain RRs. 1342 6.3. Method of Measurement 1344 This category includes columns for references to relevant sections of 1345 the RFC(s) and any supplemental information needed to ensure an 1346 unambiguous methods for implementations. 1348 6.3.1. Reference Method 1350 1353 The methodology for this metric is defined as Type-P-Round-trip- 1354 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1355 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1356 Fixed Parameters. 1358 The reference method distinguishes between long-delayed packets and 1359 lost packets by implementing a maximum waiting time for packet 1360 arrival. Tmax is the waiting time used as the threshold to declare a 1361 packet lost. Lost packets SHALL be designated as having undefined 1362 delay, and counted for the RLDNS metric. 1364 The calculations on the delay (RTT) SHALL be performed on the 1365 conditional distribution, conditioned on successful packet arrival 1366 within Tmax. Also, when all packet delays are stored, the process 1367 which calculates the RTT value MAY enforce the Tmax threshold on 1368 stored values before calculations. See section 4.1 of [RFC3393] for 1369 details on the conditional distribution to exclude undefined values 1370 of delay, and Section 5 of [RFC6703] for background on this analysis 1371 choice. 1373 The reference method requires some way to distinguish between 1374 different packets in a stream to establish correspondence between 1375 sending times and receiving times for each successfully-arriving 1376 reply. Therefore, sequence numbers or other send-order 1377 identification MUST be retained at the Src or included with each 1378 packet to dis-ambiguate packet reordering if it occurs. Sequence 1379 number is part of the payload described under Fixed Parameters. 1381 DNS Messages bearing Queries provide for random ID Numbers in the 1382 Identification header field, so more than one query may be launched 1383 while a previous request is outstanding when the ID Number is used. 1385 IF a DNS response does not arrive within Tmax, the response time is 1386 undefined, and RTDNS = 1. The Message ID SHALL be used to 1387 disambiguate the successive queries. 1389 @@@@ This would require support of ID generation and population in 1390 the Message. An alternative would be to use a random Source port on 1391 the Query Message, but we would choose ONE before proceding. 1393 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1394 instruction to "send a Type-P packet back to the Src as quickly as 1395 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1396 [RFC6673] presents additional requirements which shall be included in 1397 the method of measurement for this metric. 1399 In addition to operations described in [RFC2681], the Src MUST parse 1400 the DNS headers of the reply and prepare the information for 1401 subsequent reporting as a measured result, along with the Round-Trip 1402 Delay. 1404 6.3.2. Packet Stream Generation 1406 This section gives the details of the packet traffic which is the 1407 basis for measurement. In IPPM metrics, this is called the Stream, 1408 and can easily be dscribed by providing the list of stream 1409 parameters. 1411 1412 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1413 generate Poisson sampling intervals. The reciprocal of lambda is the 1414 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1415 = 1/lambda, in seconds. 1417 Method 3 is used, where given a start time (Run-time Parameter), the 1418 subsequent send times are all computed prior to measurement by 1419 computing the pseudo-random distribution of inter-packet send times, 1420 (truncating the distribution as specified in the Run-time 1421 Parameters), and the Src sends each packet at the computed times. 1423 Note that Trunc is the upper limit on inter-packet times in the 1424 Poisson distribution. A random value greater than Trunc is set equal 1425 to Trunc instead. 1427 6.3.3. Traffic Filtering (observation) Details 1429 The measured results based on a filtered version of the packets 1430 observed, and this section provides the filter details (when 1431 present). 1433
. 1435 NA 1437 6.3.4. Sampling Distribution 1439 1442 NA 1444 6.3.5. Run-time Parameters and Data Format 1446 Run-time Parameters are input factors that must be determined, 1447 configured into the measurement system, and reported with the results 1448 for the context to be complete. 1450 1452 Src the IP address of the host in the Src Role (format ipv4-address- 1453 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1454 see Section 4 of [RFC6991]) 1456 Dst the IP address of the host in the Dst Role (format ipv4-address- 1457 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1458 see section 4 of [RFC6991]) 1460 T0 a time, the start of a measurement interval, (format "date-and- 1461 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1462 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1463 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1464 and Tf is to be interpreted as the Duration of the measurement 1465 interval. The start time is controlled through other means. 1467 Tf a time, the end of a measurement interval, (format "date-and-time" 1468 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1469 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1470 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1471 Tf is interpreted as the Duration of the measurement interval. 1473 Reciprocal_lambda average packet interval for Poisson Streams 1474 expressed in units of seconds, as a positive value of type 1475 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1476 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1477 conversion to/from the 32-bit NTP timestamp as per section 6 of 1478 [RFC5905]. 1480 Trunc Upper limit on Poisson distribution expressed in units of 1481 seconds, as a positive value of type decimal64 with fraction 1482 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1483 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1484 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1485 this limit will be clipped and set to the limit value). (if fixed, 1486 Trunc = 30.0000 seconds.) 1488 ID The 16-bit identifier assigned by the program that generates the 1489 query, and which must vary in successive queries, see 1490 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1491 corresponding reply and can be used by the requester (Src) to 1492 match-up replies to outstanding queries. 1494 QNAME The domain name of the Query, formatted as specified in 1495 section 4 of [RFC6991]. 1497 QTYPE The Query Type, which will correspond to the IP address family 1498 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1499 uint16, as per section 9.2 of [RFC6020]. 1501 6.3.6. Roles 1503 1505 Src launches each packet and waits for return transmissions from 1506 Dst. 1508 Dst waits for each packet from Src and sends a return packet to Src. 1510 6.4. Output 1512 This category specifies all details of the Output of measurements 1513 using the metric. 1515 6.4.1. Type 1517 1519 Raw -- for each DNS Query packet sent, sets of values as defined in 1520 the next column, including the status of the response, only assigning 1521 delay values to successful query-response pairs. 1523 6.4.2. Reference Definition 1525 1527 For all outputs: 1529 T the time the DNS Query was sent during the measurement interval, 1530 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1531 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1532 by Section 6.1 of [RFC2330]. 1534 dT The time value of the round-trip delay to receive the DNS 1535 response, expressed in units of seconds, as a positive value of 1536 type decimal64 with fraction digits = 9 (see section 9.3 of 1537 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1538 with lossless conversion to/from the 64-bit NTP timestamp as per 1539 section 6 of RFC [RFC5905]. This value is undefined when the 1540 response packet is not received at Src within waiting time Tmxax 1541 seconds. 1543 Rcode The value of the Rcode field in the DNS response header, 1544 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1545 Non-zero values convey errors in the response, and such replies 1546 must be analyzed separately from successful requests. 1548 6.4.3. Metric Units 1550 . 1553 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1555 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1557 6.4.4. Calibration 1559 Section 3.7.3 of [RFC7679] provides a means to quantify the 1560 systematic and random errors of a time measurement. In-situ 1561 calibration could be enabled with an internal loopback at the Source 1562 host that includes as much of the measurement system as possible, 1563 performs address and payload manipulation as needed, and provides 1564 some form of isolation (e.g., deterministic delay) to avoid send- 1565 receive interface contention. Some portion of the random and 1566 systematic error can be characterized this way. 1568 When a measurement controller requests a calibration measurement, the 1569 loopback is applied and the result is output in the same format as a 1570 normal measurement with additional indication that it is a 1571 calibration result. 1573 Both internal loopback calibration and clock synchronization can be 1574 used to estimate the *available accuracy* of the Output Metric Units. 1575 For example, repeated loopback delay measurements will reveal the 1576 portion of the Output result resolution which is the result of system 1577 noise, and thus inaccurate. 1579 6.5. Administrative items 1581 6.5.1. Status 1583 1585 6.5.2. Requestor 1587 name or RFC, etc. 1589 6.5.3. Revision 1591 1.0 1593 6.5.4. Revision Date 1595 YYYY-MM-DD 1597 6.6. Comments and Remarks 1599 Additional (Informational) details for this entry 1601 7. UDP Poisson One-way Delay and Loss Registry Entries 1603 This section specifies five initial registry entries for the UDP 1604 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1606 IANA Note: Registry "Name" below specifies a single registry entry, 1607 whose output format varies according to the element of 1608 the name that specifies one form of statistical summary. There is an 1609 additional metric name for the Loss metric. 1611 All column entries beside the ID, Name, Description, and Output 1612 Reference Method categories are the same, thus this section proposes 1613 six closely-related registry entries. As a result, IANA is also 1614 asked to assign corresponding URNs and URLs to each Named Metric. 1616 7.1. Summary 1618 This category includes multiple indexes to the registry entries, the 1619 element ID and metric name. 1621 7.1.1. ID (Identifier) 1623 1626 IANA is asked to assign different numeric identifiers to each of the 1627 six Metrics. 1629 7.1.2. Name 1631 1633 OWDelay_Active_IP-UDP-Poisson- 1634 Payload250B_RFCXXXXsecY_Seconds_ 1636 where is one of: 1638 o 95Percentile 1640 o Mean 1642 o Min 1644 o Max 1646 o StdDev 1647 OWLoss_Active_IP-UDP-Poisson- 1648 Payload250B_RFCXXXXsecY_Percent_LossRatio 1650 7.1.3. URI and URL 1652 URI: Prefix urn:ietf:metrics:perf: 1654 URL: http:\\www.iana.org\ ... 1656 7.1.4. Description 1658 OWDelay: This metric assesses the delay of a stream of packets 1659 exchanged between two hosts (or measurement points), and reports the 1660 One-way delay for all successfully exchanged packets 1661 based on their conditional delay distribution. 1663 where is one of: 1665 o 95Percentile 1667 o Mean 1669 o Min 1671 o Max 1673 o StdDev 1675 OWLoss: This metric assesses the loss ratio of a stream of packets 1676 exchanged between two hosts (which are the two measurement points), 1677 and the Output is the One-way loss ratio for all successfully 1678 received packets expressed as a percentage. 1680 7.2. Metric Definition 1682 This category includes columns to prompt the entry of all necessary 1683 details related to the metric definition, including the RFC reference 1684 and values of input factors, called fixed parameters. 1686 7.2.1. Reference Definition 1688 1690 For Delay: 1692 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1693 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1694 7679, DOI 10.17487/RFC7679, January 2016, . 1697 [RFC7679] 1699 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1700 6049, January 2011. 1702 [RFC6049] 1704 1706 Section 3.4 of [RFC7679] provides the reference definition of the 1707 singleton (single value) One-way delay metric. Section 4.4 of 1708 [RFC7679] provides the reference definition expanded to cover a 1709 multi-value sample. Note that terms such as singleton and sample are 1710 defined in Section 11 of [RFC2330]. 1712 Only successful packet transfers with finite delay are included in 1713 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1715 For loss: 1717 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1718 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1719 10.17487/RFC7680, January 2016, . 1722 Section 2.4 of [RFC7680] provides the reference definition of the 1723 singleton (single value) one-way loss metric. Section 3.4 of 1724 [RFC7680] provides the reference definition expanded to cover a 1725 multi-singleton sample. Note that terms such as singleton and sample 1726 are defined in Section 11 of [RFC2330]. 1728 7.2.2. Fixed Parameters 1730 1734 Type-P: 1736 o IPv4 header values: 1738 * DSCP: set to 0 1740 * TTL: set to 255 1741 * Protocol: Set to 17 (UDP) 1743 o IPv6 header values: 1745 * DSCP: set to 0 1747 * Hop Count: set to 255 1749 * Protocol: Set to 17 (UDP) 1751 o UDP header values: 1753 * Checksum: the checksum MUST be calculated and included in the 1754 header 1756 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1758 * Security features in use influence the number of Padding 1759 octets. 1761 * 250 octets total, including the TWAMP format 1763 Other measurement parameters: 1765 Tmax: a loss threshold waiting time with value 3.0, expressed in 1766 units of seconds, as a positive value of type decimal64 with 1767 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1768 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1769 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1771 See the Packet Stream generation category for two additional Fixed 1772 Parameters. 1774 7.3. Method of Measurement 1776 This category includes columns for references to relevant sections of 1777 the RFC(s) and any supplemental information needed to ensure an 1778 unambiguous methods for implementations. 1780 7.3.1. Reference Method 1782 1785 The methodology for this metric is defined as Type-P-One-way-Delay- 1786 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1787 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1789 The reference method distinguishes between long-delayed packets and 1790 lost packets by implementing a maximum waiting time for packet 1791 arrival. Tmax is the waiting time used as the threshold to declare a 1792 packet lost. Lost packets SHALL be designated as having undefined 1793 delay, and counted for the OWLoss metric. 1795 The calculations on the one-way delay SHALL be performed on the 1796 conditional distribution, conditioned on successful packet arrival 1797 within Tmax. Also, when all packet delays are stored, the process 1798 which calculates the one-way delay value MAY enforce the Tmax 1799 threshold on stored values before calculations. See section 4.1 of 1800 [RFC3393] for details on the conditional distribution to exclude 1801 undefined values of delay, and Section 5 of [RFC6703] for background 1802 on this analysis choice. 1804 The reference method requires some way to distinguish between 1805 different packets in a stream to establish correspondence between 1806 sending times and receiving times for each successfully-arriving 1807 packet. Sequence numbers or other send-order identification MUST be 1808 retained at the Src or included with each packet to dis-ambiguate 1809 packet reordering if it occurs. 1811 Since a standard measurement protocol is employed [RFC5357], then the 1812 measurement process will determine the sequence numbers or timestamps 1813 applied to test packets after the Fixed and Runtime parameters are 1814 passed to that process. The measurement protocol dictates the format 1815 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1816 payload. 1818 7.3.2. Packet Stream Generation 1820 This section gives the details of the packet traffic which is the 1821 basis for measurement. In IPPM metrics, this is called the Stream, 1822 and can easily be dscribed by providing the list of stream 1823 parameters. 1825 1827 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1828 generate Poisson sampling intervals. the reciprocal of lambda is the 1829 average packet spacing, thus the Run-time Parameter is 1830 Reciprocal_lambda = 1/lambda, in seconds. 1832 Method 3 SHALL be used, where given a start time (Run-time 1833 Parameter), the subsequent send times are all computed prior to 1834 measurement by computing the pseudo-random distribution of inter- 1835 packet send times, (truncating the distribution as specified in the 1836 Parameter Trunc), and the Src sends each packet at the computed 1837 times. 1839 Note that Trunc is the upper limit on inter-packet times in the 1840 Poisson distribution. A random value greater than Trunc is set equal 1841 to Trunc instead. 1843 Reciprocal_lambda average packet interval for Poisson Streams 1844 expressed in units of seconds, as a positive value of type 1845 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1846 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1847 conversion to/from the 32-bit NTP timestamp as per section 6 of 1848 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1850 Trunc Upper limit on Poisson distribution expressed in units of 1851 seconds, as a positive value of type decimal64 with fraction 1852 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1853 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1854 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1855 this limit will be clipped and set to the limit value). Trunc = 1856 30.0000 seconds. 1858 7.3.3. Traffic Filtering (observation) Details 1860 NA 1862 7.3.4. Sampling Distribution 1864 NA 1866 7.3.5. Run-time Parameters and Data Format 1868 Run-time Parameters are input factors that must be determined, 1869 configured into the measurement system, and reported with the results 1870 for the context to be complete. 1872 1874 Src the IP address of the host in the Src Role (format ipv4-address- 1875 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1876 see Section 4 of [RFC6991]) 1878 Dst the IP address of the host in the Dst Role (format ipv4-address- 1879 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1880 see section 4 of [RFC6991]) 1882 T0 a time, the start of a measurement interval, (format "date-and- 1883 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1884 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1885 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1886 and Tf is to be interpreted as the Duration of the measurement 1887 interval. The start time is controlled through other means. 1889 Tf a time, the end of a measurement interval, (format "date-and-time" 1890 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1891 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1892 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1893 Tf is interpreted as the Duration of the measurement interval. 1895 7.3.6. Roles 1897 1899 Src launches each packet and waits for return transmissions from 1900 Dst. This is the TWAMP Session-Sender. 1902 Dst waits for each packet from Src and sends a return packet to Src. 1903 This is the TWAMP Session-Reflector. 1905 7.4. Output 1907 This category specifies all details of the Output of measurements 1908 using the metric. 1910 7.4.1. Type 1912 1914 See subsection titles below for Types. 1916 7.4.2. Reference Definition 1918 1920 For all output types --- 1922 T0 the start of a measurement interval, (format "date-and-time" as 1923 specified in Section 5.6 of [RFC3339], see also Section 3 of 1924 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1925 [RFC2330]. 1927 Tf the end of a measurement interval, (format "date-and-time" as 1928 specified in Section 5.6 of [RFC3339], see also Section 3 of 1929 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1930 [RFC2330]. 1932 For LossRatio -- the count of lost packets to total packets sent is 1933 the basis for the loss ratio calculation as per Section 4.1 of 1934 [RFC7680]. 1936 For each , one of the following sub-sections apply: 1938 7.4.2.1. Percentile95 1940 The 95th percentile SHALL be calculated using the conditional 1941 distribution of all packets with a finite value of One-way delay 1942 (undefined delays are excluded), a single value as follows: 1944 See section 4.1 of [RFC3393] for details on the conditional 1945 distribution to exclude undefined values of delay, and Section 5 of 1946 [RFC6703] for background on this analysis choice. 1948 See section 4.3 of [RFC3393] for details on the percentile statistic 1949 (where Round-trip delay should be substituted for "ipdv"). 1951 The percentile = 95, meaning that the reported delay, "95Percentile", 1952 is the smallest value of one-way delay for which the Empirical 1953 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1954 one-way delay values in the conditional distribution. See section 1955 11.3 of [RFC2330] for the definition of the percentile statistic 1956 using the EDF. 1958 95Percentile The time value of the result is expressed in units of 1959 seconds, as a positive value of type decimal64 with fraction 1960 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1961 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1962 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1964 7.4.2.2. Mean 1966 The mean SHALL be calculated using the conditional distribution of 1967 all packets with a finite value of One-way delay (undefined delays 1968 are excluded), a single value as follows: 1970 See section 4.1 of [RFC3393] for details on the conditional 1971 distribution to exclude undefined values of delay, and Section 5 of 1972 [RFC6703] for background on this analysis choice. 1974 See section 4.2.2 of [RFC6049] for details on calculating this 1975 statistic, and 4.2.3 of [RFC6049]. 1977 Mean The time value of the result is expressed in units of seconds, 1978 as a positive value of type decimal64 with fraction digits = 9 1979 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1980 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1981 NTP timestamp as per section 6 of RFC [RFC5905] 1983 7.4.2.3. Min 1985 The minimum SHALL be calculated using the conditional distribution of 1986 all packets with a finite value of One-way delay (undefined delays 1987 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.2 of [RFC6049] for details on calculating this 1994 statistic, and 4.3.3 of [RFC6049]. 1996 Min The time value of the result is expressed in units of seconds, 1997 as a positive value of type decimal64 with fraction digits = 9 1998 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1999 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2000 NTP timestamp as per section 6 of RFC [RFC5905] 2002 7.4.2.4. Max 2004 The maximum SHALL be calculated using the conditional distribution of 2005 all packets with a finite value of One-way delay (undefined delays 2006 are excluded), a single value as follows: 2008 See section 4.1 of [RFC3393] for details on the conditional 2009 distribution to exclude undefined values of delay, and Section 5 of 2010 [RFC6703] for background on this analysis choice. 2012 See section 4.3.2 of [RFC6049] for a closely related method for 2013 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2014 as follows: 2016 Max = (FiniteDelay [j]) 2018 such that for some index, j, where 1 <= j <= N 2019 FiniteDelay[j] >= FiniteDelay[n] for all n 2021 Max The time value of the result is expressed in units of seconds, 2022 as a positive value of type decimal64 with fraction digits = 9 2023 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2024 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2025 NTP timestamp as per section 6 of RFC [RFC5905] 2027 7.4.2.5. Std_Dev 2029 The Std_Dev SHALL be calculated using the conditional distribution of 2030 all packets with a finite value of One-way delay (undefined delays 2031 are excluded), a single value as follows: 2033 See section 4.1 of [RFC3393] for details on the conditional 2034 distribution to exclude undefined values of delay, and Section 5 of 2035 [RFC6703] for background on this analysis choice. 2037 See section 4.3.2 of [RFC6049] for a closely related method for 2038 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2039 the classic calculation for standard deviation of a population. 2041 Std_Dev The time value of the result is expressed in units of 2042 seconds, as a positive value of type decimal64 with fraction 2043 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2044 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2045 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2047 7.4.3. Metric Units 2049 . 2052 The of One-way Delay is expressed in seconds. 2054 The One-way Loss Ratio is expressed as a percentage of lost packets 2055 to total packets sent. 2057 7.4.4. Calibration 2059 Section 3.7.3 of [RFC7679] provides a means to quantify the 2060 systematic and random errors of a time measurement. In-situ 2061 calibration could be enabled with an internal loopback that includes 2062 as much of the measurement system as possible, performs address 2063 manipulation as needed, and provides some form of isolation (e.g., 2064 deterministic delay) to avoid send-receive interface contention. 2065 Some portion of the random and systematic error can be characterized 2066 this way. 2068 For one-way delay measurements, the error calibration must include an 2069 assessment of the internal clock synchronization with its external 2070 reference (this internal clock is supplying timestamps for 2071 measurement). In practice, the time offsets of clocks at both the 2072 source and destination are needed to estimate the systematic error 2073 due to imperfect clock synchronization (the time offsets are 2074 smoothed, thus the random variation is not usually represented in the 2075 results). 2077 time_offset The time value of the result is expressed in units of 2078 seconds, as a signed value of type decimal64 with fraction digits 2079 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2080 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2081 NTP timestamp as per section 6 of RFC [RFC5905] 2083 When a measurement controller requests a calibration measurement, the 2084 loopback is applied and the result is output in the same format as a 2085 normal measurement with additional indication that it is a 2086 calibration result. In any measurement, the measurement function 2087 SHOULD report its current estimate of time offset as an indicator of 2088 the degree of synchronization. 2090 Both internal loopback calibration and clock synchronization can be 2091 used to estimate the *available accuracy* of the Output Metric Units. 2092 For example, repeated loopback delay measurements will reveal the 2093 portion of the Output result resolution which is the result of system 2094 noise, and thus inaccurate. 2096 7.5. Administrative items 2098 7.5.1. Status 2100 2102 7.5.2. Requestor (keep?) 2104 name or RFC, etc. 2106 7.5.3. Revision 2108 1.0 2110 7.5.4. Revision Date 2112 YYYY-MM-DD 2114 7.6. Comments and Remarks 2116 Additional (Informational) details for this entry 2118 8. UDP Periodic One-way Delay and Loss Registry Entries 2120 This section specifies five initial registry entries for the UDP 2121 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 2123 IANA Note: Registry "Name" below specifies a single registry entry, 2124 whose output format varies according to the element of 2125 the name that specifies one form of statistical summary. There is an 2126 additional metric name for the Loss metric. 2128 All column entries beside the ID, Name, Description, and Output 2129 Reference Method categories are the same, thus this section proposes 2130 six closely-related registry entries. As a result, IANA is also 2131 asked to assign corresponding URNs and URLs to each Named Metric. 2133 8.1. Summary 2135 This category includes multiple indexes to the registry entries, the 2136 element ID and metric name. 2138 8.1.1. ID (Identifier) 2140 2143 IANA is asked to assign a different numeric identifiers to each of 2144 the six Metrics. 2146 8.1.2. Name 2148 2150 OWDelay_Active_IP-UDP-Periodic- 2151 Payload142B_RFCXXXXsecY_Seconds_ 2153 where is one of: 2155 o 95Percentile 2157 o Mean 2159 o Min 2161 o Max 2163 o StdDev 2164 OWLoss_Active_IP-UDP-Periodic- 2165 Payload142B_RFCXXXXsecY_Percent_LossRatio 2167 8.1.3. URIs 2169 URI: Prefix urn:ietf:metrics:perf: 2171 URL: http:\\www.iana.org\ ... 2173 8.1.4. Description 2175 OWDelay: This metric assesses the delay of a stream of packets 2176 exchanged between two hosts (or measurement points), and reports the 2177 One-way delay for all successfully exchanged packets 2178 based on their conditional delay distribution. 2180 where is one of: 2182 o 95Percentile 2184 o Mean 2186 o Min 2188 o Max 2190 o StdDev 2192 OWLoss: This metric assesses the loss ratio of a stream of packets 2193 exchanged between two hosts (which are the two measurement points), 2194 and the Output is the One-way loss ratio for all successfully 2195 received packets expressed as a percentage. 2197 8.2. Metric Definition 2199 This category includes columns to prompt the entry of all necessary 2200 details related to the metric definition, including the RFC reference 2201 and values of input factors, called fixed parameters. 2203 8.2.1. Reference Definition 2205 2207 For Delay: 2209 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2210 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2211 7679, DOI 10.17487/RFC7679, January 2016, . 2214 [RFC7679] 2216 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2217 6049, January 2011. 2219 [RFC6049] 2221 2223 Section 3.4 of [RFC7679] provides the reference definition of the 2224 singleton (single value) One-way delay metric. Section 4.4 of 2225 [RFC7679] provides the reference definition expanded to cover a 2226 multi-value sample. Note that terms such as singleton and sample are 2227 defined in Section 11 of [RFC2330]. 2229 Only successful packet transfers with finite delay are included in 2230 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2232 For loss: 2234 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2235 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2236 10.17487/RFC7680, January 2016, . 2239 Section 2.4 of [RFC7680] provides the reference definition of the 2240 singleton (single value) one-way loss metric. Section 3.4 of 2241 [RFC7680] provides the reference definition expanded to cover a 2242 multi-singleton sample. Note that terms such as singleton and sample 2243 are defined in Section 11 of [RFC2330]. 2245 8.2.2. Fixed Parameters 2247 2251 Type-P: 2253 o IPv4 header values: 2255 * DSCP: set to 0 2257 * TTL: set to 255 2258 * Protocol: Set to 17 (UDP) 2260 o IPv6 header values: 2262 * DSCP: set to 0 2264 * Hop Count: set to 255 2266 * Protocol: Set to 17 (UDP) 2268 o UDP header values: 2270 * Checksum: the checksum MUST be calculated and included in the 2271 header 2273 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2275 * Security features in use influence the number of Padding 2276 octets. 2278 * 142 octets total, including the TWAMP format 2280 Other measurement parameters: 2282 Tmax: a loss threshold waiting time with value 3.0, expressed in 2283 units of seconds, as a positive value of type decimal64 with 2284 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2285 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2286 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2288 See the Packet Stream generation category for two additional Fixed 2289 Parameters. 2291 8.3. Method of Measurement 2293 This category includes columns for references to relevant sections of 2294 the RFC(s) and any supplemental information needed to ensure an 2295 unambiguous methods for implementations. 2297 8.3.1. Reference Method 2299 2302 The methodology for this metric is defined as Type-P-One-way-Delay- 2303 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2304 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2306 The reference method distinguishes between long-delayed packets and 2307 lost packets by implementing a maximum waiting time for packet 2308 arrival. Tmax is the waiting time used as the threshold to declare a 2309 packet lost. Lost packets SHALL be designated as having undefined 2310 delay, and counted for the OWLoss metric. 2312 The calculations on the one-way delay SHALL be performed on the 2313 conditional distribution, conditioned on successful packet arrival 2314 within Tmax. Also, when all packet delays are stored, the process 2315 which calculates the one-way delay value MAY enforce the Tmax 2316 threshold on stored values before calculations. See section 4.1 of 2317 [RFC3393] for details on the conditional distribution to exclude 2318 undefined values of delay, and Section 5 of [RFC6703] for background 2319 on this analysis choice. 2321 The reference method requires some way to distinguish between 2322 different packets in a stream to establish correspondence between 2323 sending times and receiving times for each successfully-arriving 2324 packet. Sequence numbers or other send-order identification MUST be 2325 retained at the Src or included with each packet to dis-ambiguate 2326 packet reordering if it occurs. 2328 Since a standard measurement protocol is employed [RFC5357], then the 2329 measurement process will determine the sequence numbers or timestamps 2330 applied to test packets after the Fixed and Runtime parameters are 2331 passed to that process. The measurement protocol dictates the format 2332 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2333 payload. 2335 8.3.2. Packet Stream Generation 2337 2339 This section gives the details of the packet traffic which is the 2340 basis for measurement. In IPPM metrics, this is called the Stream, 2341 and can easily be described by providing the list of stream 2342 parameters. 2344 Section 3 of [RFC3432] prescribes the method for generating Periodic 2345 streams using associated parameters. 2347 incT the nominal duration of inter-packet interval, first bit to 2348 first bit 2350 dT the duration of the interval for allowed sample start times 2352 T0 the actual start time of the periodic stream 2353 NOTE: an initiation process with a number of control exchanges 2354 resulting in unpredictable start times (within a time interval) may 2355 be sufficient to avoid synchronization of periodic streams, and 2356 therefore a valid replacement for selecting a start time at random 2357 from a fixed interval. 2359 These stream parameters will be specified as Run-time parameters. 2361 8.3.3. Traffic Filtering (observation) Details 2363 NA 2365 8.3.4. Sampling Distribution 2367 NA 2369 8.3.5. Run-time Parameters and Data Format 2371 Run-time Parameters are input factors that must be determined, 2372 configured into the measurement system, and reported with the results 2373 for the context to be complete. 2375 2377 Src the IP address of the host in the Src Role (format ipv4-address- 2378 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2379 see Section 4 of [RFC6991]) 2381 Dst the IP address of the host in the Dst Role (format ipv4-address- 2382 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2383 see section 4 of [RFC6991]) 2385 T0 a time, the start of a measurement interval, (format "date-and- 2386 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2387 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2388 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2389 and Tf is to be interpreted as the Duration of the measurement 2390 interval. The start time is controlled through other means. 2392 Tf a time, the end of a measurement interval, (format "date-and-time" 2393 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2394 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2395 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2396 Tf is interpreted as the Duration of the measurement interval. 2398 >>> should Periodic run-time params be fixed instead? probably yes if 2399 modeling a specific version of tests. Note in the NAME, i.e. 2400 Poisson3.3 2402 8.3.6. Roles 2404 2406 Src launches each packet and waits for return transmissions from 2407 Dst. This is the TWAMP Session-Sender. 2409 Dst waits for each packet from Src and sends a return packet to Src. 2410 This is the TWAMP Session-Reflector. 2412 8.4. Output 2414 This category specifies all details of the Output of measurements 2415 using the metric. 2417 8.4.1. Type 2419 2421 See subsection titles in Data Format for Types. 2423 8.4.2. Reference Definition 2425 2427 For all output types --- 2429 T0 the start of a measurement interval, (format "date-and-time" as 2430 specified in Section 5.6 of [RFC3339], see also Section 3 of 2431 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2432 [RFC2330]. 2434 Tf the end of a measurement interval, (format "date-and-time" as 2435 specified in Section 5.6 of [RFC3339], see also Section 3 of 2436 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2437 [RFC2330]. 2439 For LossRatio -- the count of lost packets to total packets sent is 2440 the basis for the loss ratio calculation as per Section 4.1 of 2441 [RFC7680]. 2443 For each , one of the following sub-sections apply: 2445 8.4.2.1. Percentile95 2447 The 95th percentile SHALL be calculated using the conditional 2448 distribution of all packets with a finite value of One-way delay 2449 (undefined delays are excluded), a single value as follows: 2451 See section 4.1 of [RFC3393] for details on the conditional 2452 distribution to exclude undefined values of delay, and Section 5 of 2453 [RFC6703] for background on this analysis choice. 2455 See section 4.3 of [RFC3393] for details on the percentile statistic 2456 (where Round-trip delay should be substituted for "ipdv"). 2458 The percentile = 95, meaning that the reported delay, "95Percentile", 2459 is the smallest value of one-way delay for which the Empirical 2460 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2461 one-way delay values in the conditional distribution. See section 2462 11.3 of [RFC2330] for the definition of the percentile statistic 2463 using the EDF. 2465 95Percentile The time value of the result is expressed in units of 2466 seconds, as a positive value of type decimal64 with fraction 2467 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2468 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2469 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2471 8.4.2.2. Mean 2473 The mean SHALL be calculated using the conditional distribution of 2474 all packets with a finite value of One-way delay (undefined delays 2475 are excluded), a single value as follows: 2477 See section 4.1 of [RFC3393] for details on the conditional 2478 distribution to exclude undefined values of delay, and Section 5 of 2479 [RFC6703] for background on this analysis choice. 2481 See section 4.2.2 of [RFC6049] for details on calculating this 2482 statistic, and 4.2.3 of [RFC6049]. 2484 Mean The time value of the result is expressed in units of seconds, 2485 as a positive value of type decimal64 with fraction digits = 9 2486 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2487 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2488 NTP timestamp as per section 6 of RFC [RFC5905] 2490 8.4.2.3. Min 2492 The minimum SHALL be calculated using the conditional distribution of 2493 all packets with a finite value of One-way delay (undefined delays 2494 are excluded), a single value as follows: 2496 See section 4.1 of [RFC3393] for details on the conditional 2497 distribution to exclude undefined values of delay, and Section 5 of 2498 [RFC6703] for background on this analysis choice. 2500 See section 4.3.2 of [RFC6049] for details on calculating this 2501 statistic, and 4.3.3 of [RFC6049]. 2503 Min The time value of the result is expressed in units of seconds, 2504 as a positive value of type decimal64 with fraction digits = 9 2505 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2506 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2507 NTP timestamp as per section 6 of RFC [RFC5905] 2509 8.4.2.4. Max 2511 The maximum SHALL be calculated using the conditional distribution of 2512 all packets with a finite value of One-way delay (undefined delays 2513 are excluded), a single value as follows: 2515 See section 4.1 of [RFC3393] for details on the conditional 2516 distribution to exclude undefined values of delay, and Section 5 of 2517 [RFC6703] for background on this analysis choice. 2519 See section 4.3.2 of [RFC6049] for a closely related method for 2520 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2521 as follows: 2523 Max = (FiniteDelay [j]) 2525 such that for some index, j, where 1 <= j <= N 2526 FiniteDelay[j] >= FiniteDelay[n] for all n 2528 Max The time value of the result is expressed in units of seconds, 2529 as a positive value of type decimal64 with fraction digits = 9 2530 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2531 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2532 NTP timestamp as per section 6 of RFC [RFC5905] 2534 8.4.2.5. Std_Dev 2536 The Std_Dev SHALL be calculated using the conditional distribution of 2537 all packets with a finite value of One-way delay (undefined delays 2538 are excluded), a single value as follows: 2540 See section 4.1 of [RFC3393] for details on the conditional 2541 distribution to exclude undefined values of delay, and Section 5 of 2542 [RFC6703] for background on this analysis choice. 2544 See section 4.3.2 of [RFC6049] for a closely related method for 2545 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2546 the classic calculation for standard deviation of a population. 2548 Std_Dev The time value of the result is expressed in units of 2549 seconds, as a positive value of type decimal64 with fraction 2550 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2551 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2552 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2554 8.4.3. Metric Units 2556 . 2559 The of One-way Delay is expressed in seconds. 2561 The One-way Loss Ratio is expressed as a percentage of lost packets 2562 to total packets sent. 2564 8.4.4. Calibration 2566 Section 3.7.3 of [RFC7679] provides a means to quantify the 2567 systematic and random errors of a time measurement. In-situ 2568 calibration could be enabled with an internal loopback that includes 2569 as much of the measurement system as possible, performs address 2570 manipulation as needed, and provides some form of isolation (e.g., 2571 deterministic delay) to avoid send-receive interface contention. 2572 Some portion of the random and systematic error can be characterized 2573 this way. 2575 For one-way delay measurements, the error calibration must include an 2576 assessment of the internal clock synchronization with its external 2577 reference (this internal clock is supplying timestamps for 2578 measurement). In practice, the time offsets of clocks at both the 2579 source and destination are needed to estimate the systematic error 2580 due to imperfect clock synchronization (the time offsets are 2581 smoothed, thus the random variation is not usually represented in the 2582 results). 2584 time_offset The time value of the result is expressed in units of 2585 seconds, as a signed value of type decimal64 with fraction digits 2586 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2587 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2588 NTP timestamp as per section 6 of RFC [RFC5905] 2590 When a measurement controller requests a calibration measurement, the 2591 loopback is applied and the result is output in the same format as a 2592 normal measurement with additional indication that it is a 2593 calibration result. In any measurement, the measurement function 2594 SHOULD report its current estimate of time offset as an indicator of 2595 the degree of synchronization. 2597 Both internal loopback calibration and clock synchronization can be 2598 used to estimate the *available accuracy* of the Output Metric Units. 2599 For example, repeated loopback delay measurements will reveal the 2600 portion of the Output result resolution which is the result of system 2601 noise, and thus inaccurate. 2603 8.5. Administrative items 2605 8.5.1. Status 2607 2609 8.5.2. Requestor (keep?) 2611 name or RFC, etc. 2613 8.5.3. Revision 2615 1.0 2617 8.5.4. Revision Date 2619 YYYY-MM-DD 2621 8.6. Comments and Remarks 2623 Additional (Informational) details for this entry 2625 9. ver08 BLANK Registry Entry 2627 This section gives an initial registry entry for .... 2629 9.1. Summary 2631 This category includes multiple indexes to the registry entries, the 2632 element ID and metric name. 2634 9.1.1. ID (Identifier) 2636 2638 9.1.2. Name 2640 2642 9.1.3. URIs 2644 URI: Prefix urn:ietf:metrics:perf: 2646 URL: 2648 9.1.4. Description 2650 TBD. 2652 9.1.5. Reference 2654 2656 9.1.6. Change Controller 2658 2660 9.1.7. Version (of Registry Format) 2662 2664 9.2. Metric Definition 2666 This category includes columns to prompt the entry of all necessary 2667 details related to the metric definition, including the RFC reference 2668 and values of input factors, called fixed parameters. 2670 9.2.1. Reference Definition 2672 2674 2676 9.2.2. Fixed Parameters 2678 2682 9.3. Method of Measurement 2684 This category includes columns for references to relevant sections of 2685 the RFC(s) and any supplemental information needed to ensure an 2686 unambiguous methods for implementations. 2688 9.3.1. Reference Method 2690 2693 9.3.2. Packet Stream Generation 2695 2697 9.3.3. Traffic Filtering (observation) Details 2699 . 2703 9.3.4. Sampling Distribution 2705 2708 9.3.5. Run-time Parameters and Data Format 2710 . 2712 9.3.6. Roles 2714 2716 9.4. Output 2718 This category specifies all details of the Output of measurements 2719 using the metric. 2721 9.4.1. Type 2723 2725 9.4.2. Reference Definition 2727 2729 9.4.3. Metric Units 2731 . 2734 9.4.4. Calibration 2736 2740 9.5. Administrative items 2742 9.5.1. Status 2744 2746 9.5.2. Requestor 2748 2750 9.5.3. Revision 2752 1.0 2754 9.5.4. Revision Date 2756 YYYY-MM-DD 2758 9.6. Comments and Remarks 2760 Additional (Informational) details for this entry 2762 10. Example RTCP-XR Registry Entry 2764 This section is MAY BE DELETED or adapted before submission. 2766 This section gives an example registry entry for the end-point metric 2767 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 2768 reporting. 2770 10.1. Registry Indexes 2772 This category includes multiple indexes to the registry entries, the 2773 element ID and metric name. 2775 10.1.1. Identifier 2777 An integer having enough digits to uniquely identify each entry in 2778 the Registry. 2780 10.1.2. Name 2782 A metric naming convention is TBD. 2784 10.1.3. URI 2786 Prefix urn:ietf:metrics:param: 2788 10.1.4. Status 2790 current 2792 10.1.5. Requestor 2794 Alcelip Mornuley 2796 10.1.6. Revision 2798 1.0 2800 10.1.7. Revision Date 2802 2014-07-04 2804 10.1.8. Description 2806 TBD. 2808 10.1.9. Reference Specification(s) 2810 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 2812 10.2. Metric Definition 2814 This category includes columns to prompt the entry of all necessary 2815 details related to the metric definition, including the RFC reference 2816 and values of input factors, called fixed parameters. Section 3.2 of 2817 [RFC7003] provides the reference information for this category. 2819 10.2.1. Reference Definition 2821 Packets Discarded in Bursts: 2823 The total number of packets discarded during discard bursts. The 2824 measured value is unsigned value. If the measured value exceeds 2825 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 2826 range measurement. If the measurement is unavailable, the value 2827 0xFFFFFF MUST be reported. 2829 10.2.2. Fixed Parameters 2831 Fixed Parameters are input factors that must be determined and 2832 embedded in the measurement system for use when needed. The values 2833 of these parameters is specified in the Registry. 2835 Threshold: 8 bits, set to value = 3 packets. 2837 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 2838 successive packets that must not be discarded prior to and following 2839 a discard packet in order for this discarded packet to be regarded as 2840 part of a gap. Note that the Threshold is set in accordance with the 2841 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 2843 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 2845 This field is used to indicate whether the burst/gap discard metrics 2846 are Sampled, Interval, or Cumulative metrics [RFC6792]: 2848 I=10: Interval Duration - the reported value applies to the most 2849 recent measurement interval duration between successive metrics 2850 reports. 2852 I=11: Cumulative Duration - the reported value applies to the 2853 accumulation period characteristic of cumulative measurements. 2855 Senders MUST NOT use the values I=00 or I=01. 2857 10.3. Method of Measurement 2859 This category includes columns for references to relevant sections of 2860 the RFC(s) and any supplemental information needed to ensure an 2861 unambiguous methods for implementations. For the Burst/Gap Discard 2862 Metric, it appears that the only guidance on methods of measurement 2863 is in Section 3.0 of [RFC7003] and its supporting references. 2864 Relevant information is repeated below, although there appears to be 2865 no section titled "Method of Measurement" in [RFC7003]. 2867 10.3.1. Reference Method 2869 Metrics in this block report on burst/gap discard in the stream 2870 arriving at the RTP system. Measurements of these metrics are made 2871 at the receiving end of the RTP stream. Instances of this metrics 2872 block use the synchronization source (SSRC) to refer to the separate 2873 auxiliary Measurement Information Block [RFC6776], which describes 2874 measurement periods in use (see [RFC6776], Section 4.2). 2876 This metrics block relies on the measurement period in the 2877 Measurement Information Block indicating the span of the report. 2878 Senders MUST send this block in the same compound RTCP packet as the 2879 Measurement Information Block. Receivers MUST verify that the 2880 measurement period is received in the same compound RTCP packet as 2881 this metrics block. If not, this metrics block MUST be discarded. 2883 10.3.2. Stream Type and Stream Parameters 2885 Since RTCP-XR Measurements are conducted on live RTP traffic, the 2886 complete description of the stream is contained in SDP messages that 2887 proceed the establishment of a compatible stream between two or more 2888 communicating hosts. See Run-time Parameters, below. 2890 10.3.3. Output Type and Data Format 2892 The output type defines the type of result that the metric produces. 2894 o Value: Packets Discarded in Bursts 2896 o Data Format: 24 bits 2898 o Reference: Section 3.2 of [RFC7003] 2900 10.3.4. Metric Units 2902 The measured results are apparently expressed in packets, although 2903 there is no section of [RFC7003] titled "Metric Units". 2905 10.3.5. Run-time Parameters and Data Format 2907 Run-Time Parameters are input factors that must be determined, 2908 configured into the measurement system, and reported with the results 2909 for the context to be complete. However, the values of these 2910 parameters is not specified in the Registry, rather these parameters 2911 are listed as an aid to the measurement system implementor or user 2912 (they must be left as variables, and supplied on execution). 2914 The Data Format of each Run-time Parameter SHALL be specified in this 2915 column, to simplify the control and implementation of measurement 2916 devices. 2918 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 2920 SDP Parameters: As defined in [RFC4566] 2922 Session description v= (protocol version number, currently only 0) 2923 o= (originator and session identifier : username, id, version number, 2924 network address) 2926 s= (session name : mandatory with at least one UTF-8-encoded 2927 character) 2929 i=* (session title or short information) u=* (URI of description) 2931 e=* (zero or more email address with optional name of contacts) 2933 p=* (zero or more phone number with optional name of contacts) 2935 c=* (connection information--not required if included in all media) 2937 b=* (zero or more bandwidth information lines) One or more Time 2938 descriptions ("t=" and "r=" lines; see below) 2940 z=* (time zone adjustments) 2942 k=* (encryption key) 2944 a=* (zero or more session attribute lines) 2946 Zero or more Media descriptions (each one starting by an "m=" line; 2947 see below) 2949 m= (media name and transport address) 2951 i=* (media title or information field) 2953 c=* (connection information -- optional if included at session level) 2955 b=* (zero or more bandwidth information lines) 2957 k=* (encryption key) 2959 a=* (zero or more media attribute lines -- overriding the Session 2960 attribute lines) 2962 An example Run-time SDP description follows: 2964 v=0 2966 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 2968 s=SDP Seminar i=A Seminar on the session description protocol 2969 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 2970 Doe) 2972 c=IN IP4 233.252.0.12/127 2974 t=2873397496 2873404696 2976 a=recvonly 2978 m=audio 49170 RTP/AVP 0 2980 m=video 51372 RTP/AVP 99 2982 a=rtpmap:99 h263-1998/90000 2984 10.4. Comments and Remarks 2986 TBD. 2988 11. Revision History 2990 This section may be removed for publication. It contains partial 2991 information on updtes. 2993 This draft replaced draft-mornuley-ippm-initial-registry. 2995 In version 02, Section 4 has been edited to reflect recent discussion 2996 on the ippm-list: * Removed the combination or "Raw" and left 95th 2997 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 2998 use bullet lists and other indenting formats. * Payload format for 2999 measurement has been removed. * Explanation of Conditional delay 3000 distribution. 3002 Version 03 addressed Phil Eardley's comments and suggestions in 3003 sections 1-4. and resolved the definition of Percentiles. 3005 Version 04 * All section 4 parameters reference YANG types for 3006 alternate data formats. * Discussion has concluded that usecase(s) 3007 for machine parse-able registry columns are not needed. 3009 12. Security Considerations 3011 These registry entries represent no known security implications for 3012 Internet Security. Each referenced Metric contains a Security 3013 Considerations section. 3015 13. IANA Considerations 3017 IANA is requested to populate The Performance Metric Registry defined 3018 in [I-D.ietf-ippm-metric-registry] with the values defined above. 3020 See the IANA Considerations section of 3021 [I-D.ietf-ippm-metric-registry] for additional requests and 3022 considerations. 3024 14. Acknowledgements 3026 The authors thank Brian Trammell for suggesting the term "Run-time 3027 Parameters", which led to the distinction between run-time and fixed 3028 parameters implemented in this memo, for identifying the IPFIX metric 3029 with Flow Key as an example, and for many other productive 3030 suggestions. Thanks to Peter Koch, who provided several useful 3031 suggestions for disambiguating successive DNS Queries in the DNS 3032 Response time metric. 3034 The authors also acknowledge the constructive reviews and helpful 3035 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 3036 participants in the LMAP working group. Thanks to Michelle Cotton 3037 for her early IANA review, and to Amanda Barber for answering 3038 questions related to the presentation of the registry and 3039 accessibility of the complete template via URL. 3041 15. References 3043 15.1. Normative References 3045 [I-D.ietf-ippm-metric-registry] 3046 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 3047 "Registry for Performance Metrics", Internet Draft (work 3048 in progress) draft-ietf-ippm-metric-registry, 2014. 3050 [RFC1035] Mockapetris, P., "Domain names - implementation and 3051 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3052 November 1987, . 3054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3055 Requirement Levels", BCP 14, RFC 2119, 3056 DOI 10.17487/RFC2119, March 1997, 3057 . 3059 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 3060 "Framework for IP Performance Metrics", RFC 2330, 3061 DOI 10.17487/RFC2330, May 1998, 3062 . 3064 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 3065 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 3066 September 1999, . 3068 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 3069 Packet Loss Metric for IPPM", RFC 2680, 3070 DOI 10.17487/RFC2680, September 1999, 3071 . 3073 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 3074 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 3075 September 1999, . 3077 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3078 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3079 . 3081 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 3082 Metric for IP Performance Metrics (IPPM)", RFC 3393, 3083 DOI 10.17487/RFC3393, November 2002, 3084 . 3086 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 3087 performance measurement with periodic streams", RFC 3432, 3088 DOI 10.17487/RFC3432, November 2002, 3089 . 3091 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 3092 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 3093 DOI 10.17487/RFC4737, November 2006, 3094 . 3096 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3097 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 3098 RFC 5357, DOI 10.17487/RFC5357, October 2008, 3099 . 3101 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 3102 "Network Time Protocol Version 4: Protocol and Algorithms 3103 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 3104 . 3106 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3107 the Network Configuration Protocol (NETCONF)", RFC 6020, 3108 DOI 10.17487/RFC6020, October 2010, 3109 . 3111 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 3112 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 3113 . 3115 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 3116 DOI 10.17487/RFC6673, August 2012, 3117 . 3119 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3120 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3121 . 3123 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3124 Ed., "A One-Way Delay Metric for IP Performance Metrics 3125 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 3126 2016, . 3128 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3129 Ed., "A One-Way Loss Metric for IP Performance Metrics 3130 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 3131 2016, . 3133 15.2. Informative References 3135 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 3136 Distributions", March 2000. 3138 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 3139 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 3140 July 1991, . 3142 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 3143 "RTP Control Protocol Extended Reports (RTCP XR)", 3144 RFC 3611, DOI 10.17487/RFC3611, November 2003, 3145 . 3147 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 3148 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 3149 2005, . 3151 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3152 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 3153 July 2006, . 3155 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 3156 Flow Information Export (IPFIX) Applicability", RFC 5472, 3157 DOI 10.17487/RFC5472, March 2009, 3158 . 3160 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 3161 Carle, "Information Model for Packet Sampling Exports", 3162 RFC 5477, DOI 10.17487/RFC5477, March 2009, 3163 . 3165 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 3166 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 3167 March 2009, . 3169 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 3170 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 3171 DOI 10.17487/RFC6248, April 2011, 3172 . 3174 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 3175 Performance Metric Development", BCP 170, RFC 6390, 3176 DOI 10.17487/RFC6390, October 2011, 3177 . 3179 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 3180 IP Network Performance Metrics: Different Points of View", 3181 RFC 6703, DOI 10.17487/RFC6703, August 2012, 3182 . 3184 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 3185 Reporting Using a Source Description (SDES) Item and an 3186 RTCP Extended Report (XR) Block", RFC 6776, 3187 DOI 10.17487/RFC6776, October 2012, 3188 . 3190 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 3191 of the RTP Monitoring Framework", RFC 6792, 3192 DOI 10.17487/RFC6792, November 2012, 3193 . 3195 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 3196 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 3197 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 3198 September 2013, . 3200 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 3201 Aitken, P., and A. Akhter, "A Framework for Large-Scale 3202 Measurement of Broadband Performance (LMAP)", RFC 7594, 3203 DOI 10.17487/RFC7594, September 2015, 3204 . 3206 Authors' Addresses 3208 Al Morton 3209 AT&T Labs 3210 200 Laurel Avenue South 3211 Middletown,, NJ 07748 3212 USA 3214 Phone: +1 732 420 1571 3215 Fax: +1 732 368 1192 3216 Email: acmorton@att.com 3217 URI: http://home.comcast.net/~acmacm/ 3219 Marcelo Bagnulo 3220 Universidad Carlos III de Madrid 3221 Av. Universidad 30 3222 Leganes, Madrid 28911 3223 SPAIN 3225 Phone: 34 91 6249500 3226 Email: marcelo@it.uc3m.es 3227 URI: http://www.it.uc3m.es 3229 Philip Eardley 3230 BT 3231 Adastral Park, Martlesham Heath 3232 Ipswich 3233 ENGLAND 3235 Email: philip.eardley@bt.com 3237 Kevin D'Souza 3238 AT&T Labs 3239 200 Laurel Avenue South 3240 Middletown,, NJ 07748 3241 USA 3243 Phone: +1 732 420 xxxx 3244 Email: kld@att.com