idnits 2.17.1 draft-ietf-ippm-initial-registry-15.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 588 has weird spacing: '... Src the IP...' == Line 592 has weird spacing: '... Dst the IP...' == Line 612 has weird spacing: '... Src launch...' == Line 615 has weird spacing: '... Dst waits ...' == Line 657 has weird spacing: '...talPkts the c...' == (25 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 (December 11, 2019) is 1597 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 (~~), 9 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: June 13, 2020 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 December 11, 2019 12 Initial Performance Metrics Registry Entries 13 draft-ietf-ippm-initial-registry-15 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 June 13, 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 . . . . . . . . . . . . . . . . . . . . 10 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. Requester . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . 22 120 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 121 5.5. Administrative items . . . . . . . . . . . . . . . . . . 23 122 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 123 5.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 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) . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . 31 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. Requester . . . . . . . . . . . . . . . . . . . . . . 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) . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . 36 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. Requester . . . . . . . . . . . . . . . . . . . . . . 42 181 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 182 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43 183 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43 184 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 43 185 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 186 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 187 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 188 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44 189 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 44 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 . . . . . . . 48 197 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48 198 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 199 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 200 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49 201 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49 202 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 203 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52 204 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 205 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 206 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 207 8.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 53 208 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 209 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 210 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 54 211 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 54 212 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54 213 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54 214 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 215 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54 216 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 55 217 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 55 218 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 55 219 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55 220 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 221 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 56 222 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 57 223 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 57 224 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 58 225 9.3.3. Traffic Filtering (observation) Details . . . . . . . 59 226 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 59 227 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 59 228 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 229 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 60 230 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 60 231 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 60 232 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 62 233 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 62 234 9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 235 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 236 9.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 63 237 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 63 238 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 63 239 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 63 240 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 63 241 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63 242 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 243 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 244 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 64 245 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 64 246 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 247 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 248 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 65 249 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 65 250 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 67 251 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 68 252 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 68 253 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 69 254 10.3.3. Traffic Filtering (observation) Details . . . . . . 70 255 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 70 256 10.3.5. Run-time Parameters and Data Format . . . . . . . . 70 257 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 70 258 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 71 259 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 71 260 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 71 261 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 73 262 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 73 263 10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 264 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 265 10.5.2. Requester . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 74 270 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 271 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 272 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 273 14.1. Normative References . . . . . . . . . . . . . . . . . . 74 274 14.2. Informative References . . . . . . . . . . . . . . . . . 77 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 Specification Required policy, which includes Expert Review, which 305 will ensure that the metrics are tightly defined. 307 2. Scope 309 This document defines a set of initial Performance Metrics Registry 310 entries. Most are Active Performance Metrics, which are based on 311 RFCs prepared in the IPPM working group of the IETF, according to 312 their framework [RFC2330] and its updates. 314 3. Registry Categories and Columns 316 This memo uses the terminology defined in 317 [I-D.ietf-ippm-metric-registry]. 319 This section provides the categories and columns of the registry, for 320 easy reference. An entry (row) therefore gives a complete 321 description of a Registered Metric. 323 Legend: 324 Registry Categories and Columns, shown as 325 Category 326 ------------------ 327 Column | Column | 329 Summary 330 ------------------------------------------------------------------------ 331 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 333 Metric Definition 334 ----------------------------------------- 335 Reference Definition | Fixed Parameters | 337 Method of Measurement 338 --------------------------------------------------------------------- 339 Reference | Packet | Traffic | Sampling | Run-time | Role | 340 Method | Stream | Filter | Distribution | Parameters | | 341 | Generation | 342 Output 343 ----------------------------------------- 344 Type | Reference | Units | Calibration | 345 | Definition | | | 347 Administrative Information 348 ------------------------------------ 349 Status |Requester | Rev | Rev.Date | 351 Comments and Remarks 352 -------------------- 354 4. UDP Round-trip Latency and Loss Registry Entries 356 This section specifies an initial registry entry for the UDP Round- 357 trip Latency, and another entry for UDP Round-trip Loss Ratio. 359 Note: Each Registry entry only produces a "raw" output or a 360 statistical summary. To describe both "raw" and one or more 361 statistics efficiently, the Identifier, Name, and Output Categories 362 can be split and a single section can specify two or more closely- 363 related metrics. This section specifies two Registry entries with 364 many common columns. See Section 7 for an example specifying 365 multiple Registry entries with many common columns. 367 All column entries beside the ID, Name, Description, and Output 368 Reference Method categories are the same, thus this section proposes 369 two closely-related registry entries. As a result, IANA is also 370 asked to assign a corresponding URL to each Named Metric. 372 4.1. Summary 374 This category includes multiple indexes to the registry entry: the 375 element ID and metric name. 377 4.1.1. ID (Identifier) 379 IANA is asked to assign different numeric identifiers to each of the 380 two Named Metrics. 382 4.1.2. Name 384 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile 386 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio 388 4.1.3. URIs 390 URL: https://www.iana.org/ ... 392 4.1.4. Description 394 RTDelay: This metric assesses the delay of a stream of packets 395 exchanged between two hosts (which are the two measurement points), 396 and the Output is the Round-trip delay for all successfully exchanged 397 packets expressed as the 95th percentile of their conditional delay 398 distribution. 400 RTLoss: This metric assesses the loss ratio of a stream of packets 401 exchanged between two hosts (which are the two measurement points), 402 and the Output is the Round-trip loss ratio for all successfully 403 exchanged packets expressed as a percentage. 405 4.1.5. Change Controller 407 IETF 409 4.1.6. Version (of Registry Format) 411 1.0 413 4.2. Metric Definition 415 This category includes columns to prompt the entry of all necessary 416 details related to the metric definition, including the RFC reference 417 and values of input factors, called fixed parameters. 419 4.2.1. Reference Definition 421 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 422 Metric for IPPM", RFC 2681, September 1999. 424 [RFC2681] 426 Section 2.4 of [RFC2681] provides the reference definition of the 427 singleton (single value) Round-trip delay metric. Section 3.4 of 428 [RFC2681] provides the reference definition expanded to cover a 429 multi-singleton sample. Note that terms such as singleton and sample 430 are defined in Section 11 of [RFC2330]. 432 Note that although the [RFC2681] definition of "Round-trip-Delay 433 between Src and Dst" is directionally ambiguous in the text, this 434 metric tightens the definition further to recognize that the host in 435 the "Src" role will send the first packet to "Dst", and ultimately 436 receive the corresponding return packet from "Dst" (when neither are 437 lost). 439 Finally, note that the variable "dT" is used in [RFC2681] to refer to 440 the value of Round-trip delay in metric definitions and methods. The 441 variable "dT" has been re-used in other IPPM literature to refer to 442 different quantities, and cannot be used as a global variable name. 444 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 446 [RFC6673] 448 Both delay and loss metrics employ a maximum waiting time for 449 received packets, so the count of lost packets to total packets sent 450 is the basis for the loss ratio calculation as per Section 6.1 of 451 [RFC6673]. 453 4.2.2. Fixed Parameters 455 Type-P as defined in Section 13 of [RFC2330]: 457 o IPv4 header values: 459 * DSCP: set to 0 460 * TTL: set to 255 462 * Protocol: set to 17 (UDP) 464 o IPv6 header values: 466 * DSCP: set to 0 468 * Hop Count: set to 255 470 * Next Header: set to 17 (UDP) 472 * Flow Label: set to zero 474 * Extension Headers: none 476 o UDP header values: 478 * Checksum: the checksum MUST be calculated and the non-zero 479 checksum included in the header 481 o UDP Payload 483 * total of 100 bytes 485 Other measurement parameters: 487 o Tmax: a loss threshold waiting time 489 * 3.0, expressed in units of seconds, as a positive value of type 490 decimal64 with fraction digits = 4 (see section 9.3 of 491 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 492 lossless conversion to/from the 32-bit NTP timestamp as per 493 section 6 of [RFC5905]. 495 4.3. Method of Measurement 497 This category includes columns for references to relevant sections of 498 the RFC(s) and any supplemental information needed to ensure an 499 unambiguous methods for implementations. 501 4.3.1. Reference Method 503 The methodology for this metric is defined as Type-P-Round-trip- 504 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 505 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 506 Fixed Parameters. However, the Periodic stream will be generated 507 according to [RFC3432]. 509 The reference method distinguishes between long-delayed packets and 510 lost packets by implementing a maximum waiting time for packet 511 arrival. Tmax is the waiting time used as the threshold to declare a 512 packet lost. Lost packets SHALL be designated as having undefined 513 delay, and counted for the RTLoss metric. 515 The calculations on the delay (RTT) SHALL be performed on the 516 conditional distribution, conditioned on successful packet arrival 517 within Tmax. Also, when all packet delays are stored, the process 518 which calculates the RTT value MUST enforce the Tmax threshold on 519 stored values before calculations. See section 4.1 of [RFC3393] for 520 details on the conditional distribution to exclude undefined values 521 of delay, and Section 5 of [RFC6703] for background on this analysis 522 choice. 524 The reference method requires some way to distinguish between 525 different packets in a stream to establish correspondence between 526 sending times and receiving times for each successfully-arriving 527 packet. Sequence numbers or other send-order identification MUST be 528 retained at the Src or included with each packet to disambiguate 529 packet reordering if it occurs. 531 If a standard measurement protocol is employed, then the measurement 532 process will determine the sequence numbers or timestamps applied to 533 test packets after the Fixed and Runtime parameters are passed to 534 that process. The chosen measurement protocol will dictate the 535 format of sequence numbers and time-stamps, if they are conveyed in 536 the packet payload. 538 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 539 instruction to "send a Type-P packet back to the Src as quickly as 540 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 541 [RFC6673] presents additional requirements which MUST be included in 542 the method of measurement for this metric. 544 4.3.2. Packet Stream Generation 546 This section gives the details of the packet traffic which is the 547 basis for measurement. In IPPM metrics, this is called the Stream, 548 and can easily be described by providing the list of stream 549 parameters. 551 Section 3 of [RFC3432] prescribes the method for generating Periodic 552 streams using associated parameters. 554 incT the nominal duration of inter-packet interval, first bit to 555 first bit, with value 0.0200, expressed in units of seconds, as a 556 positive value of type decimal64 with fraction digits = 4 (see 557 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 558 (0.1 ms). 560 dT the duration of the interval for allowed sample start times, with 561 value 1.0, expressed in units of seconds, as a positive value of 562 type decimal64 with fraction digits = 4 (see section 9.3 of 563 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 565 NOTE: an initiation process with a number of control exchanges 566 resulting in unpredictable start times (within a time interval) may 567 be sufficient to avoid synchronization of periodic streams, and 568 therefore a valid replacement for selecting a start time at random 569 from a fixed interval. 571 The T0 parameter will be reported as a measured parameter. 572 Parameters incT and dT are Fixed Parameters. 574 4.3.3. Traffic Filtering (observation) Details 576 NA 578 4.3.4. Sampling Distribution 580 NA 582 4.3.5. Run-time Parameters and Data Format 584 Run-time Parameters are input factors that must be determined, 585 configured into the measurement system, and reported with the results 586 for the context to be complete. 588 Src the IP address of the host in the Src Role (format ipv4-address- 589 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 590 see Section 4 of [RFC6991]) 592 Dst the IP address of the host in the Dst Role (format ipv4-address- 593 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 594 see section 4 of [RFC6991]) 596 T0 a time, the start of a measurement interval, (format "date-and- 597 time" as specified in Section 5.6 of [RFC3339], see also Section 3 598 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 599 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 600 and Tf is to be interpreted as the Duration of the measurement 601 interval. The start time is controlled through other means. 603 Tf a time, the end of a measurement interval, (format "date-and-time" 604 as specified in Section 5.6 of [RFC3339], see also Section 3 of 606 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 607 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 608 Tf is interpreted as the Duration of the measurement interval. 610 4.3.6. Roles 612 Src launches each packet and waits for return transmissions from 613 Dst. 615 Dst waits for each packet from Src and sends a return packet to Src. 617 4.4. Output 619 This category specifies all details of the Output of measurements 620 using the metric. 622 4.4.1. Type 624 Percentile -- for the conditional distribution of all packets with a 625 valid value of Round-trip delay (undefined delays are excluded), a 626 single value corresponding to the 95th percentile, as follows: 628 See section 4.1 of [RFC3393] for details on the conditional 629 distribution to exclude undefined values of delay, and Section 5 of 630 [RFC6703] for background on this analysis choice. 632 The percentile = 95, meaning that the reported delay, "95Percentile", 633 is the smallest value of Round-trip delay for which the Empirical 634 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 635 Round-trip delay values in the conditional distribution. See section 636 11.3 of [RFC2330] for the definition of the percentile statistic 637 using the EDF. 639 LossRatio -- the count of lost packets to total packets sent is the 640 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 642 4.4.2. Reference Definition 644 For all outputs --- 646 T0 the start of a measurement interval, (format "date-and-time" as 647 specified in Section 5.6 of [RFC3339], see also Section 3 of 648 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 649 [RFC2330]. 651 Tf the end of a measurement interval, (format "date-and-time" as 652 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). 669 For 671 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio: 673 Percentile The numeric value of the result is expressed in units of 674 lost packets to total packets times 100%, as a positive value of 675 type decimal64 with fraction digits = 9 (see section 9.3 of 676 [RFC6020]) with resolution of 0.0000000001. 678 4.4.3. Metric Units 680 The 95th Percentile of Round-trip Delay is expressed in seconds. 682 The Round-trip Loss Ratio is expressed as a percentage of lost 683 packets to total packets sent. 685 4.4.4. Calibration 687 Section 3.7.3 of [RFC7679] provides a means to quantify the 688 systematic and random errors of a time measurement. In-situ 689 calibration could be enabled with an internal loopback at the Source 690 host that includes as much of the measurement system as possible, 691 performs address manipulation as needed, and provides some form of 692 isolation (e.g., deterministic delay) to avoid send-receive interface 693 contention. Some portion of the random and systematic error can be 694 characterized this way. 696 When a measurement controller requests a calibration measurement, the 697 loopback is applied and the result is output in the same format as a 698 normal measurement with additional indication that it is a 699 calibration result. 701 Both internal loopback calibration and clock synchronization can be 702 used to estimate the available accuracy of the Output Metric Units. 703 For example, repeated loopback delay measurements will reveal the 704 portion of the Output result resolution which is the result of system 705 noise, and thus inaccurate. 707 4.5. Administrative items 709 4.5.1. Status 711 Current 713 4.5.2. Requester 715 This RFC number 717 4.5.3. Revision 719 1.0 721 4.5.4. Revision Date 723 YYYY-MM-DD 725 4.6. Comments and Remarks 727 None. 729 5. Packet Delay Variation Registry Entry 731 This section gives an initial registry entry for a Packet Delay 732 Variation metric. 734 5.1. Summary 736 This category includes multiple indexes to the registry entries, the 737 element ID and metric name. 739 5.1.1. ID (Identifier) 741 743 5.1.2. Name 745 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsec5_Seconds_95Percentile 747 5.1.3. URIs 749 URL: https://www.iana.org/ ... 751 5.1.4. Description 753 An assessment of packet delay variation with respect to the minimum 754 delay observed on the periodic stream, and the Output is expressed as 755 the 95th percentile of the packet delay variation distribution. 757 5.1.5. Change Controller 759 IETF 761 5.1.6. Version (of Registry Format) 763 1.0 765 5.2. Metric Definition 767 This category includes columns to prompt the entry of all necessary 768 details related to the metric definition, including the RFC reference 769 and values of input factors, called fixed parameters. 771 5.2.1. Reference Definition 773 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 774 Performance Metrics", RFC 2330, May 1998. [RFC2330] 776 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 777 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 778 [RFC3393] 780 Morton, A. and B. Claise, "Packet Delay Variation Applicability 781 Statement", RFC 5481, March 2009. [RFC5481] 783 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 784 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 785 June 2010. [RFC5905] 787 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 788 measured are referred to by the variable name "ddT" (applicable to 789 all forms of delay variation). However, this metric entry specifies 790 the PDV form defined in section 4.2 of [RFC5481], where the singleton 791 PDV for packet i is referred to by the variable name "PDV(i)". 793 5.2.2. Fixed Parameters 795 o IPv4 header values: 797 * DSCP: set to 0 799 * TTL: set to 255 801 * Protocol: set to 17 (UDP) 803 o IPv6 header values: 805 * DSCP: set to 0 807 * Hop Count: set to 255 809 * Next Header: set to 17 (UDP) 811 * Flow Label: set to zero 813 * Extension Headers: none 815 o UDP header values: 817 * Checksum: the checksum MUST be calculated and the non-zero 818 checksum included in the header 820 o UDP Payload 822 * total of 200 bytes 824 Other measurement parameters: 826 Tmax: a loss threshold waiting time with value 3.0, expressed in 827 units of seconds, as a positive value of type decimal64 with 828 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 829 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 830 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 832 F a selection function unambiguously defining the packets from the 833 stream selected for the metric. See section 4.2 of [RFC5481] for 834 the PDV form. 836 See the Packet Stream generation category for two additional Fixed 837 Parameters. 839 5.3. Method of Measurement 841 This category includes columns for references to relevant sections of 842 the RFC(s) and any supplemental information needed to ensure an 843 unambiguous methods for implementations. 845 5.3.1. Reference Method 847 See section 2.6 and 3.6 of [RFC3393] for general singleton element 848 calculations. This metric entry requires implementation of the PDV 849 form defined in section 4.2 of [RFC5481]. Also see measurement 850 considerations in section 8 of [RFC5481]. 852 The reference method distinguishes between long-delayed packets and 853 lost packets by implementing a maximum waiting time for packet 854 arrival. Tmax is the waiting time used as the threshold to declare a 855 packet lost. Lost packets SHALL be designated as having undefined 856 delay. 858 The calculations on the one-way delay SHALL be performed on the 859 conditional distribution, conditioned on successful packet arrival 860 within Tmax. Also, when all packet delays are stored, the process 861 which calculates the one-way delay value MUST enforce the Tmax 862 threshold on stored values before calculations. See section 4.1 of 863 [RFC3393] for details on the conditional distribution to exclude 864 undefined values of delay, and Section 5 of [RFC6703] for background 865 on this analysis choice. 867 The reference method requires some way to distinguish between 868 different packets in a stream to establish correspondence between 869 sending times and receiving times for each successfully-arriving 870 packet. Sequence numbers or other send-order identification MUST be 871 retained at the Src or included with each packet to disambiguate 872 packet reordering if it occurs. 874 If a standard measurement protocol is employed, then the measurement 875 process will determine the sequence numbers or timestamps applied to 876 test packets after the Fixed and Runtime parameters are passed to 877 that process. The chosen measurement protocol will dictate the 878 format of sequence numbers and time-stamps, if they are conveyed in 879 the packet payload. 881 5.3.2. Packet Stream Generation 883 This section gives the details of the packet traffic which is the 884 basis for measurement. In IPPM metrics, this is called the Stream, 885 and can easily be described by providing the list of stream 886 parameters. 888 Section 3 of [RFC3432] prescribes the method for generating Periodic 889 streams using associated parameters. 891 incT the nominal duration of inter-packet interval, first bit to 892 first bit, with value 0.0200, expressed in units of seconds, as a 893 positive value of type decimal64 with fraction digits = 4 (see 894 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 895 (0.1 ms). 897 dT the duration of the interval for allowed sample start times, with 898 value 1.0, expressed in units of seconds, as a positive value of 899 type decimal64 with fraction digits = 4 (see section 9.3 of 900 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 902 NOTE: an initiation process with a number of control exchanges 903 resulting in unpredictable start times (within a time interval) may 904 be sufficient to avoid synchronization of periodic streams, and 905 therefore a valid replacement for selecting a start time at random 906 from a fixed interval. 908 The T0 parameter will be reported as a measured parameter. 909 Parameters incT and dT are Fixed Parameters. 911 5.3.3. Traffic Filtering (observation) Details 913 NA 915 5.3.4. Sampling Distribution 917 NA 919 5.3.5. Run-time Parameters and Data Format 921 Src the IP address of the host in the Src Role (format ipv4-address- 922 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 923 see Section 4 of [RFC6991]) 925 Dst the IP address of the host in the Dst Role (format ipv4-address- 926 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 927 see section 4 of [RFC6991]) 929 T0 a time, the start of a measurement interval, (format "date-and- 930 time" as specified in Section 5.6 of [RFC3339], see also Section 3 931 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 932 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 933 and Tf is to be interpreted as the Duration of the measurement 934 interval. The start time is controlled through other means. 936 Tf a time, the end of a measurement interval, (format "date-and-time" 937 as specified in Section 5.6 of [RFC3339], see also Section 3 of 938 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 939 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 940 Tf is interpreted as the Duration of the measurement interval. 942 5.3.6. Roles 944 Src launches each packet and waits for return transmissions from 945 Dst. 947 Dst waits for each packet from Src and sends a return packet to Src. 949 5.4. Output 951 This category specifies all details of the Output of measurements 952 using the metric. 954 5.4.1. Type 956 Percentile -- for the conditional distribution of all packets with a 957 valid value of one-way delay (undefined delays are excluded), a 958 single value corresponding to the 95th percentile, as follows: 960 See section 4.1 of [RFC3393] for details on the conditional 961 distribution to exclude undefined values of delay, and Section 5 of 962 [RFC6703] for background on this analysis choice. 964 The percentile = 95, meaning that the reported delay, "95Percentile", 965 is the smallest value of one-way PDV for which the Empirical 966 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 967 one-way PDV values in the conditional distribution. See section 11.3 968 of [RFC2330] for the definition of the percentile statistic using the 969 EDF. 971 5.4.2. Reference Definition 973 T0 the start of a measurement interval, (format "date-and-time" as 974 specified in Section 5.6 of [RFC3339], see also Section 3 of 975 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 976 [RFC2330]. 978 Tf the end of a measurement interval, (format "date-and-time" as 979 specified in Section 5.6 of [RFC3339], see also Section 3 of 980 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 981 [RFC2330]. 983 95Percentile The time value of the result is expressed in units of 984 seconds, as a positive value of type decimal64 with fraction 985 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 986 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 987 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 989 5.4.3. Metric Units 991 The 95th Percentile of one-way PDV is expressed in seconds. 993 5.4.4. Calibration 995 Section 3.7.3 of [RFC7679] provides a means to quantify the 996 systematic and random errors of a time measurement. In-situ 997 calibration could be enabled with an internal loopback that includes 998 as much of the measurement system as possible, performs address 999 manipulation as needed, and provides some form of isolation (e.g., 1000 deterministic delay) to avoid send-receive interface contention. 1001 Some portion of the random and systematic error can be characterized 1002 this way. 1004 For one-way delay measurements, the error calibration must include an 1005 assessment of the internal clock synchronization with its external 1006 reference (this internal clock is supplying timestamps for 1007 measurement). In practice, the time offsets [RFC5905] of clocks at 1008 both the source and destination are needed to estimate the systematic 1009 error due to imperfect clock synchronization (the time offsets are 1010 smoothed, thus the random variation is not usually represented in the 1011 results). 1013 time_offset The time value of the result is expressed in units of 1014 seconds, as a signed value of type decimal64 with fraction digits 1015 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1016 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1017 NTP timestamp as per section 6 of RFC [RFC5905] 1019 When a measurement controller requests a calibration measurement, the 1020 loopback is applied and the result is output in the same format as a 1021 normal measurement with additional indication that it is a 1022 calibration result. In any measurement, the measurement function 1023 SHOULD report its current estimate of time offset [RFC5905] as an 1024 indicator of the degree of synchronization. 1026 Both internal loopback calibration and clock synchronization can be 1027 used to estimate the available accuracy of the Output Metric Units. 1028 For example, repeated loopback delay measurements will reveal the 1029 portion of the Output result resolution which is the result of system 1030 noise, and thus inaccurate. 1032 5.5. Administrative items 1034 5.5.1. Status 1036 Current 1038 5.5.2. Requester 1040 This RFC number 1042 5.5.3. Revision 1044 1.0 1046 5.5.4. Revision Date 1048 YYYY-MM-DD 1050 5.6. Comments and Remarks 1052 Lost packets represent a challenge for delay variation metrics. See 1053 section 4.1 of [RFC3393] and the delay variation applicability 1054 statement[RFC5481] for extensive analysis and comparison of PDV and 1055 an alternate metric, IPDV. 1057 6. DNS Response Latency and Loss Registry Entries 1059 This section gives initial registry entries for DNS Response Latency 1060 and Loss from a network user's perspective, for a specific named 1061 resource. The metric can be measured repeatedly using different 1062 names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1063 build on that metric by specifying several of the input parameters to 1064 precisely define two metrics for measuring DNS latency and loss. 1066 Note to IANA: Each Registry "Name" below specifies a single registry 1067 entry, whose output format varies in accordance with the name. 1069 All column entries beside the ID, Name, Description, and Output 1070 Reference Method categories are the same, thus this section proposes 1071 two closely-related registry entries. As a result, IANA is also 1072 asked to assign corresponding URLs to each Named Metric. 1074 6.1. Summary 1076 This category includes multiple indexes to the registry entries, the 1077 element ID and metric name. 1079 6.1.1. ID (Identifier) 1081 1083 IANA is asked to assign different numeric identifiers to each of the 1084 two Named Metrics. 1086 6.1.2. Name 1088 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Seconds_Raw 1090 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Logical_Raw 1092 6.1.3. URI 1094 URL: https://www.iana.org/ ... 1096 6.1.4. Description 1098 This is a metric for DNS Response performance from a network user's 1099 perspective, for a specific named resource. The metric can be 1100 measured repeatedly using different resource names. 1102 RTDNS: This metric assesses the response time, the interval from the 1103 query transmission to the response. 1105 RLDNS: This metric indicates that the response was deemed lost. In 1106 other words, the response time exceeded the maximum waiting time. 1108 6.1.5. Change Controller 1110 IETF 1112 6.1.6. Version (of Registry Format) 1114 1.0 1116 6.2. Metric Definition 1118 This category includes columns to prompt the entry of all necessary 1119 details related to the metric definition, including the RFC reference 1120 and values of input factors, called fixed parameters. 1122 6.2.1. Reference Definition 1124 Mockapetris, P., "Domain names - implementation and specification", 1125 STD 13, RFC 1035, November 1987. (and updates) 1127 [RFC1035] 1129 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1130 Metric for IPPM", RFC 2681, September 1999. 1132 [RFC2681] 1134 Section 2.4 of [RFC2681] provides the reference definition of the 1135 singleton (single value) Round-trip delay metric. Section 3.4 of 1136 [RFC2681] provides the reference definition expanded to cover a 1137 multi-singleton sample. Note that terms such as singleton and sample 1138 are defined in Section 11 of [RFC2330]. 1140 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1141 [RFC2681]. The Local Host with its User Program and Resolver take 1142 the role of "Src", and the Foreign Name Server takes the role of 1143 "Dst". 1145 Note that although the [RFC2681] definition of "Round-trip-Delay 1146 between Src and Dst at T" is directionally ambiguous in the text, 1147 this metric tightens the definition further to recognize that the 1148 host in the "Src" role will send the first packet to "Dst", and 1149 ultimately receive the corresponding return packet from "Dst" (when 1150 neither are lost). 1152 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1154 [RFC6673] 1156 Both response time and loss metrics employ a maximum waiting time for 1157 received responses, so the count of lost packets to total packets 1158 sent is the basis for the loss determination as per Section 4.3 of 1159 [RFC6673]. 1161 6.2.2. Fixed Parameters 1163 Type-P as defined in Section 13 of [RFC2330]: 1165 o IPv4 header values: 1167 * DSCP: set to 0 1169 * TTL set to 255 1171 * Protocol: set to 17 (UDP) 1173 o IPv6 header values: 1175 * DSCP: set to 0 1177 * Hop Count: set to 255 1179 * Next Header: set to 17 (UDP) 1181 * Flow Label: set to zero 1183 * Extension Headers: none 1185 o UDP header values: 1187 * Source port: 53 1189 * Destination port: 53 1191 * Checksum: the checksum must be calculated and the non-zero 1192 checksum included in the header 1194 o Payload: The payload contains a DNS message as defined in RFC 1035 1195 [RFC1035] with the following values: 1197 * The DNS header section contains: 1199 + Identification (see the Run-time column) 1201 + QR: set to 0 (Query) 1203 + OPCODE: set to 0 (standard query) 1205 + AA: not set 1207 + TC: not set 1209 + RD: set to one (recursion desired) 1211 + RA: not set 1213 + RCODE: not set 1215 + QDCOUNT: set to one (only one entry) 1217 + ANCOUNT: not set 1219 + NSCOUNT: not set 1221 + ARCOUNT: not set 1223 * The Question section contains: 1225 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1226 input for the test, see the Run-time column 1228 + QTYPE: the query type provided as input for the test, see 1229 the Run-time column 1231 + QCLASS: set to 1 for IN 1233 * The other sections do not contain any Resource Records. 1235 Other measurement parameters: 1237 o Tmax: a loss threshold waiting time (and to help disambiguate 1238 queries) 1240 * 5.0, expressed in units of seconds, as a positive value of type 1241 decimal64 with fraction digits = 4 (see section 9.3 of 1242 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1243 lossless conversion to/from the 32-bit NTP timestamp as per 1244 section 6 of [RFC5905]. 1246 Observation: reply packets will contain a DNS response and may 1247 contain RRs. 1249 6.3. Method of Measurement 1251 This category includes columns for references to relevant sections of 1252 the RFC(s) and any supplemental information needed to ensure an 1253 unambiguous methods for implementations. 1255 6.3.1. Reference Method 1257 The methodology for this metric is defined as Type-P-Round-trip- 1258 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1259 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1260 Fixed Parameters. 1262 The reference method distinguishes between long-delayed packets and 1263 lost packets by implementing a maximum waiting time for packet 1264 arrival. Tmax is the waiting time used as the threshold to declare a 1265 response packet lost. Lost packets SHALL be designated as having 1266 undefined delay and counted for the RLDNS metric. 1268 The calculations on the delay (RTT) SHALL be performed on the 1269 conditional distribution, conditioned on successful packet arrival 1270 within Tmax. Also, when all packet delays are stored, the process 1271 which calculates the RTT value MUST enforce the Tmax threshold on 1272 stored values before calculations. See section 4.1 of [RFC3393] for 1273 details on the conditional distribution to exclude undefined values 1274 of delay, and Section 5 of [RFC6703] for background on this analysis 1275 choice. 1277 The reference method requires some way to distinguish between 1278 different packets in a stream to establish correspondence between 1279 sending times and receiving times for each successfully-arriving 1280 reply. 1282 DNS Messages bearing Queries provide for random ID Numbers in the 1283 Identification header field, so more than one query may be launched 1284 while a previous request is outstanding when the ID Number is used. 1285 Therefore, the ID Number MUST be retained at the Src and included 1286 with each response packet to disambiguate packet reordering if it 1287 occurs. 1289 IF a DNS response does not arrive within Tmax, the response time 1290 RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to 1291 disambiguate the successive queries that are otherwise identical. 1293 Since the ID Number field is only 16 bits in length, it places a 1294 limit on the number of simultaneous outstanding DNS queries during a 1295 stress test from a single Src address. 1297 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1298 instruction to "send a Type-P packet back to the Src as quickly as 1299 possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS 1300 Server is expected to perform all required functions to prepare and 1301 send a response, so the response time will include processing time 1302 and network delay. Section 8 of [RFC6673] presents additional 1303 requirements which SHALL be included in the method of measurement for 1304 this metric. 1306 In addition to operations described in [RFC2681], the Src MUST parse 1307 the DNS headers of the reply and prepare the query response 1308 information for subsequent reporting as a measured result, along with 1309 the Round-Trip Delay. 1311 6.3.2. Packet Stream Generation 1313 This section gives the details of the packet traffic which is the 1314 basis for measurement. In IPPM metrics, this is called the Stream, 1315 and can easily be described by providing the list of stream 1316 parameters. 1318 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1319 generate Poisson sampling intervals. The reciprocal of lambda is the 1320 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1321 = 1/lambda, in packets per second. 1323 Method 3 is used, where given a start time (Run-time Parameter), the 1324 subsequent send times are all computed prior to measurement by 1325 computing the pseudo-random distribution of inter-packet send times, 1326 (truncating the distribution as specified in the Run-time 1327 Parameters), and the Src sends each packet at the computed times. 1329 Note that Trunc is the upper limit on inter-packet times in the 1330 Poisson distribution. A random value greater than Trunc is set equal 1331 to Trunc instead. 1333 6.3.3. Traffic Filtering (observation) Details 1335 NA 1337 6.3.4. Sampling Distribution 1339 NA 1341 6.3.5. Run-time Parameters and Data Format 1343 Run-time Parameters are input factors that must be determined, 1344 configured into the measurement system, and reported with the results 1345 for the context to be complete. 1347 Src the IP address of the host in the Src Role (format ipv4-address- 1348 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1349 see Section 4 of [RFC6991]) 1351 Dst the IP address of the host in the Dst Role (format ipv4-address- 1352 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1353 see section 4 of [RFC6991]) 1355 T0 a time, the start of a measurement interval, (format "date-and- 1356 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1357 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1358 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1359 and Tf is to be interpreted as the Duration of the measurement 1360 interval. The start time is controlled through other means. 1362 Tf a time, the end of a measurement interval, (format "date-and-time" 1363 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1364 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1366 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1367 Tf is interpreted as the Duration of the measurement interval. 1369 Reciprocal_lambda average packet interval for Poisson Streams 1370 expressed in units of seconds, as a positive value of type 1371 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1372 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1373 conversion to/from the 32-bit NTP timestamp as per section 6 of 1374 [RFC5905]. 1376 Trunc Upper limit on Poisson distribution expressed in units of 1377 seconds, as a positive value of type decimal64 with fraction 1378 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1379 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1380 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1381 this limit will be clipped and set to the limit value). 1383 ID The 16-bit identifier assigned by the program that generates the 1384 query, and which must vary in successive queries (a list of IDs is 1385 needed), see Section 4.1.1 of [RFC1035]. This identifier is 1386 copied into the corresponding reply and can be used by the 1387 requester (Src) to match-up replies to outstanding queries. 1389 QNAME The domain name of the Query, formatted as specified in 1390 section 4 of [RFC6991]. 1392 QTYPE The Query Type, which will correspond to the IP address family 1393 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1394 uint16, as per section 9.2 of [RFC6020]. 1396 6.3.6. Roles 1398 Src launches each packet and waits for return transmissions from 1399 Dst. 1401 Dst waits for each packet from Src and sends a return packet to Src. 1403 6.4. Output 1405 This category specifies all details of the Output of measurements 1406 using the metric. 1408 6.4.1. Type 1410 Raw -- for each DNS Query packet sent, sets of values as defined in 1411 the next column, including the status of the response, only assigning 1412 delay values to successful query-response pairs. 1414 6.4.2. Reference Definition 1416 For all outputs: 1418 T the time the DNS Query was sent during the measurement interval, 1419 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1420 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1421 by Section 6.1 of [RFC2330]. 1423 dT The time value of the round-trip delay to receive the DNS 1424 response, expressed in units of seconds, as a positive value of 1425 type decimal64 with fraction digits = 9 (see section 9.3 of 1426 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1427 with lossless conversion to/from the 64-bit NTP timestamp as per 1428 section 6 of RFC [RFC5905]. This value is undefined when the 1429 response packet is not received at Src within waiting time Tmax 1430 seconds. 1432 Rcode The value of the Rcode field in the DNS response header, 1433 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1434 Non-zero values convey errors in the response, and such replies 1435 must be analyzed separately from successful requests. 1437 6.4.3. Metric Units 1439 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1441 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1443 6.4.4. Calibration 1445 Section 3.7.3 of [RFC7679] provides a means to quantify the 1446 systematic and random errors of a time measurement. In-situ 1447 calibration could be enabled with an internal loopback at the Source 1448 host that includes as much of the measurement system as possible, 1449 performs address and payload manipulation as needed, and provides 1450 some form of isolation (e.g., deterministic delay) to avoid send- 1451 receive interface contention. Some portion of the random and 1452 systematic error can be characterized this way. 1454 When a measurement controller requests a calibration measurement, the 1455 loopback is applied and the result is output in the same format as a 1456 normal measurement with additional indication that it is a 1457 calibration result. 1459 Both internal loopback calibration and clock synchronization can be 1460 used to estimate the available accuracy of the Output Metric Units. 1461 For example, repeated loopback delay measurements will reveal the 1462 portion of the Output result resolution which is the result of system 1463 noise, and thus inaccurate. 1465 6.5. Administrative items 1467 6.5.1. Status 1469 Current 1471 6.5.2. Requester 1473 This RFC number 1475 6.5.3. Revision 1477 1.0 1479 6.5.4. Revision Date 1481 YYYY-MM-DD 1483 6.6. Comments and Remarks 1485 None 1487 7. UDP Poisson One-way Delay and Loss Registry Entries 1489 This section specifies five initial registry entries for the UDP 1490 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1492 IANA Note: Registry "Name" below specifies multiple registry entries, 1493 whose output format varies according to the element of 1494 the name that specifies one form of statistical summary. There is an 1495 additional metric name for the Loss metric. 1497 All column entries beside the ID, Name, Description, and Output 1498 Reference Method categories are the same, thus this section proposes 1499 six closely-related registry entries. As a result, IANA is also 1500 asked to assign corresponding URLs to each Named Metric. 1502 7.1. Summary 1504 This category includes multiple indexes to the registry entries, the 1505 element ID and metric name. 1507 7.1.1. ID (Identifier) 1509 IANA is asked to assign different numeric identifiers to each of the 1510 six Metrics. 1512 7.1.2. Name 1514 OWDelay_Active_IP-UDP-Poisson- 1515 Payload250B_RFCXXXXsec7_Seconds_ 1517 where is one of: 1519 o 95Percentile 1521 o Mean 1523 o Min 1525 o Max 1527 o StdDev 1529 OWLoss_Active_IP-UDP-Poisson- 1530 Payload250B_RFCXXXXsec7_Percent_LossRatio 1532 7.1.3. URI and URL 1534 URL: https://www.iana.org/ ... 1536 7.1.4. Description 1538 OWDelay: This metric assesses the delay of a stream of packets 1539 exchanged between two hosts (or measurement points), and reports the 1540 One-way delay for all successfully exchanged packets 1541 based on their conditional delay distribution. 1543 where is one of: 1545 o 95Percentile 1547 o Mean 1549 o Min 1551 o Max 1553 o StdDev 1554 OWLoss: This metric assesses the loss ratio of a stream of packets 1555 exchanged between two hosts (which are the two measurement points), 1556 and the Output is the One-way loss ratio for all successfully 1557 received packets expressed as a percentage. 1559 7.2. Metric Definition 1561 This category includes columns to prompt the entry of all necessary 1562 details related to the metric definition, including the RFC reference 1563 and values of input factors, called fixed parameters. 1565 7.2.1. Reference Definition 1567 For Delay: 1569 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1570 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1571 7679, DOI 10.17487/RFC7679, January 2016, . 1574 [RFC7679] 1576 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1577 6049, January 2011. 1579 [RFC6049] 1581 Section 3.4 of [RFC7679] provides the reference definition of the 1582 singleton (single value) One-way delay metric. Section 4.4 of 1583 [RFC7679] provides the reference definition expanded to cover a 1584 multi-value sample. Note that terms such as singleton and sample are 1585 defined in Section 11 of [RFC2330]. 1587 Only successful packet transfers with finite delay are included in 1588 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1590 For loss: 1592 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1593 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1594 10.17487/RFC7680, January 2016, . 1597 Section 2.4 of [RFC7680] provides the reference definition of the 1598 singleton (single value) one-way loss metric. Section 3.4 of 1599 [RFC7680] provides the reference definition expanded to cover a 1600 multi-singleton sample. Note that terms such as singleton and sample 1601 are defined in Section 11 of [RFC2330]. 1603 7.2.2. Fixed Parameters 1605 Type-P: 1607 o IPv4 header values: 1609 * DSCP: set to 0 1611 * TTL: set to 255 1613 * Protocol: Set to 17 (UDP) 1615 o IPv6 header values: 1617 * DSCP: set to 0 1619 * Hop Count: set to 255 1621 * Next Header: set to 17 (UDP) 1623 * Flow Label: set to zero 1625 * Extension Headers: none 1627 o UDP header values: 1629 * Checksum: the checksum MUST be calculated and the non-zero 1630 checksum included in the header 1632 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1634 * Security features in use influence the number of Padding 1635 octets. 1637 * 250 octets total, including the TWAMP format type, which MUST 1638 be reported. 1640 Other measurement parameters: 1642 Tmax: a loss threshold waiting time with value 3.0, expressed in 1643 units of seconds, as a positive value of type decimal64 with 1644 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1645 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1646 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1648 See the Packet Stream generation category for two additional Fixed 1649 Parameters. 1651 7.3. Method of Measurement 1653 This category includes columns for references to relevant sections of 1654 the RFC(s) and any supplemental information needed to ensure an 1655 unambiguous methods for implementations. 1657 7.3.1. Reference Method 1659 The methodology for this metric is defined as Type-P-One-way-Delay- 1660 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1661 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1663 The reference method distinguishes between long-delayed packets and 1664 lost packets by implementing a maximum waiting time for packet 1665 arrival. Tmax is the waiting time used as the threshold to declare a 1666 packet lost. Lost packets SHALL be designated as having undefined 1667 delay, and counted for the OWLoss metric. 1669 The calculations on the one-way delay SHALL be performed on the 1670 conditional distribution, conditioned on successful packet arrival 1671 within Tmax. Also, when all packet delays are stored, the process 1672 which calculates the one-way delay value MUST enforce the Tmax 1673 threshold on stored values before calculations. See section 4.1 of 1674 [RFC3393] for details on the conditional distribution to exclude 1675 undefined values of delay, and Section 5 of [RFC6703] for background 1676 on this analysis choice. 1678 The reference method requires some way to distinguish between 1679 different packets in a stream to establish correspondence between 1680 sending times and receiving times for each successfully-arriving 1681 packet. 1683 Since a standard measurement protocol is employed [RFC5357], then the 1684 measurement process will determine the sequence numbers or timestamps 1685 applied to test packets after the Fixed and Runtime parameters are 1686 passed to that process. The measurement protocol dictates the format 1687 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1688 payload. 1690 7.3.2. Packet Stream Generation 1692 This section gives the details of the packet traffic which is the 1693 basis for measurement. In IPPM metrics, this is called the Stream, 1694 and can easily be described by providing the list of stream 1695 parameters. 1697 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1698 generate Poisson sampling intervals. The reciprocal of lambda is the 1699 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1700 = 1/lambda, in packets per second. 1702 Method 3 SHALL be used, where given a start time (Run-time 1703 Parameter), the subsequent send times are all computed prior to 1704 measurement by computing the pseudo-random distribution of inter- 1705 packet send times, (truncating the distribution as specified in the 1706 Parameter Trunc), and the Src sends each packet at the computed 1707 times. 1709 Note that Trunc is the upper limit on inter-packet times in the 1710 Poisson distribution. A random value greater than Trunc is set equal 1711 to Trunc instead. 1713 Reciprocal_lambda average packet interval for Poisson Streams 1714 expressed in units of seconds, as a positive value of type 1715 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1716 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1717 conversion to/from the 32-bit NTP timestamp as per section 6 of 1718 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1720 Trunc Upper limit on Poisson distribution expressed in units of 1721 seconds, as a positive value of type decimal64 with fraction 1722 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1723 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1724 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1725 this limit will be clipped and set to the limit value). Trunc = 1726 30.0000 seconds. 1728 7.3.3. Traffic Filtering (observation) Details 1730 NA 1732 7.3.4. Sampling Distribution 1734 NA 1736 7.3.5. Run-time Parameters and Data Format 1738 Run-time Parameters are input factors that must be determined, 1739 configured into the measurement system, and reported with the results 1740 for the context to be complete. 1742 Src the IP address of the host in the Src Role (format ipv4-address- 1743 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1744 see Section 4 of [RFC6991]) 1746 Dst the IP address of the host in the Dst Role (format ipv4-address- 1747 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1748 see section 4 of [RFC6991]) 1750 T0 a time, the start of a measurement interval, (format "date-and- 1751 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1752 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1753 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1754 and Tf is to be interpreted as the Duration of the measurement 1755 interval. The start time is controlled through other means. 1757 Tf a time, the end of a measurement interval, (format "date-and-time" 1758 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1759 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1760 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1761 Tf is interpreted as the Duration of the measurement interval. 1763 7.3.6. Roles 1765 Src launches each packet and waits for return transmissions from 1766 Dst. This is the TWAMP Session-Sender. 1768 Dst waits for each packet from Src and sends a return packet to Src. 1769 This is the TWAMP Session-Reflector. 1771 7.4. Output 1773 This category specifies all details of the Output of measurements 1774 using the metric. 1776 7.4.1. Type 1778 See subsection titles below for Types. 1780 7.4.2. Reference Definition 1782 For all output types --- 1784 T0 the start of a measurement interval, (format "date-and-time" as 1785 specified in Section 5.6 of [RFC3339], see also Section 3 of 1786 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1787 [RFC2330]. 1789 Tf the end of a measurement interval, (format "date-and-time" as 1790 specified in Section 5.6 of [RFC3339], see also Section 3 of 1791 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1792 [RFC2330]. 1794 For LossRatio -- the count of lost packets to total packets sent is 1795 the basis for the loss ratio calculation as per Section 4.1 of 1796 [RFC7680]. 1798 For each , one of the following sub-sections apply: 1800 7.4.2.1. Percentile95 1802 The 95th percentile SHALL be calculated using the conditional 1803 distribution of all packets with a finite value of One-way delay 1804 (undefined delays are excluded), a single value as follows: 1806 See section 4.1 of [RFC3393] for details on the conditional 1807 distribution to exclude undefined values of delay, and Section 5 of 1808 [RFC6703] for background on this analysis choice. 1810 See section 4.3 of [RFC3393] for details on the percentile statistic 1811 (where Round-trip delay should be substituted for "ipdv"). 1813 The percentile = 95, meaning that the reported delay, "95Percentile", 1814 is the smallest value of one-way delay for which the Empirical 1815 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1816 one-way delay values in the conditional distribution. See section 1817 11.3 of [RFC2330] for the definition of the percentile statistic 1818 using the EDF. 1820 95Percentile The time value of the result is expressed in units of 1821 seconds, as a positive value of type decimal64 with fraction 1822 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1823 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1824 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1826 7.4.2.2. Mean 1828 The mean SHALL be calculated using the conditional distribution of 1829 all packets with a finite value of One-way delay (undefined delays 1830 are excluded), a single value as follows: 1832 See section 4.1 of [RFC3393] for details on the conditional 1833 distribution to exclude undefined values of delay, and Section 5 of 1834 [RFC6703] for background on this analysis choice. 1836 See section 4.2.2 of [RFC6049] for details on calculating this 1837 statistic, and 4.2.3 of [RFC6049]. 1839 Mean The time value of the result is expressed in units of seconds, 1840 as a positive value of type decimal64 with fraction digits = 9 1841 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1842 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1843 NTP timestamp as per section 6 of RFC [RFC5905] 1845 7.4.2.3. Min 1847 The minimum SHALL be calculated using the conditional distribution of 1848 all packets with a finite value of One-way delay (undefined delays 1849 are excluded), a single value as follows: 1851 See section 4.1 of [RFC3393] for details on the conditional 1852 distribution to exclude undefined values of delay, and Section 5 of 1853 [RFC6703] for background on this analysis choice. 1855 See section 4.3.2 of [RFC6049] for details on calculating this 1856 statistic, and 4.3.3 of [RFC6049]. 1858 Min The time value of the result is expressed in units of seconds, 1859 as a positive value of type decimal64 with fraction digits = 9 1860 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1861 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1862 NTP timestamp as per section 6 of RFC [RFC5905] 1864 7.4.2.4. Max 1866 The maximum SHALL be calculated using the conditional distribution of 1867 all packets with a finite value of One-way delay (undefined delays 1868 are excluded), a single value as follows: 1870 See section 4.1 of [RFC3393] for details on the conditional 1871 distribution to exclude undefined values of delay, and Section 5 of 1872 [RFC6703] for background on this analysis choice. 1874 See section 4.3.2 of [RFC6049] for a closely related method for 1875 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1876 as follows: 1878 Max = (FiniteDelay [j]) 1880 such that for some index, j, where 1 <= j <= N 1881 FiniteDelay[j] >= FiniteDelay[n] for all n 1883 Max The time value of the result is expressed in units of seconds, 1884 as a positive value of type decimal64 with fraction digits = 9 1885 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1886 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1887 NTP timestamp as per section 6 of RFC [RFC5905] 1889 7.4.2.5. Std_Dev 1891 The Std_Dev SHALL be calculated using the conditional distribution of 1892 all packets with a finite value of One-way delay (undefined delays 1893 are excluded), a single value as follows: 1895 See section 4.1 of [RFC3393] for details on the conditional 1896 distribution to exclude undefined values of delay, and Section 5 of 1897 [RFC6703] for background on this analysis choice. 1899 See section 6.1.4 of [RFC6049] for a closely related method for 1900 calculating this statistic. The formula is the classic calculation 1901 for standard deviation of a population. 1903 Define Population Std_Dev_Delay as follows: 1904 (where all packets n = 1 through N have a value for Delay[n], 1905 and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the 1906 Square Root function: 1907 _ _ 1908 | N | 1909 | --- | 1910 | 1 \ 2 | 1911 Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) | 1912 | (N) / | 1913 | --- | 1914 | n = 1 | 1915 |_ _| 1917 Std_Dev The time value of the result is expressed in units of 1918 seconds, as a positive value of type decimal64 with fraction 1919 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1920 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1921 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1923 7.4.3. Metric Units 1925 The of One-way Delay is expressed in seconds. 1927 The One-way Loss Ratio is expressed as a percentage of lost packets 1928 to total packets sent. 1930 7.4.4. Calibration 1932 Section 3.7.3 of [RFC7679] provides a means to quantify the 1933 systematic and random errors of a time measurement. In-situ 1934 calibration could be enabled with an internal loopback that includes 1935 as much of the measurement system as possible, performs address 1936 manipulation as needed, and provides some form of isolation (e.g., 1937 deterministic delay) to avoid send-receive interface contention. 1938 Some portion of the random and systematic error can be characterized 1939 this way. 1941 For one-way delay measurements, the error calibration must include an 1942 assessment of the internal clock synchronization with its external 1943 reference (this internal clock is supplying timestamps for 1944 measurement). In practice, the time offsets [RFC5905] of clocks at 1945 both the source and destination are needed to estimate the systematic 1946 error due to imperfect clock synchronization (the time offsets 1947 [RFC5905] are smoothed, thus the random variation is not usually 1948 represented in the results). 1950 time_offset The time value of the result is expressed in units of 1951 seconds, as a signed value of type decimal64 with fraction digits 1952 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1953 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1954 NTP timestamp as per section 6 of RFC [RFC5905] 1956 When a measurement controller requests a calibration measurement, the 1957 loopback is applied and the result is output in the same format as a 1958 normal measurement with additional indication that it is a 1959 calibration result. In any measurement, the measurement function 1960 SHOULD report its current estimate of time offset [RFC5905] as an 1961 indicator of the degree of synchronization. 1963 Both internal loopback calibration and clock synchronization can be 1964 used to estimate the available accuracy of the Output Metric Units. 1965 For example, repeated loopback delay measurements will reveal the 1966 portion of the Output result resolution which is the result of system 1967 noise, and thus inaccurate. 1969 7.5. Administrative items 1971 7.5.1. Status 1973 Current 1975 7.5.2. Requester 1977 This RFC number 1979 7.5.3. Revision 1981 1.0 1983 7.5.4. Revision Date 1985 YYYY-MM-DD 1987 7.6. Comments and Remarks 1989 None 1991 8. UDP Periodic One-way Delay and Loss Registry Entries 1993 This section specifies five initial registry entries for the UDP 1994 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 1996 IANA Note: Registry "Name" below specifies multiple registry entries, 1997 whose output format varies according to the element of 1998 the name that specifies one form of statistical summary. There is an 1999 additional metric name for the Loss metric. 2001 All column entries beside the ID, Name, Description, and Output 2002 Reference Method categories are the same, thus this section proposes 2003 six closely-related registry entries. As a result, IANA is also 2004 asked to assign corresponding URLs to each Named Metric. 2006 8.1. Summary 2008 This category includes multiple indexes to the registry entries, the 2009 element ID and metric name. 2011 8.1.1. ID (Identifier) 2013 IANA is asked to assign a different numeric identifiers to each of 2014 the six Metrics. 2016 8.1.2. Name 2018 OWDelay_Active_IP-UDP-Periodic20m- 2019 Payload142B_RFCXXXXsec8_Seconds_ 2021 where is one of: 2023 o 95Percentile 2025 o Mean 2027 o Min 2029 o Max 2030 o StdDev 2032 OWLoss_Active_IP-UDP-Periodic- 2033 Payload142B_RFCXXXXsec8_Percent_LossRatio 2035 8.1.3. URIs 2037 URL: https://www.iana.org/ ... 2039 8.1.4. Description 2041 OWDelay: This metric assesses the delay of a stream of packets 2042 exchanged between two hosts (or measurement points), and reports the 2043 One-way delay for all successfully exchanged packets 2044 based on their conditional delay distribution. 2046 where is one of: 2048 o 95Percentile 2050 o Mean 2052 o Min 2054 o Max 2056 o StdDev 2058 OWLoss: This metric assesses the loss ratio of a stream of packets 2059 exchanged between two hosts (which are the two measurement points), 2060 and the Output is the One-way loss ratio for all successfully 2061 received packets expressed as a percentage. 2063 8.2. Metric Definition 2065 This category includes columns to prompt the entry of all necessary 2066 details related to the metric definition, including the RFC reference 2067 and values of input factors, called fixed parameters. 2069 8.2.1. Reference Definition 2071 For Delay: 2073 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2074 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2075 7679, DOI 10.17487/RFC7679, January 2016, . 2078 [RFC7679] 2080 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2081 6049, January 2011. 2083 [RFC6049] 2085 Section 3.4 of [RFC7679] provides the reference definition of the 2086 singleton (single value) One-way delay metric. Section 4.4 of 2087 [RFC7679] provides the reference definition expanded to cover a 2088 multi-value sample. Note that terms such as singleton and sample are 2089 defined in Section 11 of [RFC2330]. 2091 Only successful packet transfers with finite delay are included in 2092 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2094 For loss: 2096 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2097 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2098 10.17487/RFC7680, January 2016, . 2101 Section 2.4 of [RFC7680] provides the reference definition of the 2102 singleton (single value) one-way loss metric. Section 3.4 of 2103 [RFC7680] provides the reference definition expanded to cover a 2104 multi-singleton sample. Note that terms such as singleton and sample 2105 are defined in Section 11 of [RFC2330]. 2107 8.2.2. Fixed Parameters 2109 Type-P: 2111 o IPv4 header values: 2113 * DSCP: set to 0 2115 * TTL: set to 255 2117 * Protocol: Set to 17 (UDP) 2119 o IPv6 header values: 2121 * DSCP: set to 0 2123 * Hop Count: set to 255 2125 * Next Header: set to 17 (UDP) 2126 * Flow Label: set to zero 2128 * Extension Headers: none 2130 o UDP header values: 2132 * Checksum: the checksum MUST be calculated and the non-zero 2133 checksum included in the header 2135 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2137 * Security features in use influence the number of Padding 2138 octets. 2140 * 142 octets total, including the TWAMP format (and format type 2141 MUST be reported, if used) 2143 Other measurement parameters: 2145 Tmax: a loss threshold waiting time with value 3.0, expressed in 2146 units of seconds, as a positive value of type decimal64 with 2147 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2148 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2149 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2151 See the Packet Stream generation category for two additional Fixed 2152 Parameters. 2154 8.3. Method of Measurement 2156 This category includes columns for references to relevant sections of 2157 the RFC(s) and any supplemental information needed to ensure an 2158 unambiguous methods for implementations. 2160 8.3.1. Reference Method 2162 The methodology for this metric is defined as Type-P-One-way-Delay- 2163 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2164 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2165 However, a Periodic stream is used, as defined in [RFC3432]. 2167 The reference method distinguishes between long-delayed packets and 2168 lost packets by implementing a maximum waiting time for packet 2169 arrival. Tmax is the waiting time used as the threshold to declare a 2170 packet lost. Lost packets SHALL be designated as having undefined 2171 delay, and counted for the OWLoss metric. 2173 The calculations on the one-way delay SHALL be performed on the 2174 conditional distribution, conditioned on successful packet arrival 2175 within Tmax. Also, when all packet delays are stored, the process 2176 which calculates the one-way delay value MUST enforce the Tmax 2177 threshold on stored values before calculations. See section 4.1 of 2178 [RFC3393] for details on the conditional distribution to exclude 2179 undefined values of delay, and Section 5 of [RFC6703] for background 2180 on this analysis choice. 2182 The reference method requires some way to distinguish between 2183 different packets in a stream to establish correspondence between 2184 sending times and receiving times for each successfully-arriving 2185 packet. 2187 Since a standard measurement protocol is employed [RFC5357], then the 2188 measurement process will determine the sequence numbers or timestamps 2189 applied to test packets after the Fixed and Runtime parameters are 2190 passed to that process. The measurement protocol dictates the format 2191 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2192 payload. 2194 8.3.2. Packet Stream Generation 2196 This section gives the details of the packet traffic which is the 2197 basis for measurement. In IPPM metrics, this is called the Stream, 2198 and can easily be described by providing the list of stream 2199 parameters. 2201 Section 3 of [RFC3432] prescribes the method for generating Periodic 2202 streams using associated parameters. 2204 incT the nominal duration of inter-packet interval, first bit to 2205 first bit, with value 0.0200 expressed in units of seconds, as a 2206 positive value of type decimal64 with fraction digits = 4 (see 2207 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 2208 (0.1 ms), with lossless conversion to/from the 32-bit NTP 2209 timestamp as per section 6 of [RFC5905]. 2211 dT the duration of the interval for allowed sample start times, with 2212 value 1.0000, expressed in units of seconds, as a positive value 2213 of type decimal64 with fraction digits = 4 (see section 9.3 of 2214 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2215 lossless conversion to/from the 32-bit NTP timestamp as per 2216 section 6 of [RFC5905]. 2218 T0 the actual start time of the periodic stream, determined from T0 2219 and dT. 2221 NOTE: an initiation process with a number of control exchanges 2222 resulting in unpredictable start times (within a time interval) may 2223 be sufficient to avoid synchronization of periodic streams, and 2224 therefore a valid replacement for selecting a start time at random 2225 from a fixed interval. 2227 These stream parameters will be specified as Run-time parameters. 2229 8.3.3. Traffic Filtering (observation) Details 2231 NA 2233 8.3.4. Sampling Distribution 2235 NA 2237 8.3.5. Run-time Parameters and Data Format 2239 Run-time Parameters are input factors that must be determined, 2240 configured into the measurement system, and reported with the results 2241 for the context to be complete. 2243 Src the IP address of the host in the Src Role (format ipv4-address- 2244 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2245 see Section 4 of [RFC6991]) 2247 Dst the IP address of the host in the Dst Role (format ipv4-address- 2248 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2249 see section 4 of [RFC6991]) 2251 T0 a time, the start of a measurement interval, (format "date-and- 2252 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2253 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2254 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2255 and Tf is to be interpreted as the Duration of the measurement 2256 interval. The start time is controlled through other means. 2258 Tf a time, the end of a measurement interval, (format "date-and-time" 2259 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2260 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2261 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2262 Tf is interpreted as the Duration of the measurement interval. 2264 8.3.6. Roles 2266 Src launches each packet and waits for return transmissions from 2267 Dst. This is the TWAMP Session-Sender. 2269 Dst waits for each packet from Src and sends a return packet to Src. 2270 This is the TWAMP Session-Reflector. 2272 8.4. Output 2274 This category specifies all details of the Output of measurements 2275 using the metric. 2277 8.4.1. Type 2279 See subsection titles in Reference Definition for Latency Types. 2281 8.4.2. Reference Definition 2283 For all output types --- 2285 T0 the start of a measurement interval, (format "date-and-time" as 2286 specified in Section 5.6 of [RFC3339], see also Section 3 of 2287 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2288 [RFC2330]. 2290 Tf the end of a measurement interval, (format "date-and-time" as 2291 specified in Section 5.6 of [RFC3339], see also Section 3 of 2292 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2293 [RFC2330]. 2295 For LossRatio -- the count of lost packets to total packets sent is 2296 the basis for the loss ratio calculation as per Section 4.1 of 2297 [RFC7680]. 2299 For each , one of the following sub-sections apply: 2301 8.4.2.1. Percentile95 2303 The 95th percentile SHALL be calculated using the conditional 2304 distribution of all packets with a finite value of One-way delay 2305 (undefined delays are excluded), a single value as follows: 2307 See section 4.1 of [RFC3393] for details on the conditional 2308 distribution to exclude undefined values of delay, and Section 5 of 2309 [RFC6703] for background on this analysis choice. 2311 See section 4.3 of [RFC3393] for details on the percentile statistic 2312 (where Round-trip delay should be substituted for "ipdv"). 2314 The percentile = 95, meaning that the reported delay, "95Percentile", 2315 is the smallest value of one-way delay for which the Empirical 2316 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2317 one-way delay values in the conditional distribution. See section 2318 11.3 of [RFC2330] for the definition of the percentile statistic 2319 using the EDF. 2321 95Percentile The time value of the result is expressed in units of 2322 seconds, as a positive value of type decimal64 with fraction 2323 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2324 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2325 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2327 8.4.2.2. Mean 2329 The mean SHALL be calculated using the conditional distribution of 2330 all packets with a finite value of One-way delay (undefined delays 2331 are excluded), a single value as follows: 2333 See section 4.1 of [RFC3393] for details on the conditional 2334 distribution to exclude undefined values of delay, and Section 5 of 2335 [RFC6703] for background on this analysis choice. 2337 See section 4.2.2 of [RFC6049] for details on calculating this 2338 statistic, and 4.2.3 of [RFC6049]. 2340 Mean The time value of the result is expressed in units of seconds, 2341 as a positive value of type decimal64 with fraction digits = 9 2342 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2343 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2344 NTP timestamp as per section 6 of RFC [RFC5905] 2346 8.4.2.3. Min 2348 The minimum SHALL be calculated using the conditional distribution of 2349 all packets with a finite value of One-way delay (undefined delays 2350 are excluded), a single value as follows: 2352 See section 4.1 of [RFC3393] for details on the conditional 2353 distribution to exclude undefined values of delay, and Section 5 of 2354 [RFC6703] for background on this analysis choice. 2356 See section 4.3.2 of [RFC6049] for details on calculating this 2357 statistic, and 4.3.3 of [RFC6049]. 2359 Min The time value of the result is expressed in units of seconds, 2360 as a positive value of type decimal64 with fraction digits = 9 2361 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2362 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2363 NTP timestamp as per section 6 of RFC [RFC5905] 2365 8.4.2.4. Max 2367 The maximum SHALL be calculated using the conditional distribution of 2368 all packets with a finite value of One-way delay (undefined delays 2369 are excluded), a single value as follows: 2371 See section 4.1 of [RFC3393] for details on the conditional 2372 distribution to exclude undefined values of delay, and Section 5 of 2373 [RFC6703] for background on this analysis choice. 2375 See section 4.3.2 of [RFC6049] for a closely related method for 2376 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2377 as follows: 2379 Max = (FiniteDelay [j]) 2381 such that for some index, j, where 1 <= j <= N 2382 FiniteDelay[j] >= FiniteDelay[n] for all n 2384 Max The time value of the result is expressed in units of seconds, 2385 as a positive value of type decimal64 with fraction digits = 9 2386 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2387 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2388 NTP timestamp as per section 6 of RFC [RFC5905] 2390 8.4.2.5. Std_Dev 2392 The Std_Dev SHALL be calculated using the conditional distribution of 2393 all packets with a finite value of One-way delay (undefined delays 2394 are excluded), a single value as follows: 2396 See section 4.1 of [RFC3393] for details on the conditional 2397 distribution to exclude undefined values of delay, and Section 5 of 2398 [RFC6703] for background on this analysis choice. 2400 See section 4.3.2 of [RFC6049] for a closely related method for 2401 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2402 the classic calculation for standard deviation of a population. 2404 Define Population Std_Dev_Delay as follows: 2405 (where all packets n = 1 through N have a value for Delay[n], 2406 and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the 2407 Square Root function: 2408 _ _ 2409 | N | 2410 | --- | 2411 | 1 \ 2 | 2412 Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) | 2413 | (N) / | 2414 | --- | 2415 | n = 1 | 2416 |_ _| 2418 Std_Dev The time value of the result is expressed in units of 2419 seconds, as a positive value of type decimal64 with fraction 2420 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2421 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2422 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2424 8.4.3. Metric Units 2426 The of One-way Delay is expressed in seconds, where 2427 is one of: 2429 o 95Percentile 2431 o Mean 2433 o Min 2435 o Max 2437 o StdDev 2439 The One-way Loss Ratio is expressed as a percentage of lost packets 2440 to total packets sent. 2442 8.4.4. Calibration 2444 Section 3.7.3 of [RFC7679] provides a means to quantify the 2445 systematic and random errors of a time measurement. In-situ 2446 calibration could be enabled with an internal loopback that includes 2447 as much of the measurement system as possible, performs address 2448 manipulation as needed, and provides some form of isolation (e.g., 2449 deterministic delay) to avoid send-receive interface contention. 2450 Some portion of the random and systematic error can be characterized 2451 this way. 2453 For one-way delay measurements, the error calibration must include an 2454 assessment of the internal clock synchronization with its external 2455 reference (this internal clock is supplying timestamps for 2456 measurement). In practice, the time offsets [RFC5905] of clocks at 2457 both the source and destination are needed to estimate the systematic 2458 error due to imperfect clock synchronization (the time offsets 2459 [RFC5905] are smoothed, thus the random variation is not usually 2460 represented in the results). 2462 time_offset The time value of the result is expressed in units of 2463 seconds, as a signed value of type decimal64 with fraction digits 2464 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2465 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2466 NTP timestamp as per section 6 of RFC [RFC5905] 2468 When a measurement controller requests a calibration measurement, the 2469 loopback is applied and the result is output in the same format as a 2470 normal measurement with additional indication that it is a 2471 calibration result. In any measurement, the measurement function 2472 SHOULD report its current estimate of time offset [RFC5905] as an 2473 indicator of the degree of synchronization. 2475 Both internal loopback calibration and clock synchronization can be 2476 used to estimate the available accuracy of the Output Metric Units. 2477 For example, repeated loopback delay measurements will reveal the 2478 portion of the Output result resolution which is the result of system 2479 noise, and thus inaccurate. 2481 8.5. Administrative items 2483 8.5.1. Status 2485 Current 2487 8.5.2. Requester 2489 This RFC number 2491 8.5.3. Revision 2493 1.0 2495 8.5.4. Revision Date 2497 YYYY-MM-DD 2499 8.6. Comments and Remarks 2501 None. 2503 9. ICMP Round-trip Latency and Loss Registry Entries 2505 This section specifies three initial registry entries for the ICMP 2506 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2508 IANA Note: Registry "Name" below specifies multiple registry entries, 2509 whose output format varies according to the element of 2510 the name that specifies one form of statistical summary. There is an 2511 additional metric name for the Loss metric. 2513 All column entries beside the ID, Name, Description, and Output 2514 Reference Method categories are the same, thus this section proposes 2515 two closely-related registry entries. As a result, IANA is also 2516 asked to assign corresponding URLs to each Named Metric. 2518 9.1. Summary 2520 This category includes multiple indexes to the registry entry: the 2521 element ID and metric name. 2523 9.1.1. ID (Identifier) 2525 IANA is asked to assign different numeric identifiers to each of the 2526 four Named Metrics. 2528 9.1.2. Name 2530 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_ 2532 where is one of: 2534 o Mean 2536 o Min 2538 o Max 2540 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio 2542 9.1.3. URIs 2544 URL: https://www.iana.org/ ... 2546 9.1.4. Description 2548 RTDelay: This metric assesses the delay of a stream of ICMP packets 2549 exchanged between two hosts (which are the two measurement points), 2550 and the Output is the Round-trip delay for all successfully exchanged 2551 packets expressed as the of their conditional delay 2552 distribution, where is one of: 2554 o Mean 2556 o Min 2558 o Max 2560 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2561 packets exchanged between two hosts (which are the two measurement 2562 points), and the Output is the Round-trip loss ratio for all 2563 successfully exchanged packets expressed as a percentage. 2565 9.1.5. Change Controller 2567 IETF 2569 9.1.6. Version (of Registry Format) 2571 1.0 2573 9.2. Metric Definition 2575 This category includes columns to prompt the entry of all necessary 2576 details related to the metric definition, including the RFC reference 2577 and values of input factors, called fixed parameters. 2579 9.2.1. Reference Definition 2581 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2582 Metric for IPPM", RFC 2681, September 1999. 2584 [RFC2681] 2586 Section 2.4 of [RFC2681] provides the reference definition of the 2587 singleton (single value) Round-trip delay metric. Section 3.4 of 2588 [RFC2681] provides the reference definition expanded to cover a 2589 multi-singleton sample. Note that terms such as singleton and sample 2590 are defined in Section 11 of [RFC2330]. 2592 Note that although the [RFC2681] definition of "Round-trip-Delay 2593 between Src and Dst" is directionally ambiguous in the text, this 2594 metric tightens the definition further to recognize that the host in 2595 the "Src" role will send the first packet to "Dst", and ultimately 2596 receive the corresponding return packet from "Dst" (when neither are 2597 lost). 2599 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2600 the value of Round-trip delay in metric definitions and methods. The 2601 variable "dT" has been re-used in other IPPM literature to refer to 2602 different quantities, and cannot be used as a global variable name. 2604 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2606 [RFC6673] 2608 Both delay and loss metrics employ a maximum waiting time for 2609 received packets, so the count of lost packets to total packets sent 2610 is the basis for the loss ratio calculation as per Section 6.1 of 2611 [RFC6673]. 2613 9.2.2. Fixed Parameters 2615 Type-P as defined in Section 13 of [RFC2330]: 2617 o IPv4 header values: 2619 * DSCP: set to 0 2621 * TTL: set to 255 2623 * Protocol: Set to 01 (ICMP) 2625 o IPv6 header values: 2627 * DSCP: set to 0 2629 * Hop Count: set to 255 2631 * Next Header: set to 128 decimal (ICMP) 2633 * Flow Label: set to zero 2635 * Extension Headers: none 2637 o ICMP header values: 2639 * Type: 8 (Echo Request) 2641 * Code: 0 2642 * Checksum: the checksum MUST be calculated and the non-zero 2643 checksum included in the header 2645 * (Identifier and Sequence Number set at Run-Time) 2647 o ICMP Payload 2649 * total of 32 bytes of random info, constant per test. 2651 Other measurement parameters: 2653 o Tmax: a loss threshold waiting time 2655 * 3.0, expressed in units of seconds, as a positive value of type 2656 decimal64 with fraction digits = 4 (see section 9.3 of 2657 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2658 lossless conversion to/from the 32-bit NTP timestamp as per 2659 section 6 of [RFC5905]. 2661 9.3. Method of Measurement 2663 This category includes columns for references to relevant sections of 2664 the RFC(s) and any supplemental information needed to ensure an 2665 unambiguous methods for implementations. 2667 9.3.1. Reference Method 2669 The methodology for this metric is defined as Type-P-Round-trip- 2670 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2671 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2672 Fixed Parameters. 2674 The reference method distinguishes between long-delayed packets and 2675 lost packets by implementing a maximum waiting time for packet 2676 arrival. Tmax is the waiting time used as the threshold to declare a 2677 packet lost. Lost packets SHALL be designated as having undefined 2678 delay, and counted for the RTLoss metric. 2680 The calculations on the delay (RTD) SHALL be performed on the 2681 conditional distribution, conditioned on successful packet arrival 2682 within Tmax. Also, when all packet delays are stored, the process 2683 which calculates the RTD value MUST enforce the Tmax threshold on 2684 stored values before calculations. See section 4.1 of [RFC3393] for 2685 details on the conditional distribution to exclude undefined values 2686 of delay, and Section 5 of [RFC6703] for background on this analysis 2687 choice. 2689 The reference method requires some way to distinguish between 2690 different packets in a stream to establish correspondence between 2691 sending times and receiving times for each successfully-arriving 2692 packet. Sequence numbers or other send-order identification MUST be 2693 retained at the Src or included with each packet to disambiguate 2694 packet reordering if it occurs. 2696 The measurement process will determine the sequence numbers applied 2697 to test packets after the Fixed and Runtime parameters are passed to 2698 that process. The ICMP measurement process and protocol will dictate 2699 the format of sequence numbers and other identifiers. 2701 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2702 instruction to "send a Type-P packet back to the Src as quickly as 2703 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2704 [RFC6673] presents additional requirements which MUST be included in 2705 the method of measurement for this metric. 2707 9.3.2. Packet Stream Generation 2709 This section gives the details of the packet traffic which is the 2710 basis for measurement. In IPPM metrics, this is called the Stream, 2711 and can easily be described by providing the list of stream 2712 parameters. 2714 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2715 On Receive. This is a modification of Section 3 of [RFC3432], which 2716 prescribes the method for generating Periodic streams using 2717 associated parameters as defined below for this description: 2719 incT the nominal duration of inter-packet interval, first bit to 2720 first bit 2722 dT the duration of the interval for allowed sample start times 2724 The incT stream parameter will be specified as a Run-time parameter, 2725 and dT is not used in SendOnRcv. 2727 A SendOnRcv sender behaves exactly like a Periodic stream generator 2728 while all reply packets arrive with RTD < incT, and the inter-packet 2729 interval will be constant. 2731 If a reply packet arrives with RTD >= incT, then the inter-packet 2732 interval for the next sending time is nominally RTD. 2734 If a reply packet fails to arrive within Tmax, then the inter-packet 2735 interval for the next sending time is nominally Tmax. 2737 If an immediate send on reply arrival is desired, then set incT=0. 2739 9.3.3. Traffic Filtering (observation) Details 2741 NA 2743 9.3.4. Sampling Distribution 2745 NA 2747 9.3.5. Run-time Parameters and Data Format 2749 Run-time Parameters are input factors that must be determined, 2750 configured into the measurement system, and reported with the results 2751 for the context to be complete. 2753 Src the IP address of the host in the Src Role (format ipv4-address- 2754 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2755 see Section 4 of [RFC6991]) 2757 Dst the IP address of the host in the Dst Role (format ipv4-address- 2758 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2759 see section 4 of [RFC6991]) 2761 incT the nominal duration of inter-packet interval, first bit to 2762 first bit, expressed in units of seconds, as a positive value of 2763 type decimal64 with fraction digits = 4 (see section 9.3 of 2764 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 2766 T0 a time, the start of a measurement interval, (format "date-and- 2767 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2768 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2769 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2770 and Tf is to be interpreted as the Duration of the measurement 2771 interval. The start time is controlled through other means. 2773 Count The total count of ICMP Echo Requests to send, formatted as a 2774 uint16, as per section 9.2 of [RFC6020]. 2776 (see the Packet Stream Generation section for additional Run-time 2777 parameters) 2779 9.3.6. Roles 2781 Src launches each packet and waits for return transmissions from 2782 Dst. 2784 Dst waits for each packet from Src and sends a return packet to Src. 2786 9.4. Output 2788 This category specifies all details of the Output of measurements 2789 using the metric. 2791 9.4.1. Type 2793 See subsection titles in Reference Definition for Latency Types. 2795 LossRatio -- the count of lost packets to total packets sent is the 2796 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 2798 9.4.2. Reference Definition 2800 For all output types --- 2802 T0 the start of a measurement interval, (format "date-and-time" as 2803 specified in Section 5.6 of [RFC3339], see also Section 3 of 2804 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2805 [RFC2330]. 2807 Tf the end of a measurement interval, (format "date-and-time" as 2808 specified in Section 5.6 of [RFC3339], see also Section 3 of 2809 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2810 [RFC2330]. 2812 TotalCount the count of packets actually sent by the Src to Dst 2813 during the measurement interval. 2815 For LossRatio -- the count of lost packets to total packets sent is 2816 the basis for the loss ratio calculation as per Section 4.1 of 2817 [RFC7680]. 2819 For each , one of the following sub-sections apply: 2821 9.4.2.1. Mean 2823 The mean SHALL be calculated using the conditional distribution of 2824 all packets with a finite value of Round-trip delay (undefined delays 2825 are excluded), a single value as follows: 2827 See section 4.1 of [RFC3393] for details on the conditional 2828 distribution to exclude undefined values of delay, and Section 5 of 2829 [RFC6703] for background on this analysis choice. 2831 See section 4.2.2 of [RFC6049] for details on calculating this 2832 statistic, and 4.2.3 of [RFC6049]. 2834 Mean The time value of the result is expressed in units of seconds, 2835 as a positive value of type decimal64 with fraction digits = 9 2836 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2837 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2838 NTP timestamp as per section 6 of RFC [RFC5905] 2840 9.4.2.2. Min 2842 The minimum SHALL be calculated using the conditional distribution of 2843 all packets with a finite value of Round-trip delay (undefined delays 2844 are excluded), a single value as follows: 2846 See section 4.1 of [RFC3393] for details on the conditional 2847 distribution to exclude undefined values of delay, and Section 5 of 2848 [RFC6703] for background on this analysis choice. 2850 See section 4.3.2 of [RFC6049] for details on calculating this 2851 statistic, and 4.3.3 of [RFC6049]. 2853 Min The time value of the result is expressed in units of seconds, 2854 as a positive value of type decimal64 with fraction digits = 9 2855 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2856 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2857 NTP timestamp as per section 6 of RFC [RFC5905] 2859 9.4.2.3. Max 2861 The maximum SHALL be calculated using the conditional distribution of 2862 all packets with a finite value of Round-trip delay (undefined delays 2863 are excluded), a single value as follows: 2865 See section 4.1 of [RFC3393] for details on the conditional 2866 distribution to exclude undefined values of delay, and Section 5 of 2867 [RFC6703] for background on this analysis choice. 2869 See section 4.3.2 of [RFC6049] for a closely related method for 2870 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2871 as follows: 2873 Max = (FiniteDelay [j]) 2875 such that for some index, j, where 1 <= j <= N 2876 FiniteDelay[j] >= FiniteDelay[n] for all n 2878 Max The time value of the result is expressed in units of seconds, 2879 as a positive value of type decimal64 with fraction digits = 9 2880 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2881 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2882 NTP timestamp as per section 6 of RFC [RFC5905] 2884 9.4.3. Metric Units 2886 The of Round-trip Delay is expressed in seconds, where 2887 is one of: 2889 o Mean 2891 o Min 2893 o Max 2895 The Round-trip Loss Ratio is expressed as a percentage of lost 2896 packets to total packets sent. 2898 9.4.4. Calibration 2900 Section 3.7.3 of [RFC7679] provides a means to quantify the 2901 systematic and random errors of a time measurement. In-situ 2902 calibration could be enabled with an internal loopback at the Source 2903 host that includes as much of the measurement system as possible, 2904 performs address manipulation as needed, and provides some form of 2905 isolation (e.g., deterministic delay) to avoid send-receive interface 2906 contention. Some portion of the random and systematic error can be 2907 characterized this way. 2909 When a measurement controller requests a calibration measurement, the 2910 loopback is applied and the result is output in the same format as a 2911 normal measurement with additional indication that it is a 2912 calibration result. 2914 Both internal loopback calibration and clock synchronization can be 2915 used to estimate the available accuracy of the Output Metric Units. 2916 For example, repeated loopback delay measurements will reveal the 2917 portion of the Output result resolution which is the result of system 2918 noise, and thus inaccurate. 2920 9.5. Administrative items 2922 9.5.1. Status 2924 Current 2926 9.5.2. Requester 2928 This RFC number 2930 9.5.3. Revision 2932 1.0 2934 9.5.4. Revision Date 2936 YYYY-MM-DD 2938 9.6. Comments and Remarks 2940 None 2942 10. TCP Round-Trip Delay and Loss Registry Entries 2944 This section specifies three initial registry entries for the Passive 2945 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 2946 Round-trip Loss Count. 2948 IANA Note: Registry "Name" below specifies multiple registry entries, 2949 whose output format varies according to the element of 2950 the name that specifies one form of statistical summary. There are 2951 two additional metric names for Singleton RT Delay and Packet Count 2952 metrics. 2954 All column entries beside the ID, Name, Description, and Output 2955 Reference Method categories are the same, thus this section proposes 2956 four closely-related registry entries. As a result, IANA is also 2957 asked to assign corresponding URLs to each Named Metric. 2959 10.1. Summary 2961 This category includes multiple indexes to the registry entry: the 2962 element ID and metric name. 2964 10.1.1. ID (Identifier) 2966 IANA is asked to assign different numeric identifiers to each of the 2967 four Named Metrics. 2969 10.1.2. Name 2971 RTDelay_Passive_IP-TCP_RFCXXXXsec10_Seconds_ 2973 where is one of: 2975 o Mean 2977 o Min 2979 o Max 2981 RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton 2983 Note that a mid-point observer only has the opportunity to compose a 2984 single RTDelay on the TCP Hand Shake. 2986 RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count 2988 10.1.3. URIs 2990 URL: https://www.iana.org/ ... 2992 10.1.4. Description 2994 RTDelay: This metric assesses the round-trip delay of TCP packets 2995 constituting a single connection, exchanged between two hosts. We 2996 consider the measurement of round-trip delay based on a single 2997 Observation Point [RFC7011] somewhere in the network. The Output is 2998 the Round-trip delay for all successfully exchanged packets expressed 2999 as the of their conditional delay distribution, where 3000 is one of: 3002 o Mean 3004 o Min 3006 o Max 3008 RTLoss: This metric assesses the estimated loss count for TCP packets 3009 constituting a single connection, exchanged between two hosts. We 3010 consider the measurement of round-trip delay based on a single 3011 Observation Point [RFC7011] somewhere in the network. The Output is 3012 the estimated Loss Count for the measurement interval. 3014 10.1.5. Change Controller 3016 IETF 3018 10.1.6. Version (of Registry Format) 3020 1.0 3022 10.2. Metric Definition 3024 This category includes columns to prompt the entry of all necessary 3025 details related to the metric definition, including the RFC reference 3026 and values of input factors, called fixed parameters. 3028 10.2.1. Reference Definitions 3030 Although there is no RFC that describes passive measurement of Round- 3031 Trip Delay, the parallel definition for Active measurement is: 3033 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 3034 Metric for IPPM", RFC 2681, September 1999. 3036 [RFC2681] 3038 This metric definition uses the terms singleton and sample as defined 3039 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 3040 reference definition of the singleton (single value) Round-trip delay 3041 metric. Section 3.4 of [RFC2681] provides the reference definition 3042 expanded to cover a multi-singleton sample.) 3044 With the Observation Point [RFC7011] (OP) typically located between 3045 the hosts participating in the TCP connection, the Round-trip Delay 3046 metric requires two individual measurements between the OP and each 3047 host, such that the Spatial Composition [RFC6049]of the measurements 3048 yields a Round-trip Delay singleton (we are extending the composition 3049 of one-way subpath delays to subpath round-trip delay). 3051 Using the direction of TCP SYN transmission to anchor the 3052 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3053 during connection establishment. The direction of SYN transfer is 3054 considered the Forward direction of transmission, from A through OP 3055 to B (Reverse is B through OP to A). 3057 Traffic filters reduce the packet stream at the OP to a Qualified 3058 bidirectional flow of packets. 3060 In the definitions below, Corresponding Packets are transferred in 3061 different directions and convey a common value in a TCP header field 3062 that establishes correspondence (to the extent possible). Examples 3063 may be found in the TCP timestamp fields. 3065 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3066 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3067 observed a Qualified Packet to host B at wire-time T', that host B 3068 received that packet and sent a Corresponding Packet back to host A, 3069 and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. 3071 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3072 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3073 OP observed a Qualified Packet to host A at wire-time T'', that host 3074 A received that packet and sent a Corresponding Packet back to host 3075 B, and that OP observed the Corresponding Packet at wire-time T'' + 3076 RTD_rev. 3078 Ideally, the packet sent from host B to host A in both definitions 3079 above SHOULD be the same packet (or, when measuring RTD_rev first, 3080 the packet from host A to host B in both definitions should be the 3081 same). 3083 The REQUIRED Composition Function for a singleton of Round-trip Delay 3084 at time T (where T is the earliest of T' and T'' above) is: 3086 RTDelay = RTD_fwd + RTD_rev 3088 Note that when OP is located at host A or host B, one of the terms 3089 composing RTDelay will be zero or negligible. 3091 When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- 3092 SYN-ACK, then RTD_fwd == RTD_HS_fwd. 3094 When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a 3095 TCP-ACK, then RTD_rev == RTD_HS_rev. 3097 The REQUIRED Composition Function for a singleton of Round-trip Delay 3098 for the connection Hand Shake: 3100 RTDelay_HS = RTD_HS_fwd + RTD_HS_rev 3102 The definition of Round-trip Loss Count uses the nomenclature 3103 developed above, based on observation of the TCP header sequence 3104 numbers and storing the sequence number gaps observed. Packet Losses 3105 can be inferred from: 3107 o Out-of-order segments: TCP segments are transmitted with 3108 monotonically increasing sequence numbers, but these segments may 3109 be received out of order. Section 3 of [RFC4737] describes the 3110 notion of "next expected" sequence numbers which can be adapted to 3111 TCP segments (for the purpose of detecting reordered packets). 3112 Observation of out-of-order segments indicates loss on the path 3113 prior to the OP, and creates a gap. 3115 o Duplicate segments: Section 2 of [RFC5560] defines identical 3116 packets and is suitable for evaluation of TCP packets to detect 3117 duplication. Observation of duplicate segments *without a 3118 corresponding gap* indicates loss on the path following the OP 3119 (because they overlap part of the delivered sequence numbers 3120 already observed at OP). 3122 Each observation of an out-of-order or duplicate infers a singleton 3123 of loss, but composition of Round-trip Loss Counts will be conducted 3124 over a measurement interval which is synonymous with a single TCP 3125 connection. 3127 With the above observations in the Forward direction over a 3128 measurement interval, the count of out-of-order and duplicate 3129 segments is defined as RTL_fwd. Comparable observations in the 3130 Reverse direction are defined as RTL_rev. 3132 For a measurement interval (corresponding to a single TCP 3133 connection), T0 to Tf, the REQUIRED Composition Function for a the 3134 two single-direction counts of inferred loss is: 3136 RTLoss = RTL_fwd + RTL_rev 3138 10.2.2. Fixed Parameters 3140 Traffic Filters: 3142 o IPv4 header values: 3144 * DSCP: set to 0 3146 * Protocol: Set to 06 (TCP) 3148 o IPv6 header values: 3150 * DSCP: set to 0 3152 * Hop Count: set to 255 3154 * Next Header: set to 6 (TCP) 3156 * Flow Label: set to zero 3158 * Extension Headers: none 3160 o TCP header values: 3162 * Flags: ACK, SYN, FIN, set as required 3164 * Timestamp Option (TSopt): Set 3166 + Section 3.2 of [RFC7323] 3168 10.3. Method of Measurement 3170 This category includes columns for references to relevant sections of 3171 the RFC(s) and any supplemental information needed to ensure an 3172 unambiguous methods for implementations. 3174 10.3.1. Reference Methods 3176 The foundation methodology for this metric is defined in Section 4 of 3177 [RFC7323] using the Timestamp Option with modifications that allow 3178 application at a mid-path Observation Point (OP) [RFC7011]. Further 3179 details and applicable heuristics were derived from [Strowes] and 3180 [Trammell-14]. 3182 The Traffic Filter at the OP is configured to observe a single TCP 3183 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3184 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3185 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3186 of RTDelay as RTDelay_HS (composed using the forward and reverse 3187 measurement pair). RTDelay_HS SHALL be treated separately from other 3188 RTDelays on data-bearing packets and their ACKs. The RTDelay_HS 3189 value MAY be used as a sanity check on other Composed values of 3190 RTDelay. 3192 For payload bearing packets, the OP measures the time interval 3193 between observation of a packet with Sequence Number s, and the 3194 corresponding ACK with same Sequence number. When the payload is 3195 transferred from host A to host B, the observed interval is RTD_fwd. 3197 Because many data transfers are unidirectional (say, in the Forward 3198 direction from host A to host B), it is necessary to use pure ACK 3199 packets with Timestamp (TSval) and their Timestamp value echo to 3200 perform a RTD_rev measurement. The time interval between observation 3201 of the ACK from B to A, and the corresponding packet with Timestamp 3202 echo (TSecr) is the RTD_rev. 3204 Delay Measurement Filtering Heuristics: 3206 If Data payloads were transferred in both Forward and Reverse 3207 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3208 of [RFC7323] could be applied. This rule essentially excludes any 3209 measurement using a packet unless it makes progress in the transfer 3210 (advances the left edge of the send window, consistent with 3211 [Strowes]). 3213 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3214 that is larger than previously observed values. This would tend to 3215 exclude Reverse measurements taken when the Application has no data 3216 ready to send, because considerable time could be added to RTD_rev 3217 from this source of error. 3219 Note that the above Heuristic assumes that host A is sending data. 3220 Host A expecting a download would mean that this heuristic should be 3221 applied to RTD_fwd. 3223 The statistic calculations to summarize the delay (RTDelay) SHALL be 3224 performed on the conditional distribution, conditioned on successful 3225 Forward and Reverse measurements which follow the Heuristics. 3227 Method for Inferring Loss: 3229 The OP tracks sequence numbers and stores gaps for each direction of 3230 transmission, as well as the next-expected sequence number as in 3231 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3232 segments and Duplicate segments. 3234 Loss Measurement Filtering Heuristics: 3236 [Trammell-14] adds a window of evaluation based on the RTDelay. 3238 Distinguish Re-ordered from OOO due to loss, because sequence number 3239 gap is filled during the same RTDelay window. Segments detected as 3240 re-ordered according to [RFC4737] MUST reduce the Loss Count inferred 3241 from Out-of-order segments. 3243 Spurious (unneeded) retransmissions (observed as duplicates) can also 3244 be reduced this way, as described in [Trammell-14]. 3246 Sources of Error: 3248 The principal source of RTDelay error is the host processing time to 3249 return a packet that defines the termination of a time interval. The 3250 heuristics above intend to mitigate these errors by excluding 3251 measurements where host processing time is a significant part of 3252 RTD_fwd or RTD_rev. 3254 A key source of RTLoss error is observation loss, described in 3255 section 3 of [Trammell-14]. 3257 10.3.2. Packet Stream Generation 3259 NA 3261 10.3.3. Traffic Filtering (observation) Details 3263 The Fixed Parameters above give a portion of the Traffic Filter. 3264 Other aspects will be supplied as Run-time Parameters (below). 3266 10.3.4. Sampling Distribution 3268 This metric requires a complete sample of all packets that qualify 3269 according to the Traffic Filter criteria. 3271 10.3.5. Run-time Parameters and Data Format 3273 Run-time Parameters are input factors that must be determined, 3274 configured into the measurement system, and reported with the results 3275 for the context to be complete. 3277 Src the IP address of the host in the host A Role (format ipv4- 3278 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3279 IPv6, see Section 4 of [RFC6991]) 3281 Dst the IP address of the host in the host B (format ipv4-address- 3282 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3283 see section 4 of [RFC6991]) 3285 T0 a time, the start of a measurement interval, (format "date-and- 3286 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3287 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3288 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3289 and Td is to be interpreted as the Duration of the measurement 3290 interval. The start time is controlled through other means. 3292 Td Optionally, the end of a measurement interval, (format "date-and- 3293 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3294 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3295 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3296 the measurement interval MAY be controlled by the measured 3297 connection, where the second pair of FIN and ACK packets exchanged 3298 between host A and B effectively ends the interval. 3300 TTL or Hop Limit Set at desired value. 3302 10.3.6. Roles 3304 host A launches the SYN packet to open the connection, and 3305 synonymous with an IP address. 3307 host B replies with the SYN-ACK packet to open the connection, and 3308 synonymous with an IP address. 3310 10.4. Output 3312 This category specifies all details of the Output of measurements 3313 using the metric. 3315 10.4.1. Type 3317 See subsection titles in Reference Definition for RTDelay Types. 3319 For RTLoss -- the count of lost packets. 3321 10.4.2. Reference Definition 3323 For all output types --- 3325 T0 the start of a measurement interval, (format "date-and-time" as 3326 specified in Section 5.6 of [RFC3339], see also Section 3 of 3327 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3328 [RFC2330]. 3330 Tf the end of a measurement interval, (format "date-and-time" as 3331 specified in Section 5.6 of [RFC3339], see also Section 3 of 3332 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3333 [RFC2330]. The end of the measurement interval MAY be controlled 3334 by the measured connection, where the second pair of FIN and ACK 3335 packets exchanged between host A and B effectively ends the 3336 interval. 3338 ... ... 3340 For RTDelay_HS -- the Round trip delay of the Handshake. 3342 For RTLoss -- the count of lost packets. 3344 For each , one of the following sub-sections apply: 3346 10.4.2.1. Mean 3348 The mean SHALL be calculated using the conditional distribution of 3349 all packets with a finite value of Round-trip delay (undefined delays 3350 are excluded), a single value as follows: 3352 See section 4.1 of [RFC3393] for details on the conditional 3353 distribution to exclude undefined values of delay, and Section 5 of 3354 [RFC6703] for background on this analysis choice. 3356 See section 4.2.2 of [RFC6049] for details on calculating this 3357 statistic, and 4.2.3 of [RFC6049]. 3359 Mean The time value of the result is expressed in units of seconds, 3360 as a positive value of type decimal64 with fraction digits = 9 3361 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3362 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3363 NTP timestamp as per section 6 of RFC [RFC5905] 3365 10.4.2.2. Min 3367 The minimum SHALL be calculated using the conditional distribution of 3368 all packets with a finite value of Round-trip delay (undefined delays 3369 are excluded), a single value as follows: 3371 See section 4.1 of [RFC3393] for details on the conditional 3372 distribution to exclude undefined values of delay, and Section 5 of 3373 [RFC6703] for background on this analysis choice. 3375 See section 4.3.2 of [RFC6049] for details on calculating this 3376 statistic, and 4.3.3 of [RFC6049]. 3378 Min The time value of the result is expressed in units of seconds, 3379 as a positive value of type decimal64 with fraction digits = 9 3380 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3381 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3382 NTP timestamp as per section 6 of RFC [RFC5905] 3384 10.4.2.3. Max 3386 The maximum SHALL be calculated using the conditional distribution of 3387 all packets with a finite value of Round-trip delay (undefined delays 3388 are excluded), a single value as follows: 3390 See section 4.1 of [RFC3393] for details on the conditional 3391 distribution to exclude undefined values of delay, and Section 5 of 3392 [RFC6703] for background on this analysis choice. 3394 See section 4.3.2 of [RFC6049] for a closely related method for 3395 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3396 as follows: 3398 Max = (FiniteDelay [j]) 3400 such that for some index, j, where 1 <= j <= N 3401 FiniteDelay[j] >= FiniteDelay[n] for all n 3403 Max The time value of the result is expressed in units of seconds, 3404 as a positive value of type decimal64 with fraction digits = 9 3405 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3406 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3407 NTP timestamp as per section 6 of RFC [RFC5905] 3409 10.4.3. Metric Units 3411 The of Round-trip Delay is expressed in seconds, where 3412 is one of: 3414 o Mean 3416 o Min 3418 o Max 3420 The Round-trip Delay of the Hand Shake is expressed in seconds. 3422 The Round-trip Loss Count is expressed as a number of packets. 3424 10.4.4. Calibration 3426 Passive measurements at an OP could be calibrated against an active 3427 measurement (with loss emulation) at host A or B, where the active 3428 measurement represents the ground-truth. 3430 10.5. Administrative items 3432 10.5.1. Status 3434 Current 3436 10.5.2. Requester 3438 This RFC number 3440 10.5.3. Revision 3442 1.0 3444 10.5.4. Revision Date 3446 YYYY-MM-DD 3448 10.6. Comments and Remarks 3450 None. 3452 11. Security Considerations 3454 These registry entries represent no known implications for Internet 3455 Security. Each IETF Metric definition referenced above contains a 3456 Security Considerations section. Further, the LMAP Framework 3457 [RFC7594] provides both security and privacy considerations for 3458 measurements. 3460 There are potential privacy considerations for observed traffic, 3461 particularly for passive metrics in section 10. An attacker that 3462 knows that its TCP connection is being measured can modify its 3463 behavior to skew the measurement results. 3465 12. IANA Considerations 3467 IANA is requested to populate The Performance Metrics Registry 3468 defined in [I-D.ietf-ippm-metric-registry] with the values defined in 3469 sections 4 through 10. 3471 See the IANA Considerations section of 3472 [I-D.ietf-ippm-metric-registry] for additional requests and 3473 considerations. 3475 13. Acknowledgements 3477 The authors thank Brian Trammell for suggesting the term "Run-time 3478 Parameters", which led to the distinction between run-time and fixed 3479 parameters implemented in this memo, for identifying the IPFIX metric 3480 with Flow Key as an example, for suggesting the Passive TCP RTD 3481 metric and supporting references, and for many other productive 3482 suggestions. Thanks to Peter Koch, who provided several useful 3483 suggestions for disambiguating successive DNS Queries in the DNS 3484 Response time metric. 3486 The authors also acknowledge the constructive reviews and helpful 3487 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, 3488 Yaakov Stein, and participants in the LMAP working group. Thanks to 3489 Michelle Cotton for her early IANA reviews, and to Amanda Barber for 3490 answering questions related to the presentation of the registry and 3491 accessibility of the complete template via URL. 3493 14. References 3495 14.1. Normative References 3497 [I-D.ietf-ippm-metric-registry] 3498 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 3499 "Registry for Performance Metrics", Internet Draft (work 3500 in progress) draft-ietf-ippm-metric-registry, 2019. 3502 [RFC1035] Mockapetris, P., "Domain names - implementation and 3503 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3504 November 1987, . 3506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3507 Requirement Levels", BCP 14, RFC 2119, 3508 DOI 10.17487/RFC2119, March 1997, 3509 . 3511 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 3512 "Framework for IP Performance Metrics", RFC 2330, 3513 DOI 10.17487/RFC2330, May 1998, 3514 . 3516 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 3517 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 3518 September 1999, . 3520 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3521 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3522 . 3524 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 3525 Metric for IP Performance Metrics (IPPM)", RFC 3393, 3526 DOI 10.17487/RFC3393, November 2002, 3527 . 3529 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 3530 performance measurement with periodic streams", RFC 3432, 3531 DOI 10.17487/RFC3432, November 2002, 3532 . 3534 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 3535 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 3536 DOI 10.17487/RFC4737, November 2006, 3537 . 3539 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3540 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 3541 RFC 5357, DOI 10.17487/RFC5357, October 2008, 3542 . 3544 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 3545 RFC 5560, DOI 10.17487/RFC5560, May 2009, 3546 . 3548 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 3549 "Network Time Protocol Version 4: Protocol and Algorithms 3550 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 3551 . 3553 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3554 the Network Configuration Protocol (NETCONF)", RFC 6020, 3555 DOI 10.17487/RFC6020, October 2010, 3556 . 3558 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 3559 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 3560 . 3562 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 3563 DOI 10.17487/RFC6673, August 2012, 3564 . 3566 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3567 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3568 . 3570 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3571 "Specification of the IP Flow Information Export (IPFIX) 3572 Protocol for the Exchange of Flow Information", STD 77, 3573 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3574 . 3576 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 3577 Scheffenegger, Ed., "TCP Extensions for High Performance", 3578 RFC 7323, DOI 10.17487/RFC7323, September 2014, 3579 . 3581 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3582 Ed., "A One-Way Delay Metric for IP Performance Metrics 3583 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 3584 2016, . 3586 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3587 Ed., "A One-Way Loss Metric for IP Performance Metrics 3588 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 3589 2016, . 3591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3593 May 2017, . 3595 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, 3596 Communications of the ACM, Vol. 56 No. 10, Pages 57-64", 3597 September 2013. 3599 [Trammell-14] 3600 Trammell, B., "Inline Data Integrity Signals for Passive 3601 Measurement, In: Dainotti A., Mahanti A., Uhlig S. (eds) 3602 Traffic Monitoring and Analysis. TMA 2014. Lecture Notes 3603 in Computer Science, vol 8406. Springer, Berlin, 3604 Heidelberg https://link.springer.com/ 3605 chapter/10.1007/978-3-642-54999-1_2", March 2014. 3607 14.2. Informative References 3609 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 3610 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 3611 July 1991, . 3613 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 3614 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 3615 March 2009, . 3617 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 3618 Performance Metric Development", BCP 170, RFC 6390, 3619 DOI 10.17487/RFC6390, October 2011, 3620 . 3622 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 3623 IP Network Performance Metrics: Different Points of View", 3624 RFC 6703, DOI 10.17487/RFC6703, August 2012, 3625 . 3627 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 3628 Aitken, P., and A. Akhter, "A Framework for Large-Scale 3629 Measurement of Broadband Performance (LMAP)", RFC 7594, 3630 DOI 10.17487/RFC7594, September 2015, 3631 . 3633 Authors' Addresses 3634 Al Morton 3635 AT&T Labs 3636 200 Laurel Avenue South 3637 Middletown,, NJ 07748 3638 USA 3640 Phone: +1 732 420 1571 3641 Fax: +1 732 368 1192 3642 Email: acmorton@att.com 3644 Marcelo Bagnulo 3645 Universidad Carlos III de 3646 Madrid 3647 Av. Universidad 30 3648 Leganes, Madrid 28911 3649 SPAIN 3651 Phone: 34 91 6249500 3652 Email: marcelo@it.uc3m.es 3653 URI: http://www.it.uc3m.es 3655 Philip Eardley 3656 BT 3657 Adastral Park, Martlesham Heath 3658 Ipswich 3659 ENGLAND 3661 Email: philip.eardley@bt.com 3663 Kevin D'Souza 3664 AT&T Labs 3665 200 Laurel Avenue South 3666 Middletown,, NJ 07748 3667 USA 3669 Phone: +1 732 420 xxxx 3670 Email: kld@att.com