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