idnits 2.17.1 draft-ietf-ippm-initial-registry-09.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 599 has weird spacing: '... Src the IP...' == Line 603 has weird spacing: '... Dst the IP...' == Line 623 has weird spacing: '... Src launch...' == Line 626 has weird spacing: '... Dst waits ...' == Line 668 has weird spacing: '...talPkts the c...' == (23 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 7, 2018) is 1965 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2680' is defined on line 3509, but no explicit reference was found in the text == Unused Reference: 'RFC3611' is defined on line 3599, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 3604, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 3608, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 3612, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 3617, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 3626, but no explicit reference was found in the text == Unused Reference: 'RFC6776' is defined on line 3641, but no explicit reference was found in the text == Unused Reference: 'RFC6792' is defined on line 3647, but no explicit reference was found in the text == Unused Reference: 'RFC7003' is defined on line 3652, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 3657, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 19 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track M. Bagnulo 5 Expires: June 10, 2019 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 December 7, 2018 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-09 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. This version includes: 20 * removed sections which only contained examples, or a blank outine 21 for new metric entries. 23 * removed remaining comments (did not require action). 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14[RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 10, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 70 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 71 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 73 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 77 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 78 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 79 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 80 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 81 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 82 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 83 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 84 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 85 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 86 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 87 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 90 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 91 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 92 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 93 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 94 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 95 4.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 16 96 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 97 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 99 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 100 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 101 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 103 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 17 104 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 105 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 106 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 107 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 108 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 109 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 110 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 111 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19 112 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 113 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 114 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 115 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 116 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 117 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 118 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 119 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 120 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21 121 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22 122 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 123 5.5. Administrative items . . . . . . . . . . . . . . . . . . 23 124 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 125 5.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 23 126 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 127 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 128 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 129 6. DNS Response Latency and Loss Registry Entries . . . . . . . 23 130 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 131 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24 132 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 133 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 134 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 135 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24 136 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24 137 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 138 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25 139 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 140 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 141 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 142 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28 143 6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 144 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 145 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 146 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 148 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 149 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 31 150 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31 151 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 152 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31 153 6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 154 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 155 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 32 156 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 157 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 158 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 159 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32 160 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 161 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33 162 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 163 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33 164 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 165 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34 166 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34 167 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 168 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36 169 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 170 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36 171 7.3.3. Traffic Filtering (observation) Details . . . . . . . 37 172 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37 173 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 174 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38 175 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38 176 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38 177 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38 178 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41 179 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41 180 7.5. Administrative items . . . . . . . . . . . . . . . . . . 42 181 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42 182 7.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 42 183 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 184 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 42 185 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 42 186 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 43 187 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 188 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 189 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 190 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44 191 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 44 192 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44 193 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44 194 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45 195 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46 196 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46 197 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47 198 8.3.3. Traffic Filtering (observation) Details . . . . . . . 48 199 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48 200 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 201 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 202 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 48 203 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49 204 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 205 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 51 206 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 207 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 208 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 209 8.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 53 210 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 211 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 212 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53 213 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 53 214 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 53 215 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 53 216 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 217 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54 218 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54 219 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 54 220 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 54 221 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55 222 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 223 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 224 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 56 225 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 56 226 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 57 227 9.3.3. Traffic Filtering (observation) Details . . . . . . . 58 228 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 58 229 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 58 230 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 231 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 59 232 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 59 233 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 59 234 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 61 235 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 61 236 9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 237 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 238 9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 62 239 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 62 240 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 62 241 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 62 242 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 62 243 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63 244 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 245 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 246 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 63 247 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 63 248 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 249 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 250 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 64 251 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 64 252 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 66 253 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 67 254 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 67 255 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 69 256 10.3.3. Traffic Filtering (observation) Details . . . . . . 69 257 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 69 258 10.3.5. Run-time Parameters and Data Format . . . . . . . . 69 259 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 70 260 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 70 261 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 70 262 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 70 263 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 72 264 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 73 265 10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 266 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 267 10.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 73 268 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 73 269 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 73 270 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 73 271 11. Security Considerations . . . . . . . . . . . . . . . . . . . 73 272 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 273 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 274 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 275 14.1. Normative References . . . . . . . . . . . . . . . . . . 74 276 14.2. Informative References . . . . . . . . . . . . . . . . . 76 277 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 279 1. Introduction 281 Note: Efforts to synchronize structure and terminology with 282 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 283 drafts are stable. 285 This memo proposes an initial set of entries for the Performance 286 Metric Registry. It uses terms and definitions from the IPPM 287 literature, primarily [RFC2330]. 289 Although there are several standard templates for organizing 290 specifications of performance metrics (see [RFC2679] for an example 291 of the traditional IPPM template, based to large extent on the 292 Benchmarking Methodology Working Group's traditional template in 293 [RFC1242], and see [RFC6390] for a similar template), none of these 294 templates were intended to become the basis for the columns of an 295 IETF-wide registry of metrics. While examining aspects of metric 296 specifications which need to be registered, it became clear that none 297 of the existing metric templates fully satisfies the particular needs 298 of a registry. 300 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 301 for a Performance Metric Registry. Section 5 of 302 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 303 requesting registration of a Metric, that is the creation of entry(s) 304 in the Performance Metric Registry: "In essence, there needs to be 305 evidence that a candidate Registered Performance Metric has 306 significant industry interest, or has seen deployment, and there is 307 agreement that the candidate Registered Performance Metric serves its 308 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 309 also requires that new entries are administered by IANA through 310 Expert Review, which will ensure that the metrics are tightly 311 defined. 313 2. Scope 315 This document defines the initial set of Performance Metrics Registry 316 entries, for which IETF approval (following development in the IP 317 Performance Metrics (IPPM) Working Group) will satisfy the 318 requirement for Expert Review. Most are Active Performance Metrics, 319 which are based on RFCs prepared in the IPPM working group of the 320 IETF, according to their framework [RFC2330] and its updates. 322 3. Registry Categories and Columns 324 This section provides the categories and columns of the registry, for 325 easy reference. An entry (row) therefore gives a complete 326 description of a Registered Metric. 328 Registry Categories and Columns, shown as 329 Category 330 ------------------ 331 Column | Column | 333 Summary 334 ------------------------------------------------------------------------ 335 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 337 Metric Definition 338 ----------------------------------------- 339 Reference Definition | Fixed Parameters | 341 Method of Measurement 342 --------------------------------------------------------------------- 343 Reference | Packet | Traffic | Sampling | Run-time | Role | 344 Method | Stream | Filter | Distribution | Parameters | | 345 | Generation | 346 Output 347 ----------------------------------------- 348 Type | Reference | Units | Calibration | 349 | Definition | | | 351 Administrative Information 352 ---------------------------------- 353 Status |Request | Rev | Rev.Date | 355 Comments and Remarks 356 -------------------- 358 4. UDP Round-trip Latency and Loss Registry Entries 360 This section specifies an initial registry entry for the UDP Round- 361 trip Latency, and another entry for UDP Round-trip Loss Ratio. 363 Note: Each Registry entry only produces a "raw" output or a 364 statistical summary. To describe both "raw" and one or more 365 statistics efficiently, the Identifier, Name, and Output Categories 366 can be split and a single section can specify two or more closely- 367 related metrics. This section specifies two Registry entries with 368 many common columns. See Section 7 for an example specifying 369 multiple Registry entries with many common columns. 371 All column entries beside the ID, Name, Description, and Output 372 Reference Method categories are the same, thus this section proposes 373 two closely-related registry entries. As a result, IANA is also 374 asked to assign corresponding URNs and URLs to each Named Metric. 376 4.1. Summary 378 This category includes multiple indexes to the registry entry: the 379 element ID and metric name. 381 4.1.1. ID (Identifier) 383 IANA is asked to assign different numeric identifiers to each of the 384 two Named Metrics. 386 4.1.2. Name 388 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 390 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio 392 4.1.3. URIs 394 URN: Prefix urn:ietf:metrics:perf: 396 URL: http:/// 398 4.1.4. Description 400 RTDelay: This metric assesses the delay of a stream of packets 401 exchanged between two hosts (which are the two measurement points), 402 and the Output is the Round-trip delay for all successfully exchanged 403 packets expressed as the 95th percentile of their conditional delay 404 distribution. 406 RTLoss: This metric assesses the loss ratio of a stream of packets 407 exchanged between two hosts (which are the two measurement points), 408 and the Output is the Round-trip loss ratio for all successfully 409 exchanged packets expressed as a percentage. 411 4.1.5. Change Controller 413 IETF 415 4.1.6. Version (of Registry Format) 417 1.0 419 4.2. Metric Definition 421 This category includes columns to prompt the entry of all necessary 422 details related to the metric definition, including the RFC reference 423 and values of input factors, called fixed parameters. 425 4.2.1. Reference Definition 427 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 428 Metric for IPPM", RFC 2681, September 1999. 430 [RFC2681] 432 Section 2.4 of [RFC2681] provides the reference definition of the 433 singleton (single value) Round-trip delay metric. Section 3.4 of 434 [RFC2681] provides the reference definition expanded to cover a 435 multi-singleton sample. Note that terms such as singleton and sample 436 are defined in Section 11 of [RFC2330]. 438 Note that although the [RFC2681] definition of "Round-trip-Delay 439 between Src and Dst" is directionally ambiguous in the text, this 440 metric tightens the definition further to recognize that the host in 441 the "Src" role will send the first packet to "Dst", and ultimately 442 receive the corresponding return packet from "Dst" (when neither are 443 lost). 445 Finally, note that the variable "dT" is used in [RFC2681] to refer to 446 the value of Round-trip delay in metric definitions and methods. The 447 variable "dT" has been re-used in other IPPM literature to refer to 448 different quantities, and cannot be used as a global variable name. 450 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 452 [RFC6673] 454 Both delay and loss metrics employ a maximum waiting time for 455 received packets, so the count of lost packets to total packets sent 456 is the basis for the loss ratio calculation as per Section 6.1 of 457 [RFC6673]. 459 4.2.2. Fixed Parameters 461 Type-P as defined in Section 13 of [RFC2330]: 463 o IPv4 header values: 465 * DSCP: set to 0 467 * TTL: set to 255 469 * Protocol: Set to 17 (UDP) 471 o IPv6 header values: 473 * DSCP: set to 0 475 * Hop Count: set to 255 477 * Protocol: Set to 17 (UDP) 479 o UDP header values: 481 * Checksum: the checksum MUST be calculated and included in the 482 header 484 o UDP Payload 486 * total of 100 bytes 488 Other measurement parameters: 490 o Tmax: a loss threshold waiting time 492 * 3.0, expressed in units of seconds, as a positive value of type 493 decimal64 with fraction digits = 4 (see section 9.3 of 494 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 495 lossless conversion to/from the 32-bit NTP timestamp as per 496 section 6 of [RFC5905]. 498 4.3. Method of Measurement 500 This category includes columns for references to relevant sections of 501 the RFC(s) and any supplemental information needed to ensure an 502 unambiguous methods for implementations. 504 4.3.1. Reference Method 506 The methodology for this metric is defined as Type-P-Round-trip- 507 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 508 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 509 Fixed Parameters. However, the Periodic stream will be generated 510 according to [RFC3432]. 512 The reference method distinguishes between long-delayed packets and 513 lost packets by implementing a maximum waiting time for packet 514 arrival. Tmax is the waiting time used as the threshold to declare a 515 packet lost. Lost packets SHALL be designated as having undefined 516 delay, and counted for the RTLoss metric. 518 The calculations on the delay (RTT) SHALL be performed on the 519 conditional distribution, conditioned on successful packet arrival 520 within Tmax. Also, when all packet delays are stored, the process 521 which calculates the RTT value MAY enforce the Tmax threshold on 522 stored values before calculations. See section 4.1 of [RFC3393] for 523 details on the conditional distribution to exclude undefined values 524 of delay, and Section 5 of [RFC6703] for background on this analysis 525 choice. 527 The reference method requires some way to distinguish between 528 different packets in a stream to establish correspondence between 529 sending times and receiving times for each successfully-arriving 530 packet. Sequence numbers or other send-order identification MUST be 531 retained at the Src or included with each packet to disambiguate 532 packet reordering if it occurs. 534 If a standard measurement protocol is employed, then the measurement 535 process will determine the sequence numbers or timestamps applied to 536 test packets after the Fixed and Runtime parameters are passed to 537 that process. The chosen measurement protocol will dictate the 538 format of sequence numbers and time-stamps, if they are conveyed in 539 the packet payload. 541 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 542 instruction to "send a Type-P packet back to the Src as quickly as 543 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 544 [RFC6673] presents additional requirements which MUST be included in 545 the method of measurement for this metric. 547 4.3.2. Packet Stream Generation 549 This section gives the details of the packet traffic which is the 550 basis for measurement. In IPPM metrics, this is called the Stream, 551 and can easily be described by providing the list of stream 552 parameters. 554 Section 3 of [RFC3432] prescribes the method for generating Periodic 555 streams using associated parameters. 557 incT the nominal duration of inter-packet interval, first bit to 558 first bit, with value 0.0200, expressed in units of seconds, as a 559 positive value of type decimal64 with fraction digits = 4 (see 560 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 561 (0.1 ms). 563 dT the duration of the interval for allowed sample start times, with 564 value 1.0, expressed in units of seconds, as a positive value of 565 type decimal64 with fraction digits = 4 (see section 9.3 of 566 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 568 T0 the actual start time of the periodic stream, (format "date-and- 569 time" as specified in Section 5.6 of [RFC3339], see also Section 3 570 of [RFC6991]). 572 NOTE: an initiation process with a number of control exchanges 573 resulting in unpredictable start times (within a time interval) may 574 be sufficient to avoid synchronization of periodic streams, and 575 therefore a valid replacement for selecting a start time at random 576 from a fixed interval. 578 The T0 parameter will be reported as a measured parameter. 579 Parameters incT and dT are Fixed Parameters. 581 4.3.3. Traffic Filtering (observation) Details 583 The measured results based on a filtered version of the packets 584 observed, and this section provides the filter details (when 585 present). 587 NA 589 4.3.4. Sampling Distribution 591 NA 593 4.3.5. Run-time Parameters and Data Format 595 Run-time Parameters are input factors that must be determined, 596 configured into the measurement system, and reported with the results 597 for the context to be complete. 599 Src the IP address of the host in the Src Role (format ipv4-address- 600 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 601 see Section 4 of [RFC6991]) 603 Dst the IP address of the host in the Dst Role (format ipv4-address- 604 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 605 see section 4 of [RFC6991]) 607 T0 a time, the start of a measurement interval, (format "date-and- 608 time" as specified in Section 5.6 of [RFC3339], see also Section 3 609 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 610 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 611 and Tf is to be interpreted as the Duration of the measurement 612 interval. The start time is controlled through other means. 614 Tf a time, the end of a measurement interval, (format "date-and-time" 615 as specified in Section 5.6 of [RFC3339], see also Section 3 of 617 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 618 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 619 Tf is interpreted as the Duration of the measurement interval. 621 4.3.6. Roles 623 Src launches each packet and waits for return transmissions from 624 Dst. 626 Dst waits for each packet from Src and sends a return packet to Src. 628 4.4. Output 630 This category specifies all details of the Output of measurements 631 using the metric. 633 4.4.1. Type 635 Percentile -- for the conditional distribution of all packets with a 636 valid value of Round-trip delay (undefined delays are excluded), a 637 single value corresponding to the 95th percentile, as follows: 639 See section 4.1 of [RFC3393] for details on the conditional 640 distribution to exclude undefined values of delay, and Section 5 of 641 [RFC6703] for background on this analysis choice. 643 The percentile = 95, meaning that the reported delay, "95Percentile", 644 is the smallest value of Round-trip delay for which the Empirical 645 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 646 Round-trip delay values in the conditional distribution. See section 647 11.3 of [RFC2330] for the definition of the percentile statistic 648 using the EDF. 650 LossRatio -- the count of lost packets to total packets sent is the 651 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 653 4.4.2. Reference Definition 655 For all outputs --- 657 T0 the start of a measurement interval, (format "date-and-time" as 658 specified in Section 5.6 of [RFC3339], see also Section 3 of 659 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 660 [RFC2330]. 662 Tf the end of a measurement interval, (format "date-and-time" as 663 specified in Section 5.6 of [RFC3339], see also Section 3 of 665 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 666 [RFC2330]. 668 TotalPkts the count of packets sent by the Src to Dst during the 669 measurement interval. 671 For 673 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile: 675 95Percentile The time value of the result is expressed in units of 676 seconds, as a positive value of type decimal64 with fraction 677 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 678 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 679 the 64-bit NTP timestamp as 681 For 683 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio: 685 Percentile The numeric value of the result is expressed in units of 686 lost packets to total packets times 100%, as a positive value of 687 type decimal64 with fraction digits = 9 (see section 9.3 of 688 [RFC6020]) with resolution of 0.0000000001. 690 4.4.3. Metric Units 692 The 95th Percentile of Round-trip Delay is expressed in seconds. 694 The Round-trip Loss Ratio is expressed as a percentage of lost 695 packets to total packets sent. 697 4.4.4. Calibration 699 Section 3.7.3 of [RFC7679] provides a means to quantify the 700 systematic and random errors of a time measurement. In-situ 701 calibration could be enabled with an internal loopback at the Source 702 host that includes as much of the measurement system as possible, 703 performs address manipulation as needed, and provides some form of 704 isolation (e.g., deterministic delay) to avoid send-receive interface 705 contention. Some portion of the random and systematic error can be 706 characterized this way. 708 When a measurement controller requests a calibration measurement, the 709 loopback is applied and the result is output in the same format as a 710 normal measurement with additional indication that it is a 711 calibration result. 713 Both internal loopback calibration and clock synchronization can be 714 used to estimate the *available accuracy* of the Output Metric Units. 715 For example, repeated loopback delay measurements will reveal the 716 portion of the Output result resolution which is the result of system 717 noise, and thus inaccurate. 719 4.5. Administrative items 721 4.5.1. Status 723 Current 725 4.5.2. Requestor 727 This RFC numner 729 4.5.3. Revision 731 1.0 733 4.5.4. Revision Date 735 YYYY-MM-DD 737 4.6. Comments and Remarks 739 None. 741 5. Packet Delay Variation Registry Entry 743 This section gives an initial registry entry for a Packet Delay 744 Variation metric. 746 Note: If each Registry entry should only produce a "raw" output or a 747 statistical summary, then the "Output" Category can be split and this 748 section can become two closely-related metrics. 750 5.1. Summary 752 This category includes multiple indexes to the registry entries, the 753 element ID and metric name. 755 5.1.1. ID (Identifier) 757 759 5.1.2. Name 761 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 763 5.1.3. URIs 765 URI: Prefix urn:ietf:metrics:perf: 767 URL: http:/// 769 5.1.4. Description 771 An assessment of packet delay variation with respect to the minimum 772 delay observed on the periodic stream, and the Output is expressed as 773 the 95th percentile of the packet delay variation distribution. 775 5.1.5. Change Controller 777 IETF 779 5.1.6. Version (of Registry Format) 781 1.0 783 5.2. Metric Definition 785 This category includes columns to prompt the entry of all necessary 786 details related to the metric definition, including the RFC reference 787 and values of input factors, called fixed parameters. 789 5.2.1. Reference Definition 791 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 792 Performance Metrics", RFC 2330, May 1998. [RFC2330] 794 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 795 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 796 [RFC3393] 798 Morton, A. and B. Claise, "Packet Delay Variation Applicability 799 Statement", RFC 5481, March 2009. [RFC5481] 801 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 802 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 803 June 2010.[RFC5905] 805 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 806 measured are referred to by the variable name "ddT" (applicable to 807 all forms of delay variation). However, this metric entry specifies 808 the PDV form defined in section 4.2 of [RFC5481], where the singleton 809 PDV for packet i is referred to by the variable name "PDV(i)". 811 5.2.2. Fixed Parameters 813 o IPv4 header values: 815 * DSCP: set to 0 817 * TTL: set to 255 819 * Protocol: Set to 17 (UDP) 821 o IPv6 header values: 823 * DSCP: set to 0 825 * Hop Count: set to 255 827 * Protocol: Set to 17 (UDP) 829 o UDP header values: 831 * Checksum: the checksum MUST be calculated and included in the 832 header 834 o UDP Payload 836 * total of 200 bytes 838 Other measurement parameters: 840 Tmax: a loss threshold waiting time with value 3.0, expressed in 841 units of seconds, as a positive value of type decimal64 with 842 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 843 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 844 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 846 F a selection function unambiguously defining the packets from the 847 stream selected for the metric. See section 4.2 of [RFC5481] for 848 the PDV form. 850 See the Packet Stream generation category for two additional Fixed 851 Parameters. 853 5.3. Method of Measurement 855 This category includes columns for references to relevant sections of 856 the RFC(s) and any supplemental information needed to ensure an 857 unambiguous methods for implementations. 859 5.3.1. Reference Method 861 See section 2.6 and 3.6 of [RFC3393] for general singleton element 862 calculations. This metric entry requires implementation of the PDV 863 form defined in section 4.2 of [RFC5481]. Also see measurement 864 considerations in section 8 of [RFC5481]. 866 The reference method distinguishes between long-delayed packets and 867 lost packets by implementing a maximum waiting time for packet 868 arrival. Tmax is the waiting time used as the threshold to declare a 869 packet lost. Lost packets SHALL be designated as having undefined 870 delay. 872 The calculations on the one-way delay SHALL be performed on the 873 conditional distribution, conditioned on successful packet arrival 874 within Tmax. Also, when all packet delays are stored, the process 875 which calculates the one-way delay value MAY enforce the Tmax 876 threshold on stored values before calculations. See section 4.1 of 877 [RFC3393] for details on the conditional distribution to exclude 878 undefined values of delay, and Section 5 of [RFC6703] for background 879 on this analysis choice. 881 The reference method requires some way to distinguish between 882 different packets in a stream to establish correspondence between 883 sending times and receiving times for each successfully-arriving 884 packet. Sequence numbers or other send-order identification MUST be 885 retained at the Src or included with each packet to disambiguate 886 packet reordering if it occurs. 888 If a standard measurement protocol is employed, then the measurement 889 process will determine the sequence numbers or timestamps applied to 890 test packets after the Fixed and Runtime parameters are passed to 891 that process. The chosen measurement protocol will dictate the 892 format of sequence numbers and time-stamps, if they are conveyed in 893 the packet payload. 895 5.3.2. Packet Stream Generation 897 This section gives the details of the packet traffic which is the 898 basis for measurement. In IPPM metrics, this is called the Stream, 899 and can easily be described by providing the list of stream 900 parameters. 902 Section 3 of [RFC3432] prescribes the method for generating Periodic 903 streams using associated parameters. 905 incT the nominal duration of inter-packet interval, first bit to 906 first bit, with value 0.0200, expressed in units of seconds, as a 907 positive value of type decimal64 with fraction digits = 4 (see 908 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 909 (0.1 ms). 911 dT the duration of the interval for allowed sample start times, with 912 value 1.0, expressed in units of seconds, as a positive value of 913 type decimal64 with fraction digits = 4 (see section 9.3 of 914 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 916 T0 the actual start time of the periodic stream, (format "date-and- 917 time" as specified in Section 5.6 of [RFC3339], see also Section 3 918 of [RFC6991]). 920 NOTE: an initiation process with a number of control exchanges 921 resulting in unpredictable start times (within a time interval) may 922 be sufficient to avoid synchronization of periodic streams, and 923 therefore a valid replacement for selecting a start time at random 924 from a fixed interval. 926 The T0 parameter will be reported as a measured parameter. 927 Parameters incT and dT are Fixed Parameters. 929 5.3.3. Traffic Filtering (observation) Details 931 NA 933 5.3.4. Sampling Distribution 935 NA 937 5.3.5. Run-time Parameters and Data Format 939 Src the IP address of the host in the Src Role (format ipv4-address- 940 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 941 see Section 4 of [RFC6991]) 943 Dst the IP address of the host in the Dst Role (format ipv4-address- 944 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 945 see section 4 of [RFC6991]) 947 T0 a time, the start of a measurement interval, (format "date-and- 948 time" as specified in Section 5.6 of [RFC3339], see also Section 3 949 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 951 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 952 and Tf is to be interpreted as the Duration of the measurement 953 interval. The start time is controlled through other means. 955 Tf a time, the end of a measurement interval, (format "date-and-time" 956 as specified in Section 5.6 of [RFC3339], see also Section 3 of 957 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 958 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 959 Tf is interpreted as the Duration of the measurement interval. 961 5.3.6. Roles 963 5.4. Output 965 This category specifies all details of the Output of measurements 966 using the metric. 968 5.4.1. Type 970 Percentile -- for the conditional distribution of all packets with a 971 valid value of one-way delay (undefined delays are excluded), a 972 single value corresponding to the 95th percentile, as follows: 974 See section 4.1 of [RFC3393] for details on the conditional 975 distribution to exclude undefined values of delay, and Section 5 of 976 [RFC6703] for background on this analysis choice. 978 The percentile = 95, meaning that the reported delay, "95Percentile", 979 is the smallest value of one-way PDV for which the Empirical 980 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 981 one-way PDV values in the conditional distribution. See section 11.3 982 of [RFC2330] for the definition of the percentile statistic using the 983 EDF. 985 5.4.2. Reference Definition 987 T0 the start of a measurement interval, (format "date-and-time" as 988 specified in Section 5.6 of [RFC3339], see also Section 3 of 989 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 990 [RFC2330]. 992 Tf the end of a measurement interval, (format "date-and-time" as 993 specified in Section 5.6 of [RFC3339], see also Section 3 of 994 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 995 [RFC2330]. 997 95Percentile The time value of the result is expressed in units of 998 seconds, as a positive value of type decimal64 with fraction 999 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1000 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1001 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1003 5.4.3. Metric Units 1005 The 95th Percentile of one-way PDV is expressed in seconds. 1007 5.4.4. Calibration 1009 Section 3.7.3 of [RFC7679] provides a means to quantify the 1010 systematic and random errors of a time measurement. In-situ 1011 calibration could be enabled with an internal loopback that includes 1012 as much of the measurement system as possible, performs address 1013 manipulation as needed, and provides some form of isolation (e.g., 1014 deterministic delay) to avoid send-receive interface contention. 1015 Some portion of the random and systematic error can be characterized 1016 this way. 1018 For one-way delay measurements, the error calibration must include an 1019 assessment of the internal clock synchronization with its external 1020 reference (this internal clock is supplying timestamps for 1021 measurement). In practice, the time offsets of clocks at both the 1022 source and destination are needed to estimate the systematic error 1023 due to imperfect clock synchronization (the time offsets are 1024 smoothed, thus the random variation is not usually represented in the 1025 results). 1027 time_offset The time value of the result is expressed in units of 1028 seconds, as a signed value of type decimal64 with fraction digits 1029 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1030 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1031 NTP timestamp as per section 6 of RFC [RFC5905] 1033 When a measurement controller requests a calibration measurement, the 1034 loopback is applied and the result is output in the same format as a 1035 normal measurement with additional indication that it is a 1036 calibration result. In any measurement, the measurement function 1037 SHOULD report its current estimate of time offset as an indicator of 1038 the degree of synchronization. 1040 Both internal loopback calibration and clock synchronization can be 1041 used to estimate the *available accuracy* of the Output Metric Units. 1042 For example, repeated loopback delay measurements will reveal the 1043 portion of the Output result resolution which is the result of system 1044 noise, and thus inaccurate. 1046 5.5. Administrative items 1048 5.5.1. Status 1050 Current 1052 5.5.2. Requestor 1054 This RFC number 1056 5.5.3. Revision 1058 1.0 1060 5.5.4. Revision Date 1062 YYYY-MM-DD 1064 5.6. Comments and Remarks 1066 Lost packets represent a challenge for delay variation metrics. See 1067 section 4.1 of [RFC3393] and the delay variation applicability 1068 statement[RFC5481] for extensive analysis and comparison of PDV and 1069 an alternate metric, IPDV. 1071 6. DNS Response Latency and Loss Registry Entries 1073 This section gives initial registry entries for DNS Response Latency 1074 and Loss from a network user's perspective, for a specific named 1075 resource. The metric can be measured repeatedly using different 1076 names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1077 build on that metric by specifying several of the input parameters to 1078 precisely define two metrics for measuring DNS latency and loss. 1080 Note to IANA: Each Registry "Name" below specifies a single registry 1081 entry, whose output format varies in accordance with the name. 1083 All column entries beside the ID, Name, Description, and Output 1084 Reference Method categories are the same, thus this section proposes 1085 two closely-related registry entries. As a result, IANA is also 1086 asked to assign corresponding URNs and URLs to each Named Metric. 1088 6.1. Summary 1090 This category includes multiple indexes to the registry entries, the 1091 element ID and metric name. 1093 6.1.1. ID (Identifier) 1095 1097 IANA is asked to assign different numeric identifiers to each of the 1098 two Named Metrics. 1100 6.1.2. Name 1102 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1104 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw 1106 6.1.3. URI 1108 URI: Prefix urn:ietf:metrics:perf: 1110 URL: http:/// 1112 6.1.4. Description 1114 This is a metric for DNS Response performance from a network user's 1115 perspective, for a specific named resource. The metric can be 1116 measured repeatedly using different resource names. 1118 RTDNS: This metric assesses the response time, the interval from the 1119 query transmission to the response. 1121 RLDNS: This metric indicates that the response was deemed lost. In 1122 other words, the response time exceeded the maximum waiting time. 1124 6.1.5. Change Controller 1126 IETF 1128 6.1.6. Version (of Registry Format) 1130 1.0 1132 6.2. Metric Definition 1134 This category includes columns to prompt the entry of all necessary 1135 details related to the metric definition, including the RFC reference 1136 and values of input factors, called fixed parameters. 1138 6.2.1. Reference Definition 1140 Mockapetris, P., "Domain names - implementation and specification", 1141 STD 13, RFC 1035, November 1987. (and updates) 1143 [RFC1035] 1145 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1146 Metric for IPPM", RFC 2681, September 1999. 1148 [RFC2681] 1150 Section 2.4 of [RFC2681] provides the reference definition of the 1151 singleton (single value) Round-trip delay metric. Section 3.4 of 1152 [RFC2681] provides the reference definition expanded to cover a 1153 multi-singleton sample. Note that terms such as singleton and sample 1154 are defined in Section 11 of [RFC2330]. 1156 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1157 [RFC2681]. The Local Host with its User Program and Resolver take 1158 the role of "Src", and the Foreign Name Server takes the role of 1159 "Dst". 1161 Note that although the [RFC2681] definition of "Round-trip-Delay 1162 between Src and Dst at T" is directionally ambiguous in the text, 1163 this metric tightens the definition further to recognize that the 1164 host in the "Src" role will send the first packet to "Dst", and 1165 ultimately receive the corresponding return packet from "Dst" (when 1166 neither are lost). 1168 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1170 [RFC6673] 1172 Both response time and loss metrics employ a maximum waiting time for 1173 received responses, so the count of lost packets to total packets 1174 sent is the basis for the loss determination as per Section 4.3 of 1175 [RFC6673]. 1177 6.2.2. Fixed Parameters 1179 Type-P as defined in Section 13 of [RFC2330]: 1181 o IPv4 header values: 1183 * DSCP: set to 0 1185 * TTL set to 255 1186 * Protocol: Set to 17 (UDP) 1188 o IPv6 header values: 1190 * DSCP: set to 0 1192 * Hop Count: set to 255 1194 * Protocol: Set to 17 (UDP) 1196 o UDP header values: 1198 * Source port: 53 1200 * Destination port: 53 1202 * Checksum: the checksum must be calculated and included in the 1203 header 1205 o Payload: The payload contains a DNS message as defined in RFC 1035 1206 [RFC1035] with the following values: 1208 * The DNS header section contains: 1210 + Identification (see the Run-time column) 1212 + QR: set to 0 (Query) 1214 + OPCODE: set to 0 (standard query) 1216 + AA: not set 1218 + TC: not set 1220 + RD: set to one (recursion desired) 1222 + RA: not set 1224 + RCODE: not set 1226 + QDCOUNT: set to one (only one entry) 1228 + ANCOUNT: not set 1230 + NSCOUNT: not set 1232 + ARCOUNT: not set 1234 * The Question section contains: 1236 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1237 input for the test, see the Run-time column 1239 + QTYPE: the query type provided as input for the test, see 1240 the Run-time column 1242 + QCLASS: set to 1 for IN 1244 * The other sections do not contain any Resource Records. 1246 Other measurement parameters: 1248 o Tmax: a loss threshold waiting time (and to help disambiguate 1249 queries) 1251 * 5.0, expressed in units of seconds, as a positive value of type 1252 decimal64 with fraction digits = 4 (see section 9.3 of 1253 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1254 lossless conversion to/from the 32-bit NTP timestamp as per 1255 section 6 of [RFC5905]. 1257 Observation: reply packets will contain a DNS response and may 1258 contain RRs. 1260 6.3. Method of Measurement 1262 This category includes columns for references to relevant sections of 1263 the RFC(s) and any supplemental information needed to ensure an 1264 unambiguous methods for implementations. 1266 6.3.1. Reference Method 1268 The methodology for this metric is defined as Type-P-Round-trip- 1269 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1270 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1271 Fixed Parameters. 1273 The reference method distinguishes between long-delayed packets and 1274 lost packets by implementing a maximum waiting time for packet 1275 arrival. Tmax is the waiting time used as the threshold to declare a 1276 response packet lost. Lost packets SHALL be designated as having 1277 undefined delay and counted for the RLDNS metric. 1279 The calculations on the delay (RTT) SHALL be performed on the 1280 conditional distribution, conditioned on successful packet arrival 1281 within Tmax. Also, when all packet delays are stored, the process 1282 which calculates the RTT value MAY enforce the Tmax threshold on 1283 stored values before calculations. See section 4.1 of [RFC3393] for 1284 details on the conditional distribution to exclude undefined values 1285 of delay, and Section 5 of [RFC6703] for background on this analysis 1286 choice. 1288 The reference method requires some way to distinguish between 1289 different packets in a stream to establish correspondence between 1290 sending times and receiving times for each successfully-arriving 1291 reply. 1293 DNS Messages bearing Queries provide for random ID Numbers in the 1294 Identification header field, so more than one query may be launched 1295 while a previous request is outstanding when the ID Number is used. 1296 Therefore, the ID Number MUST be retained at the Src or included with 1297 each response packet to disambiguate packet reordering if it occurs. 1299 IF a DNS response does not arrive within Tmax, the response time 1300 RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to 1301 disambiguate the successive queries that are otherwise identical. 1303 Since the ID Number filed is only 16 bits in length, it places a 1304 limit on the number of simultaneous outstanding DNS queries during a 1305 stress test from a single Src address. 1307 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1308 instruction to "send a Type-P packet back to the Src as quickly as 1309 possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS 1310 Server is expected to perform all required functions to prepare and 1311 send a response, so the response time will include processing time 1312 and network delay. Section 8 of [RFC6673] presents additional 1313 requirements which SHALL be included in the method of measurement for 1314 this metric. 1316 In addition to operations described in [RFC2681], the Src MUST parse 1317 the DNS headers of the reply and prepare the information for 1318 subsequent reporting as a measured result, along with the Round-Trip 1319 Delay. 1321 6.3.2. Packet Stream Generation 1323 This section gives the details of the packet traffic which is the 1324 basis for measurement. In IPPM metrics, this is called the Stream, 1325 and can easily be described by providing the list of stream 1326 parameters. 1328 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1329 generate Poisson sampling intervals. The reciprocal of lambda is the 1330 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1331 = 1/lambda, in seconds. 1333 Method 3 is used, where given a start time (Run-time Parameter), the 1334 subsequent send times are all computed prior to measurement by 1335 computing the pseudo-random distribution of inter-packet send times, 1336 (truncating the distribution as specified in the Run-time 1337 Parameters), and the Src sends each packet at the computed times. 1339 Note that Trunc is the upper limit on inter-packet times in the 1340 Poisson distribution. A random value greater than Trunc is set equal 1341 to Trunc instead. 1343 6.3.3. Traffic Filtering (observation) Details 1345 The measured results based on a filtered version of the packets 1346 observed, and this section provides the filter details (when 1347 present). 1349 NA 1351 6.3.4. Sampling Distribution 1353 NA 1355 6.3.5. Run-time Parameters and Data Format 1357 Run-time Parameters are input factors that must be determined, 1358 configured into the measurement system, and reported with the results 1359 for the context to be complete. 1361 Src the IP address of the host in the Src Role (format ipv4-address- 1362 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1363 see Section 4 of [RFC6991]) 1365 Dst the IP address of the host in the Dst Role (format ipv4-address- 1366 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1367 see section 4 of [RFC6991]) 1369 T0 a time, the start of a measurement interval, (format "date-and- 1370 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1371 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1372 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1373 and Tf is to be interpreted as the Duration of the measurement 1374 interval. The start time is controlled through other means. 1376 Tf a time, the end of a measurement interval, (format "date-and-time" 1377 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1379 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1380 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1381 Tf is interpreted as the Duration of the measurement interval. 1383 Reciprocal_lambda average packet interval for Poisson Streams 1384 expressed in units of seconds, as a positive value of type 1385 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1386 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1387 conversion to/from the 32-bit NTP timestamp as per section 6 of 1388 [RFC5905]. 1390 Trunc Upper limit on Poisson distribution expressed in units of 1391 seconds, as a positive value of type decimal64 with fraction 1392 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1393 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1394 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1395 this limit will be clipped and set to the limit value). (if fixed, 1396 Trunc = 30.0000 seconds.) 1398 ID The 16-bit identifier assigned by the program that generates the 1399 query, and which must vary in successive queries, see 1400 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1401 corresponding reply and can be used by the requester (Src) to 1402 match-up replies to outstanding queries. 1404 QNAME The domain name of the Query, formatted as specified in 1405 section 4 of [RFC6991]. 1407 QTYPE The Query Type, which will correspond to the IP address family 1408 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1409 uint16, as per section 9.2 of [RFC6020]. 1411 6.3.6. Roles 1413 Src launches each packet and waits for return transmissions from 1414 Dst. 1416 Dst waits for each packet from Src and sends a return packet to Src. 1418 6.4. Output 1420 This category specifies all details of the Output of measurements 1421 using the metric. 1423 6.4.1. Type 1425 Raw -- for each DNS Query packet sent, sets of values as defined in 1426 the next column, including the status of the response, only assigning 1427 delay values to successful query-response pairs. 1429 6.4.2. Reference Definition 1431 For all outputs: 1433 T the time the DNS Query was sent during the measurement interval, 1434 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1435 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1436 by Section 6.1 of [RFC2330]. 1438 dT The time value of the round-trip delay to receive the DNS 1439 response, expressed in units of seconds, as a positive value of 1440 type decimal64 with fraction digits = 9 (see section 9.3 of 1441 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1442 with lossless conversion to/from the 64-bit NTP timestamp as per 1443 section 6 of RFC [RFC5905]. This value is undefined when the 1444 response packet is not received at Src within waiting time Tmax 1445 seconds. 1447 Rcode The value of the Rcode field in the DNS response header, 1448 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1449 Non-zero values convey errors in the response, and such replies 1450 must be analyzed separately from successful requests. 1452 6.4.3. Metric Units 1454 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1456 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1458 6.4.4. Calibration 1460 Section 3.7.3 of [RFC7679] provides a means to quantify the 1461 systematic and random errors of a time measurement. In-situ 1462 calibration could be enabled with an internal loopback at the Source 1463 host that includes as much of the measurement system as possible, 1464 performs address and payload manipulation as needed, and provides 1465 some form of isolation (e.g., deterministic delay) to avoid send- 1466 receive interface contention. Some portion of the random and 1467 systematic error can be characterized this way. 1469 When a measurement controller requests a calibration measurement, the 1470 loopback is applied and the result is output in the same format as a 1471 normal measurement with additional indication that it is a 1472 calibration result. 1474 Both internal loopback calibration and clock synchronization can be 1475 used to estimate the *available accuracy* of the Output Metric Units. 1476 For example, repeated loopback delay measurements will reveal the 1477 portion of the Output result resolution which is the result of system 1478 noise, and thus inaccurate. 1480 6.5. Administrative items 1482 6.5.1. Status 1484 Current 1486 6.5.2. Requestor 1488 This RFC number 1490 6.5.3. Revision 1492 1.0 1494 6.5.4. Revision Date 1496 YYYY-MM-DD 1498 6.6. Comments and Remarks 1500 Additional (Informational) details for this entry 1502 7. UDP Poisson One-way Delay and Loss Registry Entries 1504 This section specifies five initial registry entries for the UDP 1505 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1507 IANA Note: Registry "Name" below specifies a single registry entry, 1508 whose output format varies according to the element of 1509 the name that specifies one form of statistical summary. There is an 1510 additional metric name for the Loss metric. 1512 All column entries beside the ID, Name, Description, and Output 1513 Reference Method categories are the same, thus this section proposes 1514 six closely-related registry entries. As a result, IANA is also 1515 asked to assign corresponding URNs and URLs to each Named Metric. 1517 7.1. Summary 1519 This category includes multiple indexes to the registry entries, the 1520 element ID and metric name. 1522 7.1.1. ID (Identifier) 1524 IANA is asked to assign different numeric identifiers to each of the 1525 six Metrics. 1527 7.1.2. Name 1529 OWDelay_Active_IP-UDP-Poisson- 1530 Payload250B_RFCXXXXsecY_Seconds_ 1532 where is one of: 1534 o 95Percentile 1536 o Mean 1538 o Min 1540 o Max 1542 o StdDev 1544 OWLoss_Active_IP-UDP-Poisson- 1545 Payload250B_RFCXXXXsecY_Percent_LossRatio 1547 7.1.3. URI and URL 1549 URI: Prefix urn:ietf:metrics:perf: 1551 URL: http:\\www.iana.org\ ... 1553 7.1.4. Description 1555 OWDelay: This metric assesses the delay of a stream of packets 1556 exchanged between two hosts (or measurement points), and reports the 1557 One-way delay for all successfully exchanged packets 1558 based on their conditional delay distribution. 1560 where is one of: 1562 o 95Percentile 1564 o Mean 1565 o Min 1567 o Max 1569 o StdDev 1571 OWLoss: This metric assesses the loss ratio of a stream of packets 1572 exchanged between two hosts (which are the two measurement points), 1573 and the Output is the One-way loss ratio for all successfully 1574 received packets expressed as a percentage. 1576 7.2. Metric Definition 1578 This category includes columns to prompt the entry of all necessary 1579 details related to the metric definition, including the RFC reference 1580 and values of input factors, called fixed parameters. 1582 7.2.1. Reference Definition 1584 For Delay: 1586 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1587 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1588 7679, DOI 10.17487/RFC7679, January 2016, . 1591 [RFC7679] 1593 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1594 6049, January 2011. 1596 [RFC6049] 1598 Section 3.4 of [RFC7679] provides the reference definition of the 1599 singleton (single value) One-way delay metric. Section 4.4 of 1600 [RFC7679] provides the reference definition expanded to cover a 1601 multi-value sample. Note that terms such as singleton and sample are 1602 defined in Section 11 of [RFC2330]. 1604 Only successful packet transfers with finite delay are included in 1605 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1607 For loss: 1609 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1610 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1611 10.17487/RFC7680, January 2016, . 1614 Section 2.4 of [RFC7680] provides the reference definition of the 1615 singleton (single value) one-way loss metric. Section 3.4 of 1616 [RFC7680] provides the reference definition expanded to cover a 1617 multi-singleton sample. Note that terms such as singleton and sample 1618 are defined in Section 11 of [RFC2330]. 1620 7.2.2. Fixed Parameters 1622 Type-P: 1624 o IPv4 header values: 1626 * DSCP: set to 0 1628 * TTL: set to 255 1630 * Protocol: Set to 17 (UDP) 1632 o IPv6 header values: 1634 * DSCP: set to 0 1636 * Hop Count: set to 255 1638 * Protocol: Set to 17 (UDP) 1640 o UDP header values: 1642 * Checksum: the checksum MUST be calculated and included in the 1643 header 1645 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1647 * Security features in use influence the number of Padding 1648 octets. 1650 * 250 octets total, including the TWAMP format 1652 Other measurement parameters: 1654 Tmax: a loss threshold waiting time with value 3.0, expressed in 1655 units of seconds, as a positive value of type decimal64 with 1656 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1657 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1658 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1660 See the Packet Stream generation category for two additional Fixed 1661 Parameters. 1663 7.3. Method of Measurement 1665 This category includes columns for references to relevant sections of 1666 the RFC(s) and any supplemental information needed to ensure an 1667 unambiguous methods for implementations. 1669 7.3.1. Reference Method 1671 The methodology for this metric is defined as Type-P-One-way-Delay- 1672 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1673 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1675 The reference method distinguishes between long-delayed packets and 1676 lost packets by implementing a maximum waiting time for packet 1677 arrival. Tmax is the waiting time used as the threshold to declare a 1678 packet lost. Lost packets SHALL be designated as having undefined 1679 delay, and counted for the OWLoss metric. 1681 The calculations on the one-way delay SHALL be performed on the 1682 conditional distribution, conditioned on successful packet arrival 1683 within Tmax. Also, when all packet delays are stored, the process 1684 which calculates the one-way delay value MAY enforce the Tmax 1685 threshold on stored values before calculations. See section 4.1 of 1686 [RFC3393] for details on the conditional distribution to exclude 1687 undefined values of delay, and Section 5 of [RFC6703] for background 1688 on this analysis choice. 1690 The reference method requires some way to distinguish between 1691 different packets in a stream to establish correspondence between 1692 sending times and receiving times for each successfully-arriving 1693 packet. Sequence numbers or other send-order identification MUST be 1694 retained at the Src or included with each packet to disambiguate 1695 packet reordering if it occurs. 1697 Since a standard measurement protocol is employed [RFC5357], then the 1698 measurement process will determine the sequence numbers or timestamps 1699 applied to test packets after the Fixed and Runtime parameters are 1700 passed to that process. The measurement protocol dictates the format 1701 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1702 payload. 1704 7.3.2. Packet Stream Generation 1706 This section gives the details of the packet traffic which is the 1707 basis for measurement. In IPPM metrics, this is called the Stream, 1708 and can easily be described by providing the list of stream 1709 parameters. 1711 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1712 generate Poisson sampling intervals. The reciprocal of lambda is the 1713 average packet spacing, thus the Run-time Parameter is 1714 Reciprocal_lambda = 1/lambda, in seconds. 1716 Method 3 SHALL be used, where given a start time (Run-time 1717 Parameter), the subsequent send times are all computed prior to 1718 measurement by computing the pseudo-random distribution of inter- 1719 packet send times, (truncating the distribution as specified in the 1720 Parameter Trunc), and the Src sends each packet at the computed 1721 times. 1723 Note that Trunc is the upper limit on inter-packet times in the 1724 Poisson distribution. A random value greater than Trunc is set equal 1725 to Trunc instead. 1727 Reciprocal_lambda average packet interval for Poisson Streams 1728 expressed in units of seconds, as a positive value of type 1729 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1730 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1731 conversion to/from the 32-bit NTP timestamp as per section 6 of 1732 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1734 Trunc Upper limit on Poisson distribution expressed in units of 1735 seconds, as a positive value of type decimal64 with fraction 1736 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1737 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1738 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1739 this limit will be clipped and set to the limit value). Trunc = 1740 30.0000 seconds. 1742 7.3.3. Traffic Filtering (observation) Details 1744 NA 1746 7.3.4. Sampling Distribution 1748 NA 1750 7.3.5. Run-time Parameters and Data Format 1752 Run-time Parameters are input factors that must be determined, 1753 configured into the measurement system, and reported with the results 1754 for the context to be complete. 1756 Src the IP address of the host in the Src Role (format ipv4-address- 1757 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1758 see Section 4 of [RFC6991]) 1760 Dst the IP address of the host in the Dst Role (format ipv4-address- 1761 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1762 see section 4 of [RFC6991]) 1764 T0 a time, the start of a measurement interval, (format "date-and- 1765 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1766 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1767 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1768 and Tf is to be interpreted as the Duration of the measurement 1769 interval. The start time is controlled through other means. 1771 Tf a time, the end of a measurement interval, (format "date-and-time" 1772 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1773 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1774 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1775 Tf is interpreted as the Duration of the measurement interval. 1777 7.3.6. Roles 1779 1781 Src launches each packet and waits for return transmissions from 1782 Dst. This is the TWAMP Session-Sender. 1784 Dst waits for each packet from Src and sends a return packet to Src. 1785 This is the TWAMP Session-Reflector. 1787 7.4. Output 1789 This category specifies all details of the Output of measurements 1790 using the metric. 1792 7.4.1. Type 1794 See subsection titles below for Types. 1796 7.4.2. Reference Definition 1798 For all output types --- 1800 T0 the start of a measurement interval, (format "date-and-time" as 1801 specified in Section 5.6 of [RFC3339], see also Section 3 of 1802 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1803 [RFC2330]. 1805 Tf the end of a measurement interval, (format "date-and-time" as 1806 specified in Section 5.6 of [RFC3339], see also Section 3 of 1808 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1809 [RFC2330]. 1811 For LossRatio -- the count of lost packets to total packets sent is 1812 the basis for the loss ratio calculation as per Section 4.1 of 1813 [RFC7680]. 1815 For each , one of the following sub-sections apply: 1817 7.4.2.1. Percentile95 1819 The 95th percentile SHALL be calculated using the conditional 1820 distribution of all packets with a finite value of One-way delay 1821 (undefined delays are excluded), a single value as follows: 1823 See section 4.1 of [RFC3393] for details on the conditional 1824 distribution to exclude undefined values of delay, and Section 5 of 1825 [RFC6703] for background on this analysis choice. 1827 See section 4.3 of [RFC3393] for details on the percentile statistic 1828 (where Round-trip delay should be substituted for "ipdv"). 1830 The percentile = 95, meaning that the reported delay, "95Percentile", 1831 is the smallest value of one-way delay for which the Empirical 1832 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1833 one-way delay values in the conditional distribution. See section 1834 11.3 of [RFC2330] for the definition of the percentile statistic 1835 using the EDF. 1837 95Percentile The time value of the result is expressed in units of 1838 seconds, as a positive value of type decimal64 with fraction 1839 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1840 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1841 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1843 7.4.2.2. Mean 1845 The mean SHALL be calculated using the conditional distribution of 1846 all packets with a finite value of One-way delay (undefined delays 1847 are excluded), a single value as follows: 1849 See section 4.1 of [RFC3393] for details on the conditional 1850 distribution to exclude undefined values of delay, and Section 5 of 1851 [RFC6703] for background on this analysis choice. 1853 See section 4.2.2 of [RFC6049] for details on calculating this 1854 statistic, and 4.2.3 of [RFC6049]. 1856 Mean The time value of the result is expressed in units of seconds, 1857 as a positive value of type decimal64 with fraction digits = 9 1858 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1859 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1860 NTP timestamp as per section 6 of RFC [RFC5905] 1862 7.4.2.3. Min 1864 The minimum SHALL be calculated using the conditional distribution of 1865 all packets with a finite value of One-way delay (undefined delays 1866 are excluded), a single value as follows: 1868 See section 4.1 of [RFC3393] for details on the conditional 1869 distribution to exclude undefined values of delay, and Section 5 of 1870 [RFC6703] for background on this analysis choice. 1872 See section 4.3.2 of [RFC6049] for details on calculating this 1873 statistic, and 4.3.3 of [RFC6049]. 1875 Min 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.4. Max 1883 The maximum 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 as follows: 1895 Max = (FiniteDelay [j]) 1897 such that for some index, j, where 1 <= j <= N 1898 FiniteDelay[j] >= FiniteDelay[n] for all n 1900 Max The time value of the result is expressed in units of seconds, 1901 as a positive value of type decimal64 with fraction digits = 9 1902 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1903 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1904 NTP timestamp as per section 6 of RFC [RFC5905] 1906 7.4.2.5. Std_Dev 1908 The Std_Dev SHALL be calculated using the conditional distribution of 1909 all packets with a finite value of One-way delay (undefined delays 1910 are excluded), a single value as follows: 1912 See section 4.1 of [RFC3393] for details on the conditional 1913 distribution to exclude undefined values of delay, and Section 5 of 1914 [RFC6703] for background on this analysis choice. 1916 See section 4.3.2 of [RFC6049] for a closely related method for 1917 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1918 the classic calculation for standard deviation of a population. 1920 Std_Dev The time value of the result is expressed in units of 1921 seconds, as a positive value of type decimal64 with fraction 1922 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1923 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1924 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1926 7.4.3. Metric Units 1928 The of One-way Delay is expressed in seconds. 1930 The One-way Loss Ratio is expressed as a percentage of lost packets 1931 to total packets sent. 1933 7.4.4. Calibration 1935 Section 3.7.3 of [RFC7679] provides a means to quantify the 1936 systematic and random errors of a time measurement. In-situ 1937 calibration could be enabled with an internal loopback that includes 1938 as much of the measurement system as possible, performs address 1939 manipulation as needed, and provides some form of isolation (e.g., 1940 deterministic delay) to avoid send-receive interface contention. 1941 Some portion of the random and systematic error can be characterized 1942 this way. 1944 For one-way delay measurements, the error calibration must include an 1945 assessment of the internal clock synchronization with its external 1946 reference (this internal clock is supplying timestamps for 1947 measurement). In practice, the time offsets of clocks at both the 1948 source and destination are needed to estimate the systematic error 1949 due to imperfect clock synchronization (the time offsets are 1950 smoothed, thus the random variation is not usually represented in the 1951 results). 1953 time_offset The time value of the result is expressed in units of 1954 seconds, as a signed value of type decimal64 with fraction digits 1955 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1956 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1957 NTP timestamp as per section 6 of RFC [RFC5905] 1959 When a measurement controller requests a calibration measurement, the 1960 loopback is applied and the result is output in the same format as a 1961 normal measurement with additional indication that it is a 1962 calibration result. In any measurement, the measurement function 1963 SHOULD report its current estimate of time offset as an indicator of 1964 the degree of synchronization. 1966 Both internal loopback calibration and clock synchronization can be 1967 used to estimate the *available accuracy* of the Output Metric Units. 1968 For example, repeated loopback delay measurements will reveal the 1969 portion of the Output result resolution which is the result of system 1970 noise, and thus inaccurate. 1972 7.5. Administrative items 1974 7.5.1. Status 1976 Current 1978 7.5.2. Requestor 1980 This REFC number 1982 7.5.3. Revision 1984 1.0 1986 7.5.4. Revision Date 1988 YYYY-MM-DD 1990 7.6. Comments and Remarks 1992 Additional (Informational) details for this entry 1994 8. UDP Periodic One-way Delay and Loss Registry Entries 1996 This section specifies five initial registry entries for the UDP 1997 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 1999 IANA Note: Registry "Name" below specifies a single registry entry, 2000 whose output format varies according to the element of 2001 the name that specifies one form of statistical summary. There is an 2002 additional metric name for the Loss metric. 2004 All column entries beside the ID, Name, Description, and Output 2005 Reference Method categories are the same, thus this section proposes 2006 six closely-related registry entries. As a result, IANA is also 2007 asked to assign corresponding URNs and URLs to each Named Metric. 2009 8.1. Summary 2011 This category includes multiple indexes to the registry entries, the 2012 element ID and metric name. 2014 8.1.1. ID (Identifier) 2016 IANA is asked to assign a different numeric identifiers to each of 2017 the six Metrics. 2019 8.1.2. Name 2021 OWDelay_Active_IP-UDP-Periodic20m- 2022 Payload142B_RFCXXXXsecY_Seconds_ 2024 where is one of: 2026 o 95Percentile 2028 o Mean 2030 o Min 2032 o Max 2034 o StdDev 2036 OWLoss_Active_IP-UDP-Periodic- 2037 Payload142B_RFCXXXXsecY_Percent_LossRatio 2039 8.1.3. URIs 2041 URI: Prefix urn:ietf:metrics:perf: 2043 URL: http:\\www.iana.org\ ... 2045 8.1.4. Description 2047 OWDelay: This metric assesses the delay of a stream of packets 2048 exchanged between two hosts (or measurement points), and reports the 2049 One-way delay for all successfully exchanged packets 2050 based on their conditional delay distribution. 2052 where is one of: 2054 o 95Percentile 2056 o Mean 2058 o Min 2060 o Max 2062 o StdDev 2064 OWLoss: This metric assesses the loss ratio of a stream of packets 2065 exchanged between two hosts (which are the two measurement points), 2066 and the Output is the One-way loss ratio for all successfully 2067 received packets expressed as a percentage. 2069 8.2. Metric Definition 2071 This category includes columns to prompt the entry of all necessary 2072 details related to the metric definition, including the RFC reference 2073 and values of input factors, called fixed parameters. 2075 8.2.1. Reference Definition 2077 For Delay: 2079 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2080 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2081 7679, DOI 10.17487/RFC7679, January 2016, . 2084 [RFC7679] 2085 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2086 6049, January 2011. 2088 [RFC6049] 2090 Section 3.4 of [RFC7679] provides the reference definition of the 2091 singleton (single value) One-way delay metric. Section 4.4 of 2092 [RFC7679] provides the reference definition expanded to cover a 2093 multi-value sample. Note that terms such as singleton and sample are 2094 defined in Section 11 of [RFC2330]. 2096 Only successful packet transfers with finite delay are included in 2097 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2099 For loss: 2101 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2102 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2103 10.17487/RFC7680, January 2016, . 2106 Section 2.4 of [RFC7680] provides the reference definition of the 2107 singleton (single value) one-way loss metric. Section 3.4 of 2108 [RFC7680] provides the reference definition expanded to cover a 2109 multi-singleton sample. Note that terms such as singleton and sample 2110 are defined in Section 11 of [RFC2330]. 2112 8.2.2. Fixed Parameters 2114 Type-P: 2116 o IPv4 header values: 2118 * DSCP: set to 0 2120 * TTL: set to 255 2122 * Protocol: Set to 17 (UDP) 2124 o IPv6 header values: 2126 * DSCP: set to 0 2128 * Hop Count: set to 255 2130 * Protocol: Set to 17 (UDP) 2132 o UDP header values: 2134 * Checksum: the checksum MUST be calculated and included in the 2135 header 2137 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2139 * Security features in use influence the number of Padding 2140 octets. 2142 * 142 octets total, including the TWAMP format (if used) 2144 Other measurement parameters: 2146 Tmax: a loss threshold waiting time with value 3.0, expressed in 2147 units of seconds, as a positive value of type decimal64 with 2148 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2149 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2150 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2152 See the Packet Stream generation category for two additional Fixed 2153 Parameters. 2155 8.3. Method of Measurement 2157 This category includes columns for references to relevant sections of 2158 the RFC(s) and any supplemental information needed to ensure an 2159 unambiguous methods for implementations. 2161 8.3.1. Reference Method 2163 The methodology for this metric is defined as Type-P-One-way-Delay- 2164 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2165 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2166 However, a Periodic stream is used, as defined in [RFC3432]. 2168 The reference method distinguishes between long-delayed packets and 2169 lost packets by implementing a maximum waiting time for packet 2170 arrival. Tmax is the waiting time used as the threshold to declare a 2171 packet lost. Lost packets SHALL be designated as having undefined 2172 delay, and counted for the OWLoss metric. 2174 The calculations on the one-way delay SHALL be performed on the 2175 conditional distribution, conditioned on successful packet arrival 2176 within Tmax. Also, when all packet delays are stored, the process 2177 which calculates the one-way delay value MAY enforce the Tmax 2178 threshold on stored values before calculations. See section 4.1 of 2179 [RFC3393] for details on the conditional distribution to exclude 2180 undefined values of delay, and Section 5 of [RFC6703] for background 2181 on this analysis choice. 2183 The reference method requires some way to distinguish between 2184 different packets in a stream to establish correspondence between 2185 sending times and receiving times for each successfully-arriving 2186 packet. Sequence numbers or other send-order identification MUST be 2187 retained at the Src or included with each packet to disambiguate 2188 packet reordering if it occurs. 2190 Since a standard measurement protocol is employed [RFC5357], then the 2191 measurement process will determine the sequence numbers or timestamps 2192 applied to test packets after the Fixed and Runtime parameters are 2193 passed to that process. The measurement protocol dictates the format 2194 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2195 payload. 2197 8.3.2. Packet Stream Generation 2199 This section gives the details of the packet traffic which is the 2200 basis for measurement. In IPPM metrics, this is called the Stream, 2201 and can easily be described by providing the list of stream 2202 parameters. 2204 Section 3 of [RFC3432] prescribes the method for generating Periodic 2205 streams using associated parameters. 2207 incT the nominal duration of inter-packet interval, first bit to 2208 first bit, with value 0.0200 expressed in units of seconds, as a 2209 positive value of type decimal64 with fraction digits = 4 (see 2210 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 2211 (0.1 ms), with lossless conversion to/from the 32-bit NTP 2212 timestamp as per section 6 of [RFC5905]. 2214 dT the duration of the interval for allowed sample start times, with 2215 value 1.0000, expressed in units of seconds, as a positive value 2216 of type decimal64 with fraction digits = 4 (see section 9.3 of 2217 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2218 lossless conversion to/from the 32-bit NTP timestamp as per 2219 section 6 of [RFC5905]. 2221 T0 the actual start time of the periodic stream, determined from T0 2222 and dT. 2224 NOTE: an initiation process with a number of control exchanges 2225 resulting in unpredictable start times (within a time interval) may 2226 be sufficient to avoid synchronization of periodic streams, and 2227 therefore a valid replacement for selecting a start time at random 2228 from a fixed interval. 2230 These stream parameters will be specified as Run-time parameters. 2232 8.3.3. Traffic Filtering (observation) Details 2234 NA 2236 8.3.4. Sampling Distribution 2238 NA 2240 8.3.5. Run-time Parameters and Data Format 2242 Run-time Parameters are input factors that must be determined, 2243 configured into the measurement system, and reported with the results 2244 for the context to be complete. 2246 Src the IP address of the host in the Src Role (format ipv4-address- 2247 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2248 see Section 4 of [RFC6991]) 2250 Dst the IP address of the host in the Dst Role (format ipv4-address- 2251 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2252 see section 4 of [RFC6991]) 2254 T0 a time, the start of a measurement interval, (format "date-and- 2255 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2256 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2257 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2258 and Tf is to be interpreted as the Duration of the measurement 2259 interval. The start time is controlled through other means. 2261 Tf a time, the end of a measurement interval, (format "date-and-time" 2262 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2263 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2264 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2265 Tf is interpreted as the Duration of the measurement interval. 2267 8.3.6. Roles 2269 Src launches each packet and waits for return transmissions from 2270 Dst. This is the TWAMP Session-Sender. 2272 Dst waits for each packet from Src and sends a return packet to Src. 2273 This is the TWAMP Session-Reflector. 2275 8.4. Output 2277 This category specifies all details of the Output of measurements 2278 using the metric. 2280 8.4.1. Type 2282 2284 See subsection titles in Reference Definition for Latency Types. 2286 8.4.2. Reference Definition 2288 For all output types --- 2290 T0 the start of a measurement interval, (format "date-and-time" as 2291 specified in Section 5.6 of [RFC3339], see also Section 3 of 2292 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2293 [RFC2330]. 2295 Tf the end of a measurement interval, (format "date-and-time" as 2296 specified in Section 5.6 of [RFC3339], see also Section 3 of 2297 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2298 [RFC2330]. 2300 For LossRatio -- the count of lost packets to total packets sent is 2301 the basis for the loss ratio calculation as per Section 4.1 of 2302 [RFC7680]. 2304 For each , one of the following sub-sections apply: 2306 8.4.2.1. Percentile95 2308 The 95th percentile SHALL be calculated using the conditional 2309 distribution of all packets with a finite value of One-way delay 2310 (undefined delays are excluded), a single value as follows: 2312 See section 4.1 of [RFC3393] for details on the conditional 2313 distribution to exclude undefined values of delay, and Section 5 of 2314 [RFC6703] for background on this analysis choice. 2316 See section 4.3 of [RFC3393] for details on the percentile statistic 2317 (where Round-trip delay should be substituted for "ipdv"). 2319 The percentile = 95, meaning that the reported delay, "95Percentile", 2320 is the smallest value of one-way delay for which the Empirical 2321 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2322 one-way delay values in the conditional distribution. See section 2323 11.3 of [RFC2330] for the definition of the percentile statistic 2324 using the EDF. 2326 95Percentile The time value of the result is expressed in units of 2327 seconds, as a positive value of type decimal64 with fraction 2328 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2329 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2330 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2332 8.4.2.2. Mean 2334 The mean SHALL be calculated using the conditional distribution of 2335 all packets with a finite value of One-way delay (undefined delays 2336 are excluded), a single value as follows: 2338 See section 4.1 of [RFC3393] for details on the conditional 2339 distribution to exclude undefined values of delay, and Section 5 of 2340 [RFC6703] for background on this analysis choice. 2342 See section 4.2.2 of [RFC6049] for details on calculating this 2343 statistic, and 4.2.3 of [RFC6049]. 2345 Mean The time value of the result is expressed in units of seconds, 2346 as a positive value of type decimal64 with fraction digits = 9 2347 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2348 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2349 NTP timestamp as per section 6 of RFC [RFC5905] 2351 8.4.2.3. Min 2353 The minimum SHALL be calculated using the conditional distribution of 2354 all packets with a finite value of One-way delay (undefined delays 2355 are excluded), a single value as follows: 2357 See section 4.1 of [RFC3393] for details on the conditional 2358 distribution to exclude undefined values of delay, and Section 5 of 2359 [RFC6703] for background on this analysis choice. 2361 See section 4.3.2 of [RFC6049] for details on calculating this 2362 statistic, and 4.3.3 of [RFC6049]. 2364 Min The time value of the result is expressed in units of seconds, 2365 as a positive value of type decimal64 with fraction digits = 9 2366 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2367 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2368 NTP timestamp as per section 6 of RFC [RFC5905] 2370 8.4.2.4. Max 2372 The maximum SHALL be calculated using the conditional distribution of 2373 all packets with a finite value of One-way delay (undefined delays 2374 are excluded), a single value as follows: 2376 See section 4.1 of [RFC3393] for details on the conditional 2377 distribution to exclude undefined values of delay, and Section 5 of 2378 [RFC6703] for background on this analysis choice. 2380 See section 4.3.2 of [RFC6049] for a closely related method for 2381 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2382 as follows: 2384 Max = (FiniteDelay [j]) 2386 such that for some index, j, where 1 <= j <= N 2387 FiniteDelay[j] >= FiniteDelay[n] for all n 2389 Max The time value of the result is expressed in units of seconds, 2390 as a positive value of type decimal64 with fraction digits = 9 2391 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2392 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2393 NTP timestamp as per section 6 of RFC [RFC5905] 2395 8.4.2.5. Std_Dev 2397 The Std_Dev SHALL be calculated using the conditional distribution of 2398 all packets with a finite value of One-way delay (undefined delays 2399 are excluded), a single value as follows: 2401 See section 4.1 of [RFC3393] for details on the conditional 2402 distribution to exclude undefined values of delay, and Section 5 of 2403 [RFC6703] for background on this analysis choice. 2405 See section 4.3.2 of [RFC6049] for a closely related method for 2406 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2407 the classic calculation for standard deviation of a population. 2409 Std_Dev The time value of the result is expressed in units of 2410 seconds, as a positive value of type decimal64 with fraction 2411 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2412 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2413 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2415 8.4.3. Metric Units 2417 The of One-way Delay is expressed in seconds, where 2418 is one of: 2420 o 95Percentile 2422 o Mean 2423 o Min 2425 o Max 2427 o StdDev 2429 The One-way Loss Ratio is expressed as a percentage of lost packets 2430 to total packets sent. 2432 8.4.4. Calibration 2434 Section 3.7.3 of [RFC7679] provides a means to quantify the 2435 systematic and random errors of a time measurement. In-situ 2436 calibration could be enabled with an internal loopback that includes 2437 as much of the measurement system as possible, performs address 2438 manipulation as needed, and provides some form of isolation (e.g., 2439 deterministic delay) to avoid send-receive interface contention. 2440 Some portion of the random and systematic error can be characterized 2441 this way. 2443 For one-way delay measurements, the error calibration must include an 2444 assessment of the internal clock synchronization with its external 2445 reference (this internal clock is supplying timestamps for 2446 measurement). In practice, the time offsets of clocks at both the 2447 source and destination are needed to estimate the systematic error 2448 due to imperfect clock synchronization (the time offsets are 2449 smoothed, thus the random variation is not usually represented in the 2450 results). 2452 time_offset The time value of the result is expressed in units of 2453 seconds, as a signed value of type decimal64 with fraction digits 2454 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2455 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2456 NTP timestamp as per section 6 of RFC [RFC5905] 2458 When a measurement controller requests a calibration measurement, the 2459 loopback is applied and the result is output in the same format as a 2460 normal measurement with additional indication that it is a 2461 calibration result. In any measurement, the measurement function 2462 SHOULD report its current estimate of time offset as an indicator of 2463 the degree of synchronization. 2465 Both internal loopback calibration and clock synchronization can be 2466 used to estimate the *available accuracy* of the Output Metric Units. 2467 For example, repeated loopback delay measurements will reveal the 2468 portion of the Output result resolution which is the result of system 2469 noise, and thus inaccurate. 2471 8.5. Administrative items 2473 8.5.1. Status 2475 Current 2477 8.5.2. Requestor 2479 This RFC number 2481 8.5.3. Revision 2483 1.0 2485 8.5.4. Revision Date 2487 YYYY-MM-DD 2489 8.6. Comments and Remarks 2491 9. ICMP Round-trip Latency and Loss Registry Entries 2493 This section specifies three initial registry entries for the ICMP 2494 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2496 This section specifies four Registry entries with many common 2497 columns. 2499 All column entries beside the ID, Name, Description, and Output 2500 Reference Method categories are the same, thus this section proposes 2501 two closely-related registry entries. As a result, IANA is also 2502 asked to assign four corresponding URNs and URLs to each Named 2503 Metric. 2505 9.1. Summary 2507 This category includes multiple indexes to the registry entry: the 2508 element ID and metric name. 2510 9.1.1. ID (Identifier) 2512 IANA is asked to assign different numeric identifiers to each of the 2513 four Named Metrics. 2515 9.1.2. Name 2517 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Seconds_ 2519 where is one of: 2521 o Mean 2523 o Min 2525 o Max 2527 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Percent_LossRatio 2529 9.1.3. URIs 2531 URN: Prefix urn:ietf:metrics:perf: 2533 URL: http:/// 2535 9.1.4. Description 2537 RTDelay: This metric assesses the delay of a stream of ICMP packets 2538 exchanged between two hosts (which are the two measurement points), 2539 and the Output is the Round-trip delay for all successfully exchanged 2540 packets expressed as the of their conditional delay 2541 distribution, where is one of: 2543 o Mean 2545 o Min 2547 o Max 2549 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2550 packets exchanged between two hosts (which are the two measurement 2551 points), and the Output is the Round-trip loss ratio for all 2552 successfully exchanged packets expressed as a percentage. 2554 9.1.5. Change Controller 2556 IETF 2558 9.1.6. Version (of Registry Format) 2560 1.0 2562 9.2. Metric Definition 2564 This category includes columns to prompt the entry of all necessary 2565 details related to the metric definition, including the RFC reference 2566 and values of input factors, called fixed parameters. 2568 9.2.1. Reference Definition 2570 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2571 Metric for IPPM", RFC 2681, September 1999. 2573 [RFC2681] 2575 Section 2.4 of [RFC2681] provides the reference definition of the 2576 singleton (single value) Round-trip delay metric. Section 3.4 of 2577 [RFC2681] provides the reference definition expanded to cover a 2578 multi-singleton sample. Note that terms such as singleton and sample 2579 are defined in Section 11 of [RFC2330]. 2581 Note that although the [RFC2681] definition of "Round-trip-Delay 2582 between Src and Dst" is directionally ambiguous in the text, this 2583 metric tightens the definition further to recognize that the host in 2584 the "Src" role will send the first packet to "Dst", and ultimately 2585 receive the corresponding return packet from "Dst" (when neither are 2586 lost). 2588 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2589 the value of Round-trip delay in metric definitions and methods. The 2590 variable "dT" has been re-used in other IPPM literature to refer to 2591 different quantities, and cannot be used as a global variable name. 2593 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2595 [RFC6673] 2597 Both delay and loss metrics employ a maximum waiting time for 2598 received packets, so the count of lost packets to total packets sent 2599 is the basis for the loss ratio calculation as per Section 6.1 of 2600 [RFC6673]. 2602 9.2.2. Fixed Parameters 2604 Type-P as defined in Section 13 of [RFC2330]: 2606 o IPv4 header values: 2608 * DSCP: set to 0 2609 * TTL: set to 255 2611 * Protocol: Set to 01 (ICMP) 2613 o IPv6 header values: 2615 * DSCP: set to 0 2617 * Hop Limit: set to 255 2619 * Protocol: Set to 01 (ICMP) 2621 o ICMP header values: 2623 * Type: 8 (Echo Request) 2625 * Code: 0 2627 * Checksum: the checksum MUST be calculated and included in the 2628 header 2630 * (Identifier and Sequence Number set at Run-Time) 2632 o ICMP Payload 2634 * total of 32 bytes of random info 2636 Other measurement parameters: 2638 o Tmax: a loss threshold waiting time 2640 * 3.0, expressed in units of seconds, as a positive value of type 2641 decimal64 with fraction digits = 4 (see section 9.3 of 2642 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2643 lossless conversion to/from the 32-bit NTP timestamp as per 2644 section 6 of [RFC5905]. 2646 9.3. Method of Measurement 2648 This category includes columns for references to relevant sections of 2649 the RFC(s) and any supplemental information needed to ensure an 2650 unambiguous methods for implementations. 2652 9.3.1. Reference Method 2654 The methodology for this metric is defined as Type-P-Round-trip- 2655 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2656 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2657 Fixed Parameters. 2659 The reference method distinguishes between long-delayed packets and 2660 lost packets by implementing a maximum waiting time for packet 2661 arrival. Tmax is the waiting time used as the threshold to declare a 2662 packet lost. Lost packets SHALL be designated as having undefined 2663 delay, and counted for the RTLoss metric. 2665 The calculations on the delay (RTD) SHALL be performed on the 2666 conditional distribution, conditioned on successful packet arrival 2667 within Tmax. Also, when all packet delays are stored, the process 2668 which calculates the RTD value MAY enforce the Tmax threshold on 2669 stored values before calculations. See section 4.1 of [RFC3393] for 2670 details on the conditional distribution to exclude undefined values 2671 of delay, and Section 5 of [RFC6703] for background on this analysis 2672 choice. 2674 The reference method requires some way to distinguish between 2675 different packets in a stream to establish correspondence between 2676 sending times and receiving times for each successfully-arriving 2677 packet. Sequence numbers or other send-order identification MUST be 2678 retained at the Src or included with each packet to disambiguate 2679 packet reordering if it occurs. 2681 The measurement process will determine the sequence numbers applied 2682 to test packets after the Fixed and Runtime parameters are passed to 2683 that process. The ICMP measurement process and protocol will dictate 2684 the format of sequence numbers and other identifiers. 2686 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2687 instruction to "send a Type-P packet back to the Src as quickly as 2688 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2689 [RFC6673] presents additional requirements which MUST be included in 2690 the method of measurement for this metric. 2692 9.3.2. Packet Stream Generation 2694 This section gives the details of the packet traffic which is the 2695 basis for measurement. In IPPM metrics, this is called the Stream, 2696 and can easily be described by providing the list of stream 2697 parameters. 2699 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2700 On Receive. This is a modification of Section 3 of [RFC3432], which 2701 prescribes the method for generating Periodic streams using 2702 associated parameters: 2704 incT the nominal duration of inter-packet interval, first bit to 2705 first bit 2707 dT the duration of the interval for allowed sample start times 2709 T0 the actual start time of the periodic stream 2711 The incT and T0 stream parameters will be specified as Run-time 2712 parameters, dT is not used in SendOnRcv. 2714 A SendOnRcv sender behaves exactly like a Periodic stream generator 2715 while all reply packets arrive with RTD < incT, and the inter-packet 2716 interval will be constant. 2718 If a reply packet arrives with RTD >= incT, then the inter-packet 2719 interval for the next sending time is nominally RTD. 2721 If a reply packet fails to arrive within Tmax, then the inter-packet 2722 interval for the next sending time is nominally Tmax. 2724 If an immediate send on reply arrival is desired, then set incT=0. 2726 9.3.3. Traffic Filtering (observation) Details 2728 The measured results based on a filtered version of the packets 2729 observed, and this section provides the filter details (when 2730 present). 2732 NA 2734 9.3.4. Sampling Distribution 2736 NA 2738 9.3.5. Run-time Parameters and Data Format 2740 Run-time Parameters are input factors that must be determined, 2741 configured into the measurement system, and reported with the results 2742 for the context to be complete. 2744 Src the IP address of the host in the Src Role (format ipv4-address- 2745 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2746 see Section 4 of [RFC6991]) 2748 Dst the IP address of the host in the Dst Role (format ipv4-address- 2749 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2750 see section 4 of [RFC6991]) 2752 T0 a time, the start of a measurement interval, (format "date-and- 2753 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2754 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2755 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2756 and Tf is to be interpreted as the Duration of the measurement 2757 interval. The start time is controlled through other means. 2759 Count The total count of ICMP Echo Requests to send, formatted as a 2760 uint16, as per section 9.2 of [RFC6020]. 2762 (see the Packet Stream Generation section for additional Run-time 2763 parameters) 2765 9.3.6. Roles 2767 Src launches each packet and waits for return transmissions from 2768 Dst. 2770 Dst waits for each packet from Src and sends a return packet to Src. 2772 9.4. Output 2774 This category specifies all details of the Output of measurements 2775 using the metric. 2777 9.4.1. Type 2779 See subsection titles in Reference Definition for Latency Types. 2781 LossRatio -- the count of lost packets to total packets sent is the 2782 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 2784 9.4.2. Reference Definition 2786 For all output types --- 2788 T0 the start of a measurement interval, (format "date-and-time" as 2789 specified in Section 5.6 of [RFC3339], see also Section 3 of 2790 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2791 [RFC2330]. 2793 Tf the end of a measurement interval, (format "date-and-time" as 2794 specified in Section 5.6 of [RFC3339], see also Section 3 of 2795 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2796 [RFC2330]. 2798 TotalCount the count of packets actually sent by the Src to Dst 2799 during the measurement interval. 2801 For LossRatio -- the count of lost packets to total packets sent is 2802 the basis for the loss ratio calculation as per Section 4.1 of 2803 [RFC7680]. 2805 For each , one of the following sub-sections apply: 2807 9.4.2.1. Mean 2809 The mean SHALL be calculated using the conditional distribution of 2810 all packets with a finite value of Round-trip delay (undefined delays 2811 are excluded), a single value as follows: 2813 See section 4.1 of [RFC3393] for details on the conditional 2814 distribution to exclude undefined values of delay, and Section 5 of 2815 [RFC6703] for background on this analysis choice. 2817 See section 4.2.2 of [RFC6049] for details on calculating this 2818 statistic, and 4.2.3 of [RFC6049]. 2820 Mean The time value of the result is expressed in units of seconds, 2821 as a positive value of type decimal64 with fraction digits = 9 2822 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2823 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2824 NTP timestamp as per section 6 of RFC [RFC5905] 2826 9.4.2.2. Min 2828 The minimum SHALL be calculated using the conditional distribution of 2829 all packets with a finite value of Round-trip delay (undefined delays 2830 are excluded), a single value as follows: 2832 See section 4.1 of [RFC3393] for details on the conditional 2833 distribution to exclude undefined values of delay, and Section 5 of 2834 [RFC6703] for background on this analysis choice. 2836 See section 4.3.2 of [RFC6049] for details on calculating this 2837 statistic, and 4.3.3 of [RFC6049]. 2839 Min The time value of the result is expressed in units of seconds, 2840 as a positive value of type decimal64 with fraction digits = 9 2841 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2842 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2843 NTP timestamp as per section 6 of RFC [RFC5905] 2845 9.4.2.3. Max 2847 The maximum SHALL be calculated using the conditional distribution of 2848 all packets with a finite value of Round-trip delay (undefined delays 2849 are excluded), a single value as follows: 2851 See section 4.1 of [RFC3393] for details on the conditional 2852 distribution to exclude undefined values of delay, and Section 5 of 2853 [RFC6703] for background on this analysis choice. 2855 See section 4.3.2 of [RFC6049] for a closely related method for 2856 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2857 as follows: 2859 Max = (FiniteDelay [j]) 2861 such that for some index, j, where 1 <= j <= N 2862 FiniteDelay[j] >= FiniteDelay[n] for all n 2864 Max The time value of the result is expressed in units of seconds, 2865 as a positive value of type decimal64 with fraction digits = 9 2866 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2867 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2868 NTP timestamp as per section 6 of RFC [RFC5905] 2870 9.4.3. Metric Units 2872 The of Round-trip Delay is expressed in seconds, where 2873 is one of: 2875 o Mean 2877 o Min 2879 o Max 2881 The Round-trip Loss Ratio is expressed as a percentage of lost 2882 packets to total packets sent. 2884 9.4.4. Calibration 2886 Section 3.7.3 of [RFC7679] provides a means to quantify the 2887 systematic and random errors of a time measurement. In-situ 2888 calibration could be enabled with an internal loopback at the Source 2889 host that includes as much of the measurement system as possible, 2890 performs address manipulation as needed, and provides some form of 2891 isolation (e.g., deterministic delay) to avoid send-receive interface 2892 contention. Some portion of the random and systematic error can be 2893 characterized this way. 2895 When a measurement controller requests a calibration measurement, the 2896 loopback is applied and the result is output in the same format as a 2897 normal measurement with additional indication that it is a 2898 calibration result. 2900 Both internal loopback calibration and clock synchronization can be 2901 used to estimate the *available accuracy* of the Output Metric Units. 2902 For example, repeated loopback delay measurements will reveal the 2903 portion of the Output result resolution which is the result of system 2904 noise, and thus inaccurate. 2906 9.5. Administrative items 2908 9.5.1. Status 2910 Current 2912 9.5.2. Requestor 2914 This RFC number 2916 9.5.3. Revision 2918 1.0 2920 9.5.4. Revision Date 2922 YYYY-MM-DD 2924 9.6. Comments and Remarks 2926 None 2928 10. TCP Round-Trip Delay and Loss Registry Entries 2930 This section specifies three initial registry entries for the Passive 2931 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 2932 Round-trip Loss Count. 2934 This section specifies four Registry entries with many common 2935 columns. 2937 All column entries beside the ID, Name, Description, and Output 2938 Reference Method categories are the same, thus this section proposes 2939 four closely-related registry entries. As a result, IANA is also 2940 asked to assign four corresponding URNs and URLs to each Named 2941 Metric. 2943 10.1. Summary 2945 This category includes multiple indexes to the registry entry: the 2946 element ID and metric name. 2948 10.1.1. ID (Identifier) 2950 IANA is asked to assign different numeric identifiers to each of the 2951 four Named Metrics. 2953 10.1.2. Name 2955 RTDelay_Passive_IP-TCP_RFCXXXXsecY_Seconds_ 2957 where is one of: 2959 o Mean 2961 o Min 2963 o Max 2965 RTDelay_Passive_IP-TCP-HS_RFCXXXXsecY_Seconds_Singleton 2967 Note that a mid-point observer only has the opportuinty to compose a 2968 single RTDelay on the TCP Hand Shake. 2970 RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count 2972 10.1.3. URIs 2974 URN: Prefix urn:ietf:metrics:perf: 2976 URL: http:/// 2978 10.1.4. Description 2980 RTDelay: This metric assesses the round-trip delay of TCP packets 2981 constituting a single connection, exchanged between two hosts. We 2982 consider the measurement of round-trip delay based on a single 2983 Observation Point [RFC7011] somewhere in the network. The Output is 2984 the Round-trip delay for all successfully exchanged packets expressed 2985 as the of their conditional delay distribution, where 2986 is one of: 2988 o Mean 2990 o Min 2992 o Max 2994 RTLoss: This metric assesses the estimated loss count for TCP packets 2995 constituting a single connection, exchanged between two hosts. We 2996 consider the measurement of round-trip delay based on a single 2997 Observation Point [RFC7011] somewhere in the network. The Output is 2998 the estimated Loss Count for the measurement interval. 3000 10.1.5. Change Controller 3002 IETF 3004 10.1.6. Version (of Registry Format) 3006 1.0 3008 10.2. Metric Definition 3010 This category includes columns to prompt the entry of all necessary 3011 details related to the metric definition, including the RFC reference 3012 and values of input factors, called fixed parameters. 3014 10.2.1. Reference Definitions 3016 Although there is no RFC that describes passive measurement of Round- 3017 Trip Delay, the parallel definition for Active measurement is: 3019 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 3020 Metric for IPPM", RFC 2681, September 1999. 3022 [RFC2681] 3024 This metric definition uses the terms singleton and sample as defined 3025 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 3026 reference definition of the singleton (single value) Round-trip delay 3027 metric. Section 3.4 of [RFC2681] provides the reference definition 3028 expanded to cover a multi-singleton sample.) 3030 With the Observation Point [RFC7011] (OP) typically located between 3031 the hosts participating in the TCP connection, the Round-trip Delay 3032 metric requires two individual measurements between the OP and each 3033 host, such that the Spatial Composition [RFC6049]of the measurements 3034 yields a Round-trip Delay singleton (we are extending the composition 3035 of one-way subpath delays to subpath round-trip delay). 3037 Using the direction of TCP SYN transmission to anchor the 3038 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3039 during connection establishment. The direction of SYN transfer is 3040 considered the Forward direction of transmission, from A through OP 3041 to B (Reverse is B through OP to A). 3043 Traffic filters reduce the packet stream at the OP to a Qualified 3044 bidirectional flow packets. 3046 In the definitions below, Corresponding Packets are transferred in 3047 different directions and convey a common value in a TCP header field 3048 that establishes correspondence (to the extent possible). Examples 3049 may be found in the TCP timestamp fields. 3051 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3052 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3053 observed a Qualified Packet to host B at wire-time T', that host B 3054 received that packet and sent a Corresponding Packet back to host A, 3055 and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. 3057 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3058 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3059 OP observed a Qualified Packet to host A at wire-time T'', that host 3060 A received that packet and sent a Corresponding Packet back to host 3061 B, and that OP observed the Corresponding Packet at wire-time T'' + 3062 RTD_rev. 3064 Ideally, the packet sent from host B to host A in both definitions 3065 above SHOULD be the same packet (or, when measuring RTD_rev first, 3066 the packet from host A to host B in both definitions should be the 3067 same). 3069 The REQUIRED Composition Function for a singleton of Round-trip Delay 3070 at time T (where T is the earliest of T' and T'' above) is: 3072 RTDelay = RTD_fwd + RTD_rev 3074 Note that when OP is located at host A or host B, one of the terms 3075 composing RTDelay will be zero or negligible. 3077 When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- 3078 SYN-ACK, then RTD_fwd == RTD_HS_fwd. 3080 When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a 3081 TCP-ACK, then RTD_rev == RTD_HS_rev. 3083 The REQUIRED Composition Function for a singleton of Round-trip Delay 3084 for the connection Hand Shake: 3086 RTDelay_HS = RTD_HS_fwd + RTD_HS_rev 3088 The definition of Round-trip Loss Count uses the nomenclature 3089 developed above, based on observation of the TCP header sequence 3090 numbers and storing the sequence number gaps observed. Packet Losses 3091 can be inferred from: 3093 o Out-of-order segments: TCP segments are transmitted with 3094 monotonically increasing sequence numbers, but these segments may 3095 be received out of order. Section 3 of [RFC4737] describes the 3096 notion of "next expected" sequence numbers which can be adapted to 3097 TCP segments (for the purpose of detecting reordered packets). 3098 Observation of out-of-order segments indicates loss on the path 3099 prior to the OP, and creates a gap. 3101 o Duplicate segments: Section 2 of [RFC5560] defines identical 3102 packets and is suitable for evaluation of TCP packets to detect 3103 duplication. Observation of duplicate segments *without a 3104 corresponding gap* indicates loss on the path following the OP 3105 (because they overlap part of the delivered sequence numbers 3106 already observed at OP). 3108 Each observation of an out-of-order or duplicate infers a singleton 3109 of loss, but composition of Round-trip Loss Counts will be conducted 3110 over a measurement interval which is synonymous with a single TCP 3111 connection. 3113 With the above observations in the Forward direction over a 3114 measurement interval, the count of out-of-order and duplicate 3115 segments is defined as RTL_fwd. Comparable observations in the 3116 Reverse direction are defined as RTL_rev. 3118 For a measurement interval (corresponding to a single TCP 3119 connection), T0 to Tf, the REQUIRED Composition Function for a the 3120 two single-direction counts of inferred loss is: 3122 RTLoss = RTL_fwd + RTL_rev 3124 10.2.2. Fixed Parameters 3126 3130 Traffic Filters: 3132 o IPv4 header values: 3134 * DSCP: set to 0 3136 * Protocol: Set to 06 (TCP) 3138 o IPv6 header values: 3140 * DSCP: set to 0 3142 * Protocol: Set to 06 (TCP) 3144 o TCP header values: 3146 * Flags: ACK, SYN, FIN, @@@@@ others?? 3148 * Timestamp Option (TSopt): Set 3150 + Kind: 8 3152 + Length: 10 bytes 3154 o 3156 10.3. Method of Measurement 3158 This category includes columns for references to relevant sections of 3159 the RFC(s) and any supplemental information needed to ensure an 3160 unambiguous methods for implementations. 3162 10.3.1. Reference Methods 3164 The foundation methodology for this metric is defined in Section 4 of 3165 [RFC7323] using the Timestamp Option with modifications that allow 3166 application at a mid-path Observation Point (OP) [RFC7011]. Further 3167 details and applicable heuristics were derived from [Strowes] and 3168 [Trammell-14]. 3170 The Traffic Filter at the OP is configured to observe a single TCP 3171 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3172 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3173 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3174 of RTDelay as RTDelay_HS (composed using the forward and reverse 3175 measurement pair). RTDelay_HS SHALL be treated separately from other 3176 RTDelays on data-bearing packets and their ACKs. The RTDelay_HS 3177 value MAY be used as a sanity check on other Composed values of 3178 RTDelay. 3180 For payload bearing packets, the OP measures the time interval 3181 between observation of a packet with Sequence Number s, and the 3182 corresponding ACK with same Sequence number. When the payload is 3183 transferred from host A to host B, the observed interval is RTD_fwd. 3185 Because many data transfers are unidirectional (say, in the Forward 3186 direction from host A to host B), it is necessary to use pure ACK 3187 packets with Timestamp (TSval) and their Timestamp value echo to 3188 perform a RTD_rev measurement. The time interval between observation 3189 of the ACK from B to A, and the corresponding packet with Timestamp 3190 echo (TSecr) is the RTD_rev. 3192 Delay Measurement Filtering Heuristics: 3194 If Data payloads were transferred in both Forward and Reverse 3195 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3196 of [RFC7323] could be applied. This rule essentially excludes any 3197 measurement using a packet unless it makes progress in the transfer 3198 (advances the left edge of the send window, consistent 3199 with[Strowes]). 3201 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3202 that is larger than previously observed values. This would tend to 3203 exclude Reverse measurements taken when the Application has no data 3204 ready to send, because considerable time could be added to RTD_rev 3205 from this source of error. 3207 Note that the above Heuristic assumes that host A is sending data. 3208 Host A expecting a download would mean that this heuristic should be 3209 applied to RTD_fwd. 3211 The statistic calculations to summarize the delay (RTDelay) SHALL be 3212 performed on the conditional distribution, conditioned on successful 3213 Forward and Reverse measurements which follow the Heuristics. 3215 Method for Inferring Loss: 3217 The OP tracks sequence numbers and stores gaps for each direction of 3218 transmission, as well as the next-expected sequence number as in 3219 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3220 segments and Duplicate segments. 3222 Loss Measurement Filtering Heuristics: 3224 [Trammell-14] adds a window of evaluation based on the RTDelay. 3226 Distinguish Re-ordered from OOO due to loss, because sequence number 3227 gap is filled during the same RTDelay window. Segments detected as 3228 re-ordered according to [RFC4737] MUST reduce the Loss Count inferred 3229 from Out-of-order segments. 3231 Spurious (unneeded) retransmissions (observed as duplicates) can also 3232 be reduced this way, as described in [Trammell-14]. 3234 Sources of Error: 3236 The principal source of RTDelay error is the host processing time to 3237 return a packet that defines the termination of a time interval. The 3238 heuristics above intend to mitigate these errors by excluding 3239 measurements where host processing time is a significant part of 3240 RTD_fwd or RTD_rev. 3242 A key source of RTLoss error is observation loss, described in 3243 section 3 of [Trammell-14]. 3245 10.3.2. Packet Stream Generation 3247 This section gives the details of the packet traffic which is the 3248 basis for measurement. In IPPM metrics, this is called the Stream, 3249 and can easily be described by providing the list of stream 3250 parameters. 3252 NA 3254 10.3.3. Traffic Filtering (observation) Details 3256 The measured results based on a filtered version of the packets 3257 observed, and this section provides the filter details (when 3258 present). 3260 The Fixed Parameters above give a portion of the Traffic Filter. 3261 Other aspects will be supplied as Run-time Parameters (below). 3263 10.3.4. Sampling Distribution 3265 This metric requires a complete sample of all packets that qualify 3266 according to the Traffic Filter criteria. 3268 10.3.5. Run-time Parameters and Data Format 3270 Run-time Parameters are input factors that must be determined, 3271 configured into the measurement system, and reported with the results 3272 for the context to be complete. 3274 Src the IP address of the host in the host A Role (format ipv4- 3275 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3276 IPv6, see Section 4 of [RFC6991]) 3278 Dst the IP address of the host in the host B (format ipv4-address- 3279 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3280 see section 4 of [RFC6991]) 3282 T0 a time, the start of a measurement interval, (format "date-and- 3283 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3284 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3285 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3286 and Td is to be interpreted as the Duration of the measurement 3287 interval. The start time is controlled through other means. 3289 Td Optionally, the end of a measurement interval, (format "date-and- 3290 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3291 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3292 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3293 the measurement interval MAY be controlled by the measured 3294 connection, where the second pair of FIN and ACK packets exchanged 3295 between host A and B effectively ends the interval. 3297 TTL or Hop Limit Set at desired value. 3299 10.3.6. Roles 3301 host A launches the SYN packet to open the connection, and 3302 synonymous with an IP address. 3304 host B replies with the SYN-ACK packet to open the connection, and 3305 synonymous with an IP address. 3307 10.4. Output 3309 This category specifies all details of the Output of measurements 3310 using the metric. 3312 10.4.1. Type 3314 See subsection titles in Reference Definition for RTDelay Types. 3316 For RTLoss -- the count of lost packets. 3318 10.4.2. Reference Definition 3320 For all output types --- 3322 T0 the start of a measurement interval, (format "date-and-time" as 3323 specified in Section 5.6 of [RFC3339], see also Section 3 of 3324 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3325 [RFC2330]. 3327 Tf the end of a measurement interval, (format "date-and-time" as 3328 specified in Section 5.6 of [RFC3339], see also Section 3 of 3329 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3330 [RFC2330]. The end of the measurement interval MAY be controlled 3331 by the measured connection, where the second pair of FIN and ACK 3332 packets exchanged between host A and B effectively ends the 3333 interval. 3335 ... ... 3337 For RTDelay_HS -- the Round trip delay of the Handshake. 3339 For RTLoss -- the count of lost packets. 3341 For each , one of the following sub-sections apply: 3343 10.4.2.1. Mean 3345 The mean SHALL be calculated using the conditional distribution of 3346 all packets with a finite value of Round-trip delay (undefined delays 3347 are excluded), a single value as follows: 3349 See section 4.1 of [RFC3393] for details on the conditional 3350 distribution to exclude undefined values of delay, and Section 5 of 3351 [RFC6703] for background on this analysis choice. 3353 See section 4.2.2 of [RFC6049] for details on calculating this 3354 statistic, and 4.2.3 of [RFC6049]. 3356 Mean The time value of the result is expressed in units of seconds, 3357 as a positive value of type decimal64 with fraction digits = 9 3358 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3359 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3360 NTP timestamp as per section 6 of RFC [RFC5905] 3362 10.4.2.2. Min 3364 The minimum SHALL be calculated using the conditional distribution of 3365 all packets with a finite value of Round-trip delay (undefined delays 3366 are excluded), a single value as follows: 3368 See section 4.1 of [RFC3393] for details on the conditional 3369 distribution to exclude undefined values of delay, and Section 5 of 3370 [RFC6703] for background on this analysis choice. 3372 See section 4.3.2 of [RFC6049] for details on calculating this 3373 statistic, and 4.3.3 of [RFC6049]. 3375 Min The time value of the result is expressed in units of seconds, 3376 as a positive value of type decimal64 with fraction digits = 9 3377 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3378 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3379 NTP timestamp as per section 6 of RFC [RFC5905] 3381 10.4.2.3. Max 3383 The maximum SHALL be calculated using the conditional distribution of 3384 all packets with a finite value of Round-trip delay (undefined delays 3385 are excluded), a single value as follows: 3387 See section 4.1 of [RFC3393] for details on the conditional 3388 distribution to exclude undefined values of delay, and Section 5 of 3389 [RFC6703] for background on this analysis choice. 3391 See section 4.3.2 of [RFC6049] for a closely related method for 3392 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3393 as follows: 3395 Max = (FiniteDelay [j]) 3397 such that for some index, j, where 1 <= j <= N 3398 FiniteDelay[j] >= FiniteDelay[n] for all n 3400 Max The time value of the result is expressed in units of seconds, 3401 as a positive value of type decimal64 with fraction digits = 9 3402 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3403 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3404 NTP timestamp as per section 6 of RFC [RFC5905] 3406 10.4.3. Metric Units 3408 The of Round-trip Delay is expressed in seconds, where 3409 is one of: 3411 o Mean 3413 o Min 3415 o Max 3417 The Round-trip Delay of the Hand Shake is expressed in seconds. 3419 The Round-trip Loss Count is expressed as a number of packets. 3421 10.4.4. Calibration 3423 Passive measurements at an OP could be calibrated against an active 3424 measurement (with loss emulation) at host A or B, where the active 3425 measurement represents the ground-truth. 3427 10.5. Administrative items 3429 10.5.1. Status 3431 Current 3433 10.5.2. Requestor 3435 This RFC 3437 10.5.3. Revision 3439 1.0 3441 10.5.4. Revision Date 3443 YYYY-MM-DD 3445 10.6. Comments and Remarks 3447 None. 3449 11. Security Considerations 3451 These registry entries represent no known implications for Internet 3452 Security. Each referenced Metric contains a Security Considerations 3453 section. 3455 12. IANA Considerations 3457 IANA is requested to populate The Performance Metric Registry defined 3458 in [I-D.ietf-ippm-metric-registry] with the values defined above. 3460 See the IANA Considerations section of 3461 [I-D.ietf-ippm-metric-registry] for additional requests and 3462 considerations. 3464 13. Acknowledgements 3466 The authors thank Brian Trammell for suggesting the term "Run-time 3467 Parameters", which led to the distinction between run-time and fixed 3468 parameters implemented in this memo, for identifying the IPFIX metric 3469 with Flow Key as an example, for suggesting the Passive TCP RTD 3470 metric and supporting references, and for many other productive 3471 suggestions. Thanks to Peter Koch, who provided several useful 3472 suggestions for disambiguating successive DNS Queries in the DNS 3473 Response time metric. 3475 The authors also acknowledge the constructive reviews and helpful 3476 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, 3477 Yaakov Stein, and participants in the LMAP working group. Thanks to 3478 Michelle Cotton for her early IANA review, and to Amanda Barber for 3479 answering questions related to the presentation of the registry and 3480 accessibility of the complete template via URL. 3482 14. References 3484 14.1. Normative References 3486 [I-D.ietf-ippm-metric-registry] 3487 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 3488 "Registry for Performance Metrics", Internet Draft (work 3489 in progress) draft-ietf-ippm-metric-registry, 2014. 3491 [RFC1035] Mockapetris, P., "Domain names - implementation and 3492 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3493 November 1987, . 3495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3496 Requirement Levels", BCP 14, RFC 2119, 3497 DOI 10.17487/RFC2119, March 1997, 3498 . 3500 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 3501 "Framework for IP Performance Metrics", RFC 2330, 3502 DOI 10.17487/RFC2330, May 1998, 3503 . 3505 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 3506 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 3507 September 1999, . 3509 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 3510 Packet Loss Metric for IPPM", RFC 2680, 3511 DOI 10.17487/RFC2680, September 1999, 3512 . 3514 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 3515 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 3516 September 1999, . 3518 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3519 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3520 . 3522 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 3523 Metric for IP Performance Metrics (IPPM)", RFC 3393, 3524 DOI 10.17487/RFC3393, November 2002, 3525 . 3527 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 3528 performance measurement with periodic streams", RFC 3432, 3529 DOI 10.17487/RFC3432, November 2002, 3530 . 3532 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 3533 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 3534 DOI 10.17487/RFC4737, November 2006, 3535 . 3537 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3538 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 3539 RFC 5357, DOI 10.17487/RFC5357, October 2008, 3540 . 3542 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 3543 RFC 5560, DOI 10.17487/RFC5560, May 2009, 3544 . 3546 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 3547 "Network Time Protocol Version 4: Protocol and Algorithms 3548 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 3549 . 3551 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3552 the Network Configuration Protocol (NETCONF)", RFC 6020, 3553 DOI 10.17487/RFC6020, October 2010, 3554 . 3556 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 3557 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 3558 . 3560 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 3561 DOI 10.17487/RFC6673, August 2012, 3562 . 3564 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3565 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3566 . 3568 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3569 "Specification of the IP Flow Information Export (IPFIX) 3570 Protocol for the Exchange of Flow Information", STD 77, 3571 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3572 . 3574 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 3575 Scheffenegger, Ed., "TCP Extensions for High Performance", 3576 RFC 7323, DOI 10.17487/RFC7323, September 2014, 3577 . 3579 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3580 Ed., "A One-Way Delay Metric for IP Performance Metrics 3581 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 3582 2016, . 3584 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3585 Ed., "A One-Way Loss Metric for IP Performance Metrics 3586 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 3587 2016, . 3589 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3590 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3591 May 2017, . 3593 14.2. Informative References 3595 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 3596 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 3597 July 1991, . 3599 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 3600 "RTP Control Protocol Extended Reports (RTCP XR)", 3601 RFC 3611, DOI 10.17487/RFC3611, November 2003, 3602 . 3604 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 3605 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 3606 2005, . 3608 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3609 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 3610 July 2006, . 3612 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 3613 Flow Information Export (IPFIX) Applicability", RFC 5472, 3614 DOI 10.17487/RFC5472, March 2009, 3615 . 3617 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 3618 Carle, "Information Model for Packet Sampling Exports", 3619 RFC 5477, DOI 10.17487/RFC5477, March 2009, 3620 . 3622 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 3623 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 3624 March 2009, . 3626 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 3627 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 3628 DOI 10.17487/RFC6248, April 2011, 3629 . 3631 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 3632 Performance Metric Development", BCP 170, RFC 6390, 3633 DOI 10.17487/RFC6390, October 2011, 3634 . 3636 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 3637 IP Network Performance Metrics: Different Points of View", 3638 RFC 6703, DOI 10.17487/RFC6703, August 2012, 3639 . 3641 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 3642 Reporting Using a Source Description (SDES) Item and an 3643 RTCP Extended Report (XR) Block", RFC 6776, 3644 DOI 10.17487/RFC6776, October 2012, 3645 . 3647 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 3648 of the RTP Monitoring Framework", RFC 6792, 3649 DOI 10.17487/RFC6792, November 2012, 3650 . 3652 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 3653 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 3654 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 3655 September 2013, . 3657 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 3658 Aitken, P., and A. Akhter, "A Framework for Large-Scale 3659 Measurement of Broadband Performance (LMAP)", RFC 7594, 3660 DOI 10.17487/RFC7594, September 2015, 3661 . 3663 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, 3664 Communications of the ACM, Vol. 56 No. 10, Pages 57-64", 3665 September 2013. 3667 [Trammell-14] 3668 Trammell, B., "Inline Data Integrity Signals for Passive 3669 Measurement, TMA 2014 3670 https://trammell.ch/pdf/qof-tma14.pdf", March 2014. 3672 Authors' Addresses 3674 Al Morton 3675 AT&T Labs 3676 200 Laurel Avenue South 3677 Middletown,, NJ 07748 3678 USA 3680 Phone: +1 732 420 1571 3681 Fax: +1 732 368 1192 3682 Email: acmorton@att.com 3683 URI: http://home.comcast.net/~acmacm/ 3685 Marcelo Bagnulo 3686 Universidad Carlos III de Madrid 3687 Av. Universidad 30 3688 Leganes, Madrid 28911 3689 SPAIN 3691 Phone: 34 91 6249500 3692 Email: marcelo@it.uc3m.es 3693 URI: http://www.it.uc3m.es 3695 Philip Eardley 3696 BT 3697 Adastral Park, Martlesham Heath 3698 Ipswich 3699 ENGLAND 3701 Email: philip.eardley@bt.com 3702 Kevin D'Souza 3703 AT&T Labs 3704 200 Laurel Avenue South 3705 Middletown,, NJ 07748 3706 USA 3708 Phone: +1 732 420 xxxx 3709 Email: kld@att.com