idnits 2.17.1 draft-ietf-ippm-initial-registry-03.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 582 has weird spacing: '... Src the IP...' == Line 586 has weird spacing: '... Dst the IP...' == Line 603 has weird spacing: '..._lambda avera...' == Line 625 has weird spacing: '... Src launch...' == Line 628 has weird spacing: '... Dst waits ...' == (19 more instances...) -- The document date (March 9, 2017) is 2605 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 2934, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 2957, but no explicit reference was found in the text == Unused Reference: 'RFC7680' is defined on line 2994, but no explicit reference was found in the text == Unused Reference: 'Brow00' is defined on line 3001, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 3013, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 3021, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 3026, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 3035, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 3066, 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 (~~), 16 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: September 10, 2017 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 March 9, 2017 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-03 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. This version includes: 20 * All section 4, 5, 6, 7, and 8 parameters reference YANG types for 21 alternate data formats. 23 * implementation of standard naming format for parameters. 25 * implementation of many IANA early-review comments. 27 Still need: Add MBM metric entry. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 10, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 71 4. UDP Round-trip Latency Registry Entry . . . . . . . . . . . . 8 72 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 74 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 78 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 79 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 80 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 81 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 82 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 83 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 84 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 85 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 86 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 87 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 88 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 15 92 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 93 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 94 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 95 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 96 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16 97 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 98 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 99 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 100 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 101 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 17 103 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 17 104 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 105 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 106 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 107 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 108 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 109 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 110 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 111 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19 112 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 113 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 20 114 5.3.3. Traffic Filtering (observation) Details . . . . . . . 21 115 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 21 116 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 21 117 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 118 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22 119 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22 120 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 22 121 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23 122 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23 123 5.5. Administrative items . . . . . . . . . . . . . . . . . . 24 124 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24 125 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 24 126 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24 127 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 24 128 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 24 129 6. DNS Response Latency Registry Entry . . . . . . . . . . . . . 24 130 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24 131 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24 132 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 25 133 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 25 134 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 25 135 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 25 136 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 25 137 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 25 138 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25 139 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 26 140 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 28 141 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 28 142 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 29 143 6.3.3. Traffic Filtering (observation) Details . . . . . . . 30 144 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 30 145 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 30 146 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 31 147 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 31 148 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 31 149 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 32 150 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 32 151 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 32 152 6.5. Administrative items . . . . . . . . . . . . . . . . . . 33 153 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 33 154 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 33 155 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 33 156 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 33 157 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 33 158 7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 33 159 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34 160 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 34 161 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 34 162 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 34 163 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 34 164 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 35 165 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 35 166 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 167 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36 168 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 169 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 37 170 7.3.3. Traffic Filtering (observation) Details . . . . . . . 38 171 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 38 172 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 38 173 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 39 174 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 39 175 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 39 176 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 39 177 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 42 178 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 42 179 7.5. Administrative items . . . . . . . . . . . . . . . . . . 43 180 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 43 181 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 43 182 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 43 183 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43 184 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43 185 8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 43 186 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 44 187 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 44 188 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 44 189 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44 190 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 45 191 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 45 192 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 45 193 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 46 194 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 47 195 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 47 196 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 48 197 8.3.3. Traffic Filtering (observation) Details . . . . . . . 48 198 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48 199 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 200 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 49 201 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49 202 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49 203 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 204 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52 205 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 206 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 207 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 208 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 53 209 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 210 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 211 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53 212 9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 54 213 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54 214 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54 215 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 216 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54 217 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54 218 9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 54 219 9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 54 220 9.1.7. Version (of Registry Format) . . . . . . . . . . . . 54 221 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 54 222 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 223 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 224 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 55 225 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 55 226 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 55 227 9.3.3. Traffic Filtering (observation) Details . . . . . . . 55 228 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 55 229 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 55 230 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 55 231 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 56 232 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 56 233 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 56 234 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56 235 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56 236 9.5. Administrative items . . . . . . . . . . . . . . . . . . 56 237 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 56 238 9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 56 239 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 56 240 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 56 242 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 56 243 10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 57 244 10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 57 245 10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 57 246 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 57 247 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 57 248 10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 57 249 10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 57 250 10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 57 251 10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 57 252 10.1.8. Description . . . . . . . . . . . . . . . . . . . . 57 253 10.1.9. Reference Specification(s) . . . . . . . . . . . . . 58 254 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 58 255 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 58 256 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 58 257 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 59 258 10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 59 259 10.3.2. Stream Type and Stream Parameters . . . . . . . . . 59 260 10.3.3. Output Type and Data Format . . . . . . . . . . . . 59 261 10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 59 262 10.3.5. Run-time Parameters and Data Format . . . . . . . . 60 263 10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 61 264 11. Revision History . . . . . . . . . . . . . . . . . . . . . . 61 265 12. Security Considerations . . . . . . . . . . . . . . . . . . . 62 266 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 267 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 268 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 269 15.1. Normative References . . . . . . . . . . . . . . . . . . 63 270 15.2. Informative References . . . . . . . . . . . . . . . . . 64 271 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 273 1. Introduction 275 Note: Efforts to synchronize structure and terminology with 276 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 277 drafts are stable. 279 This memo proposes an initial set of entries for the Performance 280 Metric Registry. It uses terms and definitions from the IPPM 281 literature, primarily [RFC2330]. Proponents of Passive Performance 282 Metrics are encouraged to develop a similar document. 284 Although there are several standard templates for organizing 285 specifications of performance metrics (see [RFC2679] for an example 286 of the traditional IPPM template, based to large extent on the 287 Benchmarking Methodology Working Group's traditional template in 288 [RFC1242], and see [RFC6390] for a similar template), none of these 289 templates were intended to become the basis for the columns of an 290 IETF-wide registry of metrics. While examinating aspects of metric 291 specifications which need to be registered, it became clear that none 292 of the existing metric templates fully satisfies the particular needs 293 of a registry. 295 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 296 for a Performance Metric Registry. Section 5 of 297 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 298 requesting registration of a Metric, that is the creation of entry(s) 299 in the Performance Metric Registry: "In essence, there needs to be 300 evidence that a candidate Registered Performance Metric has 301 significant industry interest, or has seen deployment, and there is 302 agreement that the candidate Registered Performance Metric serves its 303 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 304 also requires that new entries are administered by IANA through 305 Expert Review, which will ensure that the metrics are tightly 306 defined. 308 2. Scope 310 This document defines the initial set of Performance Metrics Registry 311 entries, for which IETF approval (following development in the IP 312 Performance Metrics (IPPM) Working Group) will satisfy the 313 requirement for Expert Review. Note that all are Active Performance 314 Metrics, which are based on RFCs prepared in the IPPM working group 315 of the IETF, according to their framework [RFC2330] and its updates. 317 3. Registry Categories and Columns 319 This section provides the categories and columns of the registry, for 320 easy reference. An entry (row) therefore gives a complete 321 description of a Registered Metric. 323 Registry Categories and Columns, shown as 324 Category 325 ------------------ 326 Column | Column | 328 Summary 329 ------------------------------------------------------------------------ 330 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 332 Metric Definition 333 ----------------------------------------- 334 Reference Definition | Fixed Parameters | 336 Method of Measurement 337 --------------------------------------------------------------------- 338 Reference | Packet | Traffic | Sampling | Run-time | Role | 339 Method | Stream | Filter | Distribution | Parameters | | 340 | Generation | 341 Output 342 ----------------------------------------- 343 Type | Reference | Units | Calibration | 344 | Definition | | | 346 Administrative Information 347 ---------------------------------- 348 Status |Request | Rev | Rev.Date | 350 Comments and Remarks 351 -------------------- 353 4. UDP Round-trip Latency Registry Entry 355 This section gives an initial registry entry for the UDP Round-trip 356 Latency. 358 Note: Each Registry entry only produces a "raw" output or a 359 statistical summary. To describe both "raw" and one or more 360 statistics efficiently, the Identifier, Name, and Output Categories 361 can be split and a single section can specify two or more closely- 362 related metrics. See Section 7 for an example specifying multiple 363 Registry entries with many common columns. 365 4.1. Summary 367 This category includes multiple indexes to the registry entry: the 368 element ID and metric name. 370 4.1.1. ID (Identifier) 372 374 4.1.2. Name 376 378 RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 380 4.1.3. URIs 382 URN: Prefix urn:ietf:metrics:perf: 384 URL: http:/// 386 4.1.4. Description 388 This metric assesses the delay of a stream of packets exchanged 389 between two hosts (which are the two measurement points), and the 390 Output is the Round-trip delay for all successfully exchanged packets 391 expressed as the 95th percentile of their conditional delay 392 distribution. 394 4.1.5. Change Controller 396 IETF 398 4.1.6. Version (of Registry Format) 400 1.0 402 4.2. Metric Definition 404 This category includes columns to prompt the entry of all necessary 405 details related to the metric definition, including the RFC reference 406 and values of input factors, called fixed parameters. 408 4.2.1. Reference Definition 410 412 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 413 Metric for IPPM", RFC 2681, September 1999. 415 [RFC2681] 417 418 Section 2.4 of [RFC2681] provides the reference definition of the 419 singleton (single value) Round-trip delay metric. Section 3.4 of 420 [RFC2681] provides the reference definition expanded to cover a 421 multi-singleton sample. Note that terms such as singleton and sample 422 are defined in Section 11 of [RFC2330]. 424 Note that although the [RFC2681] definition of "Round-trip-Delay 425 between Src and Dst" is directionally ambiguous in the text, this 426 metric tightens the definition further to recognize that the host in 427 the "Src" role will send the first packet to "Dst", and ultimately 428 receive the corresponding return packet from "Dst" (when neither are 429 lost). 431 Finally, note that the variable "dT" is used in [RFC2681] to refer to 432 the value of Round-trip delay in metric definitions and methods. The 433 variable "dT" has been re-used in other IPPM literature to refer to 434 different quantities, and cannot be used as a global variable name. 436 4.2.2. Fixed Parameters 438 442 Type-P as defined in Section 13 of [RFC2330]: 444 o IPv4 header values: 446 * DSCP: set to 0 448 * TTL: set to 255 450 * Protocol: Set to 17 (UDP) 452 o IPv6 header values: 454 * DSCP: set to 0 456 * Hop Count: set to 255 458 * Protocol: Set to 17 (UDP) 460 o UDP header values: 462 * Checksum: the checksum MUST be calculated and included in the 463 header 465 o UDP Payload 466 * total of 9 bytes 468 Other measurement parameters: 470 o Tmax: a loss threshold waiting time 472 * 3.0, expressed in units of seconds, as a positive value of type 473 decimal64 with fraction digits = 5 (see section 9.3 of 474 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 475 lossless conversion to/from the 32-bit NTP timestamp as per 476 section 6 of [RFC5905]. 478 4.3. Method of Measurement 480 This category includes columns for references to relevant sections of 481 the RFC(s) and any supplemental information needed to ensure an 482 unambiguous methods for implementations. 484 4.3.1. Reference Method 486 489 The methodology for this metric is defined as Type-P-Round-trip- 490 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 491 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 492 Fixed Parameters. 494 The reference method distinguishes between long-delayed packets and 495 lost packets by implementing a maximum waiting time for packet 496 arrival. Tmax is the waiting time used as the threshold to declare a 497 packet lost. Lost packets SHALL be designated as having undefined 498 delay. 500 The calculations on the delay (RTT) SHALL be performed on the 501 conditional distribution, conditioned on successful packet arrival 502 within Tmax. Also, when all packet delays are stored, the process 503 which calculates the RTT value MAY enforce the Tmax threshold on 504 stored values before calculations. See section 4.1 of [RFC3393] for 505 details on the conditional distribution to exclude undefined values 506 of delay, and Section 5 of [RFC6703] for background on this analysis 507 choice. 509 The reference method requires some way to distinguish between 510 different packets in a stream to establish correspondence between 511 sending times and receiving times for each successfully-arriving 512 packet. Sequence numbers or other send-order identification MUST be 513 retained at the Src or included with each packet to dis-ambiguate 514 packet reordering if it occurs. 516 If a standard measurement protocol is employed, then the measurement 517 process will determine the sequence numbers or timestamps applied to 518 test packets after the Fixed and Runtime parameters are passed to 519 that process. The chosen measurement protocol will dictate the 520 format of sequence numbers and time-stamps, if they are conveyed in 521 the packet payload. 523 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 524 instruction to "send a Type-P packet back to the Src as quickly as 525 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 526 [RFC6673] presents additional requirements which MUST be included in 527 the method of measurement for this metric. 529 4.3.2. Packet Stream Generation 531 This section gives the details of the packet traffic which is the 532 basis for measurement. In IPPM metrics, this is called the Stream, 533 and can easily be described by providing the list of stream 534 parameters. 536
539 Section 11.1.3 of [RFC2330] provides three methods to generate 540 Poisson sampling intervals. the reciprocal of lambda is the average 541 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 542 lambda, in seconds. 544 >>> Check with Sam, most likely it is this... 546 Method 3 SHALL be used, where given a start time (Run-time 547 Parameter), the subsequent send times are all computed prior to 548 measurement by computing the pseudo-random distribution of inter- 549 packet send times, (truncating the distribution as specified in the 550 Run-time Parameter, Trunc), and the Src sends each packet at the 551 computed times. 553 Note that Trunc is the upper limit on inter-packet times in the 554 Poisson distribution. A random value greater than Trunc is set equal 555 to Trunc instead. 557 4.3.3. Traffic Filtering (observation) Details 559 The measured results based on a filtered version of the packets 560 observed, and this section provides the filter details (when 561 present). 563
. 565 NA 567 4.3.4. Sampling Distribution 569 572 NA 574 4.3.5. Run-time Parameters and Data Format 576 Run-time Parameters are input factors that must be determined, 577 configured into the measurement system, and reported with the results 578 for the context to be complete. 580 582 Src the IP address of the host in the Src Role (format ipv4-address- 583 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 584 see Section 4 of [RFC6991]) 586 Dst the IP address of the host in the Dst Role (format ipv4-address- 587 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 588 see section 4 of [RFC6991]) 590 T0 a time, the start of a measurement interval, (format "date-and- 591 time" as specified in Section 5.6 of [RFC3339], see also Section 3 592 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 593 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 594 and Tf is to be interpreted as the Duration of the measurement 595 interval. The start time is controlled through other means. 597 Tf a time, the end of a measurement interval, (format "date-and-time" 598 as specified in Section 5.6 of [RFC3339], see also Section 3 of 599 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 600 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 601 Tf is interpreted as the Duration of the measurement interval. 603 Reciprocal_lambda average packet interval for Poisson Streams 604 expressed in units of seconds, as a positive value of type 605 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 606 with resolution of 0.0001 seconds (0.1 ms), and with lossless 607 conversion to/from the 32-bit NTP timestamp as per section 6 of 608 [RFC5905]. 610 Trunc Upper limit on Poisson distribution expressed in units of 611 seconds, as a positive value of type decimal64 with fraction 612 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 613 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 614 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 615 this limit will be clipped and set to the limit value). (if fixed, 616 Trunc = 30.0000 seconds.) 618 >>> should Poisson run-time params be fixed instead? probably yes if 619 modeling a specific version of MBA tests. 621 4.3.6. Roles 623 625 Src launches each packet and waits for return transmissions from 626 Dst. 628 Dst waits for each packet from Src and sends a return packet to Src. 630 4.4. Output 632 This category specifies all details of the Output of measurements 633 using the metric. 635 4.4.1. Type 637 639 Percentile -- for the conditional distribution of all packets with a 640 valid value of Round-trip delay (undefined delays are excluded), a 641 single value corresponding to the 95th percentile, as follows: 643 See section 4.1 of [RFC3393] for details on the conditional 644 distribution to exclude undefined values of delay, and Section 5 of 645 [RFC6703] for background on this analysis choice. 647 The percentile = 95, meaning that the reported delay, "95Percentile", 648 is the smallest value of Round-trip delay for which the Empirical 649 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 650 Round-trip delay values in the conditional distribution. See section 651 11.3 of [RFC2330] for the definition of the percentile statistic 652 using the EDF. 654 4.4.2. Reference Definition 656 658 For all outputs --- 660 T0 the start of a measurement interval, (format "date-and-time" as 661 specified in Section 5.6 of [RFC3339], see also Section 3 of 662 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 663 [RFC2330]. 665 Tf the end of a measurement interval, (format "date-and-time" as 666 specified in Section 5.6 of [RFC3339], see also Section 3 of 667 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 668 [RFC2330]. 670 Raw -- REMOVED IN VERSION 01 672 For Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile: 674 95Percentile The time value of the result is expressed in units of 675 seconds, as a positive value of type decimal64 with fraction 676 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 677 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 678 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 680 4.4.3. Metric Units 682 . 685 The 95th Percentile of Round-trip Delay is expressed in seconds. 687 4.4.4. Calibration 689 Section 3.7.3 of [RFC7679] provides a means to quantify the 690 systematic and random errors of a time measurement. In-situ 691 calibration could be enabled with an internal loopback at the Source 692 host that includes as much of the measurement system as possible, 693 performs address manipulation as needed, and provides some form of 694 isolation (e.g., deterministic delay) to avoid send-receive interface 695 contention. Some portion of the random and systematic error can be 696 characterized this way. 698 When a measurement controller requests a calibration measurement, the 699 loopback is applied and the result is output in the same format as a 700 normal measurement with additional indication that it is a 701 calibration result. 703 Both internal loopback calibration and clock synchronization can be 704 used to estimate the *available accuracy* of the Output Metric Units. 705 For example, repeated loopback delay measurements will reveal the 706 portion of the Output result resolution which is the result of system 707 noise, and thus inaccurate. 709 4.5. Administrative items 711 4.5.1. Status 713 715 4.5.2. Requestor (keep?) 717 name or RFC, etc. 719 4.5.3. Revision 721 1.0 723 4.5.4. Revision Date 725 YYYY-MM-DD 727 4.6. Comments and Remarks 729 Additional (Informational) details for this entry 731 5. Packet Delay Variation Registry Entry 733 This section gives an initial registry entry for a Packet Delay 734 Variation metric. 736 Note: If each Registry entry should only produce a "raw" output or a 737 statistical summary, then the "Output" Category can be split and this 738 section can become two closely-related metrics. 740 5.1. Summary 742 This category includes multiple indexes to the registry entries, the 743 element ID and metric name. 745 747 5.1.1. ID (Identifier) 749 751 5.1.2. Name 753 755 OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile 757 5.1.3. URIs 759 URI: Prefix urn:ietf:metrics:perf: 761 URL: http:/// 763 5.1.4. Description 765 An assessment of packet delay variation with respect to the minimum 766 delay observed on the stream, and the Output is expressed as the 95th 767 percentile of the packet delay variation distribution. 769 5.1.5. Change Controller 771 773 IETF 775 5.1.6. Version (of Registry Format) 777 1.0 779 5.2. Metric Definition 781 This category includes columns to prompt the entry of all necessary 782 details related to the metric definition, including the RFC reference 783 and values of input factors, called fixed parameters. 785 5.2.1. Reference Definition 787 789 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 790 Performance Metrics", RFC 2330, May 1998. [RFC2330] 792 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 793 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 794 [RFC3393] 795 Morton, A. and B. Claise, "Packet Delay Variation Applicability 796 Statement", RFC 5481, March 2009. [RFC5481] 798 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 799 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 800 June 2010.[RFC5905] 802 804 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 805 measured are referred to by the variable name "ddT" (applicable to 806 all forms of delay variation). However, this metric entry specifies 807 the PDV form defined in section 4.2 of [RFC5481], where the singleton 808 PDV for packet i is referred to by the variable name "PDV(i)". 810 5.2.2. Fixed Parameters 812 816 o IPv4 header values: 818 * DSCP: set to 0 820 * TTL: set to 255 822 * Protocol: Set to 17 (UDP) 824 o IPv6 header values: 826 * DSCP: set to 0 828 * Hop Count: set to 255 830 * Protocol: Set to 17 (UDP) 832 o UDP header values: 834 * Checksum: the checksum MUST be calculated and included in the 835 header 837 o UDP Payload 839 * total of 200 bytes 841 Other measurement parameters: 843 Tmax: a loss threshold waiting time with value 3.0, expressed in 844 units of seconds, as a positive value of type decimal64 with 845 fraction digits = 5 (see section 9.3 of [RFC6020]) and with 846 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 847 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 849 F a selection function unambiguously defining the packets from the 850 stream selected for the metric. See section 4.2 of [RFC5481] for 851 the PDV form. 853 See the Packet Stream generation category for two additional Fixed 854 Parameters. 856 5.3. Method of Measurement 858 This category includes columns for references to relevant sections of 859 the RFC(s) and any supplemental information needed to ensure an 860 unambiguous methods for implementations. 862 5.3.1. Reference Method 864 867 See section 2.6 and 3.6 of [RFC3393] for general singleton element 868 calculations. This metric entry requires implementation of the PDV 869 form defined in section 4.2 of [RFC5481]. Also see measurement 870 considerations in section 8 of [RFC5481]. 872 The reference method distinguishes between long-delayed packets and 873 lost packets by implementing a maximum waiting time for packet 874 arrival. Tmax is the waiting time used as the threshold to declare a 875 packet lost. Lost packets SHALL be designated as having undefined 876 delay. 878 The calculations on the one-way delay SHALL be performed on the 879 conditional distribution, conditioned on successful packet arrival 880 within Tmax. Also, when all packet delays are stored, the process 881 which calculates the one-way delay value MAY enforce the Tmax 882 threshold on stored values before calculations. See section 4.1 of 883 [RFC3393] for details on the conditional distribution to exclude 884 undefined values of delay, and Section 5 of [RFC6703] for background 885 on this analysis choice. 887 The reference method requires some way to distinguish between 888 different packets in a stream to establish correspondence between 889 sending times and receiving times for each successfully-arriving 890 packet. Sequence numbers or other send-order identification MUST be 891 retained at the Src or included with each packet to dis-ambiguate 892 packet reordering if it occurs. 894 If a standard measurement protocol is employed, then the measurement 895 process will determine the sequence numbers or timestamps applied to 896 test packets after the Fixed and Runtime parameters are passed to 897 that process. The chosen measurement protocol will dictate the 898 format of sequence numbers and time-stamps, if they are conveyed in 899 the packet payload. 901 5.3.2. Packet Stream Generation 903 905 Section 11.1.3 of [RFC2330] provides three methods to generate 906 Poisson sampling intervals. the reciprocal of lambda is the average 907 packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/ 908 lambda, in seconds. 910 >>> Check with Sam, most likely it is this... 912 Method 3 SHALL be used, where given a start time (Run-time 913 Parameter), the subsequent send times are all computed prior to 914 measurement by computing the pseudo-random distribution of inter- 915 packet send times, (truncating the distribution as specified in the 916 Parameter Trunc), and the Src sends each packet at the computed 917 times. 919 Note that Trunc is the upper limit on inter-packet times in the 920 Poisson distribution. A random value greater than Trunc is set equal 921 to Trunc instead. 923 Reciprocal_lambda average packet interval for Poisson Streams 924 expressed in units of seconds, as a positive value of type 925 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 926 with resolution of 0.0001 seconds (0.1 ms), and with lossless 927 conversion to/from the 32-bit NTP timestamp as per section 6 of 928 [RFC5905]. Reciprocal_lambda = 1 packet per second. 930 Trunc Upper limit on Poisson distribution expressed in units of 931 seconds, as a positive value of type decimal64 with fraction 932 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 933 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 934 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 935 this limit will be clipped and set to the limit value). Trunc = 936 30.0000 seconds. 938 5.3.3. Traffic Filtering (observation) Details 940 . 944 NA 946 5.3.4. Sampling Distribution 948 951 NA 953 5.3.5. Run-time Parameters and Data Format 955 957 Src the IP address of the host in the Src Role (format ipv4-address- 958 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 959 see Section 4 of [RFC6991]) 961 Dst the IP address of the host in the Dst Role (format ipv4-address- 962 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 963 see section 4 of [RFC6991]) 965 T0 a time, the start of a measurement interval, (format "date-and- 966 time" as specified in Section 5.6 of [RFC3339], see also Section 3 967 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 968 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 969 and Tf is to be interpreted as the Duration of the measurement 970 interval. The start time is controlled through other means. 972 Tf a time, the end of a measurement interval, (format "date-and-time" 973 as specified in Section 5.6 of [RFC3339], see also Section 3 of 974 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 975 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 976 Tf is interpreted as the Duration of the measurement interval. 978 5.3.6. Roles 980 982 Src launches each packet to Dst. 984 Dst waits for each packet from Src. 986 5.4. Output 988 This category specifies all details of the Output of measurements 989 using the metric. 991 5.4.1. Type 993 995 Percentile -- for the conditional distribution of all packets with a 996 valid value of one-way delay (undefined delays are excluded), a 997 single value corresponding to the 95th percentile, as follows: 999 See section 4.1 of [RFC3393] for details on the conditional 1000 distribution to exclude undefined values of delay, and Section 5 of 1001 [RFC6703] for background on this analysis choice. 1003 The percentile = 95, meaning that the reported delay, "95Percentile", 1004 is the smallest value of one-way PDV for which the Empirical 1005 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1006 one-way PDV values in the conditional distribution. See section 11.3 1007 of [RFC2330] for the definition of the percentile statistic using the 1008 EDF. 1010 5.4.2. Reference Definition 1012 1014 T0 the start of a measurement interval, (format "date-and-time" as 1015 specified in Section 5.6 of [RFC3339], see also Section 3 of 1016 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1017 [RFC2330]. 1019 Tf the end of a measurement interval, (format "date-and-time" as 1020 specified in Section 5.6 of [RFC3339], see also Section 3 of 1021 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1022 [RFC2330]. 1024 95Percentile The time value of the result is expressed in units of 1025 seconds, as a positive value of type decimal64 with fraction 1026 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1027 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1028 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1030 5.4.3. Metric Units 1032 . 1035 The 95th Percentile of one-way PDV is expressed in seconds. 1037 5.4.4. Calibration 1039 Section 3.7.3 of [RFC7679] provides a means to quantify the 1040 systematic and random errors of a time measurement. In-situ 1041 calibration could be enabled with an internal loopback that includes 1042 as much of the measurement system as possible, performs address 1043 manipulation as needed, and provides some form of isolation (e.g., 1044 deterministic delay) to avoid send-receive interface contention. 1045 Some portion of the random and systematic error can be characterized 1046 this way. 1048 For one-way delay measurements, the error calibration must include an 1049 assessment of the internal clock synchronization with its external 1050 reference (this internal clock is supplying timestamps for 1051 measurement). In practice, the time offsets of clocks at both the 1052 source and destination are needed to estimate the systematic error 1053 due to imperfect clock synchronization (the time offsets are 1054 smoothed, thus the random variation is not usually represented in the 1055 results). 1057 time_offset The time value of the result is expressed in units of 1058 seconds, as a signed value of type decimal64 with fraction digits 1059 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1060 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1061 NTP timestamp as per section 6 of RFC [RFC5905] 1063 When a measurement controller requests a calibration measurement, the 1064 loopback is applied and the result is output in the same format as a 1065 normal measurement with additional indication that it is a 1066 calibration result. In any measurement, the measurement function 1067 SHOULD report its current estimate of time offset as an indicator of 1068 the degree of synchronization. 1070 Both internal loopback calibration and clock synchronization can be 1071 used to estimate the *available accuracy* of the Output Metric Units. 1072 For example, repeated loopback delay measurements will reveal the 1073 portion of the Output result resolution which is the result of system 1074 noise, and thus inaccurate. 1076 5.5. Administrative items 1078 5.5.1. Status 1080 1082 5.5.2. Requestor (keep?) 1084 1086 5.5.3. Revision 1088 1.0 1090 5.5.4. Revision Date 1092 YYYY-MM-DD 1094 5.6. Comments and Remarks 1096 1098 Lost packets represent a challenge for delay variation metrics. See 1099 section 4.1 of [RFC3393] and the delay variation applicability 1100 statement[RFC5481] for extensive analysis and comparison of PDV and 1101 an alternate metric, IPDV. 1103 6. DNS Response Latency Registry Entry 1105 This section gives an initial registry entry for DNS Response 1106 Latency. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1107 build on that metric by specifying several of the input parameters to 1108 precisely define a metric for measuring DNS latency. 1110 6.1. Summary 1112 This category includes multiple indexes to the registry entries, the 1113 element ID and metric name. 1115 1117 6.1.1. ID (Identifier) 1119 1121 6.1.2. Name 1123 1125 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1127 6.1.3. URI 1129 URI: Prefix urn:ietf:metrics:perf: 1131 URL: http:/// 1133 6.1.4. Description 1135 This metric assesses the response time, the interval from the query 1136 transmission to the response. 1138 6.1.5. Change Controller 1140 IETF 1142 6.1.6. Version (of Registry Format) 1144 1.0 1146 6.2. Metric Definition 1148 This category includes columns to prompt the entry of all necessary 1149 details related to the metric definition, including the RFC reference 1150 and values of input factors, called fixed parameters. 1152 6.2.1. Reference Definition 1154 1156 Mockapetris, P., "Domain names - implementation and specification", 1157 STD 13, RFC 1035, November 1987. (and updates) 1159 [RFC1035] 1161 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1162 Metric for IPPM", RFC 2681, September 1999. 1164 [RFC2681] 1166 1167 Section 2.4 of [RFC2681] provides the reference definition of the 1168 singleton (single value) Round-trip delay metric. Section 3.4 of 1169 [RFC2681] provides the reference definition expanded to cover a 1170 multi-singleton sample. Note that terms such as singleton and sample 1171 are defined in Section 11 of [RFC2330]. 1173 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1174 [RFC2681]. The Local Host with its User Program and Resolver take 1175 the role of "Src", and the Foreign Name Server takes the role of 1176 "Dst". 1178 Note that although the [RFC2681] definition of "Round-trip-Delay 1179 between Src and Dst at T" is directionally ambiguous in the text, 1180 this metric tightens the definition further to recognize that the 1181 host in the "Src" role will send the first packet to "Dst", and 1182 ultimately receive the corresponding return packet from "Dst" (when 1183 neither are lost). 1185 6.2.2. Fixed Parameters 1187 1191 Type-P as defined in Section 13 of [RFC2330]: 1193 o IPv4 header values: 1195 * DSCP: set to 0 1197 * TTL set to 255 1199 * Protocol: Set to 17 (UDP) 1201 o IPv6 header values: 1203 * DSCP: set to 0 1205 * Hop Count: set to 255 1207 * Protocol: Set to 17 (UDP) 1209 o UDP header values: 1211 * Source port: 53 1213 * Destination port: 53 1214 * Checksum: the checksum must be calculated and included in the 1215 header 1217 o Payload: The payload contains a DNS message as defined in RFC 1035 1218 [RFC1035] with the following values: 1220 * The DNS header section contains: 1222 + Identification (see the Run-time column) 1224 + QR: set to 0 (Query) 1226 + OPCODE: set to 0 (standard query) 1228 + AA: not set 1230 + TC: not set 1232 + RD: set to one (recursion desired) 1234 + RA: not set 1236 + RCODE: not set 1238 + QDCOUNT: set to one (only one entry) 1240 + ANCOUNT: not set 1242 + NSCOUNT: not set 1244 + ARCOUNT: not set 1246 * The Question section contains: 1248 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1249 input for the test, see the Run-time column 1251 + QTYPE: the query type provided as input for the test, see 1252 the Run-time column 1254 + QCLASS: set to 1 for IN 1256 * The other sections do not contain any Resource Records. 1258 Other measurement parameters: 1260 o Tmax: a loss threshold waiting time (and to help disambiguate 1261 queries) 1262 * 5.0, expressed in units of seconds, as a positive value of type 1263 decimal64 with fraction digits = 5 (see section 9.3 of 1264 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1265 lossless conversion to/from the 32-bit NTP timestamp as per 1266 section 6 of [RFC5905]. 1268 Observation: reply packets will contain a DNS response and may 1269 contain RRs. 1271 6.3. Method of Measurement 1273 This category includes columns for references to relevant sections of 1274 the RFC(s) and any supplemental information needed to ensure an 1275 unambiguous methods for implementations. 1277 6.3.1. Reference Method 1279 1282 The methodology for this metric is defined as Type-P-Round-trip- 1283 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1284 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1285 Fixed Parameters. 1287 The reference method distinguishes between long-delayed packets and 1288 lost packets by implementing a maximum waiting time for packet 1289 arrival. Tmax is the waiting time used as the threshold to declare a 1290 packet lost. Lost packets SHALL be designated as having undefined 1291 delay. 1293 The calculations on the delay (RTT) SHALL be performed on the 1294 conditional distribution, conditioned on successful packet arrival 1295 within Tmax. Also, when all packet delays are stored, the process 1296 which calculates the RTT value MAY enforce the Tmax threshold on 1297 stored values before calculations. See section 4.1 of [RFC3393] for 1298 details on the conditional distribution to exclude undefined values 1299 of delay, and Section 5 of [RFC6703] for background on this analysis 1300 choice. 1302 The reference method requires some way to distinguish between 1303 different packets in a stream to establish correspondence between 1304 sending times and receiving times for each successfully-arriving 1305 reply. Therefore, sequence numbers or other send-order 1306 identification MUST be retained at the Src or included with each 1307 packet to dis-ambiguate packet reordering if it occurs. Sequence 1308 number is part of the payload described under Fixed Parameters. 1310 DNS Messages bearing Queries provide for random ID Numbers in the 1311 Identification header field, so more than one query may be launched 1312 while a previous request is outstanding when the ID Number is used. 1314 IF a DNS response does not arrive within Tmax, the result is 1315 undefined. The Message ID SHALL be used to disambiguate the 1316 successive queries. 1318 >>> This would require support of ID generation and population in the 1319 Message. An alternative would be to use a random Source port on the 1320 Query Message, but we would choose ONE before proceding. 1322 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1323 instruction to "send a Type-P packet back to the Src as quickly as 1324 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1325 [RFC6673] presents additional requirements which shall be included in 1326 the method of measurement for this metric. 1328 In addition to operations described in [RFC2681], the Src MUST parse 1329 the DNS headers of the reply and prepare the information for 1330 subsequent reporting as a measured result, along with the Round-Trip 1331 Delay. 1333 6.3.2. Packet Stream Generation 1335 This section gives the details of the packet traffic which is the 1336 basis for measurement. In IPPM metrics, this is called the Stream, 1337 and can easily be dscribed by providing the list of stream 1338 parameters. 1340 1342 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1343 generate Poisson sampling intervals. The reciprocal of lambda is the 1344 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1345 = 1/lambda, in seconds. 1347 Method 3 is used, where given a start time (Run-time Parameter), the 1348 subsequent send times are all computed prior to measurement by 1349 computing the pseudo-random distribution of inter-packet send times, 1350 (truncating the distribution as specified in the Run-time 1351 Parameters), and the Src sends each packet at the computed times. 1353 Note that Trunc is the upper limit on inter-packet times in the 1354 Poisson distribution. A random value greater than Trunc is set equal 1355 to Trunc instead. 1357 6.3.3. Traffic Filtering (observation) Details 1359 The measured results based on a filtered version of the packets 1360 observed, and this section provides the filter details (when 1361 present). 1363
. 1365 NA 1367 6.3.4. Sampling Distribution 1369 1372 NA 1374 6.3.5. Run-time Parameters and Data Format 1376 Run-time Parameters are input factors that must be determined, 1377 configured into the measurement system, and reported with the results 1378 for the context to be complete. 1380 1382 Src the IP address of the host in the Src Role (format ipv4-address- 1383 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1384 see Section 4 of [RFC6991]) 1386 Dst the IP address of the host in the Dst Role (format ipv4-address- 1387 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1388 see section 4 of [RFC6991]) 1390 T0 a time, the start of a measurement interval, (format "date-and- 1391 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1392 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1393 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1394 and Tf is to be interpreted as the Duration of the measurement 1395 interval. The start time is controlled through other means. 1397 Tf a time, the end of a measurement interval, (format "date-and-time" 1398 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1399 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1400 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1401 Tf is interpreted as the Duration of the measurement interval. 1403 Reciprocal_lambda average packet interval for Poisson Streams 1404 expressed in units of seconds, as a positive value of type 1405 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 1406 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1407 conversion to/from the 32-bit NTP timestamp as per section 6 of 1408 [RFC5905]. 1410 Trunc Upper limit on Poisson distribution expressed in units of 1411 seconds, as a positive value of type decimal64 with fraction 1412 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 1413 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1414 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1415 this limit will be clipped and set to the limit value). (if fixed, 1416 Trunc = 30.0000 seconds.) 1418 ID The 16-bit identifier assigned by the program that generates the 1419 query, and which must vary in successive queries, see 1420 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1421 corresponding reply and can be used by the requester (Src) to 1422 match-up replies to outstanding queries. 1424 QNAME The domain name of the Query, formatted as specified in 1425 section 4 of [RFC6991]. 1427 QTYPE The Query Type, which will correspond to the IP address family 1428 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1429 uint16, as per section 9.2 of [RFC6020]. 1431 6.3.6. Roles 1433 1435 Src launches each packet and waits for return transmissions from 1436 Dst. 1438 Dst waits for each packet from Src and sends a return packet to Src. 1440 6.4. Output 1442 This category specifies all details of the Output of measurements 1443 using the metric. 1445 6.4.1. Type 1447 1449 Raw -- for each DNS Query packet sent, sets of values as defined in 1450 the next column, including the status of the response, only assigning 1451 delay values to successful query-response pairs. 1453 6.4.2. Reference Definition 1455 1457 For all outputs: 1459 T the time the DNS Query was sent during the measurement interval, 1460 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1461 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1462 by Section 6.1 of [RFC2330]. 1464 dT The time value of the round-trip delay to receive the DNS 1465 response, expressed in units of seconds, as a positive value of 1466 type decimal64 with fraction digits = 9 (see section 9.3 of 1467 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1468 with lossless conversion to/from the 64-bit NTP timestamp as per 1469 section 6 of RFC [RFC5905]. This value is undefined when the 1470 response packet is not received at Src within waiting time Tmxax 1471 seconds. 1473 Rcode The value of the Rcode field in the DNS response header, 1474 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1475 Non-zero values convey errors in the response, and such replies 1476 must be analyzed separately from successful requests. 1478 6.4.3. Metric Units 1480 . 1483 Round-trip Delay, dT, is expressed in seconds. 1485 6.4.4. Calibration 1487 Section 3.7.3 of [RFC7679] provides a means to quantify the 1488 systematic and random errors of a time measurement. In-situ 1489 calibration could be enabled with an internal loopback at the Source 1490 host that includes as much of the measurement system as possible, 1491 performs address and payload manipulation as needed, and provides 1492 some form of isolation (e.g., deterministic delay) to avoid send- 1493 receive interface contention. Some portion of the random and 1494 systematic error can be characterized this way. 1496 When a measurement controller requests a calibration measurement, the 1497 loopback is applied and the result is output in the same format as a 1498 normal measurement with additional indication that it is a 1499 calibration result. 1501 Both internal loopback calibration and clock synchronization can be 1502 used to estimate the *available accuracy* of the Output Metric Units. 1503 For example, repeated loopback delay measurements will reveal the 1504 portion of the Output result resolution which is the result of system 1505 noise, and thus inaccurate. 1507 6.5. Administrative items 1509 6.5.1. Status 1511 1513 6.5.2. Requestor 1515 name or RFC, etc. 1517 6.5.3. Revision 1519 1.0 1521 6.5.4. Revision Date 1523 YYYY-MM-DD 1525 6.6. Comments and Remarks 1527 Additional (Informational) details for this entry 1529 7. UDP Poisson One-way Delay Registry Entries 1531 This section specifies five initial registry entries for the UDP 1532 Poisson One-way Delay. 1534 Note: Each Registry "Name" below specifies a single registry entry, 1535 whose output format varies according to the element of 1536 the name that specifies one form of statistical summary. 1538 IANA is asked to assign a different numeric identifiers to each of 1539 the five Metrics. All column entries beside the ID, Name, 1540 Description, and Output Reference Method categories are the same, 1541 thus this section proposes five closely-related registry entries. As 1542 a result, IANA is also asked to assign corresponding URNs and URLs to 1543 each Named Metric. 1545 7.1. Summary 1547 This category includes multiple indexes to the registry entries, the 1548 element ID and metric name. 1550 7.1.1. ID (Identifier) 1552 1555 7.1.2. Name 1557 1559 OWDelay_Active_IP-UDP-Poisson- 1560 Payload250B_RFCXXXXsecY_Seconds_ 1562 where is one of: 1564 o 95Percentile 1566 o Mean 1568 o Min 1570 o Max 1572 o StdDev 1574 7.1.3. URI and URL 1576 URI: Prefix urn:ietf:metrics:perf: 1578 URL: http:\\www.iana.org\ ... 1580 7.1.4. Description 1582 This metric assesses the delay of a stream of packets exchanged 1583 between two hosts (or measurement points), and reports the 1584 One-way delay for all successfully exchanged packets 1585 based on their conditional delay distribution. 1587 where is one of: 1589 o 95Percentile 1591 o Mean 1592 o Min 1594 o Max 1596 o StdDev 1598 7.2. Metric Definition 1600 This category includes columns to prompt the entry of all necessary 1601 details related to the metric definition, including the RFC reference 1602 and values of input factors, called fixed parameters. 1604 7.2.1. Reference Definition 1606 1608 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1609 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1610 7679, DOI 10.17487/RFC7679, January 2016, . 1613 [RFC7679] 1615 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1616 6049, January 2011. 1618 [RFC6049] 1620 1622 Section 3.4 of [RFC7679] provides the reference definition of the 1623 singleton (single value) One-way delay metric. Section 4.4 of 1624 [RFC7679] provides the reference definition expanded to cover a 1625 multi-value sample. Note that terms such as singleton and sample are 1626 defined in Section 11 of [RFC2330]. 1628 Only successful packet transfers with finite delay are included in 1629 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1631 7.2.2. Fixed Parameters 1633 1637 Type-P: 1639 o IPv4 header values: 1641 * DSCP: set to 0 1643 * TTL: set to 255 1645 * Protocol: Set to 17 (UDP) 1647 o IPv6 header values: 1649 * DSCP: set to 0 1651 * Hop Count: set to 255 1653 * Protocol: Set to 17 (UDP) 1655 o UDP header values: 1657 * Checksum: the checksum MUST be calculated and included in the 1658 header 1660 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1662 * Security features in use influence the number of Padding 1663 octets. 1665 * 250 octets total, including the TWAMP format 1667 Other measurement parameters: 1669 Tmax: a loss threshold waiting time with value 3.0, expressed in 1670 units of seconds, as a positive value of type decimal64 with 1671 fraction digits = 5 (see section 9.3 of [RFC6020]) and with 1672 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1673 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1675 See the Packet Stream generation category for two additional Fixed 1676 Parameters. 1678 7.3. Method of Measurement 1680 This category includes columns for references to relevant sections of 1681 the RFC(s) and any supplemental information needed to ensure an 1682 unambiguous methods for implementations. 1684 7.3.1. Reference Method 1686 1688 The methodology for this metric is defined as Type-P-One-way-Delay- 1689 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1690 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1692 The reference method distinguishes between long-delayed packets and 1693 lost packets by implementing a maximum waiting time for packet 1694 arrival. Tmax is the waiting time used as the threshold to declare a 1695 packet lost. Lost packets SHALL be designated as having undefined 1696 delay. 1698 The calculations on the one-way delay SHALL be performed on the 1699 conditional distribution, conditioned on successful packet arrival 1700 within Tmax. Also, when all packet delays are stored, the process 1701 which calculates the one-way delay value MAY enforce the Tmax 1702 threshold on stored values before calculations. See section 4.1 of 1703 [RFC3393] for details on the conditional distribution to exclude 1704 undefined values of delay, and Section 5 of [RFC6703] for background 1705 on this analysis choice. 1707 The reference method requires some way to distinguish between 1708 different packets in a stream to establish correspondence between 1709 sending times and receiving times for each successfully-arriving 1710 packet. Sequence numbers or other send-order identification MUST be 1711 retained at the Src or included with each packet to dis-ambiguate 1712 packet reordering if it occurs. 1714 Since a standard measurement protocol is employed [RFC5357], then the 1715 measurement process will determine the sequence numbers or timestamps 1716 applied to test packets after the Fixed and Runtime parameters are 1717 passed to that process. The measurement protocol dictates the format 1718 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1719 payload. 1721 7.3.2. Packet Stream Generation 1723 This section gives the details of the packet traffic which is the 1724 basis for measurement. In IPPM metrics, this is called the Stream, 1725 and can easily be dscribed by providing the list of stream 1726 parameters. 1728 1730 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1731 generate Poisson sampling intervals. the reciprocal of lambda is the 1732 average packet spacing, thus the Run-time Parameter is 1733 Reciprocal_lambda = 1/lambda, in seconds. 1735 Method 3 SHALL be used, where given a start time (Run-time 1736 Parameter), the subsequent send times are all computed prior to 1737 measurement by computing the pseudo-random distribution of inter- 1738 packet send times, (truncating the distribution as specified in the 1739 Parameter Trunc), and the Src sends each packet at the computed 1740 times. 1742 Note that Trunc is the upper limit on inter-packet times in the 1743 Poisson distribution. A random value greater than Trunc is set equal 1744 to Trunc instead. 1746 Reciprocal_lambda average packet interval for Poisson Streams 1747 expressed in units of seconds, as a positive value of type 1748 decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020]) 1749 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1750 conversion to/from the 32-bit NTP timestamp as per section 6 of 1751 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1753 Trunc Upper limit on Poisson distribution expressed in units of 1754 seconds, as a positive value of type decimal64 with fraction 1755 digits = 5 (see section 9.3 of [RFC6020]) with resolution of 1756 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1757 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1758 this limit will be clipped and set to the limit value). Trunc = 1759 30.0000 seconds. 1761 7.3.3. Traffic Filtering (observation) Details 1763 NA 1765 7.3.4. Sampling Distribution 1767 NA 1769 7.3.5. Run-time Parameters and Data Format 1771 Run-time Parameters are input factors that must be determined, 1772 configured into the measurement system, and reported with the results 1773 for the context to be complete. 1775 1777 Src the IP address of the host in the Src Role (format ipv4-address- 1778 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1779 see Section 4 of [RFC6991]) 1781 Dst the IP address of the host in the Dst Role (format ipv4-address- 1782 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1783 see section 4 of [RFC6991]) 1785 T0 a time, the start of a measurement interval, (format "date-and- 1786 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1787 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1788 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1789 and Tf is to be interpreted as the Duration of the measurement 1790 interval. The start time is controlled through other means. 1792 Tf a time, the end of a measurement interval, (format "date-and-time" 1793 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1794 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1795 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1796 Tf is interpreted as the Duration of the measurement interval. 1798 7.3.6. Roles 1800 1802 Src launches each packet and waits for return transmissions from 1803 Dst. This is the TWAMP Session-Sender. 1805 Dst waits for each packet from Src and sends a return packet to Src. 1806 This is the TWAMP Session-Reflector. 1808 7.4. Output 1810 This category specifies all details of the Output of measurements 1811 using the metric. 1813 7.4.1. Type 1815 1817 See subsection titles below for Types. 1819 7.4.2. Reference Definition 1821 1823 For all output types --- 1825 T0 the start of a measurement interval, (format "date-and-time" as 1826 specified in Section 5.6 of [RFC3339], see also Section 3 of 1827 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1828 [RFC2330]. 1830 Tf the end of a measurement interval, (format "date-and-time" as 1831 specified in Section 5.6 of [RFC3339], see also Section 3 of 1832 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1833 [RFC2330]. 1835 For each , one of the following sub-sections apply: 1837 7.4.2.1. Percentile95 1839 The 95th percentile SHALL be calculated using the conditional 1840 distribution of all packets with a finite value of One-way delay 1841 (undefined delays are excluded), a single value as follows: 1843 See section 4.1 of [RFC3393] for details on the conditional 1844 distribution to exclude undefined values of delay, and Section 5 of 1845 [RFC6703] for background on this analysis choice. 1847 See section 4.3 of [RFC3393] for details on the percentile statistic 1848 (where Round-trip delay should be substituted for "ipdv"). 1850 The percentile = 95, meaning that the reported delay, "95Percentile", 1851 is the smallest value of one-way delay for which the Empirical 1852 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1853 one-way delay values in the conditional distribution. See section 1854 11.3 of [RFC2330] for the definition of the percentile statistic 1855 using the EDF. 1857 95Percentile The time value of the result is expressed in units of 1858 seconds, as a positive value of type decimal64 with fraction 1859 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1860 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1861 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1863 7.4.2.2. Mean 1865 The mean SHALL be calculated using the conditional distribution of 1866 all packets with a finite value of One-way delay (undefined delays 1867 are excluded), a single value as follows: 1869 See section 4.1 of [RFC3393] for details on the conditional 1870 distribution to exclude undefined values of delay, and Section 5 of 1871 [RFC6703] for background on this analysis choice. 1873 See section 4.2.2 of [RFC6049] for details on calculating this 1874 statistic, and 4.2.3 of [RFC6049]. 1876 Mean The time value of the result is expressed in units of seconds, 1877 as a positive value of type decimal64 with fraction digits = 9 1878 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1879 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1880 NTP timestamp as per section 6 of RFC [RFC5905] 1882 7.4.2.3. Min 1884 The minimum SHALL be calculated using the conditional distribution of 1885 all packets with a finite value of One-way delay (undefined delays 1886 are excluded), a single value as follows: 1888 See section 4.1 of [RFC3393] for details on the conditional 1889 distribution to exclude undefined values of delay, and Section 5 of 1890 [RFC6703] for background on this analysis choice. 1892 See section 4.3.2 of [RFC6049] for details on calculating this 1893 statistic, and 4.3.3 of [RFC6049]. 1895 Min The time value of the result is expressed in units of seconds, 1896 as a positive value of type decimal64 with fraction digits = 9 1897 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1898 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1899 NTP timestamp as per section 6 of RFC [RFC5905] 1901 7.4.2.4. Max 1903 The maximum SHALL be calculated using the conditional distribution of 1904 all packets with a finite value of One-way delay (undefined delays 1905 are excluded), a single value as follows: 1907 See section 4.1 of [RFC3393] for details on the conditional 1908 distribution to exclude undefined values of delay, and Section 5 of 1909 [RFC6703] for background on this analysis choice. 1911 See section 4.3.2 of [RFC6049] for a closely related method for 1912 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1913 as follows: 1915 Max = (FiniteDelay [j]) 1917 such that for some index, j, where 1 <= j <= N 1918 FiniteDelay[j] >= FiniteDelay[n] for all n 1920 Max The time value of the result is expressed in units of seconds, 1921 as a positive value of type decimal64 with fraction digits = 9 1922 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1923 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1924 NTP timestamp as per section 6 of RFC [RFC5905] 1926 7.4.2.5. Std_Dev 1928 The Std_Dev SHALL be calculated using the conditional distribution of 1929 all packets with a finite value of One-way delay (undefined delays 1930 are excluded), a single value as follows: 1932 See section 4.1 of [RFC3393] for details on the conditional 1933 distribution to exclude undefined values of delay, and Section 5 of 1934 [RFC6703] for background on this analysis choice. 1936 See section 4.3.2 of [RFC6049] for a closely related method for 1937 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1938 the classic calculation for standard deviation of a population. 1940 Std_Dev The time value of the result is expressed in units of 1941 seconds, as a positive value of type decimal64 with fraction 1942 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1943 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1944 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1946 7.4.3. Metric Units 1948 . 1951 The of One-way Delay is expressed in seconds. 1953 7.4.4. Calibration 1955 Section 3.7.3 of [RFC7679] provides a means to quantify the 1956 systematic and random errors of a time measurement. In-situ 1957 calibration could be enabled with an internal loopback that includes 1958 as much of the measurement system as possible, performs address 1959 manipulation as needed, and provides some form of isolation (e.g., 1960 deterministic delay) to avoid send-receive interface contention. 1961 Some portion of the random and systematic error can be characterized 1962 this way. 1964 For one-way delay measurements, the error calibration must include an 1965 assessment of the internal clock synchronization with its external 1966 reference (this internal clock is supplying timestamps for 1967 measurement). In practice, the time offsets of clocks at both the 1968 source and destination are needed to estimate the systematic error 1969 due to imperfect clock synchronization (the time offsets are 1970 smoothed, thus the random variation is not usually represented in the 1971 results). 1973 time_offset The time value of the result is expressed in units of 1974 seconds, as a signed value of type decimal64 with fraction digits 1975 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1976 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1977 NTP timestamp as per section 6 of RFC [RFC5905] 1979 When a measurement controller requests a calibration measurement, the 1980 loopback is applied and the result is output in the same format as a 1981 normal measurement with additional indication that it is a 1982 calibration result. In any measurement, the measurement function 1983 SHOULD report its current estimate of time offset as an indicator of 1984 the degree of synchronization. 1986 Both internal loopback calibration and clock synchronization can be 1987 used to estimate the *available accuracy* of the Output Metric Units. 1988 For example, repeated loopback delay measurements will reveal the 1989 portion of the Output result resolution which is the result of system 1990 noise, and thus inaccurate. 1992 7.5. Administrative items 1994 7.5.1. Status 1996 1998 7.5.2. Requestor (keep?) 2000 name or RFC, etc. 2002 7.5.3. Revision 2004 1.0 2006 7.5.4. Revision Date 2008 YYYY-MM-DD 2010 7.6. Comments and Remarks 2012 Additional (Informational) details for this entry 2014 8. UDP Periodic One-way Delay Registry Entries 2016 This section specifies five initial registry entries for the UDP 2017 Periodic One-way Delay. 2019 Note: Each Registry "Name" below specifies a single registry entry, 2020 whose output format varies according to the element of 2021 the name that specifies one form of statistical summary. 2023 IANA is asked to assign a different numeric identifiers to each of 2024 the five Metrics. All column entries beside the ID, Name, 2025 Description, and Output Reference Method categories are the same, 2026 thus this section proposes five closely-related registry entries. As 2027 a result, IANA is also asked to assign corresponding URNs and URLs to 2028 each Named Metric. 2030 8.1. Summary 2032 This category includes multiple indexes to the registry entries, the 2033 element ID and metric name. 2035 8.1.1. ID (Identifier) 2037 2040 8.1.2. Name 2042 2044 OWDelay_Active_IP-UDP-Periodic- 2045 Payload142B_RFCXXXXsecY_Seconds_ 2047 where is one of: 2049 o 95Percentile 2051 o Mean 2053 o Min 2055 o Max 2057 o StdDev 2059 8.1.3. URIs 2061 URI: Prefix urn:ietf:metrics:perf: 2063 URL: http:\\www.iana.org\ ... 2065 8.1.4. Description 2067 This metric assesses the delay of a stream of packets exchanged 2068 between two hosts (or measurement points), and reports the 2069 One-way delay for all successfully exchanged packets 2070 based on their conditional delay distribution. 2072 where is one of: 2074 o 95Percentile 2076 o Mean 2078 o Min 2080 o Max 2082 o StdDev 2084 8.2. Metric Definition 2086 This category includes columns to prompt the entry of all necessary 2087 details related to the metric definition, including the RFC reference 2088 and values of input factors, called fixed parameters. 2090 8.2.1. Reference Definition 2092 2094 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2095 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2096 7679, DOI 10.17487/RFC7679, January 2016, . 2099 [RFC7679] 2101 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2102 6049, January 2011. 2104 [RFC6049] 2106 2108 Section 3.4 of [RFC7679] provides the reference definition of the 2109 singleton (single value) One-way delay metric. Section 4.4 of 2110 [RFC7679] provides the reference definition expanded to cover a 2111 multi-value sample. Note that terms such as singleton and sample are 2112 defined in Section 11 of [RFC2330]. 2114 Only successful packet transfers with finite delay are included in 2115 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2117 8.2.2. Fixed Parameters 2119 2123 Type-P: 2125 o IPv4 header values: 2127 * DSCP: set to 0 2129 * TTL: set to 255 2131 * Protocol: Set to 17 (UDP) 2133 o IPv6 header values: 2135 * DSCP: set to 0 2137 * Hop Count: set to 255 2139 * Protocol: Set to 17 (UDP) 2141 o UDP header values: 2143 * Checksum: the checksum MUST be calculated and included in the 2144 header 2146 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2148 * Security features in use influence the number of Padding 2149 octets. 2151 * 142 octets total, including the TWAMP format 2153 Other measurement parameters: 2155 Tmax: a loss threshold waiting time with value 3.0, expressed in 2156 units of seconds, as a positive value of type decimal64 with 2157 fraction digits = 5 (see section 9.3 of [RFC6020]) and with 2158 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2159 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2161 See the Packet Stream generation category for two additional Fixed 2162 Parameters. 2164 8.3. Method of Measurement 2166 This category includes columns for references to relevant sections of 2167 the RFC(s) and any supplemental information needed to ensure an 2168 unambiguous methods for implementations. 2170 8.3.1. Reference Method 2172 2175 The methodology for this metric is defined as Type-P-One-way-Delay- 2176 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2177 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2179 The reference method distinguishes between long-delayed packets and 2180 lost packets by implementing a maximum waiting time for packet 2181 arrival. Tmax is the waiting time used as the threshold to declare a 2182 packet lost. Lost packets SHALL be designated as having undefined 2183 delay. 2185 The calculations on the one-way delay SHALL be performed on the 2186 conditional distribution, conditioned on successful packet arrival 2187 within Tmax. Also, when all packet delays are stored, the process 2188 which calculates the one-way delay value MAY enforce the Tmax 2189 threshold on stored values before calculations. See section 4.1 of 2190 [RFC3393] for details on the conditional distribution to exclude 2191 undefined values of delay, and Section 5 of [RFC6703] for background 2192 on this analysis choice. 2194 The reference method requires some way to distinguish between 2195 different packets in a stream to establish correspondence between 2196 sending times and receiving times for each successfully-arriving 2197 packet. Sequence numbers or other send-order identification MUST be 2198 retained at the Src or included with each packet to dis-ambiguate 2199 packet reordering if it occurs. 2201 Since a standard measurement protocol is employed [RFC5357], then the 2202 measurement process will determine the sequence numbers or timestamps 2203 applied to test packets after the Fixed and Runtime parameters are 2204 passed to that process. The measurement protocol dictates the format 2205 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2206 payload. 2208 8.3.2. Packet Stream Generation 2210 2212 This section gives the details of the packet traffic which is the 2213 basis for measurement. In IPPM metrics, this is called the Stream, 2214 and can easily be described by providing the list of stream 2215 parameters. 2217 Section 3 of [RFC3432] prescribes the method for generating Periodic 2218 streams using associated parameters. 2220 incT the nominal duration of inter-packet interval, first bit to 2221 first bit 2223 dT the duration of the interval for allowed sample start times 2225 T0 the actual start time of the periodic stream 2227 NOTE: an initiation process with a number of control exchanges 2228 resulting in unpredictable start times (within a time interval) may 2229 be sufficient to avoid synchronization of periodic streams, and 2230 therefore a valid replacement for selecting a start time at random 2231 from a fixed interval. 2233 These stream parameters will be specified as Run-time parameters. 2235 8.3.3. Traffic Filtering (observation) Details 2237 NA 2239 8.3.4. Sampling Distribution 2241 NA 2243 8.3.5. Run-time Parameters and Data Format 2245 Run-time Parameters are input factors that must be determined, 2246 configured into the measurement system, and reported with the results 2247 for the context to be complete. 2249 2251 Src the IP address of the host in the Src Role (format ipv4-address- 2252 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2253 see Section 4 of [RFC6991]) 2255 Dst the IP address of the host in the Dst Role (format ipv4-address- 2256 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2257 see section 4 of [RFC6991]) 2259 T0 a time, the start of a measurement interval, (format "date-and- 2260 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2261 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2262 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2263 and Tf is to be interpreted as the Duration of the measurement 2264 interval. The start time is controlled through other means. 2266 Tf a time, the end of a measurement interval, (format "date-and-time" 2267 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2268 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2269 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2270 Tf is interpreted as the Duration of the measurement interval. 2272 >>> should Periodic run-time params be fixed instead? probably yes if 2273 modeling a specific version of tests. Note in the NAME, i.e. 2274 Poisson3.3 2276 8.3.6. Roles 2278 2280 Src launches each packet and waits for return transmissions from 2281 Dst. This is the TWAMP Session-Sender. 2283 Dst waits for each packet from Src and sends a return packet to Src. 2284 This is the TWAMP Session-Reflector. 2286 8.4. Output 2288 This category specifies all details of the Output of measurements 2289 using the metric. 2291 8.4.1. Type 2293 2295 See subsection titles in Data Format for Types. 2297 8.4.2. Reference Definition 2299 2301 For all output types --- 2302 T0 the start of a measurement interval, (format "date-and-time" as 2303 specified in Section 5.6 of [RFC3339], see also Section 3 of 2304 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2305 [RFC2330]. 2307 Tf the end of a measurement interval, (format "date-and-time" as 2308 specified in Section 5.6 of [RFC3339], see also Section 3 of 2309 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2310 [RFC2330]. 2312 For each , one of the following sub-sections apply: 2314 8.4.2.1. Percentile95 2316 The 95th percentile SHALL be calculated using the conditional 2317 distribution of all packets with a finite value of One-way delay 2318 (undefined delays are excluded), a single value as follows: 2320 See section 4.1 of [RFC3393] for details on the conditional 2321 distribution to exclude undefined values of delay, and Section 5 of 2322 [RFC6703] for background on this analysis choice. 2324 See section 4.3 of [RFC3393] for details on the percentile statistic 2325 (where Round-trip delay should be substituted for "ipdv"). 2327 The percentile = 95, meaning that the reported delay, "95Percentile", 2328 is the smallest value of one-way delay for which the Empirical 2329 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2330 one-way delay values in the conditional distribution. See section 2331 11.3 of [RFC2330] for the definition of the percentile statistic 2332 using the EDF. 2334 95Percentile The time value of the result is expressed in units of 2335 seconds, as a positive value of type decimal64 with fraction 2336 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2337 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2338 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2340 8.4.2.2. Mean 2342 The mean SHALL be calculated using the conditional distribution of 2343 all packets with a finite value of One-way delay (undefined delays 2344 are excluded), a single value as follows: 2346 See section 4.1 of [RFC3393] for details on the conditional 2347 distribution to exclude undefined values of delay, and Section 5 of 2348 [RFC6703] for background on this analysis choice. 2350 See section 4.2.2 of [RFC6049] for details on calculating this 2351 statistic, and 4.2.3 of [RFC6049]. 2353 Mean The time value of the result is expressed in units of seconds, 2354 as a positive value of type decimal64 with fraction digits = 9 2355 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2356 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2357 NTP timestamp as per section 6 of RFC [RFC5905] 2359 8.4.2.3. Min 2361 The minimum SHALL be calculated using the conditional distribution of 2362 all packets with a finite value of One-way delay (undefined delays 2363 are excluded), a single value as follows: 2365 See section 4.1 of [RFC3393] for details on the conditional 2366 distribution to exclude undefined values of delay, and Section 5 of 2367 [RFC6703] for background on this analysis choice. 2369 See section 4.3.2 of [RFC6049] for details on calculating this 2370 statistic, and 4.3.3 of [RFC6049]. 2372 Min The time value of the result is expressed in units of seconds, 2373 as a positive value of type decimal64 with fraction digits = 9 2374 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2375 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2376 NTP timestamp as per section 6 of RFC [RFC5905] 2378 8.4.2.4. Max 2380 The maximum SHALL be calculated using the conditional distribution of 2381 all packets with a finite value of One-way delay (undefined delays 2382 are excluded), a single value as follows: 2384 See section 4.1 of [RFC3393] for details on the conditional 2385 distribution to exclude undefined values of delay, and Section 5 of 2386 [RFC6703] for background on this analysis choice. 2388 See section 4.3.2 of [RFC6049] for a closely related method for 2389 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2390 as follows: 2392 Max = (FiniteDelay [j]) 2394 such that for some index, j, where 1 <= j <= N 2395 FiniteDelay[j] >= FiniteDelay[n] for all n 2397 Max The time value of the result is expressed in units of seconds, 2398 as a positive value of type decimal64 with fraction digits = 9 2399 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2400 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2401 NTP timestamp as per section 6 of RFC [RFC5905] 2403 8.4.2.5. Std_Dev 2405 The Std_Dev SHALL be calculated using the conditional distribution of 2406 all packets with a finite value of One-way delay (undefined delays 2407 are excluded), a single value as follows: 2409 See section 4.1 of [RFC3393] for details on the conditional 2410 distribution to exclude undefined values of delay, and Section 5 of 2411 [RFC6703] for background on this analysis choice. 2413 See section 4.3.2 of [RFC6049] for a closely related method for 2414 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2415 the classic calculation for standard deviation of a population. 2417 Std_Dev The time value of the result is expressed in units of 2418 seconds, as a positive value of type decimal64 with fraction 2419 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2420 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2421 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2423 8.4.3. Metric Units 2425 . 2428 The of One-way Delay is expressed in seconds. 2430 8.4.4. Calibration 2432 Section 3.7.3 of [RFC7679] provides a means to quantify the 2433 systematic and random errors of a time measurement. In-situ 2434 calibration could be enabled with an internal loopback that includes 2435 as much of the measurement system as possible, performs address 2436 manipulation as needed, and provides some form of isolation (e.g., 2437 deterministic delay) to avoid send-receive interface contention. 2438 Some portion of the random and systematic error can be characterized 2439 this way. 2441 For one-way delay measurements, the error calibration must include an 2442 assessment of the internal clock synchronization with its external 2443 reference (this internal clock is supplying timestamps for 2444 measurement). In practice, the time offsets of clocks at both the 2445 source and destination are needed to estimate the systematic error 2446 due to imperfect clock synchronization (the time offsets are 2447 smoothed, thus the random variation is not usually represented in the 2448 results). 2450 time_offset The time value of the result is expressed in units of 2451 seconds, as a signed value of type decimal64 with fraction digits 2452 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2453 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2454 NTP timestamp as per section 6 of RFC [RFC5905] 2456 When a measurement controller requests a calibration measurement, the 2457 loopback is applied and the result is output in the same format as a 2458 normal measurement with additional indication that it is a 2459 calibration result. In any measurement, the measurement function 2460 SHOULD report its current estimate of time offset as an indicator of 2461 the degree of synchronization. 2463 Both internal loopback calibration and clock synchronization can be 2464 used to estimate the *available accuracy* of the Output Metric Units. 2465 For example, repeated loopback delay measurements will reveal the 2466 portion of the Output result resolution which is the result of system 2467 noise, and thus inaccurate. 2469 8.5. Administrative items 2471 8.5.1. Status 2473 2475 8.5.2. Requestor (keep?) 2477 name or RFC, etc. 2479 8.5.3. Revision 2481 1.0 2483 8.5.4. Revision Date 2485 YYYY-MM-DD 2487 8.6. Comments and Remarks 2489 Additional (Informational) details for this entry 2491 9. ver08 BLANK Registry Entry 2493 This section gives an initial registry entry for .... 2495 9.1. Summary 2497 This category includes multiple indexes to the registry entries, the 2498 element ID and metric name. 2500 9.1.1. ID (Identifier) 2502 2504 9.1.2. Name 2506 2508 9.1.3. URIs 2510 URI: Prefix urn:ietf:metrics:perf: 2512 URL: 2514 9.1.4. Description 2516 TBD. 2518 9.1.5. Reference 2520 2522 9.1.6. Change Controller 2524 2526 9.1.7. Version (of Registry Format) 2528 2530 9.2. Metric Definition 2532 This category includes columns to prompt the entry of all necessary 2533 details related to the metric definition, including the RFC reference 2534 and values of input factors, called fixed parameters. 2536 9.2.1. Reference Definition 2538 2540 2542 9.2.2. Fixed Parameters 2544 2548 9.3. Method of Measurement 2550 This category includes columns for references to relevant sections of 2551 the RFC(s) and any supplemental information needed to ensure an 2552 unambiguous methods for implementations. 2554 9.3.1. Reference Method 2556 2559 9.3.2. Packet Stream Generation 2561 2563 9.3.3. Traffic Filtering (observation) Details 2565 . 2569 9.3.4. Sampling Distribution 2571 2574 9.3.5. Run-time Parameters and Data Format 2576 . 2578 9.3.6. Roles 2580 2582 9.4. Output 2584 This category specifies all details of the Output of measurements 2585 using the metric. 2587 9.4.1. Type 2589 2591 9.4.2. Reference Definition 2593 2595 9.4.3. Metric Units 2597 . 2600 9.4.4. Calibration 2602 2606 9.5. Administrative items 2608 9.5.1. Status 2610 2612 9.5.2. Requestor 2614 2616 9.5.3. Revision 2618 1.0 2620 9.5.4. Revision Date 2622 YYYY-MM-DD 2624 9.6. Comments and Remarks 2626 Additional (Informational) details for this entry 2628 10. Example RTCP-XR Registry Entry 2630 This section is MAY BE DELETED or adapted before submission. 2632 This section gives an example registry entry for the end-point metric 2633 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 2634 reporting. 2636 10.1. Registry Indexes 2638 This category includes multiple indexes to the registry entries, the 2639 element ID and metric name. 2641 10.1.1. Identifier 2643 An integer having enough digits to uniquely identify each entry in 2644 the Registry. 2646 10.1.2. Name 2648 A metric naming convention is TBD. 2650 10.1.3. URI 2652 Prefix urn:ietf:metrics:param: 2654 10.1.4. Status 2656 current 2658 10.1.5. Requestor 2660 Alcelip Mornuley 2662 10.1.6. Revision 2664 1.0 2666 10.1.7. Revision Date 2668 2014-07-04 2670 10.1.8. Description 2672 TBD. 2674 10.1.9. Reference Specification(s) 2676 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 2678 10.2. Metric Definition 2680 This category includes columns to prompt the entry of all necessary 2681 details related to the metric definition, including the RFC reference 2682 and values of input factors, called fixed parameters. Section 3.2 of 2683 [RFC7003] provides the reference information for this category. 2685 10.2.1. Reference Definition 2687 Packets Discarded in Bursts: 2689 The total number of packets discarded during discard bursts. The 2690 measured value is unsigned value. If the measured value exceeds 2691 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 2692 range measurement. If the measurement is unavailable, the value 2693 0xFFFFFF MUST be reported. 2695 10.2.2. Fixed Parameters 2697 Fixed Parameters are input factors that must be determined and 2698 embedded in the measurement system for use when needed. The values 2699 of these parameters is specified in the Registry. 2701 Threshold: 8 bits, set to value = 3 packets. 2703 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 2704 successive packets that must not be discarded prior to and following 2705 a discard packet in order for this discarded packet to be regarded as 2706 part of a gap. Note that the Threshold is set in accordance with the 2707 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 2709 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 2711 This field is used to indicate whether the burst/gap discard metrics 2712 are Sampled, Interval, or Cumulative metrics [RFC6792]: 2714 I=10: Interval Duration - the reported value applies to the most 2715 recent measurement interval duration between successive metrics 2716 reports. 2718 I=11: Cumulative Duration - the reported value applies to the 2719 accumulation period characteristic of cumulative measurements. 2721 Senders MUST NOT use the values I=00 or I=01. 2723 10.3. Method of Measurement 2725 This category includes columns for references to relevant sections of 2726 the RFC(s) and any supplemental information needed to ensure an 2727 unambiguous methods for implementations. For the Burst/Gap Discard 2728 Metric, it appears that the only guidance on methods of measurement 2729 is in Section 3.0 of [RFC7003] and its supporting references. 2730 Relevant information is repeated below, although there appears to be 2731 no section titled "Method of Measurement" in [RFC7003]. 2733 10.3.1. Reference Method 2735 Metrics in this block report on burst/gap discard in the stream 2736 arriving at the RTP system. Measurements of these metrics are made 2737 at the receiving end of the RTP stream. Instances of this metrics 2738 block use the synchronization source (SSRC) to refer to the separate 2739 auxiliary Measurement Information Block [RFC6776], which describes 2740 measurement periods in use (see [RFC6776], Section 4.2). 2742 This metrics block relies on the measurement period in the 2743 Measurement Information Block indicating the span of the report. 2744 Senders MUST send this block in the same compound RTCP packet as the 2745 Measurement Information Block. Receivers MUST verify that the 2746 measurement period is received in the same compound RTCP packet as 2747 this metrics block. If not, this metrics block MUST be discarded. 2749 10.3.2. Stream Type and Stream Parameters 2751 Since RTCP-XR Measurements are conducted on live RTP traffic, the 2752 complete description of the stream is contained in SDP messages that 2753 proceed the establishment of a compatible stream between two or more 2754 communicating hosts. See Run-time Parameters, below. 2756 10.3.3. Output Type and Data Format 2758 The output type defines the type of result that the metric produces. 2760 o Value: Packets Discarded in Bursts 2762 o Data Format: 24 bits 2764 o Reference: Section 3.2 of [RFC7003] 2766 10.3.4. Metric Units 2768 The measured results are apparently expressed in packets, although 2769 there is no section of [RFC7003] titled "Metric Units". 2771 10.3.5. Run-time Parameters and Data Format 2773 Run-Time Parameters are input factors that must be determined, 2774 configured into the measurement system, and reported with the results 2775 for the context to be complete. However, the values of these 2776 parameters is not specified in the Registry, rather these parameters 2777 are listed as an aid to the measurement system implementor or user 2778 (they must be left as variables, and supplied on execution). 2780 The Data Format of each Run-time Parameter SHALL be specified in this 2781 column, to simplify the control and implementation of measurement 2782 devices. 2784 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 2786 SDP Parameters: As defined in [RFC4566] 2788 Session description v= (protocol version number, currently only 0) 2790 o= (originator and session identifier : username, id, version number, 2791 network address) 2793 s= (session name : mandatory with at least one UTF-8-encoded 2794 character) 2796 i=* (session title or short information) u=* (URI of description) 2798 e=* (zero or more email address with optional name of contacts) 2800 p=* (zero or more phone number with optional name of contacts) 2802 c=* (connection information--not required if included in all media) 2804 b=* (zero or more bandwidth information lines) One or more Time 2805 descriptions ("t=" and "r=" lines; see below) 2807 z=* (time zone adjustments) 2809 k=* (encryption key) 2811 a=* (zero or more session attribute lines) 2813 Zero or more Media descriptions (each one starting by an "m=" line; 2814 see below) 2816 m= (media name and transport address) 2818 i=* (media title or information field) 2819 c=* (connection information -- optional if included at session level) 2821 b=* (zero or more bandwidth information lines) 2823 k=* (encryption key) 2825 a=* (zero or more media attribute lines -- overriding the Session 2826 attribute lines) 2828 An example Run-time SDP description follows: 2830 v=0 2832 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 2834 s=SDP Seminar i=A Seminar on the session description protocol 2836 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 2837 Doe) 2839 c=IN IP4 233.252.0.12/127 2841 t=2873397496 2873404696 2843 a=recvonly 2845 m=audio 49170 RTP/AVP 0 2847 m=video 51372 RTP/AVP 99 2849 a=rtpmap:99 h263-1998/90000 2851 10.4. Comments and Remarks 2853 TBD. 2855 11. Revision History 2857 This section may be removed for publication. It contains partial 2858 information on updtes. 2860 This draft replaced draft-mornuley-ippm-initial-registry. 2862 In version 02, Section 4 has been edited to reflect recent discussion 2863 on the ippm-list: * Removed the combination or "Raw" and left 95th 2864 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 2865 use bullet lists and other indenting formats. * Payload format for 2866 measurement has been removed. * Explanation of Conditional delay 2867 distribution. 2869 Version 03 addressed Phil Eardley's comments and suggestions in 2870 sections 1-4. and resolved the definition of Percentiles. 2872 Version 04 * All section 4 parameters reference YANG types for 2873 alternate data formats. * Discussion has concluded that usecase(s) 2874 for machine parse-able registry columns are not needed. 2876 12. Security Considerations 2878 These registry entries represent no known security implications for 2879 Internet Security. Each referenced Metric contains a Security 2880 Considerations section. 2882 13. IANA Considerations 2884 IANA is requested to populate The Performance Metric Registry defined 2885 in [I-D.ietf-ippm-metric-registry] with the values defined above. 2887 See the IANA Considerations section of 2888 [I-D.ietf-ippm-metric-registry] for additional requests and 2889 considerations. 2891 14. Acknowledgements 2893 The authors thank Brian Trammell for suggesting the term "Run-time 2894 Parameters", which led to the distinction between run-time and fixed 2895 parameters implemented in this memo, for identifying the IPFIX metric 2896 with Flow Key as an example, and for many other productive 2897 suggestions. Thanks to Peter Koch, who provided several useful 2898 suggestions for disambiguating successive DNS Queries in the DNS 2899 Response time metric. 2901 The authors also acknowledge the constructive reviews and helpful 2902 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 2903 participants in the LMAP working group. Thanks to Michelle Cotton 2904 for her early IANA review, and to Amanda Barber for answering 2905 questions related to the presentation of the registry and 2906 accessibility of the complete template via URL. 2908 15. References 2909 15.1. Normative References 2911 [I-D.ietf-ippm-metric-registry] 2912 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 2913 "Registry for Performance Metrics", Internet Draft (work 2914 in progress) draft-ietf-ippm-metric-registry, 2014. 2916 [RFC1035] Mockapetris, P., "Domain names - implementation and 2917 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2918 November 1987, . 2920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2921 Requirement Levels", BCP 14, RFC 2119, 2922 DOI 10.17487/RFC2119, March 1997, 2923 . 2925 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2926 "Framework for IP Performance Metrics", RFC 2330, 2927 DOI 10.17487/RFC2330, May 1998, 2928 . 2930 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2931 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 2932 September 1999, . 2934 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2935 Packet Loss Metric for IPPM", RFC 2680, 2936 DOI 10.17487/RFC2680, September 1999, 2937 . 2939 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2940 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 2941 September 1999, . 2943 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2944 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2945 . 2947 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2948 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2949 DOI 10.17487/RFC3393, November 2002, 2950 . 2952 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2953 performance measurement with periodic streams", RFC 3432, 2954 DOI 10.17487/RFC3432, November 2002, 2955 . 2957 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2958 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 2959 DOI 10.17487/RFC4737, November 2006, 2960 . 2962 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2963 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2964 RFC 5357, DOI 10.17487/RFC5357, October 2008, 2965 . 2967 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2968 "Network Time Protocol Version 4: Protocol and Algorithms 2969 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2970 . 2972 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2973 the Network Configuration Protocol (NETCONF)", RFC 6020, 2974 DOI 10.17487/RFC6020, October 2010, 2975 . 2977 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 2978 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 2979 . 2981 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 2982 DOI 10.17487/RFC6673, August 2012, 2983 . 2985 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2986 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2987 . 2989 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 2990 Ed., "A One-Way Delay Metric for IP Performance Metrics 2991 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2992 2016, . 2994 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 2995 Ed., "A One-Way Loss Metric for IP Performance Metrics 2996 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2997 2016, . 2999 15.2. Informative References 3001 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 3002 Distributions", March 2000. 3004 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 3005 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 3006 July 1991, . 3008 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 3009 "RTP Control Protocol Extended Reports (RTCP XR)", 3010 RFC 3611, DOI 10.17487/RFC3611, November 2003, 3011 . 3013 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 3014 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 3015 2005, . 3017 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3018 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 3019 July 2006, . 3021 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 3022 Flow Information Export (IPFIX) Applicability", RFC 5472, 3023 DOI 10.17487/RFC5472, March 2009, 3024 . 3026 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 3027 Carle, "Information Model for Packet Sampling Exports", 3028 RFC 5477, DOI 10.17487/RFC5477, March 2009, 3029 . 3031 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 3032 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 3033 March 2009, . 3035 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 3036 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 3037 DOI 10.17487/RFC6248, April 2011, 3038 . 3040 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 3041 Performance Metric Development", BCP 170, RFC 6390, 3042 DOI 10.17487/RFC6390, October 2011, 3043 . 3045 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 3046 IP Network Performance Metrics: Different Points of View", 3047 RFC 6703, DOI 10.17487/RFC6703, August 2012, 3048 . 3050 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 3051 Reporting Using a Source Description (SDES) Item and an 3052 RTCP Extended Report (XR) Block", RFC 6776, 3053 DOI 10.17487/RFC6776, October 2012, 3054 . 3056 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 3057 of the RTP Monitoring Framework", RFC 6792, 3058 DOI 10.17487/RFC6792, November 2012, 3059 . 3061 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 3062 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 3063 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 3064 September 2013, . 3066 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 3067 Aitken, P., and A. Akhter, "A Framework for Large-Scale 3068 Measurement of Broadband Performance (LMAP)", RFC 7594, 3069 DOI 10.17487/RFC7594, September 2015, 3070 . 3072 Authors' Addresses 3074 Al Morton 3075 AT&T Labs 3076 200 Laurel Avenue South 3077 Middletown,, NJ 07748 3078 USA 3080 Phone: +1 732 420 1571 3081 Fax: +1 732 368 1192 3082 Email: acmorton@att.com 3083 URI: http://home.comcast.net/~acmacm/ 3085 Marcelo Bagnulo 3086 Universidad Carlos III de Madrid 3087 Av. Universidad 30 3088 Leganes, Madrid 28911 3089 SPAIN 3091 Phone: 34 91 6249500 3092 Email: marcelo@it.uc3m.es 3093 URI: http://www.it.uc3m.es 3094 Philip Eardley 3095 BT 3096 Adastral Park, Martlesham Heath 3097 Ipswich 3098 ENGLAND 3100 Email: philip.eardley@bt.com 3102 Kevin D'Souza 3103 AT&T Labs 3104 200 Laurel Avenue South 3105 Middletown,, NJ 07748 3106 USA 3108 Phone: +1 732 420 xxxx 3109 Email: kld@att.com