idnits 2.17.1 draft-ietf-ippm-initial-registry-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 590 has weird spacing: '... Src the IP...' == Line 594 has weird spacing: '... Dst the IP...' == Line 613 has weird spacing: '... Src launch...' == Line 616 has weird spacing: '... Dst waits ...' == Line 657 has weird spacing: '...talPkts the c...' == (23 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 11, 2019) is 1686 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) ** Downref: Normative reference to an Informational RFC: RFC 2330 -- Possible downref: Non-RFC (?) normative reference: ref. 'Strowes' -- Possible downref: Non-RFC (?) normative reference: ref. 'Trammell-14' Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 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: March 14, 2020 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 September 11, 2019 12 Initial Performance Metrics Registry Entries 13 draft-ietf-ippm-initial-registry-12 15 Abstract 17 This memo defines the set of Initial Entries for the IANA Performance 18 Metrics Registry. The set includes, UDP Round-trip Latency and Loss, 19 Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson 20 One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP 21 Round-trip Latency and Loss, and TCP round-trip Latency and Loss. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14[RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 14, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 68 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 69 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 71 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 75 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 76 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 77 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 78 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 79 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 80 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 81 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 82 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 83 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 84 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 85 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 89 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 90 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 91 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 92 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 16 94 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 95 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 97 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 98 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 99 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 101 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 104 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 105 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 106 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 107 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 108 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 109 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 18 110 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 111 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 112 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 113 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 114 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 115 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 116 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 117 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 118 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21 119 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 21 120 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 121 5.5. Administrative items . . . . . . . . . . . . . . . . . . 22 122 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 22 123 5.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 23 124 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 125 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 126 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 127 6. DNS Response Latency and Loss Registry Entries . . . . . . . 23 128 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 129 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 23 130 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 131 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 132 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 133 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24 134 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24 135 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 136 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 24 137 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 138 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 139 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 140 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28 141 6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 142 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 143 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 144 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 146 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 147 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 30 148 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 30 149 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 150 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31 151 6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 152 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 153 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 32 154 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 155 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 156 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 157 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32 158 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 159 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 32 160 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 161 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33 162 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 163 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34 164 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34 165 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 166 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 35 167 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 168 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36 169 7.3.3. Traffic Filtering (observation) Details . . . . . . . 37 170 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37 171 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 172 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38 173 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38 174 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38 175 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38 176 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41 177 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41 178 7.5. Administrative items . . . . . . . . . . . . . . . . . . 42 179 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42 180 7.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 42 181 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 182 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 42 183 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 42 184 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 42 185 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 186 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 187 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 188 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 43 189 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 43 190 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44 191 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44 192 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45 193 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46 194 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46 195 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47 196 8.3.3. Traffic Filtering (observation) Details . . . . . . . 47 197 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 47 198 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 199 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 200 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 48 201 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 202 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 203 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 51 204 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 205 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 206 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 207 8.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 53 208 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 209 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 210 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53 211 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 53 212 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 53 213 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 53 214 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 215 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54 216 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54 217 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 54 218 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 54 219 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55 220 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 221 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 222 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 56 223 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 56 224 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 57 225 9.3.3. Traffic Filtering (observation) Details . . . . . . . 58 226 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 58 227 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 58 228 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 229 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 59 230 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 59 231 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 59 232 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 61 233 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 61 234 9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 235 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 236 9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 62 237 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 62 238 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 62 239 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 62 240 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 62 241 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63 242 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 243 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 244 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 63 245 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 63 246 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 247 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 248 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 64 249 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 64 250 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 66 251 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 67 252 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 67 253 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 69 254 10.3.3. Traffic Filtering (observation) Details . . . . . . 69 255 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 69 256 10.3.5. Run-time Parameters and Data Format . . . . . . . . 69 257 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 70 258 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 70 259 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 70 260 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 70 261 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 72 262 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 72 263 10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 264 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 265 10.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 73 266 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 73 267 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 73 268 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 73 269 11. Security Considerations . . . . . . . . . . . . . . . . . . . 73 270 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 271 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 272 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 273 14.1. Normative References . . . . . . . . . . . . . . . . . . 74 274 14.2. Informative References . . . . . . . . . . . . . . . . . 76 275 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 277 1. Introduction 279 This memo proposes an initial set of entries for the Performance 280 Metrics Registry. It uses terms and definitions from the IPPM 281 literature, primarily [RFC2330]. 283 Although there are several standard templates for organizing 284 specifications of performance metrics (see [RFC7679] for an example 285 of the traditional IPPM template, based to large extent on the 286 Benchmarking Methodology Working Group's traditional template in 287 [RFC1242], and see [RFC6390] for a similar template), none of these 288 templates were intended to become the basis for the columns of an 289 IETF-wide registry of metrics. While examining aspects of metric 290 specifications which need to be registered, it became clear that none 291 of the existing metric templates fully satisfies the particular needs 292 of a registry. 294 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 295 for a Performance Metrics Registry. Section 5 of 296 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 297 requesting registration of a Metric, that is the creation of entry(s) 298 in the Performance Metrics Registry: "In essence, there needs to be 299 evidence that a candidate Registered Performance Metric has 300 significant industry interest, or has seen deployment, and there is 301 agreement that the candidate Registered Performance Metric serves its 302 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 303 also requires that new entries are administered by IANA through 304 Expert Review or IETF Standards action, which will ensure that the 305 metrics are tightly defined. 307 2. Scope 309 This document defines the initial set of Performance Metrics Registry 310 entries, for which IETF approval (following development in the IP 311 Performance Metrics (IPPM) Working Group) will satisfy the 312 requirement for Expert Review. Most are Active Performance Metrics, 313 which are based on RFCs prepared in the IPPM working group of the 314 IETF, according to their framework [RFC2330] and its updates. 316 3. Registry Categories and Columns 318 This memo uses the terminology defined in 319 [I-D.ietf-ippm-metric-registry]. 321 This section provides the categories and columns of the registry, for 322 easy reference. An entry (row) therefore gives a complete 323 description of a Registered Metric. 325 Registry Categories and Columns, shown as 326 Category 327 ------------------ 328 Column | Column | 330 Summary 331 ------------------------------------------------------------------------ 332 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 334 Metric Definition 335 ----------------------------------------- 336 Reference Definition | Fixed Parameters | 338 Method of Measurement 339 --------------------------------------------------------------------- 340 Reference | Packet | Traffic | Sampling | Run-time | Role | 341 Method | Stream | Filter | Distribution | Parameters | | 342 | Generation | 343 Output 344 ----------------------------------------- 345 Type | Reference | Units | Calibration | 346 | Definition | | | 348 Administrative Information 349 ---------------------------------- 350 Status |Request | Rev | Rev.Date | 352 Comments and Remarks 353 -------------------- 355 4. UDP Round-trip Latency and Loss Registry Entries 357 This section specifies an initial registry entry for the UDP Round- 358 trip Latency, and another entry for UDP Round-trip Loss Ratio. 360 Note: Each Registry entry only produces a "raw" output or a 361 statistical summary. To describe both "raw" and one or more 362 statistics efficiently, the Identifier, Name, and Output Categories 363 can be split and a single section can specify two or more closely- 364 related metrics. This section specifies two Registry entries with 365 many common columns. See Section 7 for an example specifying 366 multiple Registry entries with many common columns. 368 All column entries beside the ID, Name, Description, and Output 369 Reference Method categories are the same, thus this section proposes 370 two closely-related registry entries. As a result, IANA is also 371 asked to assign a corresponding URL to each Named Metric. 373 4.1. Summary 375 This category includes multiple indexes to the registry entry: the 376 element ID and metric name. 378 4.1.1. ID (Identifier) 380 IANA is asked to assign different numeric identifiers to each of the 381 two Named Metrics. 383 4.1.2. Name 385 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile 387 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio 389 4.1.3. URIs 391 URL: http:/// 393 4.1.4. Description 395 RTDelay: This metric assesses the delay of a stream of packets 396 exchanged between two hosts (which are the two measurement points), 397 and the Output is the Round-trip delay for all successfully exchanged 398 packets expressed as the 95th percentile of their conditional delay 399 distribution. 401 RTLoss: This metric assesses the loss ratio of a stream of packets 402 exchanged between two hosts (which are the two measurement points), 403 and the Output is the Round-trip loss ratio for all successfully 404 exchanged packets expressed as a percentage. 406 4.1.5. Change Controller 408 IETF 410 4.1.6. Version (of Registry Format) 412 1.0 414 4.2. Metric Definition 416 This category includes columns to prompt the entry of all necessary 417 details related to the metric definition, including the RFC reference 418 and values of input factors, called fixed parameters. 420 4.2.1. Reference Definition 422 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 423 Metric for IPPM", RFC 2681, September 1999. 425 [RFC2681] 427 Section 2.4 of [RFC2681] provides the reference definition of the 428 singleton (single value) Round-trip delay metric. Section 3.4 of 429 [RFC2681] provides the reference definition expanded to cover a 430 multi-singleton sample. Note that terms such as singleton and sample 431 are defined in Section 11 of [RFC2330]. 433 Note that although the [RFC2681] definition of "Round-trip-Delay 434 between Src and Dst" is directionally ambiguous in the text, this 435 metric tightens the definition further to recognize that the host in 436 the "Src" role will send the first packet to "Dst", and ultimately 437 receive the corresponding return packet from "Dst" (when neither are 438 lost). 440 Finally, note that the variable "dT" is used in [RFC2681] to refer to 441 the value of Round-trip delay in metric definitions and methods. The 442 variable "dT" has been re-used in other IPPM literature to refer to 443 different quantities, and cannot be used as a global variable name. 445 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 447 [RFC6673] 449 Both delay and loss metrics employ a maximum waiting time for 450 received packets, so the count of lost packets to total packets sent 451 is the basis for the loss ratio calculation as per Section 6.1 of 452 [RFC6673]. 454 4.2.2. Fixed Parameters 456 Type-P as defined in Section 13 of [RFC2330]: 458 o IPv4 header values: 460 * DSCP: set to 0 462 * TTL: set to 255 464 * Protocol: Set to 17 (UDP) 466 o IPv6 header values: 468 * DSCP: set to 0 470 * Hop Count: set to 255 472 * Protocol: Set to 17 (UDP) 474 o UDP header values: 476 * Checksum: the checksum MUST be calculated and included in the 477 header 479 o UDP Payload 481 * total of 100 bytes 483 Other measurement parameters: 485 o Tmax: a loss threshold waiting time 487 * 3.0, expressed in units of seconds, as a positive value of type 488 decimal64 with fraction digits = 4 (see section 9.3 of 489 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 490 lossless conversion to/from the 32-bit NTP timestamp as per 491 section 6 of [RFC5905]. 493 4.3. Method of Measurement 495 This category includes columns for references to relevant sections of 496 the RFC(s) and any supplemental information needed to ensure an 497 unambiguous methods for implementations. 499 4.3.1. Reference Method 501 The methodology for this metric is defined as Type-P-Round-trip- 502 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 503 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 504 Fixed Parameters. However, the Periodic stream will be generated 505 according to [RFC3432]. 507 The reference method distinguishes between long-delayed packets and 508 lost packets by implementing a maximum waiting time for packet 509 arrival. Tmax is the waiting time used as the threshold to declare a 510 packet lost. Lost packets SHALL be designated as having undefined 511 delay, and counted for the RTLoss metric. 513 The calculations on the delay (RTT) SHALL be performed on the 514 conditional distribution, conditioned on successful packet arrival 515 within Tmax. Also, when all packet delays are stored, the process 516 which calculates the RTT value MAY enforce the Tmax threshold on 517 stored values before calculations. See section 4.1 of [RFC3393] for 518 details on the conditional distribution to exclude undefined values 519 of delay, and Section 5 of [RFC6703] for background on this analysis 520 choice. 522 The reference method requires some way to distinguish between 523 different packets in a stream to establish correspondence between 524 sending times and receiving times for each successfully-arriving 525 packet. Sequence numbers or other send-order identification MUST be 526 retained at the Src or included with each packet to disambiguate 527 packet reordering if it occurs. 529 If a standard measurement protocol is employed, then the measurement 530 process will determine the sequence numbers or timestamps applied to 531 test packets after the Fixed and Runtime parameters are passed to 532 that process. The chosen measurement protocol will dictate the 533 format of sequence numbers and time-stamps, if they are conveyed in 534 the packet payload. 536 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 537 instruction to "send a Type-P packet back to the Src as quickly as 538 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 539 [RFC6673] presents additional requirements which MUST be included in 540 the method of measurement for this metric. 542 4.3.2. Packet Stream Generation 544 This section gives the details of the packet traffic which is the 545 basis for measurement. In IPPM metrics, this is called the Stream, 546 and can easily be described by providing the list of stream 547 parameters. 549 Section 3 of [RFC3432] prescribes the method for generating Periodic 550 streams using associated parameters. 552 incT the nominal duration of inter-packet interval, first bit to 553 first bit, with value 0.0200, expressed in units of seconds, as a 554 positive value of type decimal64 with fraction digits = 4 (see 555 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 556 (0.1 ms). 558 dT the duration of the interval for allowed sample start times, with 559 value 1.0, expressed in units of seconds, as a positive value of 560 type decimal64 with fraction digits = 4 (see section 9.3 of 561 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 563 NOTE: an initiation process with a number of control exchanges 564 resulting in unpredictable start times (within a time interval) may 565 be sufficient to avoid synchronization of periodic streams, and 566 therefore a valid replacement for selecting a start time at random 567 from a fixed interval. 569 The T0 parameter will be reported as a measured parameter. 570 Parameters incT and dT are Fixed Parameters. 572 4.3.3. Traffic Filtering (observation) Details 574 The measured results based on a filtered version of the packets 575 observed, and this section provides the filter details (when 576 present). 578 NA 580 4.3.4. Sampling Distribution 582 NA 584 4.3.5. Run-time Parameters and Data Format 586 Run-time Parameters are input factors that must be determined, 587 configured into the measurement system, and reported with the results 588 for the context to be complete. 590 Src the IP address of the host in the Src Role (format ipv4-address- 591 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 592 see Section 4 of [RFC6991]) 594 Dst the IP address of the host in the Dst Role (format ipv4-address- 595 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 596 see section 4 of [RFC6991]) 598 T0 a time, the start of a measurement interval, (format "date-and- 599 time" as specified in Section 5.6 of [RFC3339], see also Section 3 600 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 601 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 602 and Tf is to be interpreted as the Duration of the measurement 603 interval. The start time is controlled through other means. 605 Tf a time, the end of a measurement interval, (format "date-and-time" 606 as specified in Section 5.6 of [RFC3339], see also Section 3 of 607 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 608 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 609 Tf is interpreted as the Duration of the measurement interval. 611 4.3.6. Roles 613 Src launches each packet and waits for return transmissions from 614 Dst. 616 Dst waits for each packet from Src and sends a return packet to Src. 618 4.4. Output 620 This category specifies all details of the Output of measurements 621 using the metric. 623 4.4.1. Type 625 Percentile -- for the conditional distribution of all packets with a 626 valid value of Round-trip delay (undefined delays are excluded), a 627 single value corresponding to the 95th percentile, as follows: 629 See section 4.1 of [RFC3393] for details on the conditional 630 distribution to exclude undefined values of delay, and Section 5 of 631 [RFC6703] for background on this analysis choice. 633 The percentile = 95, meaning that the reported delay, "95Percentile", 634 is the smallest value of Round-trip delay for which the Empirical 635 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 636 Round-trip delay values in the conditional distribution. See section 637 11.3 of [RFC2330] for the definition of the percentile statistic 638 using the EDF. 640 LossRatio -- the count of lost packets to total packets sent is the 641 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 643 4.4.2. Reference Definition 645 For all outputs --- 647 T0 the start of a measurement interval, (format "date-and-time" as 648 specified in Section 5.6 of [RFC3339], see also Section 3 of 649 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 650 [RFC2330]. 652 Tf the end of a measurement interval, (format "date-and-time" as 653 specified in Section 5.6 of [RFC3339], see also Section 3 of 654 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 655 [RFC2330]. 657 TotalPkts the count of packets sent by the Src to Dst during the 658 measurement interval. 660 For 662 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile: 664 95Percentile The time value of the result is expressed in units of 665 seconds, as a positive value of type decimal64 with fraction 666 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 667 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 668 the 64-bit NTP timestamp as 670 For 672 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio: 674 Percentile The numeric value of the result is expressed in units of 675 lost packets to total packets times 100%, as a positive value of 676 type decimal64 with fraction digits = 9 (see section 9.3 of 677 [RFC6020]) with resolution of 0.0000000001. 679 4.4.3. Metric Units 681 The 95th Percentile of Round-trip Delay is expressed in seconds. 683 The Round-trip Loss Ratio is expressed as a percentage of lost 684 packets to total packets sent. 686 4.4.4. Calibration 688 Section 3.7.3 of [RFC7679] provides a means to quantify the 689 systematic and random errors of a time measurement. In-situ 690 calibration could be enabled with an internal loopback at the Source 691 host that includes as much of the measurement system as possible, 692 performs address manipulation as needed, and provides some form of 693 isolation (e.g., deterministic delay) to avoid send-receive interface 694 contention. Some portion of the random and systematic error can be 695 characterized this way. 697 When a measurement controller requests a calibration measurement, the 698 loopback is applied and the result is output in the same format as a 699 normal measurement with additional indication that it is a 700 calibration result. 702 Both internal loopback calibration and clock synchronization can be 703 used to estimate the *available accuracy* of the Output Metric Units. 704 For example, repeated loopback delay measurements will reveal the 705 portion of the Output result resolution which is the result of system 706 noise, and thus inaccurate. 708 4.5. Administrative items 710 4.5.1. Status 712 Current 714 4.5.2. Requestor 716 This RFC numner 718 4.5.3. Revision 720 1.0 722 4.5.4. Revision Date 724 YYYY-MM-DD 726 4.6. Comments and Remarks 728 None. 730 5. Packet Delay Variation Registry Entry 732 This section gives an initial registry entry for a Packet Delay 733 Variation metric. 735 Note: If each Registry entry should only produce a "raw" output or a 736 statistical summary, then the "Output" Category can be split and this 737 section can become two closely-related metrics. 739 5.1. Summary 741 This category includes multiple indexes to the registry entries, the 742 element ID and metric name. 744 5.1.1. ID (Identifier) 746 748 5.1.2. Name 750 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsec5_Seconds_95Percentile 752 5.1.3. URIs 754 URL: http:/// 756 5.1.4. Description 758 An assessment of packet delay variation with respect to the minimum 759 delay observed on the periodic stream, and the Output is expressed as 760 the 95th percentile of the packet delay variation distribution. 762 5.1.5. Change Controller 764 IETF 766 5.1.6. Version (of Registry Format) 768 1.0 770 5.2. Metric Definition 772 This category includes columns to prompt the entry of all necessary 773 details related to the metric definition, including the RFC reference 774 and values of input factors, called fixed parameters. 776 5.2.1. Reference Definition 778 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 779 Performance Metrics", RFC 2330, May 1998. [RFC2330] 781 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 782 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 783 [RFC3393] 785 Morton, A. and B. Claise, "Packet Delay Variation Applicability 786 Statement", RFC 5481, March 2009. [RFC5481] 788 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 789 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 790 June 2010.[RFC5905] 792 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 793 measured are referred to by the variable name "ddT" (applicable to 794 all forms of delay variation). However, this metric entry specifies 795 the PDV form defined in section 4.2 of [RFC5481], where the singleton 796 PDV for packet i is referred to by the variable name "PDV(i)". 798 5.2.2. Fixed Parameters 800 o IPv4 header values: 802 * DSCP: set to 0 804 * TTL: set to 255 806 * Protocol: Set to 17 (UDP) 808 o IPv6 header values: 810 * DSCP: set to 0 812 * Hop Count: set to 255 814 * Protocol: Set to 17 (UDP) 816 o UDP header values: 818 * Checksum: the checksum MUST be calculated and included in the 819 header 821 o UDP Payload 823 * total of 200 bytes 825 Other measurement parameters: 827 Tmax: a loss threshold waiting time with value 3.0, expressed in 828 units of seconds, as a positive value of type decimal64 with 829 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 830 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 831 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 833 F a selection function unambiguously defining the packets from the 834 stream selected for the metric. See section 4.2 of [RFC5481] for 835 the PDV form. 837 See the Packet Stream generation category for two additional Fixed 838 Parameters. 840 5.3. Method of Measurement 842 This category includes columns for references to relevant sections of 843 the RFC(s) and any supplemental information needed to ensure an 844 unambiguous methods for implementations. 846 5.3.1. Reference Method 848 See section 2.6 and 3.6 of [RFC3393] for general singleton element 849 calculations. This metric entry requires implementation of the PDV 850 form defined in section 4.2 of [RFC5481]. Also see measurement 851 considerations in section 8 of [RFC5481]. 853 The reference method distinguishes between long-delayed packets and 854 lost packets by implementing a maximum waiting time for packet 855 arrival. Tmax is the waiting time used as the threshold to declare a 856 packet lost. Lost packets SHALL be designated as having undefined 857 delay. 859 The calculations on the one-way delay SHALL be performed on the 860 conditional distribution, conditioned on successful packet arrival 861 within Tmax. Also, when all packet delays are stored, the process 862 which calculates the one-way delay value MAY enforce the Tmax 863 threshold on stored values before calculations. See section 4.1 of 864 [RFC3393] for details on the conditional distribution to exclude 865 undefined values of delay, and Section 5 of [RFC6703] for background 866 on this analysis choice. 868 The reference method requires some way to distinguish between 869 different packets in a stream to establish correspondence between 870 sending times and receiving times for each successfully-arriving 871 packet. Sequence numbers or other send-order identification MUST be 872 retained at the Src or included with each packet to disambiguate 873 packet reordering if it occurs. 875 If a standard measurement protocol is employed, then the measurement 876 process will determine the sequence numbers or timestamps applied to 877 test packets after the Fixed and Runtime parameters are passed to 878 that process. The chosen measurement protocol will dictate the 879 format of sequence numbers and time-stamps, if they are conveyed in 880 the packet payload. 882 5.3.2. Packet Stream Generation 884 This section gives the details of the packet traffic which is the 885 basis for measurement. In IPPM metrics, this is called the Stream, 886 and can easily be described by providing the list of stream 887 parameters. 889 Section 3 of [RFC3432] prescribes the method for generating Periodic 890 streams using associated parameters. 892 incT the nominal duration of inter-packet interval, first bit to 893 first bit, with value 0.0200, expressed in units of seconds, as a 894 positive value of type decimal64 with fraction digits = 4 (see 895 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 896 (0.1 ms). 898 dT the duration of the interval for allowed sample start times, with 899 value 1.0, expressed in units of seconds, as a positive value of 900 type decimal64 with fraction digits = 4 (see section 9.3 of 901 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 903 NOTE: an initiation process with a number of control exchanges 904 resulting in unpredictable start times (within a time interval) may 905 be sufficient to avoid synchronization of periodic streams, and 906 therefore a valid replacement for selecting a start time at random 907 from a fixed interval. 909 The T0 parameter will be reported as a measured parameter. 910 Parameters incT and dT are Fixed Parameters. 912 5.3.3. Traffic Filtering (observation) Details 914 NA 916 5.3.4. Sampling Distribution 918 NA 920 5.3.5. Run-time Parameters and Data Format 922 Src the IP address of the host in the Src Role (format ipv4-address- 923 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 924 see Section 4 of [RFC6991]) 926 Dst the IP address of the host in the Dst Role (format ipv4-address- 927 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 928 see section 4 of [RFC6991]) 930 T0 a time, the start of a measurement interval, (format "date-and- 931 time" as specified in Section 5.6 of [RFC3339], see also Section 3 932 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 933 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 934 and Tf is to be interpreted as the Duration of the measurement 935 interval. The start time is controlled through other means. 937 Tf a time, the end of a measurement interval, (format "date-and-time" 938 as specified in Section 5.6 of [RFC3339], see also Section 3 of 939 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 940 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 941 Tf is interpreted as the Duration of the measurement interval. 943 5.3.6. Roles 945 5.4. Output 947 This category specifies all details of the Output of measurements 948 using the metric. 950 5.4.1. Type 952 Percentile -- for the conditional distribution of all packets with a 953 valid value of one-way delay (undefined delays are excluded), a 954 single value corresponding to the 95th percentile, as follows: 956 See section 4.1 of [RFC3393] for details on the conditional 957 distribution to exclude undefined values of delay, and Section 5 of 958 [RFC6703] for background on this analysis choice. 960 The percentile = 95, meaning that the reported delay, "95Percentile", 961 is the smallest value of one-way PDV for which the Empirical 962 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 963 one-way PDV values in the conditional distribution. See section 11.3 964 of [RFC2330] for the definition of the percentile statistic using the 965 EDF. 967 5.4.2. Reference Definition 969 T0 the start of a measurement interval, (format "date-and-time" as 970 specified in Section 5.6 of [RFC3339], see also Section 3 of 971 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 972 [RFC2330]. 974 Tf the end of a measurement interval, (format "date-and-time" as 975 specified in Section 5.6 of [RFC3339], see also Section 3 of 976 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 977 [RFC2330]. 979 95Percentile The time value of the result is expressed in units of 980 seconds, as a positive value of type decimal64 with fraction 981 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 982 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 983 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 985 5.4.3. Metric Units 987 The 95th Percentile of one-way PDV is expressed in seconds. 989 5.4.4. Calibration 991 Section 3.7.3 of [RFC7679] provides a means to quantify the 992 systematic and random errors of a time measurement. In-situ 993 calibration could be enabled with an internal loopback that includes 994 as much of the measurement system as possible, performs address 995 manipulation as needed, and provides some form of isolation (e.g., 996 deterministic delay) to avoid send-receive interface contention. 997 Some portion of the random and systematic error can be characterized 998 this way. 1000 For one-way delay measurements, the error calibration must include an 1001 assessment of the internal clock synchronization with its external 1002 reference (this internal clock is supplying timestamps for 1003 measurement). In practice, the time offsets of clocks at both the 1004 source and destination are needed to estimate the systematic error 1005 due to imperfect clock synchronization (the time offsets are 1006 smoothed, thus the random variation is not usually represented in the 1007 results). 1009 time_offset The time value of the result is expressed in units of 1010 seconds, as a signed value of type decimal64 with fraction digits 1011 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1012 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1013 NTP timestamp as per section 6 of RFC [RFC5905] 1015 When a measurement controller requests a calibration measurement, the 1016 loopback is applied and the result is output in the same format as a 1017 normal measurement with additional indication that it is a 1018 calibration result. In any measurement, the measurement function 1019 SHOULD report its current estimate of time offset as an indicator of 1020 the degree of synchronization. 1022 Both internal loopback calibration and clock synchronization can be 1023 used to estimate the *available accuracy* of the Output Metric Units. 1024 For example, repeated loopback delay measurements will reveal the 1025 portion of the Output result resolution which is the result of system 1026 noise, and thus inaccurate. 1028 5.5. Administrative items 1030 5.5.1. Status 1032 Current 1034 5.5.2. Requestor 1036 This RFC number 1038 5.5.3. Revision 1040 1.0 1042 5.5.4. Revision Date 1044 YYYY-MM-DD 1046 5.6. Comments and Remarks 1048 Lost packets represent a challenge for delay variation metrics. See 1049 section 4.1 of [RFC3393] and the delay variation applicability 1050 statement[RFC5481] for extensive analysis and comparison of PDV and 1051 an alternate metric, IPDV. 1053 6. DNS Response Latency and Loss Registry Entries 1055 This section gives initial registry entries for DNS Response Latency 1056 and Loss from a network user's perspective, for a specific named 1057 resource. The metric can be measured repeatedly using different 1058 names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1059 build on that metric by specifying several of the input parameters to 1060 precisely define two metrics for measuring DNS latency and loss. 1062 Note to IANA: Each Registry "Name" below specifies a single registry 1063 entry, whose output format varies in accordance with the name. 1065 All column entries beside the ID, Name, Description, and Output 1066 Reference Method categories are the same, thus this section proposes 1067 two closely-related registry entries. As a result, IANA is also 1068 asked to assign corresponding URLs to each Named Metric. 1070 6.1. Summary 1072 This category includes multiple indexes to the registry entries, the 1073 element ID and metric name. 1075 6.1.1. ID (Identifier) 1077 1079 IANA is asked to assign different numeric identifiers to each of the 1080 two Named Metrics. 1082 6.1.2. Name 1084 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Seconds_Raw 1086 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Logical_Raw 1088 6.1.3. URI 1090 URL: http:/// 1092 6.1.4. Description 1094 This is a metric for DNS Response performance from a network user's 1095 perspective, for a specific named resource. The metric can be 1096 measured repeatedly using different resource names. 1098 RTDNS: This metric assesses the response time, the interval from the 1099 query transmission to the response. 1101 RLDNS: This metric indicates that the response was deemed lost. In 1102 other words, the response time exceeded the maximum waiting time. 1104 6.1.5. Change Controller 1106 IETF 1108 6.1.6. Version (of Registry Format) 1110 1.0 1112 6.2. Metric Definition 1114 This category includes columns to prompt the entry of all necessary 1115 details related to the metric definition, including the RFC reference 1116 and values of input factors, called fixed parameters. 1118 6.2.1. Reference Definition 1120 Mockapetris, P., "Domain names - implementation and specification", 1121 STD 13, RFC 1035, November 1987. (and updates) 1123 [RFC1035] 1125 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1126 Metric for IPPM", RFC 2681, September 1999. 1128 [RFC2681] 1129 Section 2.4 of [RFC2681] provides the reference definition of the 1130 singleton (single value) Round-trip delay metric. Section 3.4 of 1131 [RFC2681] provides the reference definition expanded to cover a 1132 multi-singleton sample. Note that terms such as singleton and sample 1133 are defined in Section 11 of [RFC2330]. 1135 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1136 [RFC2681]. The Local Host with its User Program and Resolver take 1137 the role of "Src", and the Foreign Name Server takes the role of 1138 "Dst". 1140 Note that although the [RFC2681] definition of "Round-trip-Delay 1141 between Src and Dst at T" is directionally ambiguous in the text, 1142 this metric tightens the definition further to recognize that the 1143 host in the "Src" role will send the first packet to "Dst", and 1144 ultimately receive the corresponding return packet from "Dst" (when 1145 neither are lost). 1147 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1149 [RFC6673] 1151 Both response time and loss metrics employ a maximum waiting time for 1152 received responses, so the count of lost packets to total packets 1153 sent is the basis for the loss determination as per Section 4.3 of 1154 [RFC6673]. 1156 6.2.2. Fixed Parameters 1158 Type-P as defined in Section 13 of [RFC2330]: 1160 o IPv4 header values: 1162 * DSCP: set to 0 1164 * TTL set to 255 1166 * Protocol: Set to 17 (UDP) 1168 o IPv6 header values: 1170 * DSCP: set to 0 1172 * Hop Count: set to 255 1174 * Protocol: Set to 17 (UDP) 1176 o UDP header values: 1178 * Source port: 53 1180 * Destination port: 53 1182 * Checksum: the checksum must be calculated and included in the 1183 header 1185 o Payload: The payload contains a DNS message as defined in RFC 1035 1186 [RFC1035] with the following values: 1188 * The DNS header section contains: 1190 + Identification (see the Run-time column) 1192 + QR: set to 0 (Query) 1194 + OPCODE: set to 0 (standard query) 1196 + AA: not set 1198 + TC: not set 1200 + RD: set to one (recursion desired) 1202 + RA: not set 1204 + RCODE: not set 1206 + QDCOUNT: set to one (only one entry) 1208 + ANCOUNT: not set 1210 + NSCOUNT: not set 1212 + ARCOUNT: not set 1214 * The Question section contains: 1216 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1217 input for the test, see the Run-time column 1219 + QTYPE: the query type provided as input for the test, see 1220 the Run-time column 1222 + QCLASS: set to 1 for IN 1224 * The other sections do not contain any Resource Records. 1226 Other measurement parameters: 1228 o Tmax: a loss threshold waiting time (and to help disambiguate 1229 queries) 1231 * 5.0, expressed in units of seconds, as a positive value of type 1232 decimal64 with fraction digits = 4 (see section 9.3 of 1233 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1234 lossless conversion to/from the 32-bit NTP timestamp as per 1235 section 6 of [RFC5905]. 1237 Observation: reply packets will contain a DNS response and may 1238 contain RRs. 1240 6.3. Method of Measurement 1242 This category includes columns for references to relevant sections of 1243 the RFC(s) and any supplemental information needed to ensure an 1244 unambiguous methods for implementations. 1246 6.3.1. Reference Method 1248 The methodology for this metric is defined as Type-P-Round-trip- 1249 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1250 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1251 Fixed Parameters. 1253 The reference method distinguishes between long-delayed packets and 1254 lost packets by implementing a maximum waiting time for packet 1255 arrival. Tmax is the waiting time used as the threshold to declare a 1256 response packet lost. Lost packets SHALL be designated as having 1257 undefined delay and counted for the RLDNS metric. 1259 The calculations on the delay (RTT) SHALL be performed on the 1260 conditional distribution, conditioned on successful packet arrival 1261 within Tmax. Also, when all packet delays are stored, the process 1262 which calculates the RTT value MAY enforce the Tmax threshold on 1263 stored values before calculations. See section 4.1 of [RFC3393] for 1264 details on the conditional distribution to exclude undefined values 1265 of delay, and Section 5 of [RFC6703] for background on this analysis 1266 choice. 1268 The reference method requires some way to distinguish between 1269 different packets in a stream to establish correspondence between 1270 sending times and receiving times for each successfully-arriving 1271 reply. 1273 DNS Messages bearing Queries provide for random ID Numbers in the 1274 Identification header field, so more than one query may be launched 1275 while a previous request is outstanding when the ID Number is used. 1276 Therefore, the ID Number MUST be retained at the Src or included with 1277 each response packet to disambiguate packet reordering if it occurs. 1279 IF a DNS response does not arrive within Tmax, the response time 1280 RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to 1281 disambiguate the successive queries that are otherwise identical. 1283 Since the ID Number filed is only 16 bits in length, it places a 1284 limit on the number of simultaneous outstanding DNS queries during a 1285 stress test from a single Src address. 1287 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1288 instruction to "send a Type-P packet back to the Src as quickly as 1289 possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS 1290 Server is expected to perform all required functions to prepare and 1291 send a response, so the response time will include processing time 1292 and network delay. Section 8 of [RFC6673] presents additional 1293 requirements which SHALL be included in the method of measurement for 1294 this metric. 1296 In addition to operations described in [RFC2681], the Src MUST parse 1297 the DNS headers of the reply and prepare the information for 1298 subsequent reporting as a measured result, along with the Round-Trip 1299 Delay. 1301 6.3.2. Packet Stream Generation 1303 This section gives the details of the packet traffic which is the 1304 basis for measurement. In IPPM metrics, this is called the Stream, 1305 and can easily be described by providing the list of stream 1306 parameters. 1308 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1309 generate Poisson sampling intervals. The reciprocal of lambda is the 1310 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1311 = 1/lambda, in seconds. 1313 Method 3 is used, where given a start time (Run-time Parameter), the 1314 subsequent send times are all computed prior to measurement by 1315 computing the pseudo-random distribution of inter-packet send times, 1316 (truncating the distribution as specified in the Run-time 1317 Parameters), and the Src sends each packet at the computed times. 1319 Note that Trunc is the upper limit on inter-packet times in the 1320 Poisson distribution. A random value greater than Trunc is set equal 1321 to Trunc instead. 1323 6.3.3. Traffic Filtering (observation) Details 1325 The measured results based on a filtered version of the packets 1326 observed, and this section provides the filter details (when 1327 present). 1329 NA 1331 6.3.4. Sampling Distribution 1333 NA 1335 6.3.5. Run-time Parameters and Data Format 1337 Run-time Parameters are input factors that must be determined, 1338 configured into the measurement system, and reported with the results 1339 for the context to be complete. 1341 Src the IP address of the host in the Src Role (format ipv4-address- 1342 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1343 see Section 4 of [RFC6991]) 1345 Dst the IP address of the host in the Dst Role (format ipv4-address- 1346 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1347 see section 4 of [RFC6991]) 1349 T0 a time, the start of a measurement interval, (format "date-and- 1350 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1351 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1352 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1353 and Tf is to be interpreted as the Duration of the measurement 1354 interval. The start time is controlled through other means. 1356 Tf a time, the end of a measurement interval, (format "date-and-time" 1357 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1358 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1359 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1360 Tf is interpreted as the Duration of the measurement interval. 1362 Reciprocal_lambda average packet interval for Poisson Streams 1363 expressed in units of seconds, as a positive value of type 1364 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1365 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1366 conversion to/from the 32-bit NTP timestamp as per section 6 of 1367 [RFC5905]. 1369 Trunc Upper limit on Poisson distribution expressed in units of 1370 seconds, as a positive value of type decimal64 with fraction 1371 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1372 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1373 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1374 this limit will be clipped and set to the limit value). (if fixed, 1375 Trunc = 30.0000 seconds.) 1377 ID The 16-bit identifier assigned by the program that generates the 1378 query, and which must vary in successive queries, see 1379 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1380 corresponding reply and can be used by the requester (Src) to 1381 match-up replies to outstanding queries. 1383 QNAME The domain name of the Query, formatted as specified in 1384 section 4 of [RFC6991]. 1386 QTYPE The Query Type, which will correspond to the IP address family 1387 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1388 uint16, as per section 9.2 of [RFC6020]. 1390 6.3.6. Roles 1392 Src launches each packet and waits for return transmissions from 1393 Dst. 1395 Dst waits for each packet from Src and sends a return packet to Src. 1397 6.4. Output 1399 This category specifies all details of the Output of measurements 1400 using the metric. 1402 6.4.1. Type 1404 Raw -- for each DNS Query packet sent, sets of values as defined in 1405 the next column, including the status of the response, only assigning 1406 delay values to successful query-response pairs. 1408 6.4.2. Reference Definition 1410 For all outputs: 1412 T the time the DNS Query was sent during the measurement interval, 1413 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1414 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1415 by Section 6.1 of [RFC2330]. 1417 dT The time value of the round-trip delay to receive the DNS 1418 response, expressed in units of seconds, as a positive value of 1419 type decimal64 with fraction digits = 9 (see section 9.3 of 1420 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1421 with lossless conversion to/from the 64-bit NTP timestamp as per 1422 section 6 of RFC [RFC5905]. This value is undefined when the 1423 response packet is not received at Src within waiting time Tmax 1424 seconds. 1426 Rcode The value of the Rcode field in the DNS response header, 1427 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1428 Non-zero values convey errors in the response, and such replies 1429 must be analyzed separately from successful requests. 1431 6.4.3. Metric Units 1433 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1435 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1437 6.4.4. Calibration 1439 Section 3.7.3 of [RFC7679] provides a means to quantify the 1440 systematic and random errors of a time measurement. In-situ 1441 calibration could be enabled with an internal loopback at the Source 1442 host that includes as much of the measurement system as possible, 1443 performs address and payload manipulation as needed, and provides 1444 some form of isolation (e.g., deterministic delay) to avoid send- 1445 receive interface contention. Some portion of the random and 1446 systematic error can be characterized this way. 1448 When a measurement controller requests a calibration measurement, the 1449 loopback is applied and the result is output in the same format as a 1450 normal measurement with additional indication that it is a 1451 calibration result. 1453 Both internal loopback calibration and clock synchronization can be 1454 used to estimate the *available accuracy* of the Output Metric Units. 1455 For example, repeated loopback delay measurements will reveal the 1456 portion of the Output result resolution which is the result of system 1457 noise, and thus inaccurate. 1459 6.5. Administrative items 1461 6.5.1. Status 1463 Current 1465 6.5.2. Requestor 1467 This RFC number 1469 6.5.3. Revision 1471 1.0 1473 6.5.4. Revision Date 1475 YYYY-MM-DD 1477 6.6. Comments and Remarks 1479 Additional (Informational) details for this entry 1481 7. UDP Poisson One-way Delay and Loss Registry Entries 1483 This section specifies five initial registry entries for the UDP 1484 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1486 IANA Note: Registry "Name" below specifies a single registry entry, 1487 whose output format varies according to the element of 1488 the name that specifies one form of statistical summary. There is an 1489 additional metric name for the Loss metric. 1491 All column entries beside the ID, Name, Description, and Output 1492 Reference Method categories are the same, thus this section proposes 1493 six closely-related registry entries. As a result, IANA is also 1494 asked to assign corresponding URLs to each Named Metric. 1496 7.1. Summary 1498 This category includes multiple indexes to the registry entries, the 1499 element ID and metric name. 1501 7.1.1. ID (Identifier) 1503 IANA is asked to assign different numeric identifiers to each of the 1504 six Metrics. 1506 7.1.2. Name 1508 OWDelay_Active_IP-UDP-Poisson- 1509 Payload250B_RFCXXXXsec7_Seconds_ 1511 where is one of: 1513 o 95Percentile 1515 o Mean 1517 o Min 1519 o Max 1521 o StdDev 1523 OWLoss_Active_IP-UDP-Poisson- 1524 Payload250B_RFCXXXXsec7_Percent_LossRatio 1526 7.1.3. URI and URL 1528 URL: https:\\www.iana.org\ ... 1530 7.1.4. Description 1532 OWDelay: This metric assesses the delay of a stream of packets 1533 exchanged between two hosts (or measurement points), and reports the 1534 One-way delay for all successfully exchanged packets 1535 based on their conditional delay distribution. 1537 where is one of: 1539 o 95Percentile 1541 o Mean 1543 o Min 1545 o Max 1547 o StdDev 1549 OWLoss: This metric assesses the loss ratio of a stream of packets 1550 exchanged between two hosts (which are the two measurement points), 1551 and the Output is the One-way loss ratio for all successfully 1552 received packets expressed as a percentage. 1554 7.2. Metric Definition 1556 This category includes columns to prompt the entry of all necessary 1557 details related to the metric definition, including the RFC reference 1558 and values of input factors, called fixed parameters. 1560 7.2.1. Reference Definition 1562 For Delay: 1564 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1565 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1566 7679, DOI 10.17487/RFC7679, January 2016, . 1569 [RFC7679] 1571 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1572 6049, January 2011. 1574 [RFC6049] 1576 Section 3.4 of [RFC7679] provides the reference definition of the 1577 singleton (single value) One-way delay metric. Section 4.4 of 1578 [RFC7679] provides the reference definition expanded to cover a 1579 multi-value sample. Note that terms such as singleton and sample are 1580 defined in Section 11 of [RFC2330]. 1582 Only successful packet transfers with finite delay are included in 1583 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1585 For loss: 1587 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1588 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1589 10.17487/RFC7680, January 2016, . 1592 Section 2.4 of [RFC7680] provides the reference definition of the 1593 singleton (single value) one-way loss metric. Section 3.4 of 1594 [RFC7680] provides the reference definition expanded to cover a 1595 multi-singleton sample. Note that terms such as singleton and sample 1596 are defined in Section 11 of [RFC2330]. 1598 7.2.2. Fixed Parameters 1600 Type-P: 1602 o IPv4 header values: 1604 * DSCP: set to 0 1606 * TTL: set to 255 1608 * Protocol: Set to 17 (UDP) 1610 o IPv6 header values: 1612 * DSCP: set to 0 1614 * Hop Count: set to 255 1616 * Protocol: Set to 17 (UDP) 1618 o UDP header values: 1620 * Checksum: the checksum MUST be calculated and included in the 1621 header 1623 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1625 * Security features in use influence the number of Padding 1626 octets. 1628 * 250 octets total, including the TWAMP format 1630 Other measurement parameters: 1632 Tmax: a loss threshold waiting time with value 3.0, expressed in 1633 units of seconds, as a positive value of type decimal64 with 1634 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1635 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1636 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1638 See the Packet Stream generation category for two additional Fixed 1639 Parameters. 1641 7.3. Method of Measurement 1643 This category includes columns for references to relevant sections of 1644 the RFC(s) and any supplemental information needed to ensure an 1645 unambiguous methods for implementations. 1647 7.3.1. Reference Method 1649 The methodology for this metric is defined as Type-P-One-way-Delay- 1650 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1651 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1653 The reference method distinguishes between long-delayed packets and 1654 lost packets by implementing a maximum waiting time for packet 1655 arrival. Tmax is the waiting time used as the threshold to declare a 1656 packet lost. Lost packets SHALL be designated as having undefined 1657 delay, and counted for the OWLoss metric. 1659 The calculations on the one-way delay SHALL be performed on the 1660 conditional distribution, conditioned on successful packet arrival 1661 within Tmax. Also, when all packet delays are stored, the process 1662 which calculates the one-way delay value MAY enforce the Tmax 1663 threshold on stored values before calculations. See section 4.1 of 1664 [RFC3393] for details on the conditional distribution to exclude 1665 undefined values of delay, and Section 5 of [RFC6703] for background 1666 on this analysis choice. 1668 The reference method requires some way to distinguish between 1669 different packets in a stream to establish correspondence between 1670 sending times and receiving times for each successfully-arriving 1671 packet. Sequence numbers or other send-order identification MUST be 1672 retained at the Src or included with each packet to disambiguate 1673 packet reordering if it occurs. 1675 Since a standard measurement protocol is employed [RFC5357], then the 1676 measurement process will determine the sequence numbers or timestamps 1677 applied to test packets after the Fixed and Runtime parameters are 1678 passed to that process. The measurement protocol dictates the format 1679 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1680 payload. 1682 7.3.2. Packet Stream Generation 1684 This section gives the details of the packet traffic which is the 1685 basis for measurement. In IPPM metrics, this is called the Stream, 1686 and can easily be described by providing the list of stream 1687 parameters. 1689 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1690 generate Poisson sampling intervals. The reciprocal of lambda is the 1691 average packet spacing, thus the Run-time Parameter is 1692 Reciprocal_lambda = 1/lambda, in seconds. 1694 Method 3 SHALL be used, where given a start time (Run-time 1695 Parameter), the subsequent send times are all computed prior to 1696 measurement by computing the pseudo-random distribution of inter- 1697 packet send times, (truncating the distribution as specified in the 1698 Parameter Trunc), and the Src sends each packet at the computed 1699 times. 1701 Note that Trunc is the upper limit on inter-packet times in the 1702 Poisson distribution. A random value greater than Trunc is set equal 1703 to Trunc instead. 1705 Reciprocal_lambda average packet interval for Poisson Streams 1706 expressed in units of seconds, as a positive value of type 1707 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1708 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1709 conversion to/from the 32-bit NTP timestamp as per section 6 of 1710 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1712 Trunc Upper limit on Poisson distribution expressed in units of 1713 seconds, as a positive value of type decimal64 with fraction 1714 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1715 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1716 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1717 this limit will be clipped and set to the limit value). Trunc = 1718 30.0000 seconds. 1720 7.3.3. Traffic Filtering (observation) Details 1722 NA 1724 7.3.4. Sampling Distribution 1726 NA 1728 7.3.5. Run-time Parameters and Data Format 1730 Run-time Parameters are input factors that must be determined, 1731 configured into the measurement system, and reported with the results 1732 for the context to be complete. 1734 Src the IP address of the host in the Src Role (format ipv4-address- 1735 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1736 see Section 4 of [RFC6991]) 1738 Dst the IP address of the host in the Dst Role (format ipv4-address- 1739 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1740 see section 4 of [RFC6991]) 1742 T0 a time, the start of a measurement interval, (format "date-and- 1743 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1744 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1745 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1746 and Tf is to be interpreted as the Duration of the measurement 1747 interval. The start time is controlled through other means. 1749 Tf a time, the end of a measurement interval, (format "date-and-time" 1750 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1751 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1752 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1753 Tf is interpreted as the Duration of the measurement interval. 1755 7.3.6. Roles 1757 Src launches each packet and waits for return transmissions from 1758 Dst. This is the TWAMP Session-Sender. 1760 Dst waits for each packet from Src and sends a return packet to Src. 1761 This is the TWAMP Session-Reflector. 1763 7.4. Output 1765 This category specifies all details of the Output of measurements 1766 using the metric. 1768 7.4.1. Type 1770 See subsection titles below for Types. 1772 7.4.2. Reference Definition 1774 For all output types --- 1776 T0 the start of a measurement interval, (format "date-and-time" as 1777 specified in Section 5.6 of [RFC3339], see also Section 3 of 1778 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1779 [RFC2330]. 1781 Tf the end of a measurement interval, (format "date-and-time" as 1782 specified in Section 5.6 of [RFC3339], see also Section 3 of 1783 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1784 [RFC2330]. 1786 For LossRatio -- the count of lost packets to total packets sent is 1787 the basis for the loss ratio calculation as per Section 4.1 of 1788 [RFC7680]. 1790 For each , one of the following sub-sections apply: 1792 7.4.2.1. Percentile95 1794 The 95th percentile SHALL be calculated using the conditional 1795 distribution of all packets with a finite value of One-way delay 1796 (undefined delays are excluded), a single value as follows: 1798 See section 4.1 of [RFC3393] for details on the conditional 1799 distribution to exclude undefined values of delay, and Section 5 of 1800 [RFC6703] for background on this analysis choice. 1802 See section 4.3 of [RFC3393] for details on the percentile statistic 1803 (where Round-trip delay should be substituted for "ipdv"). 1805 The percentile = 95, meaning that the reported delay, "95Percentile", 1806 is the smallest value of one-way delay for which the Empirical 1807 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1808 one-way delay values in the conditional distribution. See section 1809 11.3 of [RFC2330] for the definition of the percentile statistic 1810 using the EDF. 1812 95Percentile The time value of the result is expressed in units of 1813 seconds, as a positive value of type decimal64 with fraction 1814 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1815 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1816 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1818 7.4.2.2. Mean 1820 The mean SHALL be calculated using the conditional distribution of 1821 all packets with a finite value of One-way delay (undefined delays 1822 are excluded), a single value as follows: 1824 See section 4.1 of [RFC3393] for details on the conditional 1825 distribution to exclude undefined values of delay, and Section 5 of 1826 [RFC6703] for background on this analysis choice. 1828 See section 4.2.2 of [RFC6049] for details on calculating this 1829 statistic, and 4.2.3 of [RFC6049]. 1831 Mean The time value of the result is expressed in units of seconds, 1832 as a positive value of type decimal64 with fraction digits = 9 1833 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1834 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1835 NTP timestamp as per section 6 of RFC [RFC5905] 1837 7.4.2.3. Min 1839 The minimum SHALL be calculated using the conditional distribution of 1840 all packets with a finite value of One-way delay (undefined delays 1841 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.2 of [RFC6049] for details on calculating this 1848 statistic, and 4.3.3 of [RFC6049]. 1850 Min The time value of the result is expressed in units of seconds, 1851 as a positive value of type decimal64 with fraction digits = 9 1852 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1853 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1854 NTP timestamp as per section 6 of RFC [RFC5905] 1856 7.4.2.4. Max 1858 The maximum SHALL be calculated using the conditional distribution of 1859 all packets with a finite value of One-way delay (undefined delays 1860 are excluded), a single value as follows: 1862 See section 4.1 of [RFC3393] for details on the conditional 1863 distribution to exclude undefined values of delay, and Section 5 of 1864 [RFC6703] for background on this analysis choice. 1866 See section 4.3.2 of [RFC6049] for a closely related method for 1867 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1868 as follows: 1870 Max = (FiniteDelay [j]) 1872 such that for some index, j, where 1 <= j <= N 1873 FiniteDelay[j] >= FiniteDelay[n] for all n 1875 Max The time value of the result is expressed in units of seconds, 1876 as a positive value of type decimal64 with fraction digits = 9 1877 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1878 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1879 NTP timestamp as per section 6 of RFC [RFC5905] 1881 7.4.2.5. Std_Dev 1883 The Std_Dev SHALL be calculated using the conditional distribution of 1884 all packets with a finite value of One-way delay (undefined delays 1885 are excluded), a single value as follows: 1887 See section 4.1 of [RFC3393] for details on the conditional 1888 distribution to exclude undefined values of delay, and Section 5 of 1889 [RFC6703] for background on this analysis choice. 1891 See section 4.3.2 of [RFC6049] for a closely related method for 1892 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1893 the classic calculation for standard deviation of a population. 1895 Std_Dev The time value of the result is expressed in units of 1896 seconds, as a positive value of type decimal64 with fraction 1897 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1898 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1899 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1901 7.4.3. Metric Units 1903 The of One-way Delay is expressed in seconds. 1905 The One-way Loss Ratio is expressed as a percentage of lost packets 1906 to total packets sent. 1908 7.4.4. Calibration 1910 Section 3.7.3 of [RFC7679] provides a means to quantify the 1911 systematic and random errors of a time measurement. In-situ 1912 calibration could be enabled with an internal loopback that includes 1913 as much of the measurement system as possible, performs address 1914 manipulation as needed, and provides some form of isolation (e.g., 1915 deterministic delay) to avoid send-receive interface contention. 1916 Some portion of the random and systematic error can be characterized 1917 this way. 1919 For one-way delay measurements, the error calibration must include an 1920 assessment of the internal clock synchronization with its external 1921 reference (this internal clock is supplying timestamps for 1922 measurement). In practice, the time offsets of clocks at both the 1923 source and destination are needed to estimate the systematic error 1924 due to imperfect clock synchronization (the time offsets are 1925 smoothed, thus the random variation is not usually represented in the 1926 results). 1928 time_offset The time value of the result is expressed in units of 1929 seconds, as a signed value of type decimal64 with fraction digits 1930 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1931 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1932 NTP timestamp as per section 6 of RFC [RFC5905] 1934 When a measurement controller requests a calibration measurement, the 1935 loopback is applied and the result is output in the same format as a 1936 normal measurement with additional indication that it is a 1937 calibration result. In any measurement, the measurement function 1938 SHOULD report its current estimate of time offset as an indicator of 1939 the degree of synchronization. 1941 Both internal loopback calibration and clock synchronization can be 1942 used to estimate the *available accuracy* of the Output Metric Units. 1943 For example, repeated loopback delay measurements will reveal the 1944 portion of the Output result resolution which is the result of system 1945 noise, and thus inaccurate. 1947 7.5. Administrative items 1949 7.5.1. Status 1951 Current 1953 7.5.2. Requestor 1955 This REFC number 1957 7.5.3. Revision 1959 1.0 1961 7.5.4. Revision Date 1963 YYYY-MM-DD 1965 7.6. Comments and Remarks 1967 Additional (Informational) details for this entry 1969 8. UDP Periodic One-way Delay and Loss Registry Entries 1971 This section specifies five initial registry entries for the UDP 1972 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 1974 IANA Note: Registry "Name" below specifies a single registry entry, 1975 whose output format varies according to the element of 1976 the name that specifies one form of statistical summary. There is an 1977 additional metric name for the Loss metric. 1979 All column entries beside the ID, Name, Description, and Output 1980 Reference Method categories are the same, thus this section proposes 1981 six closely-related registry entries. As a result, IANA is also 1982 asked to assign corresponding URLs to each Named Metric. 1984 8.1. Summary 1986 This category includes multiple indexes to the registry entries, the 1987 element ID and metric name. 1989 8.1.1. ID (Identifier) 1991 IANA is asked to assign a different numeric identifiers to each of 1992 the six Metrics. 1994 8.1.2. Name 1996 OWDelay_Active_IP-UDP-Periodic20m- 1997 Payload142B_RFCXXXXsec8_Seconds_ 1999 where is one of: 2001 o 95Percentile 2003 o Mean 2005 o Min 2007 o Max 2009 o StdDev 2011 OWLoss_Active_IP-UDP-Periodic- 2012 Payload142B_RFCXXXXsec8_Percent_LossRatio 2014 8.1.3. URIs 2016 URL: https:\\www.iana.org\ ... 2018 8.1.4. Description 2020 OWDelay: This metric assesses the delay of a stream of packets 2021 exchanged between two hosts (or measurement points), and reports the 2022 One-way delay for all successfully exchanged packets 2023 based on their conditional delay distribution. 2025 where is one of: 2027 o 95Percentile 2029 o Mean 2031 o Min 2033 o Max 2035 o StdDev 2037 OWLoss: This metric assesses the loss ratio of a stream of packets 2038 exchanged between two hosts (which are the two measurement points), 2039 and the Output is the One-way loss ratio for all successfully 2040 received packets expressed as a percentage. 2042 8.2. Metric Definition 2044 This category includes columns to prompt the entry of all necessary 2045 details related to the metric definition, including the RFC reference 2046 and values of input factors, called fixed parameters. 2048 8.2.1. Reference Definition 2050 For Delay: 2052 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2053 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2054 7679, DOI 10.17487/RFC7679, January 2016, . 2057 [RFC7679] 2059 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2060 6049, January 2011. 2062 [RFC6049] 2064 Section 3.4 of [RFC7679] provides the reference definition of the 2065 singleton (single value) One-way delay metric. Section 4.4 of 2066 [RFC7679] provides the reference definition expanded to cover a 2067 multi-value sample. Note that terms such as singleton and sample are 2068 defined in Section 11 of [RFC2330]. 2070 Only successful packet transfers with finite delay are included in 2071 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2073 For loss: 2075 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2076 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2077 10.17487/RFC7680, January 2016, . 2080 Section 2.4 of [RFC7680] provides the reference definition of the 2081 singleton (single value) one-way loss metric. Section 3.4 of 2082 [RFC7680] provides the reference definition expanded to cover a 2083 multi-singleton sample. Note that terms such as singleton and sample 2084 are defined in Section 11 of [RFC2330]. 2086 8.2.2. Fixed Parameters 2088 Type-P: 2090 o IPv4 header values: 2092 * DSCP: set to 0 2094 * TTL: set to 255 2096 * Protocol: Set to 17 (UDP) 2098 o IPv6 header values: 2100 * DSCP: set to 0 2102 * Hop Count: set to 255 2104 * Protocol: Set to 17 (UDP) 2106 o UDP header values: 2108 * Checksum: the checksum MUST be calculated and included in the 2109 header 2111 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2113 * Security features in use influence the number of Padding 2114 octets. 2116 * 142 octets total, including the TWAMP format (if used) 2118 Other measurement parameters: 2120 Tmax: a loss threshold waiting time with value 3.0, expressed in 2121 units of seconds, as a positive value of type decimal64 with 2122 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2123 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2124 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2126 See the Packet Stream generation category for two additional Fixed 2127 Parameters. 2129 8.3. Method of Measurement 2131 This category includes columns for references to relevant sections of 2132 the RFC(s) and any supplemental information needed to ensure an 2133 unambiguous methods for implementations. 2135 8.3.1. Reference Method 2137 The methodology for this metric is defined as Type-P-One-way-Delay- 2138 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2139 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2140 However, a Periodic stream is used, as defined in [RFC3432]. 2142 The reference method distinguishes between long-delayed packets and 2143 lost packets by implementing a maximum waiting time for packet 2144 arrival. Tmax is the waiting time used as the threshold to declare a 2145 packet lost. Lost packets SHALL be designated as having undefined 2146 delay, and counted for the OWLoss metric. 2148 The calculations on the one-way delay SHALL be performed on the 2149 conditional distribution, conditioned on successful packet arrival 2150 within Tmax. Also, when all packet delays are stored, the process 2151 which calculates the one-way delay value MAY enforce the Tmax 2152 threshold on stored values before calculations. See section 4.1 of 2153 [RFC3393] for details on the conditional distribution to exclude 2154 undefined values of delay, and Section 5 of [RFC6703] for background 2155 on this analysis choice. 2157 The reference method requires some way to distinguish between 2158 different packets in a stream to establish correspondence between 2159 sending times and receiving times for each successfully-arriving 2160 packet. Sequence numbers or other send-order identification MUST be 2161 retained at the Src or included with each packet to disambiguate 2162 packet reordering if it occurs. 2164 Since a standard measurement protocol is employed [RFC5357], then the 2165 measurement process will determine the sequence numbers or timestamps 2166 applied to test packets after the Fixed and Runtime parameters are 2167 passed to that process. The measurement protocol dictates the format 2168 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2169 payload. 2171 8.3.2. Packet Stream Generation 2173 This section gives the details of the packet traffic which is the 2174 basis for measurement. In IPPM metrics, this is called the Stream, 2175 and can easily be described by providing the list of stream 2176 parameters. 2178 Section 3 of [RFC3432] prescribes the method for generating Periodic 2179 streams using associated parameters. 2181 incT the nominal duration of inter-packet interval, first bit to 2182 first bit, with value 0.0200 expressed in units of seconds, as a 2183 positive value of type decimal64 with fraction digits = 4 (see 2184 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 2185 (0.1 ms), with lossless conversion to/from the 32-bit NTP 2186 timestamp as per section 6 of [RFC5905]. 2188 dT the duration of the interval for allowed sample start times, with 2189 value 1.0000, expressed in units of seconds, as a positive value 2190 of type decimal64 with fraction digits = 4 (see section 9.3 of 2191 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2192 lossless conversion to/from the 32-bit NTP timestamp as per 2193 section 6 of [RFC5905]. 2195 T0 the actual start time of the periodic stream, determined from T0 2196 and dT. 2198 NOTE: an initiation process with a number of control exchanges 2199 resulting in unpredictable start times (within a time interval) may 2200 be sufficient to avoid synchronization of periodic streams, and 2201 therefore a valid replacement for selecting a start time at random 2202 from a fixed interval. 2204 These stream parameters will be specified as Run-time parameters. 2206 8.3.3. Traffic Filtering (observation) Details 2208 NA 2210 8.3.4. Sampling Distribution 2212 NA 2214 8.3.5. Run-time Parameters and Data Format 2216 Run-time Parameters are input factors that must be determined, 2217 configured into the measurement system, and reported with the results 2218 for the context to be complete. 2220 Src the IP address of the host in the Src Role (format ipv4-address- 2221 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2222 see Section 4 of [RFC6991]) 2224 Dst the IP address of the host in the Dst Role (format ipv4-address- 2225 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2226 see section 4 of [RFC6991]) 2228 T0 a time, the start of a measurement interval, (format "date-and- 2229 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2230 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2231 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2232 and Tf is to be interpreted as the Duration of the measurement 2233 interval. The start time is controlled through other means. 2235 Tf a time, the end of a measurement interval, (format "date-and-time" 2236 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2237 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2238 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2239 Tf is interpreted as the Duration of the measurement interval. 2241 8.3.6. Roles 2243 Src launches each packet and waits for return transmissions from 2244 Dst. This is the TWAMP Session-Sender. 2246 Dst waits for each packet from Src and sends a return packet to Src. 2247 This is the TWAMP Session-Reflector. 2249 8.4. Output 2251 This category specifies all details of the Output of measurements 2252 using the metric. 2254 8.4.1. Type 2256 See subsection titles in Reference Definition for Latency Types. 2258 8.4.2. Reference Definition 2260 For all output types --- 2262 T0 the start of a measurement interval, (format "date-and-time" as 2263 specified in Section 5.6 of [RFC3339], see also Section 3 of 2264 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2265 [RFC2330]. 2267 Tf the end of a measurement interval, (format "date-and-time" as 2268 specified in Section 5.6 of [RFC3339], see also Section 3 of 2269 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2270 [RFC2330]. 2272 For LossRatio -- the count of lost packets to total packets sent is 2273 the basis for the loss ratio calculation as per Section 4.1 of 2274 [RFC7680]. 2276 For each , one of the following sub-sections apply: 2278 8.4.2.1. Percentile95 2280 The 95th percentile SHALL be calculated using the conditional 2281 distribution of all packets with a finite value of One-way delay 2282 (undefined delays are excluded), a single value as follows: 2284 See section 4.1 of [RFC3393] for details on the conditional 2285 distribution to exclude undefined values of delay, and Section 5 of 2286 [RFC6703] for background on this analysis choice. 2288 See section 4.3 of [RFC3393] for details on the percentile statistic 2289 (where Round-trip delay should be substituted for "ipdv"). 2291 The percentile = 95, meaning that the reported delay, "95Percentile", 2292 is the smallest value of one-way delay for which the Empirical 2293 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2294 one-way delay values in the conditional distribution. See section 2295 11.3 of [RFC2330] for the definition of the percentile statistic 2296 using the EDF. 2298 95Percentile The time value of the result is expressed in units of 2299 seconds, as a positive value of type decimal64 with fraction 2300 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2301 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2302 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2304 8.4.2.2. Mean 2306 The mean SHALL be calculated using the conditional distribution of 2307 all packets with a finite value of One-way delay (undefined delays 2308 are excluded), a single value as follows: 2310 See section 4.1 of [RFC3393] for details on the conditional 2311 distribution to exclude undefined values of delay, and Section 5 of 2312 [RFC6703] for background on this analysis choice. 2314 See section 4.2.2 of [RFC6049] for details on calculating this 2315 statistic, and 4.2.3 of [RFC6049]. 2317 Mean The time value of the result is expressed in units of seconds, 2318 as a positive value of type decimal64 with fraction digits = 9 2319 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2320 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2321 NTP timestamp as per section 6 of RFC [RFC5905] 2323 8.4.2.3. Min 2325 The minimum SHALL be calculated using the conditional distribution of 2326 all packets with a finite value of One-way delay (undefined delays 2327 are excluded), a single value as follows: 2329 See section 4.1 of [RFC3393] for details on the conditional 2330 distribution to exclude undefined values of delay, and Section 5 of 2331 [RFC6703] for background on this analysis choice. 2333 See section 4.3.2 of [RFC6049] for details on calculating this 2334 statistic, and 4.3.3 of [RFC6049]. 2336 Min The time value of the result is expressed in units of seconds, 2337 as a positive value of type decimal64 with fraction digits = 9 2338 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2339 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2340 NTP timestamp as per section 6 of RFC [RFC5905] 2342 8.4.2.4. Max 2344 The maximum SHALL be calculated using the conditional distribution of 2345 all packets with a finite value of One-way delay (undefined delays 2346 are excluded), a single value as follows: 2348 See section 4.1 of [RFC3393] for details on the conditional 2349 distribution to exclude undefined values of delay, and Section 5 of 2350 [RFC6703] for background on this analysis choice. 2352 See section 4.3.2 of [RFC6049] for a closely related method for 2353 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2354 as follows: 2356 Max = (FiniteDelay [j]) 2358 such that for some index, j, where 1 <= j <= N 2359 FiniteDelay[j] >= FiniteDelay[n] for all n 2361 Max The time value of the result is expressed in units of seconds, 2362 as a positive value of type decimal64 with fraction digits = 9 2363 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2364 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2365 NTP timestamp as per section 6 of RFC [RFC5905] 2367 8.4.2.5. Std_Dev 2369 The Std_Dev SHALL be calculated using the conditional distribution of 2370 all packets with a finite value of One-way delay (undefined delays 2371 are excluded), a single value as follows: 2373 See section 4.1 of [RFC3393] for details on the conditional 2374 distribution to exclude undefined values of delay, and Section 5 of 2375 [RFC6703] for background on this analysis choice. 2377 See section 4.3.2 of [RFC6049] for a closely related method for 2378 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2379 the classic calculation for standard deviation of a population. 2381 Std_Dev The time value of the result is expressed in units of 2382 seconds, as a positive value of type decimal64 with fraction 2383 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2384 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2385 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2387 8.4.3. Metric Units 2389 The of One-way Delay is expressed in seconds, where 2390 is one of: 2392 o 95Percentile 2394 o Mean 2396 o Min 2398 o Max 2399 o StdDev 2401 The One-way Loss Ratio is expressed as a percentage of lost packets 2402 to total packets sent. 2404 8.4.4. Calibration 2406 Section 3.7.3 of [RFC7679] provides a means to quantify the 2407 systematic and random errors of a time measurement. In-situ 2408 calibration could be enabled with an internal loopback that includes 2409 as much of the measurement system as possible, performs address 2410 manipulation as needed, and provides some form of isolation (e.g., 2411 deterministic delay) to avoid send-receive interface contention. 2412 Some portion of the random and systematic error can be characterized 2413 this way. 2415 For one-way delay measurements, the error calibration must include an 2416 assessment of the internal clock synchronization with its external 2417 reference (this internal clock is supplying timestamps for 2418 measurement). In practice, the time offsets of clocks at both the 2419 source and destination are needed to estimate the systematic error 2420 due to imperfect clock synchronization (the time offsets are 2421 smoothed, thus the random variation is not usually represented in the 2422 results). 2424 time_offset The time value of the result is expressed in units of 2425 seconds, as a signed value of type decimal64 with fraction digits 2426 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2427 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2428 NTP timestamp as per section 6 of RFC [RFC5905] 2430 When a measurement controller requests a calibration measurement, the 2431 loopback is applied and the result is output in the same format as a 2432 normal measurement with additional indication that it is a 2433 calibration result. In any measurement, the measurement function 2434 SHOULD report its current estimate of time offset as an indicator of 2435 the degree of synchronization. 2437 Both internal loopback calibration and clock synchronization can be 2438 used to estimate the *available accuracy* of the Output Metric Units. 2439 For example, repeated loopback delay measurements will reveal the 2440 portion of the Output result resolution which is the result of system 2441 noise, and thus inaccurate. 2443 8.5. Administrative items 2445 8.5.1. Status 2447 Current 2449 8.5.2. Requestor 2451 This RFC number 2453 8.5.3. Revision 2455 1.0 2457 8.5.4. Revision Date 2459 YYYY-MM-DD 2461 8.6. Comments and Remarks 2463 None. 2465 9. ICMP Round-trip Latency and Loss Registry Entries 2467 This section specifies three initial registry entries for the ICMP 2468 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2470 This section specifies four Registry entries with many common 2471 columns. 2473 All column entries beside the ID, Name, Description, and Output 2474 Reference Method categories are the same, thus this section proposes 2475 two closely-related registry entries. As a result, IANA is also 2476 asked to assign four corresponding URLs to each Named Metric. 2478 9.1. Summary 2480 This category includes multiple indexes to the registry entry: the 2481 element ID and metric name. 2483 9.1.1. ID (Identifier) 2485 IANA is asked to assign different numeric identifiers to each of the 2486 four Named Metrics. 2488 9.1.2. Name 2490 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_ 2492 where is one of: 2494 o Mean 2496 o Min 2498 o Max 2500 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio 2502 9.1.3. URIs 2504 URL: http:/// 2506 9.1.4. Description 2508 RTDelay: This metric assesses the delay of a stream of ICMP packets 2509 exchanged between two hosts (which are the two measurement points), 2510 and the Output is the Round-trip delay for all successfully exchanged 2511 packets expressed as the of their conditional delay 2512 distribution, where is one of: 2514 o Mean 2516 o Min 2518 o Max 2520 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2521 packets exchanged between two hosts (which are the two measurement 2522 points), and the Output is the Round-trip loss ratio for all 2523 successfully exchanged packets expressed as a percentage. 2525 9.1.5. Change Controller 2527 IETF 2529 9.1.6. Version (of Registry Format) 2531 1.0 2533 9.2. Metric Definition 2535 This category includes columns to prompt the entry of all necessary 2536 details related to the metric definition, including the RFC reference 2537 and values of input factors, called fixed parameters. 2539 9.2.1. Reference Definition 2541 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2542 Metric for IPPM", RFC 2681, September 1999. 2544 [RFC2681] 2546 Section 2.4 of [RFC2681] provides the reference definition of the 2547 singleton (single value) Round-trip delay metric. Section 3.4 of 2548 [RFC2681] provides the reference definition expanded to cover a 2549 multi-singleton sample. Note that terms such as singleton and sample 2550 are defined in Section 11 of [RFC2330]. 2552 Note that although the [RFC2681] definition of "Round-trip-Delay 2553 between Src and Dst" is directionally ambiguous in the text, this 2554 metric tightens the definition further to recognize that the host in 2555 the "Src" role will send the first packet to "Dst", and ultimately 2556 receive the corresponding return packet from "Dst" (when neither are 2557 lost). 2559 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2560 the value of Round-trip delay in metric definitions and methods. The 2561 variable "dT" has been re-used in other IPPM literature to refer to 2562 different quantities, and cannot be used as a global variable name. 2564 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2566 [RFC6673] 2568 Both delay and loss metrics employ a maximum waiting time for 2569 received packets, so the count of lost packets to total packets sent 2570 is the basis for the loss ratio calculation as per Section 6.1 of 2571 [RFC6673]. 2573 9.2.2. Fixed Parameters 2575 Type-P as defined in Section 13 of [RFC2330]: 2577 o IPv4 header values: 2579 * DSCP: set to 0 2580 * TTL: set to 255 2582 * Protocol: Set to 01 (ICMP) 2584 o IPv6 header values: 2586 * DSCP: set to 0 2588 * Hop Limit: set to 255 2590 * Protocol: Set to 01 (ICMP) 2592 o ICMP header values: 2594 * Type: 8 (Echo Request) 2596 * Code: 0 2598 * Checksum: the checksum MUST be calculated and included in the 2599 header 2601 * (Identifier and Sequence Number set at Run-Time) 2603 o ICMP Payload 2605 * total of 32 bytes of random info 2607 Other measurement parameters: 2609 o Tmax: a loss threshold waiting time 2611 * 3.0, expressed in units of seconds, as a positive value of type 2612 decimal64 with fraction digits = 4 (see section 9.3 of 2613 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2614 lossless conversion to/from the 32-bit NTP timestamp as per 2615 section 6 of [RFC5905]. 2617 9.3. Method of Measurement 2619 This category includes columns for references to relevant sections of 2620 the RFC(s) and any supplemental information needed to ensure an 2621 unambiguous methods for implementations. 2623 9.3.1. Reference Method 2625 The methodology for this metric is defined as Type-P-Round-trip- 2626 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2627 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2628 Fixed Parameters. 2630 The reference method distinguishes between long-delayed packets and 2631 lost packets by implementing a maximum waiting time for packet 2632 arrival. Tmax is the waiting time used as the threshold to declare a 2633 packet lost. Lost packets SHALL be designated as having undefined 2634 delay, and counted for the RTLoss metric. 2636 The calculations on the delay (RTD) SHALL be performed on the 2637 conditional distribution, conditioned on successful packet arrival 2638 within Tmax. Also, when all packet delays are stored, the process 2639 which calculates the RTD value MAY enforce the Tmax threshold on 2640 stored values before calculations. See section 4.1 of [RFC3393] for 2641 details on the conditional distribution to exclude undefined values 2642 of delay, and Section 5 of [RFC6703] for background on this analysis 2643 choice. 2645 The reference method requires some way to distinguish between 2646 different packets in a stream to establish correspondence between 2647 sending times and receiving times for each successfully-arriving 2648 packet. Sequence numbers or other send-order identification MUST be 2649 retained at the Src or included with each packet to disambiguate 2650 packet reordering if it occurs. 2652 The measurement process will determine the sequence numbers applied 2653 to test packets after the Fixed and Runtime parameters are passed to 2654 that process. The ICMP measurement process and protocol will dictate 2655 the format of sequence numbers and other identifiers. 2657 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2658 instruction to "send a Type-P packet back to the Src as quickly as 2659 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2660 [RFC6673] presents additional requirements which MUST be included in 2661 the method of measurement for this metric. 2663 9.3.2. Packet Stream Generation 2665 This section gives the details of the packet traffic which is the 2666 basis for measurement. In IPPM metrics, this is called the Stream, 2667 and can easily be described by providing the list of stream 2668 parameters. 2670 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2671 On Receive. This is a modification of Section 3 of [RFC3432], which 2672 prescribes the method for generating Periodic streams using 2673 associated parameters as defined below for this description: 2675 incT the nominal duration of inter-packet interval, first bit to 2676 first bit 2678 dT the duration of the interval for allowed sample start times 2680 The incT stream parameter will be specified as a Run-time parameter, 2681 and dT is not used in SendOnRcv. 2683 A SendOnRcv sender behaves exactly like a Periodic stream generator 2684 while all reply packets arrive with RTD < incT, and the inter-packet 2685 interval will be constant. 2687 If a reply packet arrives with RTD >= incT, then the inter-packet 2688 interval for the next sending time is nominally RTD. 2690 If a reply packet fails to arrive within Tmax, then the inter-packet 2691 interval for the next sending time is nominally Tmax. 2693 If an immediate send on reply arrival is desired, then set incT=0. 2695 9.3.3. Traffic Filtering (observation) Details 2697 The measured results based on a filtered version of the packets 2698 observed, and this section provides the filter details (when 2699 present). 2701 NA 2703 9.3.4. Sampling Distribution 2705 NA 2707 9.3.5. Run-time Parameters and Data Format 2709 Run-time Parameters are input factors that must be determined, 2710 configured into the measurement system, and reported with the results 2711 for the context to be complete. 2713 Src the IP address of the host in the Src Role (format ipv4-address- 2714 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2715 see Section 4 of [RFC6991]) 2717 Dst the IP address of the host in the Dst Role (format ipv4-address- 2718 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2719 see section 4 of [RFC6991]) 2721 incT the nominal duration of inter-packet interval, first bit to 2722 first bit, expressed in units of seconds, as a positive value of 2723 type decimal64 with fraction digits = 4 (see section 9.3 of 2724 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 2726 T0 a time, the start of a measurement interval, (format "date-and- 2727 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2728 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2729 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2730 and Tf is to be interpreted as the Duration of the measurement 2731 interval. The start time is controlled through other means. 2733 Count The total count of ICMP Echo Requests to send, formatted as a 2734 uint16, as per section 9.2 of [RFC6020]. 2736 (see the Packet Stream Generation section for additional Run-time 2737 parameters) 2739 9.3.6. Roles 2741 Src launches each packet and waits for return transmissions from 2742 Dst. 2744 Dst waits for each packet from Src and sends a return packet to Src. 2746 9.4. Output 2748 This category specifies all details of the Output of measurements 2749 using the metric. 2751 9.4.1. Type 2753 See subsection titles in Reference Definition for Latency Types. 2755 LossRatio -- the count of lost packets to total packets sent is the 2756 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 2758 9.4.2. Reference Definition 2760 For all output types --- 2762 T0 the start of a measurement interval, (format "date-and-time" as 2763 specified in Section 5.6 of [RFC3339], see also Section 3 of 2764 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2765 [RFC2330]. 2767 Tf the end of a measurement interval, (format "date-and-time" as 2768 specified in Section 5.6 of [RFC3339], see also Section 3 of 2769 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2770 [RFC2330]. 2772 TotalCount the count of packets actually sent by the Src to Dst 2773 during the measurement interval. 2775 For LossRatio -- the count of lost packets to total packets sent is 2776 the basis for the loss ratio calculation as per Section 4.1 of 2777 [RFC7680]. 2779 For each , one of the following sub-sections apply: 2781 9.4.2.1. Mean 2783 The mean SHALL be calculated using the conditional distribution of 2784 all packets with a finite value of Round-trip delay (undefined delays 2785 are excluded), a single value as follows: 2787 See section 4.1 of [RFC3393] for details on the conditional 2788 distribution to exclude undefined values of delay, and Section 5 of 2789 [RFC6703] for background on this analysis choice. 2791 See section 4.2.2 of [RFC6049] for details on calculating this 2792 statistic, and 4.2.3 of [RFC6049]. 2794 Mean The time value of the result is expressed in units of seconds, 2795 as a positive value of type decimal64 with fraction digits = 9 2796 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2797 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2798 NTP timestamp as per section 6 of RFC [RFC5905] 2800 9.4.2.2. Min 2802 The minimum SHALL be calculated using the conditional distribution of 2803 all packets with a finite value of Round-trip delay (undefined delays 2804 are excluded), a single value as follows: 2806 See section 4.1 of [RFC3393] for details on the conditional 2807 distribution to exclude undefined values of delay, and Section 5 of 2808 [RFC6703] for background on this analysis choice. 2810 See section 4.3.2 of [RFC6049] for details on calculating this 2811 statistic, and 4.3.3 of [RFC6049]. 2813 Min The time value of the result is expressed in units of seconds, 2814 as a positive value of type decimal64 with fraction digits = 9 2815 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2816 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2817 NTP timestamp as per section 6 of RFC [RFC5905] 2819 9.4.2.3. Max 2821 The maximum SHALL be calculated using the conditional distribution of 2822 all packets with a finite value of Round-trip delay (undefined delays 2823 are excluded), a single value as follows: 2825 See section 4.1 of [RFC3393] for details on the conditional 2826 distribution to exclude undefined values of delay, and Section 5 of 2827 [RFC6703] for background on this analysis choice. 2829 See section 4.3.2 of [RFC6049] for a closely related method for 2830 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2831 as follows: 2833 Max = (FiniteDelay [j]) 2835 such that for some index, j, where 1 <= j <= N 2836 FiniteDelay[j] >= FiniteDelay[n] for all n 2838 Max The time value of the result is expressed in units of seconds, 2839 as a positive value of type decimal64 with fraction digits = 9 2840 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2841 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2842 NTP timestamp as per section 6 of RFC [RFC5905] 2844 9.4.3. Metric Units 2846 The of Round-trip Delay is expressed in seconds, where 2847 is one of: 2849 o Mean 2851 o Min 2853 o Max 2855 The Round-trip Loss Ratio is expressed as a percentage of lost 2856 packets to total packets sent. 2858 9.4.4. Calibration 2860 Section 3.7.3 of [RFC7679] provides a means to quantify the 2861 systematic and random errors of a time measurement. In-situ 2862 calibration could be enabled with an internal loopback at the Source 2863 host that includes as much of the measurement system as possible, 2864 performs address manipulation as needed, and provides some form of 2865 isolation (e.g., deterministic delay) to avoid send-receive interface 2866 contention. Some portion of the random and systematic error can be 2867 characterized this way. 2869 When a measurement controller requests a calibration measurement, the 2870 loopback is applied and the result is output in the same format as a 2871 normal measurement with additional indication that it is a 2872 calibration result. 2874 Both internal loopback calibration and clock synchronization can be 2875 used to estimate the *available accuracy* of the Output Metric Units. 2876 For example, repeated loopback delay measurements will reveal the 2877 portion of the Output result resolution which is the result of system 2878 noise, and thus inaccurate. 2880 9.5. Administrative items 2882 9.5.1. Status 2884 Current 2886 9.5.2. Requestor 2888 This RFC number 2890 9.5.3. Revision 2892 1.0 2894 9.5.4. Revision Date 2896 YYYY-MM-DD 2898 9.6. Comments and Remarks 2900 None 2902 10. TCP Round-Trip Delay and Loss Registry Entries 2904 This section specifies three initial registry entries for the Passive 2905 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 2906 Round-trip Loss Count. 2908 This section specifies four Registry entries with many common 2909 columns. 2911 All column entries beside the ID, Name, Description, and Output 2912 Reference Method categories are the same, thus this section proposes 2913 four closely-related registry entries. As a result, IANA is also 2914 asked to assign four corresponding URLs to each Named Metric. 2916 10.1. Summary 2918 This category includes multiple indexes to the registry entry: the 2919 element ID and metric name. 2921 10.1.1. ID (Identifier) 2923 IANA is asked to assign different numeric identifiers to each of the 2924 four Named Metrics. 2926 10.1.2. Name 2928 RTDelay_Passive_IP-TCP_RFCXXXXsec10_Seconds_ 2930 where is one of: 2932 o Mean 2934 o Min 2936 o Max 2938 RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton 2940 Note that a mid-point observer only has the opportuinty to compose a 2941 single RTDelay on the TCP Hand Shake. 2943 RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count 2945 10.1.3. URIs 2947 URL: https:/// 2949 10.1.4. Description 2951 RTDelay: This metric assesses the round-trip delay of TCP packets 2952 constituting a single connection, exchanged between two hosts. We 2953 consider the measurement of round-trip delay based on a single 2954 Observation Point [RFC7011] somewhere in the network. The Output is 2955 the Round-trip delay for all successfully exchanged packets expressed 2956 as the of their conditional delay distribution, where 2957 is one of: 2959 o Mean 2960 o Min 2962 o Max 2964 RTLoss: This metric assesses the estimated loss count for TCP packets 2965 constituting a single connection, exchanged between two hosts. We 2966 consider the measurement of round-trip delay based on a single 2967 Observation Point [RFC7011] somewhere in the network. The Output is 2968 the estimated Loss Count for the measurement interval. 2970 10.1.5. Change Controller 2972 IETF 2974 10.1.6. Version (of Registry Format) 2976 1.0 2978 10.2. Metric Definition 2980 This category includes columns to prompt the entry of all necessary 2981 details related to the metric definition, including the RFC reference 2982 and values of input factors, called fixed parameters. 2984 10.2.1. Reference Definitions 2986 Although there is no RFC that describes passive measurement of Round- 2987 Trip Delay, the parallel definition for Active measurement is: 2989 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2990 Metric for IPPM", RFC 2681, September 1999. 2992 [RFC2681] 2994 This metric definition uses the terms singleton and sample as defined 2995 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 2996 reference definition of the singleton (single value) Round-trip delay 2997 metric. Section 3.4 of [RFC2681] provides the reference definition 2998 expanded to cover a multi-singleton sample.) 3000 With the Observation Point [RFC7011] (OP) typically located between 3001 the hosts participating in the TCP connection, the Round-trip Delay 3002 metric requires two individual measurements between the OP and each 3003 host, such that the Spatial Composition [RFC6049]of the measurements 3004 yields a Round-trip Delay singleton (we are extending the composition 3005 of one-way subpath delays to subpath round-trip delay). 3007 Using the direction of TCP SYN transmission to anchor the 3008 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3009 during connection establishment. The direction of SYN transfer is 3010 considered the Forward direction of transmission, from A through OP 3011 to B (Reverse is B through OP to A). 3013 Traffic filters reduce the packet stream at the OP to a Qualified 3014 bidirectional flow packets. 3016 In the definitions below, Corresponding Packets are transferred in 3017 different directions and convey a common value in a TCP header field 3018 that establishes correspondence (to the extent possible). Examples 3019 may be found in the TCP timestamp fields. 3021 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3022 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3023 observed a Qualified Packet to host B at wire-time T', that host B 3024 received that packet and sent a Corresponding Packet back to host A, 3025 and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. 3027 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3028 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3029 OP observed a Qualified Packet to host A at wire-time T'', that host 3030 A received that packet and sent a Corresponding Packet back to host 3031 B, and that OP observed the Corresponding Packet at wire-time T'' + 3032 RTD_rev. 3034 Ideally, the packet sent from host B to host A in both definitions 3035 above SHOULD be the same packet (or, when measuring RTD_rev first, 3036 the packet from host A to host B in both definitions should be the 3037 same). 3039 The REQUIRED Composition Function for a singleton of Round-trip Delay 3040 at time T (where T is the earliest of T' and T'' above) is: 3042 RTDelay = RTD_fwd + RTD_rev 3044 Note that when OP is located at host A or host B, one of the terms 3045 composing RTDelay will be zero or negligible. 3047 When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- 3048 SYN-ACK, then RTD_fwd == RTD_HS_fwd. 3050 When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a 3051 TCP-ACK, then RTD_rev == RTD_HS_rev. 3053 The REQUIRED Composition Function for a singleton of Round-trip Delay 3054 for the connection Hand Shake: 3056 RTDelay_HS = RTD_HS_fwd + RTD_HS_rev 3058 The definition of Round-trip Loss Count uses the nomenclature 3059 developed above, based on observation of the TCP header sequence 3060 numbers and storing the sequence number gaps observed. Packet Losses 3061 can be inferred from: 3063 o Out-of-order segments: TCP segments are transmitted with 3064 monotonically increasing sequence numbers, but these segments may 3065 be received out of order. Section 3 of [RFC4737] describes the 3066 notion of "next expected" sequence numbers which can be adapted to 3067 TCP segments (for the purpose of detecting reordered packets). 3068 Observation of out-of-order segments indicates loss on the path 3069 prior to the OP, and creates a gap. 3071 o Duplicate segments: Section 2 of [RFC5560] defines identical 3072 packets and is suitable for evaluation of TCP packets to detect 3073 duplication. Observation of duplicate segments *without a 3074 corresponding gap* indicates loss on the path following the OP 3075 (because they overlap part of the delivered sequence numbers 3076 already observed at OP). 3078 Each observation of an out-of-order or duplicate infers a singleton 3079 of loss, but composition of Round-trip Loss Counts will be conducted 3080 over a measurement interval which is synonymous with a single TCP 3081 connection. 3083 With the above observations in the Forward direction over a 3084 measurement interval, the count of out-of-order and duplicate 3085 segments is defined as RTL_fwd. Comparable observations in the 3086 Reverse direction are defined as RTL_rev. 3088 For a measurement interval (corresponding to a single TCP 3089 connection), T0 to Tf, the REQUIRED Composition Function for a the 3090 two single-direction counts of inferred loss is: 3092 RTLoss = RTL_fwd + RTL_rev 3094 10.2.2. Fixed Parameters 3096 Traffic Filters: 3098 o IPv4 header values: 3100 * DSCP: set to 0 3102 * Protocol: Set to 06 (TCP) 3104 o IPv6 header values: 3106 * DSCP: set to 0 3108 * Protocol: Set to 06 (TCP) 3110 o TCP header values: 3112 * Flags: ACK, SYN, FIN, set as required 3114 * Timestamp Option (TSopt): Set 3116 + Section 3.2 of [RFC7323] 3118 10.3. Method of Measurement 3120 This category includes columns for references to relevant sections of 3121 the RFC(s) and any supplemental information needed to ensure an 3122 unambiguous methods for implementations. 3124 10.3.1. Reference Methods 3126 The foundation methodology for this metric is defined in Section 4 of 3127 [RFC7323] using the Timestamp Option with modifications that allow 3128 application at a mid-path Observation Point (OP) [RFC7011]. Further 3129 details and applicable heuristics were derived from [Strowes] and 3130 [Trammell-14]. 3132 The Traffic Filter at the OP is configured to observe a single TCP 3133 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3134 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3135 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3136 of RTDelay as RTDelay_HS (composed using the forward and reverse 3137 measurement pair). RTDelay_HS SHALL be treated separately from other 3138 RTDelays on data-bearing packets and their ACKs. The RTDelay_HS 3139 value MAY be used as a sanity check on other Composed values of 3140 RTDelay. 3142 For payload bearing packets, the OP measures the time interval 3143 between observation of a packet with Sequence Number s, and the 3144 corresponding ACK with same Sequence number. When the payload is 3145 transferred from host A to host B, the observed interval is RTD_fwd. 3147 Because many data transfers are unidirectional (say, in the Forward 3148 direction from host A to host B), it is necessary to use pure ACK 3149 packets with Timestamp (TSval) and their Timestamp value echo to 3150 perform a RTD_rev measurement. The time interval between observation 3151 of the ACK from B to A, and the corresponding packet with Timestamp 3152 echo (TSecr) is the RTD_rev. 3154 Delay Measurement Filtering Heuristics: 3156 If Data payloads were transferred in both Forward and Reverse 3157 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3158 of [RFC7323] could be applied. This rule essentially excludes any 3159 measurement using a packet unless it makes progress in the transfer 3160 (advances the left edge of the send window, consistent 3161 with[Strowes]). 3163 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3164 that is larger than previously observed values. This would tend to 3165 exclude Reverse measurements taken when the Application has no data 3166 ready to send, because considerable time could be added to RTD_rev 3167 from this source of error. 3169 Note that the above Heuristic assumes that host A is sending data. 3170 Host A expecting a download would mean that this heuristic should be 3171 applied to RTD_fwd. 3173 The statistic calculations to summarize the delay (RTDelay) SHALL be 3174 performed on the conditional distribution, conditioned on successful 3175 Forward and Reverse measurements which follow the Heuristics. 3177 Method for Inferring Loss: 3179 The OP tracks sequence numbers and stores gaps for each direction of 3180 transmission, as well as the next-expected sequence number as in 3181 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3182 segments and Duplicate segments. 3184 Loss Measurement Filtering Heuristics: 3186 [Trammell-14] adds a window of evaluation based on the RTDelay. 3188 Distinguish Re-ordered from OOO due to loss, because sequence number 3189 gap is filled during the same RTDelay window. Segments detected as 3190 re-ordered according to [RFC4737] MUST reduce the Loss Count inferred 3191 from Out-of-order segments. 3193 Spurious (unneeded) retransmissions (observed as duplicates) can also 3194 be reduced this way, as described in [Trammell-14]. 3196 Sources of Error: 3198 The principal source of RTDelay error is the host processing time to 3199 return a packet that defines the termination of a time interval. The 3200 heuristics above intend to mitigate these errors by excluding 3201 measurements where host processing time is a significant part of 3202 RTD_fwd or RTD_rev. 3204 A key source of RTLoss error is observation loss, described in 3205 section 3 of [Trammell-14]. 3207 10.3.2. Packet Stream Generation 3209 This section gives the details of the packet traffic which is the 3210 basis for measurement. In IPPM metrics, this is called the Stream, 3211 and can easily be described by providing the list of stream 3212 parameters. 3214 NA 3216 10.3.3. Traffic Filtering (observation) Details 3218 The measured results based on a filtered version of the packets 3219 observed, and this section provides the filter details (when 3220 present). 3222 The Fixed Parameters above give a portion of the Traffic Filter. 3223 Other aspects will be supplied as Run-time Parameters (below). 3225 10.3.4. Sampling Distribution 3227 This metric requires a complete sample of all packets that qualify 3228 according to the Traffic Filter criteria. 3230 10.3.5. Run-time Parameters and Data Format 3232 Run-time Parameters are input factors that must be determined, 3233 configured into the measurement system, and reported with the results 3234 for the context to be complete. 3236 Src the IP address of the host in the host A Role (format ipv4- 3237 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3238 IPv6, see Section 4 of [RFC6991]) 3240 Dst the IP address of the host in the host B (format ipv4-address- 3241 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3242 see section 4 of [RFC6991]) 3244 T0 a time, the start of a measurement interval, (format "date-and- 3245 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3246 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3247 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3248 and Td is to be interpreted as the Duration of the measurement 3249 interval. The start time is controlled through other means. 3251 Td Optionally, the end of a measurement interval, (format "date-and- 3252 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3253 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3254 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3255 the measurement interval MAY be controlled by the measured 3256 connection, where the second pair of FIN and ACK packets exchanged 3257 between host A and B effectively ends the interval. 3259 TTL or Hop Limit Set at desired value. 3261 10.3.6. Roles 3263 host A launches the SYN packet to open the connection, and 3264 synonymous with an IP address. 3266 host B replies with the SYN-ACK packet to open the connection, and 3267 synonymous with an IP address. 3269 10.4. Output 3271 This category specifies all details of the Output of measurements 3272 using the metric. 3274 10.4.1. Type 3276 See subsection titles in Reference Definition for RTDelay Types. 3278 For RTLoss -- the count of lost packets. 3280 10.4.2. Reference Definition 3282 For all output types --- 3284 T0 the start of a measurement interval, (format "date-and-time" as 3285 specified in Section 5.6 of [RFC3339], see also Section 3 of 3286 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3287 [RFC2330]. 3289 Tf the end of a measurement interval, (format "date-and-time" as 3290 specified in Section 5.6 of [RFC3339], see also Section 3 of 3291 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3292 [RFC2330]. The end of the measurement interval MAY be controlled 3293 by the measured connection, where the second pair of FIN and ACK 3294 packets exchanged between host A and B effectively ends the 3295 interval. 3297 ... ... 3299 For RTDelay_HS -- the Round trip delay of the Handshake. 3301 For RTLoss -- the count of lost packets. 3303 For each , one of the following sub-sections apply: 3305 10.4.2.1. Mean 3307 The mean SHALL be calculated using the conditional distribution of 3308 all packets with a finite value of Round-trip delay (undefined delays 3309 are excluded), a single value as follows: 3311 See section 4.1 of [RFC3393] for details on the conditional 3312 distribution to exclude undefined values of delay, and Section 5 of 3313 [RFC6703] for background on this analysis choice. 3315 See section 4.2.2 of [RFC6049] for details on calculating this 3316 statistic, and 4.2.3 of [RFC6049]. 3318 Mean The time value of the result is expressed in units of seconds, 3319 as a positive value of type decimal64 with fraction digits = 9 3320 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3321 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3322 NTP timestamp as per section 6 of RFC [RFC5905] 3324 10.4.2.2. Min 3326 The minimum SHALL be calculated using the conditional distribution of 3327 all packets with a finite value of Round-trip delay (undefined delays 3328 are excluded), a single value as follows: 3330 See section 4.1 of [RFC3393] for details on the conditional 3331 distribution to exclude undefined values of delay, and Section 5 of 3332 [RFC6703] for background on this analysis choice. 3334 See section 4.3.2 of [RFC6049] for details on calculating this 3335 statistic, and 4.3.3 of [RFC6049]. 3337 Min The time value of the result is expressed in units of seconds, 3338 as a positive value of type decimal64 with fraction digits = 9 3339 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3340 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3341 NTP timestamp as per section 6 of RFC [RFC5905] 3343 10.4.2.3. Max 3345 The maximum SHALL be calculated using the conditional distribution of 3346 all packets with a finite value of Round-trip delay (undefined delays 3347 are excluded), a single value as follows: 3349 See section 4.1 of [RFC3393] for details on the conditional 3350 distribution to exclude undefined values of delay, and Section 5 of 3351 [RFC6703] for background on this analysis choice. 3353 See section 4.3.2 of [RFC6049] for a closely related method for 3354 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3355 as follows: 3357 Max = (FiniteDelay [j]) 3359 such that for some index, j, where 1 <= j <= N 3360 FiniteDelay[j] >= FiniteDelay[n] for all n 3362 Max The time value of the result is expressed in units of seconds, 3363 as a positive value of type decimal64 with fraction digits = 9 3364 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3365 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3366 NTP timestamp as per section 6 of RFC [RFC5905] 3368 10.4.3. Metric Units 3370 The of Round-trip Delay is expressed in seconds, where 3371 is one of: 3373 o Mean 3375 o Min 3377 o Max 3379 The Round-trip Delay of the Hand Shake is expressed in seconds. 3381 The Round-trip Loss Count is expressed as a number of packets. 3383 10.4.4. Calibration 3385 Passive measurements at an OP could be calibrated against an active 3386 measurement (with loss emulation) at host A or B, where the active 3387 measurement represents the ground-truth. 3389 10.5. Administrative items 3391 10.5.1. Status 3393 Current 3395 10.5.2. Requestor 3397 This RFC 3399 10.5.3. Revision 3401 1.0 3403 10.5.4. Revision Date 3405 YYYY-MM-DD 3407 10.6. Comments and Remarks 3409 None. 3411 11. Security Considerations 3413 These registry entries represent no known implications for Internet 3414 Security. Each referenced Metric contains a Security Considerations 3415 section. 3417 12. IANA Considerations 3419 IANA is requested to populate The Performance Metrics Registry 3420 defined in [I-D.ietf-ippm-metric-registry] with the values defined in 3421 sections 4 through 10. 3423 See the IANA Considerations section of 3424 [I-D.ietf-ippm-metric-registry] for additional requests and 3425 considerations. 3427 13. Acknowledgements 3429 The authors thank Brian Trammell for suggesting the term "Run-time 3430 Parameters", which led to the distinction between run-time and fixed 3431 parameters implemented in this memo, for identifying the IPFIX metric 3432 with Flow Key as an example, for suggesting the Passive TCP RTD 3433 metric and supporting references, and for many other productive 3434 suggestions. Thanks to Peter Koch, who provided several useful 3435 suggestions for disambiguating successive DNS Queries in the DNS 3436 Response time metric. 3438 The authors also acknowledge the constructive reviews and helpful 3439 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, 3440 Yaakov Stein, and participants in the LMAP working group. Thanks to 3441 Michelle Cotton for her early IANA review, and to Amanda Barber for 3442 answering questions related to the presentation of the registry and 3443 accessibility of the complete template via URL. 3445 14. References 3447 14.1. Normative References 3449 [I-D.ietf-ippm-metric-registry] 3450 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 3451 "Registry for Performance Metrics", Internet Draft (work 3452 in progress) draft-ietf-ippm-metric-registry, 2019. 3454 [RFC1035] Mockapetris, P., "Domain names - implementation and 3455 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3456 November 1987, . 3458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3459 Requirement Levels", BCP 14, RFC 2119, 3460 DOI 10.17487/RFC2119, March 1997, 3461 . 3463 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 3464 "Framework for IP Performance Metrics", RFC 2330, 3465 DOI 10.17487/RFC2330, May 1998, 3466 . 3468 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 3469 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 3470 September 1999, . 3472 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3473 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3474 . 3476 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 3477 Metric for IP Performance Metrics (IPPM)", RFC 3393, 3478 DOI 10.17487/RFC3393, November 2002, 3479 . 3481 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 3482 performance measurement with periodic streams", RFC 3432, 3483 DOI 10.17487/RFC3432, November 2002, 3484 . 3486 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 3487 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 3488 DOI 10.17487/RFC4737, November 2006, 3489 . 3491 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3492 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 3493 RFC 5357, DOI 10.17487/RFC5357, October 2008, 3494 . 3496 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 3497 RFC 5560, DOI 10.17487/RFC5560, May 2009, 3498 . 3500 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 3501 "Network Time Protocol Version 4: Protocol and Algorithms 3502 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 3503 . 3505 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3506 the Network Configuration Protocol (NETCONF)", RFC 6020, 3507 DOI 10.17487/RFC6020, October 2010, 3508 . 3510 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 3511 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 3512 . 3514 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 3515 DOI 10.17487/RFC6673, August 2012, 3516 . 3518 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3519 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3520 . 3522 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3523 "Specification of the IP Flow Information Export (IPFIX) 3524 Protocol for the Exchange of Flow Information", STD 77, 3525 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3526 . 3528 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 3529 Scheffenegger, Ed., "TCP Extensions for High Performance", 3530 RFC 7323, DOI 10.17487/RFC7323, September 2014, 3531 . 3533 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3534 Ed., "A One-Way Delay Metric for IP Performance Metrics 3535 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 3536 2016, . 3538 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3539 Ed., "A One-Way Loss Metric for IP Performance Metrics 3540 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 3541 2016, . 3543 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3544 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3545 May 2017, . 3547 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, 3548 Communications of the ACM, Vol. 56 No. 10, Pages 57-64", 3549 September 2013. 3551 [Trammell-14] 3552 Trammell, B., "Inline Data Integrity Signals for Passive 3553 Measurement, In: Dainotti A., Mahanti A., Uhlig S. (eds) 3554 Traffic Monitoring and Analysis. TMA 2014. Lecture Notes 3555 in Computer Science, vol 8406. Springer, Berlin, 3556 Heidelberg https://link.springer.com/ 3557 chapter/10.1007/978-3-642-54999-1_2", March 2014. 3559 14.2. Informative References 3561 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 3562 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 3563 July 1991, . 3565 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 3566 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 3567 March 2009, . 3569 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 3570 Performance Metric Development", BCP 170, RFC 6390, 3571 DOI 10.17487/RFC6390, October 2011, 3572 . 3574 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 3575 IP Network Performance Metrics: Different Points of View", 3576 RFC 6703, DOI 10.17487/RFC6703, August 2012, 3577 . 3579 Authors' Addresses 3581 Al Morton 3582 AT&T Labs 3583 200 Laurel Avenue South 3584 Middletown,, NJ 07748 3585 USA 3587 Phone: +1 732 420 1571 3588 Fax: +1 732 368 1192 3589 Email: acmorton@att.com 3591 Marcelo Bagnulo 3592 Universidad Carlos III de Madrid 3593 Av. Universidad 30 3594 Leganes, Madrid 28911 3595 SPAIN 3597 Phone: 34 91 6249500 3598 Email: marcelo@it.uc3m.es 3599 URI: http://www.it.uc3m.es 3601 Philip Eardley 3602 BT 3603 Adastral Park, Martlesham Heath 3604 Ipswich 3605 ENGLAND 3607 Email: philip.eardley@bt.com 3609 Kevin D'Souza 3610 AT&T Labs 3611 200 Laurel Avenue South 3612 Middletown,, NJ 07748 3613 USA 3615 Phone: +1 732 420 xxxx 3616 Email: kld@att.com