idnits 2.17.1 draft-ietf-ippm-initial-registry-11.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 594 has weird spacing: '... Src the IP...' == Line 598 has weird spacing: '... Dst the IP...' == Line 618 has weird spacing: '... Src launch...' == Line 621 has weird spacing: '... Dst waits ...' == Line 663 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 (March 28, 2019) is 1855 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 3493, but no explicit reference was found in the text == Unused Reference: 'RFC3611' is defined on line 3583, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 3588, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 3592, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 3596, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 3601, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 3610, but no explicit reference was found in the text == Unused Reference: 'RFC6776' is defined on line 3625, but no explicit reference was found in the text == Unused Reference: 'RFC6792' is defined on line 3631, but no explicit reference was found in the text == Unused Reference: 'RFC7003' is defined on line 3636, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 3641, 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: September 29, 2019 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 March 28, 2019 12 Initial Performance Metrics Registry Entries 13 draft-ietf-ippm-initial-registry-11 15 Abstract 17 This memo defines the set of Initial Entries for the IANA Performance 18 Metrics Registry. The set includes, UDP Round-trip Latency and Loss, 19 Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson 20 One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP 21 Round-trip Latency and Loss, and TCP round-trip Latency and Loss. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14[RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 29, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 68 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 69 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 71 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 75 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 76 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 77 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 78 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 79 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 80 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 81 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 82 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 83 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 84 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 85 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 89 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 90 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 91 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 92 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 16 94 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 95 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 97 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 98 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 99 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 101 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 17 102 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 104 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 105 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 106 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 107 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 108 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 109 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19 110 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 111 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 112 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 113 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 114 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 115 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 116 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 117 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 118 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21 119 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22 120 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 121 5.5. Administrative items . . . . . . . . . . . . . . . . . . 23 122 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 123 5.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 23 124 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 125 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 126 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 127 6. DNS Response Latency and Loss Registry Entries . . . . . . . 23 128 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 129 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24 130 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 131 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 132 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 133 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24 134 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24 135 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 136 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25 137 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 138 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 139 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 140 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28 141 6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 142 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 143 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 144 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 146 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 147 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 31 148 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31 149 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 150 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31 151 6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 152 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 153 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 32 154 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 155 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 156 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 157 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32 158 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 159 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33 160 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 161 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33 162 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 163 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34 164 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34 165 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 166 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36 167 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 168 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36 169 7.3.3. Traffic Filtering (observation) Details . . . . . . . 37 170 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37 171 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 172 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38 173 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38 174 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38 175 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38 176 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41 177 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41 178 7.5. Administrative items . . . . . . . . . . . . . . . . . . 42 179 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42 180 7.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 42 181 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 182 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 42 183 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 42 184 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 43 185 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 186 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 187 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 188 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44 189 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 44 190 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44 191 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44 192 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45 193 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46 194 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46 195 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47 196 8.3.3. Traffic Filtering (observation) Details . . . . . . . 48 197 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48 198 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 199 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 200 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 48 201 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49 202 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 203 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 51 204 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 205 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 206 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 207 8.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 53 208 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 209 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 210 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53 211 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 53 212 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 53 213 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 53 214 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 53 215 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54 216 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54 217 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 54 218 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 54 219 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 54 220 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 221 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55 222 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 56 223 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 56 224 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 57 225 9.3.3. Traffic Filtering (observation) Details . . . . . . . 58 226 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 58 227 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 58 228 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 229 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 59 230 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 59 231 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 59 232 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 61 233 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 61 234 9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 235 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 236 9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 62 237 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 62 238 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 62 239 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 62 240 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 62 241 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 62 242 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 243 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 244 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 63 245 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 63 246 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 247 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 248 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 64 249 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 64 250 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 66 251 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 67 252 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 67 253 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 69 254 10.3.3. Traffic Filtering (observation) Details . . . . . . 69 255 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 69 256 10.3.5. Run-time Parameters and Data Format . . . . . . . . 69 257 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 70 258 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 70 259 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 70 260 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 70 261 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 72 262 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 72 263 10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 264 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 265 10.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 73 266 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 73 267 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 73 268 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 73 269 11. Security Considerations . . . . . . . . . . . . . . . . . . . 73 270 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 271 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 272 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 273 14.1. Normative References . . . . . . . . . . . . . . . . . . 74 274 14.2. Informative References . . . . . . . . . . . . . . . . . 76 275 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 277 1. Introduction 279 This memo proposes an initial set of entries for the Performance 280 Metrics Registry. It uses terms and definitions from the IPPM 281 literature, primarily [RFC2330]. 283 Although there are several standard templates for organizing 284 specifications of performance metrics (see [RFC2679] for an example 285 of the traditional IPPM template, based to large extent on the 286 Benchmarking Methodology Working Group's traditional template in 287 [RFC1242], and see [RFC6390] for a similar template), none of these 288 templates were intended to become the basis for the columns of an 289 IETF-wide registry of metrics. While examining aspects of metric 290 specifications which need to be registered, it became clear that none 291 of the existing metric templates fully satisfies the particular needs 292 of a registry. 294 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 295 for a Performance Metrics Registry. Section 5 of 296 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 297 requesting registration of a Metric, that is the creation of entry(s) 298 in the Performance Metrics Registry: "In essence, there needs to be 299 evidence that a candidate Registered Performance Metric has 300 significant industry interest, or has seen deployment, and there is 301 agreement that the candidate Registered Performance Metric serves its 302 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 303 also requires that new entries are administered by IANA through 304 Expert Review or IETF Standards action, which will ensure that the 305 metrics are tightly defined. 307 2. Scope 309 This document defines the initial set of Performance Metrics Registry 310 entries, for which IETF approval (following development in the IP 311 Performance Metrics (IPPM) Working Group) will satisfy the 312 requirement for Expert Review. Most are Active Performance Metrics, 313 which are based on RFCs prepared in the IPPM working group of the 314 IETF, according to their framework [RFC2330] and its updates. 316 3. Registry Categories and Columns 318 This memo uses the terminology defined in 319 [I-D.ietf-ippm-metric-registry]. 321 This section provides the categories and columns of the registry, for 322 easy reference. An entry (row) therefore gives a complete 323 description of a Registered Metric. 325 Registry Categories and Columns, shown as 326 Category 327 ------------------ 328 Column | Column | 330 Summary 331 ------------------------------------------------------------------------ 332 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 334 Metric Definition 335 ----------------------------------------- 336 Reference Definition | Fixed Parameters | 338 Method of Measurement 339 --------------------------------------------------------------------- 340 Reference | Packet | Traffic | Sampling | Run-time | Role | 341 Method | Stream | Filter | Distribution | Parameters | | 342 | Generation | 343 Output 344 ----------------------------------------- 345 Type | Reference | Units | Calibration | 346 | Definition | | | 348 Administrative Information 349 ---------------------------------- 350 Status |Request | Rev | Rev.Date | 352 Comments and Remarks 353 -------------------- 355 4. UDP Round-trip Latency and Loss Registry Entries 357 This section specifies an initial registry entry for the UDP Round- 358 trip Latency, and another entry for UDP Round-trip Loss Ratio. 360 Note: Each Registry entry only produces a "raw" output or a 361 statistical summary. To describe both "raw" and one or more 362 statistics efficiently, the Identifier, Name, and Output Categories 363 can be split and a single section can specify two or more closely- 364 related metrics. This section specifies two Registry entries with 365 many common columns. See Section 7 for an example specifying 366 multiple Registry entries with many common columns. 368 All column entries beside the ID, Name, Description, and Output 369 Reference Method categories are the same, thus this section proposes 370 two closely-related registry entries. As a result, IANA is also 371 asked to assign a corresponding URL to each Named Metric. 373 4.1. Summary 375 This category includes multiple indexes to the registry entry: the 376 element ID and metric name. 378 4.1.1. ID (Identifier) 380 IANA is asked to assign different numeric identifiers to each of the 381 two Named Metrics. 383 4.1.2. Name 385 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 387 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio 389 4.1.3. URIs 391 URL: http:/// 393 4.1.4. Description 395 RTDelay: This metric assesses the delay of a stream of packets 396 exchanged between two hosts (which are the two measurement points), 397 and the Output is the Round-trip delay for all successfully exchanged 398 packets expressed as the 95th percentile of their conditional delay 399 distribution. 401 RTLoss: This metric assesses the loss ratio of a stream of packets 402 exchanged between two hosts (which are the two measurement points), 403 and the Output is the Round-trip loss ratio for all successfully 404 exchanged packets expressed as a percentage. 406 4.1.5. Change Controller 408 IETF 410 4.1.6. Version (of Registry Format) 412 1.0 414 4.2. Metric Definition 416 This category includes columns to prompt the entry of all necessary 417 details related to the metric definition, including the RFC reference 418 and values of input factors, called fixed parameters. 420 4.2.1. Reference Definition 422 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 423 Metric for IPPM", RFC 2681, September 1999. 425 [RFC2681] 427 Section 2.4 of [RFC2681] provides the reference definition of the 428 singleton (single value) Round-trip delay metric. Section 3.4 of 429 [RFC2681] provides the reference definition expanded to cover a 430 multi-singleton sample. Note that terms such as singleton and sample 431 are defined in Section 11 of [RFC2330]. 433 Note that although the [RFC2681] definition of "Round-trip-Delay 434 between Src and Dst" is directionally ambiguous in the text, this 435 metric tightens the definition further to recognize that the host in 436 the "Src" role will send the first packet to "Dst", and ultimately 437 receive the corresponding return packet from "Dst" (when neither are 438 lost). 440 Finally, note that the variable "dT" is used in [RFC2681] to refer to 441 the value of Round-trip delay in metric definitions and methods. The 442 variable "dT" has been re-used in other IPPM literature to refer to 443 different quantities, and cannot be used as a global variable name. 445 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 447 [RFC6673] 449 Both delay and loss metrics employ a maximum waiting time for 450 received packets, so the count of lost packets to total packets sent 451 is the basis for the loss ratio calculation as per Section 6.1 of 452 [RFC6673]. 454 4.2.2. Fixed Parameters 456 Type-P as defined in Section 13 of [RFC2330]: 458 o IPv4 header values: 460 * DSCP: set to 0 462 * TTL: set to 255 464 * Protocol: Set to 17 (UDP) 466 o IPv6 header values: 468 * DSCP: set to 0 470 * Hop Count: set to 255 472 * Protocol: Set to 17 (UDP) 474 o UDP header values: 476 * Checksum: the checksum MUST be calculated and included in the 477 header 479 o UDP Payload 481 * total of 100 bytes 483 Other measurement parameters: 485 o Tmax: a loss threshold waiting time 487 * 3.0, expressed in units of seconds, as a positive value of type 488 decimal64 with fraction digits = 4 (see section 9.3 of 489 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 490 lossless conversion to/from the 32-bit NTP timestamp as per 491 section 6 of [RFC5905]. 493 4.3. Method of Measurement 495 This category includes columns for references to relevant sections of 496 the RFC(s) and any supplemental information needed to ensure an 497 unambiguous methods for implementations. 499 4.3.1. Reference Method 501 The methodology for this metric is defined as Type-P-Round-trip- 502 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 503 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 504 Fixed Parameters. However, the Periodic stream will be generated 505 according to [RFC3432]. 507 The reference method distinguishes between long-delayed packets and 508 lost packets by implementing a maximum waiting time for packet 509 arrival. Tmax is the waiting time used as the threshold to declare a 510 packet lost. Lost packets SHALL be designated as having undefined 511 delay, and counted for the RTLoss metric. 513 The calculations on the delay (RTT) SHALL be performed on the 514 conditional distribution, conditioned on successful packet arrival 515 within Tmax. Also, when all packet delays are stored, the process 516 which calculates the RTT value MAY enforce the Tmax threshold on 517 stored values before calculations. See section 4.1 of [RFC3393] for 518 details on the conditional distribution to exclude undefined values 519 of delay, and Section 5 of [RFC6703] for background on this analysis 520 choice. 522 The reference method requires some way to distinguish between 523 different packets in a stream to establish correspondence between 524 sending times and receiving times for each successfully-arriving 525 packet. Sequence numbers or other send-order identification MUST be 526 retained at the Src or included with each packet to disambiguate 527 packet reordering if it occurs. 529 If a standard measurement protocol is employed, then the measurement 530 process will determine the sequence numbers or timestamps applied to 531 test packets after the Fixed and Runtime parameters are passed to 532 that process. The chosen measurement protocol will dictate the 533 format of sequence numbers and time-stamps, if they are conveyed in 534 the packet payload. 536 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 537 instruction to "send a Type-P packet back to the Src as quickly as 538 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 539 [RFC6673] presents additional requirements which MUST be included in 540 the method of measurement for this metric. 542 4.3.2. Packet Stream Generation 544 This section gives the details of the packet traffic which is the 545 basis for measurement. In IPPM metrics, this is called the Stream, 546 and can easily be described by providing the list of stream 547 parameters. 549 Section 3 of [RFC3432] prescribes the method for generating Periodic 550 streams using associated parameters. 552 incT the nominal duration of inter-packet interval, first bit to 553 first bit, with value 0.0200, expressed in units of seconds, as a 554 positive value of type decimal64 with fraction digits = 4 (see 555 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 556 (0.1 ms). 558 dT the duration of the interval for allowed sample start times, with 559 value 1.0, expressed in units of seconds, as a positive value of 560 type decimal64 with fraction digits = 4 (see section 9.3 of 561 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 563 T0 the actual start time of the periodic stream, (format "date-and- 564 time" as specified in Section 5.6 of [RFC3339], see also Section 3 565 of [RFC6991]). 567 NOTE: an initiation process with a number of control exchanges 568 resulting in unpredictable start times (within a time interval) may 569 be sufficient to avoid synchronization of periodic streams, and 570 therefore a valid replacement for selecting a start time at random 571 from a fixed interval. 573 The T0 parameter will be reported as a measured parameter. 574 Parameters incT and dT are Fixed Parameters. 576 4.3.3. Traffic Filtering (observation) Details 578 The measured results based on a filtered version of the packets 579 observed, and this section provides the filter details (when 580 present). 582 NA 584 4.3.4. Sampling Distribution 586 NA 588 4.3.5. Run-time Parameters and Data Format 590 Run-time Parameters are input factors that must be determined, 591 configured into the measurement system, and reported with the results 592 for the context to be complete. 594 Src the IP address of the host in the Src Role (format ipv4-address- 595 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 596 see Section 4 of [RFC6991]) 598 Dst the IP address of the host in the Dst Role (format ipv4-address- 599 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 600 see section 4 of [RFC6991]) 602 T0 a time, the start of a measurement interval, (format "date-and- 603 time" as specified in Section 5.6 of [RFC3339], see also Section 3 604 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 605 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 606 and Tf is to be interpreted as the Duration of the measurement 607 interval. The start time is controlled through other means. 609 Tf a time, the end of a measurement interval, (format "date-and-time" 610 as specified in Section 5.6 of [RFC3339], see also Section 3 of 612 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 613 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 614 Tf is interpreted as the Duration of the measurement interval. 616 4.3.6. Roles 618 Src launches each packet and waits for return transmissions from 619 Dst. 621 Dst waits for each packet from Src and sends a return packet to Src. 623 4.4. Output 625 This category specifies all details of the Output of measurements 626 using the metric. 628 4.4.1. Type 630 Percentile -- for the conditional distribution of all packets with a 631 valid value of Round-trip delay (undefined delays are excluded), a 632 single value corresponding to the 95th percentile, as follows: 634 See section 4.1 of [RFC3393] for details on the conditional 635 distribution to exclude undefined values of delay, and Section 5 of 636 [RFC6703] for background on this analysis choice. 638 The percentile = 95, meaning that the reported delay, "95Percentile", 639 is the smallest value of Round-trip delay for which the Empirical 640 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 641 Round-trip delay values in the conditional distribution. See section 642 11.3 of [RFC2330] for the definition of the percentile statistic 643 using the EDF. 645 LossRatio -- the count of lost packets to total packets sent is the 646 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 648 4.4.2. Reference Definition 650 For all outputs --- 652 T0 the start of a measurement interval, (format "date-and-time" as 653 specified in Section 5.6 of [RFC3339], see also Section 3 of 654 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 655 [RFC2330]. 657 Tf the end of a measurement interval, (format "date-and-time" as 658 specified in Section 5.6 of [RFC3339], see also Section 3 of 660 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 661 [RFC2330]. 663 TotalPkts the count of packets sent by the Src to Dst during the 664 measurement interval. 666 For 668 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile: 670 95Percentile The time value of the result is expressed in units of 671 seconds, as a positive value of type decimal64 with fraction 672 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 673 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 674 the 64-bit NTP timestamp as 676 For 678 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio: 680 Percentile The numeric value of the result is expressed in units of 681 lost packets to total packets times 100%, as a positive value of 682 type decimal64 with fraction digits = 9 (see section 9.3 of 683 [RFC6020]) with resolution of 0.0000000001. 685 4.4.3. Metric Units 687 The 95th Percentile of Round-trip Delay is expressed in seconds. 689 The Round-trip Loss Ratio is expressed as a percentage of lost 690 packets to total packets sent. 692 4.4.4. Calibration 694 Section 3.7.3 of [RFC7679] provides a means to quantify the 695 systematic and random errors of a time measurement. In-situ 696 calibration could be enabled with an internal loopback at the Source 697 host that includes as much of the measurement system as possible, 698 performs address manipulation as needed, and provides some form of 699 isolation (e.g., deterministic delay) to avoid send-receive interface 700 contention. Some portion of the random and systematic error can be 701 characterized this way. 703 When a measurement controller requests a calibration measurement, the 704 loopback is applied and the result is output in the same format as a 705 normal measurement with additional indication that it is a 706 calibration result. 708 Both internal loopback calibration and clock synchronization can be 709 used to estimate the *available accuracy* of the Output Metric Units. 710 For example, repeated loopback delay measurements will reveal the 711 portion of the Output result resolution which is the result of system 712 noise, and thus inaccurate. 714 4.5. Administrative items 716 4.5.1. Status 718 Current 720 4.5.2. Requestor 722 This RFC numner 724 4.5.3. Revision 726 1.0 728 4.5.4. Revision Date 730 YYYY-MM-DD 732 4.6. Comments and Remarks 734 None. 736 5. Packet Delay Variation Registry Entry 738 This section gives an initial registry entry for a Packet Delay 739 Variation metric. 741 Note: If each Registry entry should only produce a "raw" output or a 742 statistical summary, then the "Output" Category can be split and this 743 section can become two closely-related metrics. 745 5.1. Summary 747 This category includes multiple indexes to the registry entries, the 748 element ID and metric name. 750 5.1.1. ID (Identifier) 752 754 5.1.2. Name 756 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 758 5.1.3. URIs 760 URL: http:/// 762 5.1.4. Description 764 An assessment of packet delay variation with respect to the minimum 765 delay observed on the periodic stream, and the Output is expressed as 766 the 95th percentile of the packet delay variation distribution. 768 5.1.5. Change Controller 770 IETF 772 5.1.6. Version (of Registry Format) 774 1.0 776 5.2. Metric Definition 778 This category includes columns to prompt the entry of all necessary 779 details related to the metric definition, including the RFC reference 780 and values of input factors, called fixed parameters. 782 5.2.1. Reference Definition 784 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 785 Performance Metrics", RFC 2330, May 1998. [RFC2330] 787 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 788 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 789 [RFC3393] 791 Morton, A. and B. Claise, "Packet Delay Variation Applicability 792 Statement", RFC 5481, March 2009. [RFC5481] 794 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 795 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 796 June 2010.[RFC5905] 798 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 799 measured are referred to by the variable name "ddT" (applicable to 800 all forms of delay variation). However, this metric entry specifies 801 the PDV form defined in section 4.2 of [RFC5481], where the singleton 802 PDV for packet i is referred to by the variable name "PDV(i)". 804 5.2.2. Fixed Parameters 806 o IPv4 header values: 808 * DSCP: set to 0 810 * TTL: set to 255 812 * Protocol: Set to 17 (UDP) 814 o IPv6 header values: 816 * DSCP: set to 0 818 * Hop Count: set to 255 820 * Protocol: Set to 17 (UDP) 822 o UDP header values: 824 * Checksum: the checksum MUST be calculated and included in the 825 header 827 o UDP Payload 829 * total of 200 bytes 831 Other measurement parameters: 833 Tmax: a loss threshold waiting time with value 3.0, expressed in 834 units of seconds, as a positive value of type decimal64 with 835 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 836 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 837 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 839 F a selection function unambiguously defining the packets from the 840 stream selected for the metric. See section 4.2 of [RFC5481] for 841 the PDV form. 843 See the Packet Stream generation category for two additional Fixed 844 Parameters. 846 5.3. Method of Measurement 848 This category includes columns for references to relevant sections of 849 the RFC(s) and any supplemental information needed to ensure an 850 unambiguous methods for implementations. 852 5.3.1. Reference Method 854 See section 2.6 and 3.6 of [RFC3393] for general singleton element 855 calculations. This metric entry requires implementation of the PDV 856 form defined in section 4.2 of [RFC5481]. Also see measurement 857 considerations in section 8 of [RFC5481]. 859 The reference method distinguishes between long-delayed packets and 860 lost packets by implementing a maximum waiting time for packet 861 arrival. Tmax is the waiting time used as the threshold to declare a 862 packet lost. Lost packets SHALL be designated as having undefined 863 delay. 865 The calculations on the one-way delay SHALL be performed on the 866 conditional distribution, conditioned on successful packet arrival 867 within Tmax. Also, when all packet delays are stored, the process 868 which calculates the one-way delay value MAY enforce the Tmax 869 threshold on stored values before calculations. See section 4.1 of 870 [RFC3393] for details on the conditional distribution to exclude 871 undefined values of delay, and Section 5 of [RFC6703] for background 872 on this analysis choice. 874 The reference method requires some way to distinguish between 875 different packets in a stream to establish correspondence between 876 sending times and receiving times for each successfully-arriving 877 packet. Sequence numbers or other send-order identification MUST be 878 retained at the Src or included with each packet to disambiguate 879 packet reordering if it occurs. 881 If a standard measurement protocol is employed, then the measurement 882 process will determine the sequence numbers or timestamps applied to 883 test packets after the Fixed and Runtime parameters are passed to 884 that process. The chosen measurement protocol will dictate the 885 format of sequence numbers and time-stamps, if they are conveyed in 886 the packet payload. 888 5.3.2. Packet Stream Generation 890 This section gives the details of the packet traffic which is the 891 basis for measurement. In IPPM metrics, this is called the Stream, 892 and can easily be described by providing the list of stream 893 parameters. 895 Section 3 of [RFC3432] prescribes the method for generating Periodic 896 streams using associated parameters. 898 incT the nominal duration of inter-packet interval, first bit to 899 first bit, with value 0.0200, expressed in units of seconds, as a 900 positive value of type decimal64 with fraction digits = 4 (see 901 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 902 (0.1 ms). 904 dT the duration of the interval for allowed sample start times, with 905 value 1.0, expressed in units of seconds, as a positive value of 906 type decimal64 with fraction digits = 4 (see section 9.3 of 907 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 909 T0 the actual start time of the periodic stream, (format "date-and- 910 time" as specified in Section 5.6 of [RFC3339], see also Section 3 911 of [RFC6991]). 913 NOTE: an initiation process with a number of control exchanges 914 resulting in unpredictable start times (within a time interval) may 915 be sufficient to avoid synchronization of periodic streams, and 916 therefore a valid replacement for selecting a start time at random 917 from a fixed interval. 919 The T0 parameter will be reported as a measured parameter. 920 Parameters incT and dT are Fixed Parameters. 922 5.3.3. Traffic Filtering (observation) Details 924 NA 926 5.3.4. Sampling Distribution 928 NA 930 5.3.5. Run-time Parameters and Data Format 932 Src the IP address of the host in the Src Role (format ipv4-address- 933 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 934 see Section 4 of [RFC6991]) 936 Dst the IP address of the host in the Dst Role (format ipv4-address- 937 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 938 see section 4 of [RFC6991]) 940 T0 a time, the start of a measurement interval, (format "date-and- 941 time" as specified in Section 5.6 of [RFC3339], see also Section 3 942 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 944 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 945 and Tf is to be interpreted as the Duration of the measurement 946 interval. The start time is controlled through other means. 948 Tf a time, the end of a measurement interval, (format "date-and-time" 949 as specified in Section 5.6 of [RFC3339], see also Section 3 of 950 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 951 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 952 Tf is interpreted as the Duration of the measurement interval. 954 5.3.6. Roles 956 5.4. Output 958 This category specifies all details of the Output of measurements 959 using the metric. 961 5.4.1. Type 963 Percentile -- for the conditional distribution of all packets with a 964 valid value of one-way delay (undefined delays are excluded), a 965 single value corresponding to the 95th percentile, as follows: 967 See section 4.1 of [RFC3393] for details on the conditional 968 distribution to exclude undefined values of delay, and Section 5 of 969 [RFC6703] for background on this analysis choice. 971 The percentile = 95, meaning that the reported delay, "95Percentile", 972 is the smallest value of one-way PDV for which the Empirical 973 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 974 one-way PDV values in the conditional distribution. See section 11.3 975 of [RFC2330] for the definition of the percentile statistic using the 976 EDF. 978 5.4.2. Reference Definition 980 T0 the start of a measurement interval, (format "date-and-time" as 981 specified in Section 5.6 of [RFC3339], see also Section 3 of 982 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 983 [RFC2330]. 985 Tf the end of a measurement interval, (format "date-and-time" as 986 specified in Section 5.6 of [RFC3339], see also Section 3 of 987 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 988 [RFC2330]. 990 95Percentile The time value of the result is expressed in units of 991 seconds, as a positive value of type decimal64 with fraction 992 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 993 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 994 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 996 5.4.3. Metric Units 998 The 95th Percentile of one-way PDV is expressed in seconds. 1000 5.4.4. Calibration 1002 Section 3.7.3 of [RFC7679] provides a means to quantify the 1003 systematic and random errors of a time measurement. In-situ 1004 calibration could be enabled with an internal loopback that includes 1005 as much of the measurement system as possible, performs address 1006 manipulation as needed, and provides some form of isolation (e.g., 1007 deterministic delay) to avoid send-receive interface contention. 1008 Some portion of the random and systematic error can be characterized 1009 this way. 1011 For one-way delay measurements, the error calibration must include an 1012 assessment of the internal clock synchronization with its external 1013 reference (this internal clock is supplying timestamps for 1014 measurement). In practice, the time offsets of clocks at both the 1015 source and destination are needed to estimate the systematic error 1016 due to imperfect clock synchronization (the time offsets are 1017 smoothed, thus the random variation is not usually represented in the 1018 results). 1020 time_offset The time value of the result is expressed in units of 1021 seconds, as a signed value of type decimal64 with fraction digits 1022 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1023 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1024 NTP timestamp as per section 6 of RFC [RFC5905] 1026 When a measurement controller requests a calibration measurement, the 1027 loopback is applied and the result is output in the same format as a 1028 normal measurement with additional indication that it is a 1029 calibration result. In any measurement, the measurement function 1030 SHOULD report its current estimate of time offset as an indicator of 1031 the degree of synchronization. 1033 Both internal loopback calibration and clock synchronization can be 1034 used to estimate the *available accuracy* of the Output Metric Units. 1035 For example, repeated loopback delay measurements will reveal the 1036 portion of the Output result resolution which is the result of system 1037 noise, and thus inaccurate. 1039 5.5. Administrative items 1041 5.5.1. Status 1043 Current 1045 5.5.2. Requestor 1047 This RFC number 1049 5.5.3. Revision 1051 1.0 1053 5.5.4. Revision Date 1055 YYYY-MM-DD 1057 5.6. Comments and Remarks 1059 Lost packets represent a challenge for delay variation metrics. See 1060 section 4.1 of [RFC3393] and the delay variation applicability 1061 statement[RFC5481] for extensive analysis and comparison of PDV and 1062 an alternate metric, IPDV. 1064 6. DNS Response Latency and Loss Registry Entries 1066 This section gives initial registry entries for DNS Response Latency 1067 and Loss from a network user's perspective, for a specific named 1068 resource. The metric can be measured repeatedly using different 1069 names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1070 build on that metric by specifying several of the input parameters to 1071 precisely define two metrics for measuring DNS latency and loss. 1073 Note to IANA: Each Registry "Name" below specifies a single registry 1074 entry, whose output format varies in accordance with the name. 1076 All column entries beside the ID, Name, Description, and Output 1077 Reference Method categories are the same, thus this section proposes 1078 two closely-related registry entries. As a result, IANA is also 1079 asked to assign corresponding URLs to each Named Metric. 1081 6.1. Summary 1083 This category includes multiple indexes to the registry entries, the 1084 element ID and metric name. 1086 6.1.1. ID (Identifier) 1088 1090 IANA is asked to assign different numeric identifiers to each of the 1091 two Named Metrics. 1093 6.1.2. Name 1095 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1097 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw 1099 6.1.3. URI 1101 URI: Prefix urn:ietf:metrics:perf: 1103 URL: http:/// 1105 6.1.4. Description 1107 This is a metric for DNS Response performance from a network user's 1108 perspective, for a specific named resource. The metric can be 1109 measured repeatedly using different resource names. 1111 RTDNS: This metric assesses the response time, the interval from the 1112 query transmission to the response. 1114 RLDNS: This metric indicates that the response was deemed lost. In 1115 other words, the response time exceeded the maximum waiting time. 1117 6.1.5. Change Controller 1119 IETF 1121 6.1.6. Version (of Registry Format) 1123 1.0 1125 6.2. Metric Definition 1127 This category includes columns to prompt the entry of all necessary 1128 details related to the metric definition, including the RFC reference 1129 and values of input factors, called fixed parameters. 1131 6.2.1. Reference Definition 1133 Mockapetris, P., "Domain names - implementation and specification", 1134 STD 13, RFC 1035, November 1987. (and updates) 1136 [RFC1035] 1138 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1139 Metric for IPPM", RFC 2681, September 1999. 1141 [RFC2681] 1143 Section 2.4 of [RFC2681] provides the reference definition of the 1144 singleton (single value) Round-trip delay metric. Section 3.4 of 1145 [RFC2681] provides the reference definition expanded to cover a 1146 multi-singleton sample. Note that terms such as singleton and sample 1147 are defined in Section 11 of [RFC2330]. 1149 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1150 [RFC2681]. The Local Host with its User Program and Resolver take 1151 the role of "Src", and the Foreign Name Server takes the role of 1152 "Dst". 1154 Note that although the [RFC2681] definition of "Round-trip-Delay 1155 between Src and Dst at T" is directionally ambiguous in the text, 1156 this metric tightens the definition further to recognize that the 1157 host in the "Src" role will send the first packet to "Dst", and 1158 ultimately receive the corresponding return packet from "Dst" (when 1159 neither are lost). 1161 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1163 [RFC6673] 1165 Both response time and loss metrics employ a maximum waiting time for 1166 received responses, so the count of lost packets to total packets 1167 sent is the basis for the loss determination as per Section 4.3 of 1168 [RFC6673]. 1170 6.2.2. Fixed Parameters 1172 Type-P as defined in Section 13 of [RFC2330]: 1174 o IPv4 header values: 1176 * DSCP: set to 0 1178 * TTL set to 255 1179 * Protocol: Set to 17 (UDP) 1181 o IPv6 header values: 1183 * DSCP: set to 0 1185 * Hop Count: set to 255 1187 * Protocol: Set to 17 (UDP) 1189 o UDP header values: 1191 * Source port: 53 1193 * Destination port: 53 1195 * Checksum: the checksum must be calculated and included in the 1196 header 1198 o Payload: The payload contains a DNS message as defined in RFC 1035 1199 [RFC1035] with the following values: 1201 * The DNS header section contains: 1203 + Identification (see the Run-time column) 1205 + QR: set to 0 (Query) 1207 + OPCODE: set to 0 (standard query) 1209 + AA: not set 1211 + TC: not set 1213 + RD: set to one (recursion desired) 1215 + RA: not set 1217 + RCODE: not set 1219 + QDCOUNT: set to one (only one entry) 1221 + ANCOUNT: not set 1223 + NSCOUNT: not set 1225 + ARCOUNT: not set 1227 * The Question section contains: 1229 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1230 input for the test, see the Run-time column 1232 + QTYPE: the query type provided as input for the test, see 1233 the Run-time column 1235 + QCLASS: set to 1 for IN 1237 * The other sections do not contain any Resource Records. 1239 Other measurement parameters: 1241 o Tmax: a loss threshold waiting time (and to help disambiguate 1242 queries) 1244 * 5.0, expressed in units of seconds, as a positive value of type 1245 decimal64 with fraction digits = 4 (see section 9.3 of 1246 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1247 lossless conversion to/from the 32-bit NTP timestamp as per 1248 section 6 of [RFC5905]. 1250 Observation: reply packets will contain a DNS response and may 1251 contain RRs. 1253 6.3. Method of Measurement 1255 This category includes columns for references to relevant sections of 1256 the RFC(s) and any supplemental information needed to ensure an 1257 unambiguous methods for implementations. 1259 6.3.1. Reference Method 1261 The methodology for this metric is defined as Type-P-Round-trip- 1262 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1263 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1264 Fixed Parameters. 1266 The reference method distinguishes between long-delayed packets and 1267 lost packets by implementing a maximum waiting time for packet 1268 arrival. Tmax is the waiting time used as the threshold to declare a 1269 response packet lost. Lost packets SHALL be designated as having 1270 undefined delay and counted for the RLDNS metric. 1272 The calculations on the delay (RTT) SHALL be performed on the 1273 conditional distribution, conditioned on successful packet arrival 1274 within Tmax. Also, when all packet delays are stored, the process 1275 which calculates the RTT value MAY enforce the Tmax threshold on 1276 stored values before calculations. See section 4.1 of [RFC3393] for 1277 details on the conditional distribution to exclude undefined values 1278 of delay, and Section 5 of [RFC6703] for background on this analysis 1279 choice. 1281 The reference method requires some way to distinguish between 1282 different packets in a stream to establish correspondence between 1283 sending times and receiving times for each successfully-arriving 1284 reply. 1286 DNS Messages bearing Queries provide for random ID Numbers in the 1287 Identification header field, so more than one query may be launched 1288 while a previous request is outstanding when the ID Number is used. 1289 Therefore, the ID Number MUST be retained at the Src or included with 1290 each response packet to disambiguate packet reordering if it occurs. 1292 IF a DNS response does not arrive within Tmax, the response time 1293 RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to 1294 disambiguate the successive queries that are otherwise identical. 1296 Since the ID Number filed is only 16 bits in length, it places a 1297 limit on the number of simultaneous outstanding DNS queries during a 1298 stress test from a single Src address. 1300 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1301 instruction to "send a Type-P packet back to the Src as quickly as 1302 possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS 1303 Server is expected to perform all required functions to prepare and 1304 send a response, so the response time will include processing time 1305 and network delay. Section 8 of [RFC6673] presents additional 1306 requirements which SHALL be included in the method of measurement for 1307 this metric. 1309 In addition to operations described in [RFC2681], the Src MUST parse 1310 the DNS headers of the reply and prepare the information for 1311 subsequent reporting as a measured result, along with the Round-Trip 1312 Delay. 1314 6.3.2. Packet Stream Generation 1316 This section gives the details of the packet traffic which is the 1317 basis for measurement. In IPPM metrics, this is called the Stream, 1318 and can easily be described by providing the list of stream 1319 parameters. 1321 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1322 generate Poisson sampling intervals. The reciprocal of lambda is the 1323 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1324 = 1/lambda, in seconds. 1326 Method 3 is used, where given a start time (Run-time Parameter), the 1327 subsequent send times are all computed prior to measurement by 1328 computing the pseudo-random distribution of inter-packet send times, 1329 (truncating the distribution as specified in the Run-time 1330 Parameters), and the Src sends each packet at the computed times. 1332 Note that Trunc is the upper limit on inter-packet times in the 1333 Poisson distribution. A random value greater than Trunc is set equal 1334 to Trunc instead. 1336 6.3.3. Traffic Filtering (observation) Details 1338 The measured results based on a filtered version of the packets 1339 observed, and this section provides the filter details (when 1340 present). 1342 NA 1344 6.3.4. Sampling Distribution 1346 NA 1348 6.3.5. Run-time Parameters and Data Format 1350 Run-time Parameters are input factors that must be determined, 1351 configured into the measurement system, and reported with the results 1352 for the context to be complete. 1354 Src the IP address of the host in the Src Role (format ipv4-address- 1355 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1356 see Section 4 of [RFC6991]) 1358 Dst the IP address of the host in the Dst Role (format ipv4-address- 1359 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1360 see section 4 of [RFC6991]) 1362 T0 a time, the start of a measurement interval, (format "date-and- 1363 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1364 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1365 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1366 and Tf is to be interpreted as the Duration of the measurement 1367 interval. The start time is controlled through other means. 1369 Tf a time, the end of a measurement interval, (format "date-and-time" 1370 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1372 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1373 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1374 Tf is interpreted as the Duration of the measurement interval. 1376 Reciprocal_lambda average packet interval for Poisson Streams 1377 expressed in units of seconds, as a positive value of type 1378 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1379 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1380 conversion to/from the 32-bit NTP timestamp as per section 6 of 1381 [RFC5905]. 1383 Trunc Upper limit on Poisson distribution expressed in units of 1384 seconds, as a positive value of type decimal64 with fraction 1385 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1386 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1387 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1388 this limit will be clipped and set to the limit value). (if fixed, 1389 Trunc = 30.0000 seconds.) 1391 ID The 16-bit identifier assigned by the program that generates the 1392 query, and which must vary in successive queries, see 1393 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1394 corresponding reply and can be used by the requester (Src) to 1395 match-up replies to outstanding queries. 1397 QNAME The domain name of the Query, formatted as specified in 1398 section 4 of [RFC6991]. 1400 QTYPE The Query Type, which will correspond to the IP address family 1401 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1402 uint16, as per section 9.2 of [RFC6020]. 1404 6.3.6. Roles 1406 Src launches each packet and waits for return transmissions from 1407 Dst. 1409 Dst waits for each packet from Src and sends a return packet to Src. 1411 6.4. Output 1413 This category specifies all details of the Output of measurements 1414 using the metric. 1416 6.4.1. Type 1418 Raw -- for each DNS Query packet sent, sets of values as defined in 1419 the next column, including the status of the response, only assigning 1420 delay values to successful query-response pairs. 1422 6.4.2. Reference Definition 1424 For all outputs: 1426 T the time the DNS Query was sent during the measurement interval, 1427 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1428 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1429 by Section 6.1 of [RFC2330]. 1431 dT The time value of the round-trip delay to receive the DNS 1432 response, expressed in units of seconds, as a positive value of 1433 type decimal64 with fraction digits = 9 (see section 9.3 of 1434 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1435 with lossless conversion to/from the 64-bit NTP timestamp as per 1436 section 6 of RFC [RFC5905]. This value is undefined when the 1437 response packet is not received at Src within waiting time Tmax 1438 seconds. 1440 Rcode The value of the Rcode field in the DNS response header, 1441 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1442 Non-zero values convey errors in the response, and such replies 1443 must be analyzed separately from successful requests. 1445 6.4.3. Metric Units 1447 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1449 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1451 6.4.4. Calibration 1453 Section 3.7.3 of [RFC7679] provides a means to quantify the 1454 systematic and random errors of a time measurement. In-situ 1455 calibration could be enabled with an internal loopback at the Source 1456 host that includes as much of the measurement system as possible, 1457 performs address and payload manipulation as needed, and provides 1458 some form of isolation (e.g., deterministic delay) to avoid send- 1459 receive interface contention. Some portion of the random and 1460 systematic error can be characterized this way. 1462 When a measurement controller requests a calibration measurement, the 1463 loopback is applied and the result is output in the same format as a 1464 normal measurement with additional indication that it is a 1465 calibration result. 1467 Both internal loopback calibration and clock synchronization can be 1468 used to estimate the *available accuracy* of the Output Metric Units. 1469 For example, repeated loopback delay measurements will reveal the 1470 portion of the Output result resolution which is the result of system 1471 noise, and thus inaccurate. 1473 6.5. Administrative items 1475 6.5.1. Status 1477 Current 1479 6.5.2. Requestor 1481 This RFC number 1483 6.5.3. Revision 1485 1.0 1487 6.5.4. Revision Date 1489 YYYY-MM-DD 1491 6.6. Comments and Remarks 1493 Additional (Informational) details for this entry 1495 7. UDP Poisson One-way Delay and Loss Registry Entries 1497 This section specifies five initial registry entries for the UDP 1498 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1500 IANA Note: Registry "Name" below specifies a single registry entry, 1501 whose output format varies according to the element of 1502 the name that specifies one form of statistical summary. There is an 1503 additional metric name for the Loss metric. 1505 All column entries beside the ID, Name, Description, and Output 1506 Reference Method categories are the same, thus this section proposes 1507 six closely-related registry entries. As a result, IANA is also 1508 asked to assign corresponding URLs to each Named Metric. 1510 7.1. Summary 1512 This category includes multiple indexes to the registry entries, the 1513 element ID and metric name. 1515 7.1.1. ID (Identifier) 1517 IANA is asked to assign different numeric identifiers to each of the 1518 six Metrics. 1520 7.1.2. Name 1522 OWDelay_Active_IP-UDP-Poisson- 1523 Payload250B_RFCXXXXsecY_Seconds_ 1525 where is one of: 1527 o 95Percentile 1529 o Mean 1531 o Min 1533 o Max 1535 o StdDev 1537 OWLoss_Active_IP-UDP-Poisson- 1538 Payload250B_RFCXXXXsecY_Percent_LossRatio 1540 7.1.3. URI and URL 1542 URL: http:\\www.iana.org\ ... 1544 7.1.4. Description 1546 OWDelay: This metric assesses the delay of a stream of packets 1547 exchanged between two hosts (or measurement points), and reports the 1548 One-way delay for all successfully exchanged packets 1549 based on their conditional delay distribution. 1551 where is one of: 1553 o 95Percentile 1555 o Mean 1557 o Min 1558 o Max 1560 o StdDev 1562 OWLoss: This metric assesses the loss ratio of a stream of packets 1563 exchanged between two hosts (which are the two measurement points), 1564 and the Output is the One-way loss ratio for all successfully 1565 received packets expressed as a percentage. 1567 7.2. Metric Definition 1569 This category includes columns to prompt the entry of all necessary 1570 details related to the metric definition, including the RFC reference 1571 and values of input factors, called fixed parameters. 1573 7.2.1. Reference Definition 1575 For Delay: 1577 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1578 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1579 7679, DOI 10.17487/RFC7679, January 2016, . 1582 [RFC7679] 1584 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1585 6049, January 2011. 1587 [RFC6049] 1589 Section 3.4 of [RFC7679] provides the reference definition of the 1590 singleton (single value) One-way delay metric. Section 4.4 of 1591 [RFC7679] provides the reference definition expanded to cover a 1592 multi-value sample. Note that terms such as singleton and sample are 1593 defined in Section 11 of [RFC2330]. 1595 Only successful packet transfers with finite delay are included in 1596 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1598 For loss: 1600 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1601 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1602 10.17487/RFC7680, January 2016, . 1605 Section 2.4 of [RFC7680] provides the reference definition of the 1606 singleton (single value) one-way loss metric. Section 3.4 of 1607 [RFC7680] provides the reference definition expanded to cover a 1608 multi-singleton sample. Note that terms such as singleton and sample 1609 are defined in Section 11 of [RFC2330]. 1611 7.2.2. Fixed Parameters 1613 Type-P: 1615 o IPv4 header values: 1617 * DSCP: set to 0 1619 * TTL: set to 255 1621 * Protocol: Set to 17 (UDP) 1623 o IPv6 header values: 1625 * DSCP: set to 0 1627 * Hop Count: set to 255 1629 * Protocol: Set to 17 (UDP) 1631 o UDP header values: 1633 * Checksum: the checksum MUST be calculated and included in the 1634 header 1636 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1638 * Security features in use influence the number of Padding 1639 octets. 1641 * 250 octets total, including the TWAMP format 1643 Other measurement parameters: 1645 Tmax: a loss threshold waiting time with value 3.0, expressed in 1646 units of seconds, as a positive value of type decimal64 with 1647 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1648 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1649 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1651 See the Packet Stream generation category for two additional Fixed 1652 Parameters. 1654 7.3. Method of Measurement 1656 This category includes columns for references to relevant sections of 1657 the RFC(s) and any supplemental information needed to ensure an 1658 unambiguous methods for implementations. 1660 7.3.1. Reference Method 1662 The methodology for this metric is defined as Type-P-One-way-Delay- 1663 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1664 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1666 The reference method distinguishes between long-delayed packets and 1667 lost packets by implementing a maximum waiting time for packet 1668 arrival. Tmax is the waiting time used as the threshold to declare a 1669 packet lost. Lost packets SHALL be designated as having undefined 1670 delay, and counted for the OWLoss metric. 1672 The calculations on the one-way delay SHALL be performed on the 1673 conditional distribution, conditioned on successful packet arrival 1674 within Tmax. Also, when all packet delays are stored, the process 1675 which calculates the one-way delay value MAY enforce the Tmax 1676 threshold on stored values before calculations. See section 4.1 of 1677 [RFC3393] for details on the conditional distribution to exclude 1678 undefined values of delay, and Section 5 of [RFC6703] for background 1679 on this analysis choice. 1681 The reference method requires some way to distinguish between 1682 different packets in a stream to establish correspondence between 1683 sending times and receiving times for each successfully-arriving 1684 packet. Sequence numbers or other send-order identification MUST be 1685 retained at the Src or included with each packet to disambiguate 1686 packet reordering if it occurs. 1688 Since a standard measurement protocol is employed [RFC5357], then the 1689 measurement process will determine the sequence numbers or timestamps 1690 applied to test packets after the Fixed and Runtime parameters are 1691 passed to that process. The measurement protocol dictates the format 1692 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1693 payload. 1695 7.3.2. Packet Stream Generation 1697 This section gives the details of the packet traffic which is the 1698 basis for measurement. In IPPM metrics, this is called the Stream, 1699 and can easily be described by providing the list of stream 1700 parameters. 1702 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1703 generate Poisson sampling intervals. The reciprocal of lambda is the 1704 average packet spacing, thus the Run-time Parameter is 1705 Reciprocal_lambda = 1/lambda, in seconds. 1707 Method 3 SHALL be used, where given a start time (Run-time 1708 Parameter), the subsequent send times are all computed prior to 1709 measurement by computing the pseudo-random distribution of inter- 1710 packet send times, (truncating the distribution as specified in the 1711 Parameter Trunc), and the Src sends each packet at the computed 1712 times. 1714 Note that Trunc is the upper limit on inter-packet times in the 1715 Poisson distribution. A random value greater than Trunc is set equal 1716 to Trunc instead. 1718 Reciprocal_lambda average packet interval for Poisson Streams 1719 expressed in units of seconds, as a positive value of type 1720 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1721 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1722 conversion to/from the 32-bit NTP timestamp as per section 6 of 1723 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1725 Trunc Upper limit on Poisson distribution expressed in units of 1726 seconds, as a positive value of type decimal64 with fraction 1727 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1728 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1729 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1730 this limit will be clipped and set to the limit value). Trunc = 1731 30.0000 seconds. 1733 7.3.3. Traffic Filtering (observation) Details 1735 NA 1737 7.3.4. Sampling Distribution 1739 NA 1741 7.3.5. Run-time Parameters and Data Format 1743 Run-time Parameters are input factors that must be determined, 1744 configured into the measurement system, and reported with the results 1745 for the context to be complete. 1747 Src the IP address of the host in the Src Role (format ipv4-address- 1748 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1749 see Section 4 of [RFC6991]) 1751 Dst the IP address of the host in the Dst Role (format ipv4-address- 1752 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1753 see section 4 of [RFC6991]) 1755 T0 a time, the start of a measurement interval, (format "date-and- 1756 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1757 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1758 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1759 and Tf is to be interpreted as the Duration of the measurement 1760 interval. The start time is controlled through other means. 1762 Tf a time, the end of a measurement interval, (format "date-and-time" 1763 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1764 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1765 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1766 Tf is interpreted as the Duration of the measurement interval. 1768 7.3.6. Roles 1770 1772 Src launches each packet and waits for return transmissions from 1773 Dst. This is the TWAMP Session-Sender. 1775 Dst waits for each packet from Src and sends a return packet to Src. 1776 This is the TWAMP Session-Reflector. 1778 7.4. Output 1780 This category specifies all details of the Output of measurements 1781 using the metric. 1783 7.4.1. Type 1785 See subsection titles below for Types. 1787 7.4.2. Reference Definition 1789 For all output types --- 1791 T0 the start of a measurement interval, (format "date-and-time" as 1792 specified in Section 5.6 of [RFC3339], see also Section 3 of 1793 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1794 [RFC2330]. 1796 Tf the end of a measurement interval, (format "date-and-time" as 1797 specified in Section 5.6 of [RFC3339], see also Section 3 of 1799 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1800 [RFC2330]. 1802 For LossRatio -- the count of lost packets to total packets sent is 1803 the basis for the loss ratio calculation as per Section 4.1 of 1804 [RFC7680]. 1806 For each , one of the following sub-sections apply: 1808 7.4.2.1. Percentile95 1810 The 95th percentile SHALL be calculated using the conditional 1811 distribution of all packets with a finite value of One-way delay 1812 (undefined delays are excluded), a single value as follows: 1814 See section 4.1 of [RFC3393] for details on the conditional 1815 distribution to exclude undefined values of delay, and Section 5 of 1816 [RFC6703] for background on this analysis choice. 1818 See section 4.3 of [RFC3393] for details on the percentile statistic 1819 (where Round-trip delay should be substituted for "ipdv"). 1821 The percentile = 95, meaning that the reported delay, "95Percentile", 1822 is the smallest value of one-way delay for which the Empirical 1823 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1824 one-way delay values in the conditional distribution. See section 1825 11.3 of [RFC2330] for the definition of the percentile statistic 1826 using the EDF. 1828 95Percentile The time value of the result is expressed in units of 1829 seconds, as a positive value of type decimal64 with fraction 1830 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1831 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1832 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1834 7.4.2.2. Mean 1836 The mean SHALL be calculated using the conditional distribution of 1837 all packets with a finite value of One-way delay (undefined delays 1838 are excluded), a single value as follows: 1840 See section 4.1 of [RFC3393] for details on the conditional 1841 distribution to exclude undefined values of delay, and Section 5 of 1842 [RFC6703] for background on this analysis choice. 1844 See section 4.2.2 of [RFC6049] for details on calculating this 1845 statistic, and 4.2.3 of [RFC6049]. 1847 Mean The time value of the result is expressed in units of seconds, 1848 as a positive value of type decimal64 with fraction digits = 9 1849 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1850 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1851 NTP timestamp as per section 6 of RFC [RFC5905] 1853 7.4.2.3. Min 1855 The minimum SHALL be calculated using the conditional distribution of 1856 all packets with a finite value of One-way delay (undefined delays 1857 are excluded), a single value as follows: 1859 See section 4.1 of [RFC3393] for details on the conditional 1860 distribution to exclude undefined values of delay, and Section 5 of 1861 [RFC6703] for background on this analysis choice. 1863 See section 4.3.2 of [RFC6049] for details on calculating this 1864 statistic, and 4.3.3 of [RFC6049]. 1866 Min The time value of the result is expressed in units of seconds, 1867 as a positive value of type decimal64 with fraction digits = 9 1868 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1869 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1870 NTP timestamp as per section 6 of RFC [RFC5905] 1872 7.4.2.4. Max 1874 The maximum SHALL be calculated using the conditional distribution of 1875 all packets with a finite value of One-way delay (undefined delays 1876 are excluded), a single value as follows: 1878 See section 4.1 of [RFC3393] for details on the conditional 1879 distribution to exclude undefined values of delay, and Section 5 of 1880 [RFC6703] for background on this analysis choice. 1882 See section 4.3.2 of [RFC6049] for a closely related method for 1883 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1884 as follows: 1886 Max = (FiniteDelay [j]) 1888 such that for some index, j, where 1 <= j <= N 1889 FiniteDelay[j] >= FiniteDelay[n] for all n 1891 Max The time value of the result is expressed in units of seconds, 1892 as a positive value of type decimal64 with fraction digits = 9 1893 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1894 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1895 NTP timestamp as per section 6 of RFC [RFC5905] 1897 7.4.2.5. Std_Dev 1899 The Std_Dev SHALL be calculated using the conditional distribution of 1900 all packets with a finite value of One-way delay (undefined delays 1901 are excluded), a single value as follows: 1903 See section 4.1 of [RFC3393] for details on the conditional 1904 distribution to exclude undefined values of delay, and Section 5 of 1905 [RFC6703] for background on this analysis choice. 1907 See section 4.3.2 of [RFC6049] for a closely related method for 1908 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 1909 the classic calculation for standard deviation of a population. 1911 Std_Dev The time value of the result is expressed in units of 1912 seconds, as a positive value of type decimal64 with fraction 1913 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1914 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1915 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1917 7.4.3. Metric Units 1919 The of One-way Delay is expressed in seconds. 1921 The One-way Loss Ratio is expressed as a percentage of lost packets 1922 to total packets sent. 1924 7.4.4. Calibration 1926 Section 3.7.3 of [RFC7679] provides a means to quantify the 1927 systematic and random errors of a time measurement. In-situ 1928 calibration could be enabled with an internal loopback that includes 1929 as much of the measurement system as possible, performs address 1930 manipulation as needed, and provides some form of isolation (e.g., 1931 deterministic delay) to avoid send-receive interface contention. 1932 Some portion of the random and systematic error can be characterized 1933 this way. 1935 For one-way delay measurements, the error calibration must include an 1936 assessment of the internal clock synchronization with its external 1937 reference (this internal clock is supplying timestamps for 1938 measurement). In practice, the time offsets of clocks at both the 1939 source and destination are needed to estimate the systematic error 1940 due to imperfect clock synchronization (the time offsets are 1941 smoothed, thus the random variation is not usually represented in the 1942 results). 1944 time_offset The time value of the result is expressed in units of 1945 seconds, as a signed value of type decimal64 with fraction digits 1946 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1947 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1948 NTP timestamp as per section 6 of RFC [RFC5905] 1950 When a measurement controller requests a calibration measurement, the 1951 loopback is applied and the result is output in the same format as a 1952 normal measurement with additional indication that it is a 1953 calibration result. In any measurement, the measurement function 1954 SHOULD report its current estimate of time offset as an indicator of 1955 the degree of synchronization. 1957 Both internal loopback calibration and clock synchronization can be 1958 used to estimate the *available accuracy* of the Output Metric Units. 1959 For example, repeated loopback delay measurements will reveal the 1960 portion of the Output result resolution which is the result of system 1961 noise, and thus inaccurate. 1963 7.5. Administrative items 1965 7.5.1. Status 1967 Current 1969 7.5.2. Requestor 1971 This REFC number 1973 7.5.3. Revision 1975 1.0 1977 7.5.4. Revision Date 1979 YYYY-MM-DD 1981 7.6. Comments and Remarks 1983 Additional (Informational) details for this entry 1985 8. UDP Periodic One-way Delay and Loss Registry Entries 1987 This section specifies five initial registry entries for the UDP 1988 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 1990 IANA Note: Registry "Name" below specifies a single registry entry, 1991 whose output format varies according to the element of 1992 the name that specifies one form of statistical summary. There is an 1993 additional metric name for the Loss metric. 1995 All column entries beside the ID, Name, Description, and Output 1996 Reference Method categories are the same, thus this section proposes 1997 six closely-related registry entries. As a result, IANA is also 1998 asked to assign corresponding URLs to each Named Metric. 2000 8.1. Summary 2002 This category includes multiple indexes to the registry entries, the 2003 element ID and metric name. 2005 8.1.1. ID (Identifier) 2007 IANA is asked to assign a different numeric identifiers to each of 2008 the six Metrics. 2010 8.1.2. Name 2012 OWDelay_Active_IP-UDP-Periodic20m- 2013 Payload142B_RFCXXXXsecY_Seconds_ 2015 where is one of: 2017 o 95Percentile 2019 o Mean 2021 o Min 2023 o Max 2025 o StdDev 2027 OWLoss_Active_IP-UDP-Periodic- 2028 Payload142B_RFCXXXXsecY_Percent_LossRatio 2030 8.1.3. URIs 2032 URL: http:\\www.iana.org\ ... 2034 8.1.4. Description 2036 OWDelay: This metric assesses the delay of a stream of packets 2037 exchanged between two hosts (or measurement points), and reports the 2038 One-way delay for all successfully exchanged packets 2039 based on their conditional delay distribution. 2041 where is one of: 2043 o 95Percentile 2045 o Mean 2047 o Min 2049 o Max 2051 o StdDev 2053 OWLoss: This metric assesses the loss ratio of a stream of packets 2054 exchanged between two hosts (which are the two measurement points), 2055 and the Output is the One-way loss ratio for all successfully 2056 received packets expressed as a percentage. 2058 8.2. Metric Definition 2060 This category includes columns to prompt the entry of all necessary 2061 details related to the metric definition, including the RFC reference 2062 and values of input factors, called fixed parameters. 2064 8.2.1. Reference Definition 2066 For Delay: 2068 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2069 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2070 7679, DOI 10.17487/RFC7679, January 2016, . 2073 [RFC7679] 2075 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2076 6049, January 2011. 2078 [RFC6049] 2080 Section 3.4 of [RFC7679] provides the reference definition of the 2081 singleton (single value) One-way delay metric. Section 4.4 of 2082 [RFC7679] provides the reference definition expanded to cover a 2083 multi-value sample. Note that terms such as singleton and sample are 2084 defined in Section 11 of [RFC2330]. 2086 Only successful packet transfers with finite delay are included in 2087 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2089 For loss: 2091 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2092 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2093 10.17487/RFC7680, January 2016, . 2096 Section 2.4 of [RFC7680] provides the reference definition of the 2097 singleton (single value) one-way loss metric. Section 3.4 of 2098 [RFC7680] provides the reference definition expanded to cover a 2099 multi-singleton sample. Note that terms such as singleton and sample 2100 are defined in Section 11 of [RFC2330]. 2102 8.2.2. Fixed Parameters 2104 Type-P: 2106 o IPv4 header values: 2108 * DSCP: set to 0 2110 * TTL: set to 255 2112 * Protocol: Set to 17 (UDP) 2114 o IPv6 header values: 2116 * DSCP: set to 0 2118 * Hop Count: set to 255 2120 * Protocol: Set to 17 (UDP) 2122 o UDP header values: 2124 * Checksum: the checksum MUST be calculated and included in the 2125 header 2127 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2129 * Security features in use influence the number of Padding 2130 octets. 2132 * 142 octets total, including the TWAMP format (if used) 2134 Other measurement parameters: 2136 Tmax: a loss threshold waiting time with value 3.0, expressed in 2137 units of seconds, as a positive value of type decimal64 with 2138 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2139 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2140 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2142 See the Packet Stream generation category for two additional Fixed 2143 Parameters. 2145 8.3. Method of Measurement 2147 This category includes columns for references to relevant sections of 2148 the RFC(s) and any supplemental information needed to ensure an 2149 unambiguous methods for implementations. 2151 8.3.1. Reference Method 2153 The methodology for this metric is defined as Type-P-One-way-Delay- 2154 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2155 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2156 However, a Periodic stream is used, as defined in [RFC3432]. 2158 The reference method distinguishes between long-delayed packets and 2159 lost packets by implementing a maximum waiting time for packet 2160 arrival. Tmax is the waiting time used as the threshold to declare a 2161 packet lost. Lost packets SHALL be designated as having undefined 2162 delay, and counted for the OWLoss metric. 2164 The calculations on the one-way delay SHALL be performed on the 2165 conditional distribution, conditioned on successful packet arrival 2166 within Tmax. Also, when all packet delays are stored, the process 2167 which calculates the one-way delay value MAY enforce the Tmax 2168 threshold on stored values before calculations. See section 4.1 of 2169 [RFC3393] for details on the conditional distribution to exclude 2170 undefined values of delay, and Section 5 of [RFC6703] for background 2171 on this analysis choice. 2173 The reference method requires some way to distinguish between 2174 different packets in a stream to establish correspondence between 2175 sending times and receiving times for each successfully-arriving 2176 packet. Sequence numbers or other send-order identification MUST be 2177 retained at the Src or included with each packet to disambiguate 2178 packet reordering if it occurs. 2180 Since a standard measurement protocol is employed [RFC5357], then the 2181 measurement process will determine the sequence numbers or timestamps 2182 applied to test packets after the Fixed and Runtime parameters are 2183 passed to that process. The measurement protocol dictates the format 2184 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2185 payload. 2187 8.3.2. Packet Stream Generation 2189 This section gives the details of the packet traffic which is the 2190 basis for measurement. In IPPM metrics, this is called the Stream, 2191 and can easily be described by providing the list of stream 2192 parameters. 2194 Section 3 of [RFC3432] prescribes the method for generating Periodic 2195 streams using associated parameters. 2197 incT the nominal duration of inter-packet interval, first bit to 2198 first bit, with value 0.0200 expressed in units of seconds, as a 2199 positive value of type decimal64 with fraction digits = 4 (see 2200 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 2201 (0.1 ms), with lossless conversion to/from the 32-bit NTP 2202 timestamp as per section 6 of [RFC5905]. 2204 dT the duration of the interval for allowed sample start times, with 2205 value 1.0000, expressed in units of seconds, as a positive value 2206 of type decimal64 with fraction digits = 4 (see section 9.3 of 2207 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2208 lossless conversion to/from the 32-bit NTP timestamp as per 2209 section 6 of [RFC5905]. 2211 T0 the actual start time of the periodic stream, determined from T0 2212 and dT. 2214 NOTE: an initiation process with a number of control exchanges 2215 resulting in unpredictable start times (within a time interval) may 2216 be sufficient to avoid synchronization of periodic streams, and 2217 therefore a valid replacement for selecting a start time at random 2218 from a fixed interval. 2220 These stream parameters will be specified as Run-time parameters. 2222 8.3.3. Traffic Filtering (observation) Details 2224 NA 2226 8.3.4. Sampling Distribution 2228 NA 2230 8.3.5. Run-time Parameters and Data Format 2232 Run-time Parameters are input factors that must be determined, 2233 configured into the measurement system, and reported with the results 2234 for the context to be complete. 2236 Src the IP address of the host in the Src Role (format ipv4-address- 2237 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2238 see Section 4 of [RFC6991]) 2240 Dst the IP address of the host in the Dst Role (format ipv4-address- 2241 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2242 see section 4 of [RFC6991]) 2244 T0 a time, the start of a measurement interval, (format "date-and- 2245 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2246 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2247 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2248 and Tf is to be interpreted as the Duration of the measurement 2249 interval. The start time is controlled through other means. 2251 Tf a time, the end of a measurement interval, (format "date-and-time" 2252 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2253 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2254 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2255 Tf is interpreted as the Duration of the measurement interval. 2257 8.3.6. Roles 2259 Src launches each packet and waits for return transmissions from 2260 Dst. This is the TWAMP Session-Sender. 2262 Dst waits for each packet from Src and sends a return packet to Src. 2263 This is the TWAMP Session-Reflector. 2265 8.4. Output 2267 This category specifies all details of the Output of measurements 2268 using the metric. 2270 8.4.1. Type 2272 2274 See subsection titles in Reference Definition for Latency Types. 2276 8.4.2. Reference Definition 2278 For all output types --- 2280 T0 the start of a measurement interval, (format "date-and-time" as 2281 specified in Section 5.6 of [RFC3339], see also Section 3 of 2282 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2283 [RFC2330]. 2285 Tf the end of a measurement interval, (format "date-and-time" as 2286 specified in Section 5.6 of [RFC3339], see also Section 3 of 2287 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2288 [RFC2330]. 2290 For LossRatio -- the count of lost packets to total packets sent is 2291 the basis for the loss ratio calculation as per Section 4.1 of 2292 [RFC7680]. 2294 For each , one of the following sub-sections apply: 2296 8.4.2.1. Percentile95 2298 The 95th percentile SHALL be calculated using the conditional 2299 distribution of all packets with a finite value of One-way delay 2300 (undefined delays are excluded), a single value as follows: 2302 See section 4.1 of [RFC3393] for details on the conditional 2303 distribution to exclude undefined values of delay, and Section 5 of 2304 [RFC6703] for background on this analysis choice. 2306 See section 4.3 of [RFC3393] for details on the percentile statistic 2307 (where Round-trip delay should be substituted for "ipdv"). 2309 The percentile = 95, meaning that the reported delay, "95Percentile", 2310 is the smallest value of one-way delay for which the Empirical 2311 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2312 one-way delay values in the conditional distribution. See section 2313 11.3 of [RFC2330] for the definition of the percentile statistic 2314 using the EDF. 2316 95Percentile The time value of the result is expressed in units of 2317 seconds, as a positive value of type decimal64 with fraction 2318 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2319 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2320 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2322 8.4.2.2. Mean 2324 The mean SHALL be calculated using the conditional distribution of 2325 all packets with a finite value of One-way delay (undefined delays 2326 are excluded), a single value as follows: 2328 See section 4.1 of [RFC3393] for details on the conditional 2329 distribution to exclude undefined values of delay, and Section 5 of 2330 [RFC6703] for background on this analysis choice. 2332 See section 4.2.2 of [RFC6049] for details on calculating this 2333 statistic, and 4.2.3 of [RFC6049]. 2335 Mean The time value of the result is expressed in units of seconds, 2336 as a positive value of type decimal64 with fraction digits = 9 2337 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2338 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2339 NTP timestamp as per section 6 of RFC [RFC5905] 2341 8.4.2.3. Min 2343 The minimum SHALL be calculated using the conditional distribution of 2344 all packets with a finite value of One-way delay (undefined delays 2345 are excluded), a single value as follows: 2347 See section 4.1 of [RFC3393] for details on the conditional 2348 distribution to exclude undefined values of delay, and Section 5 of 2349 [RFC6703] for background on this analysis choice. 2351 See section 4.3.2 of [RFC6049] for details on calculating this 2352 statistic, and 4.3.3 of [RFC6049]. 2354 Min The time value of the result is expressed in units of seconds, 2355 as a positive value of type decimal64 with fraction digits = 9 2356 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2357 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2358 NTP timestamp as per section 6 of RFC [RFC5905] 2360 8.4.2.4. Max 2362 The maximum SHALL be calculated using the conditional distribution of 2363 all packets with a finite value of One-way delay (undefined delays 2364 are excluded), a single value as follows: 2366 See section 4.1 of [RFC3393] for details on the conditional 2367 distribution to exclude undefined values of delay, and Section 5 of 2368 [RFC6703] for background on this analysis choice. 2370 See section 4.3.2 of [RFC6049] for a closely related method for 2371 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2372 as follows: 2374 Max = (FiniteDelay [j]) 2376 such that for some index, j, where 1 <= j <= N 2377 FiniteDelay[j] >= FiniteDelay[n] for all n 2379 Max The time value of the result is expressed in units of seconds, 2380 as a positive value of type decimal64 with fraction digits = 9 2381 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2382 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2383 NTP timestamp as per section 6 of RFC [RFC5905] 2385 8.4.2.5. Std_Dev 2387 The Std_Dev SHALL be calculated using the conditional distribution of 2388 all packets with a finite value of One-way delay (undefined delays 2389 are excluded), a single value as follows: 2391 See section 4.1 of [RFC3393] for details on the conditional 2392 distribution to exclude undefined values of delay, and Section 5 of 2393 [RFC6703] for background on this analysis choice. 2395 See section 4.3.2 of [RFC6049] for a closely related method for 2396 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2397 the classic calculation for standard deviation of a population. 2399 Std_Dev The time value of the result is expressed in units of 2400 seconds, as a positive value of type decimal64 with fraction 2401 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2402 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2403 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2405 8.4.3. Metric Units 2407 The of One-way Delay is expressed in seconds, where 2408 is one of: 2410 o 95Percentile 2412 o Mean 2413 o Min 2415 o Max 2417 o StdDev 2419 The One-way Loss Ratio is expressed as a percentage of lost packets 2420 to total packets sent. 2422 8.4.4. Calibration 2424 Section 3.7.3 of [RFC7679] provides a means to quantify the 2425 systematic and random errors of a time measurement. In-situ 2426 calibration could be enabled with an internal loopback that includes 2427 as much of the measurement system as possible, performs address 2428 manipulation as needed, and provides some form of isolation (e.g., 2429 deterministic delay) to avoid send-receive interface contention. 2430 Some portion of the random and systematic error can be characterized 2431 this way. 2433 For one-way delay measurements, the error calibration must include an 2434 assessment of the internal clock synchronization with its external 2435 reference (this internal clock is supplying timestamps for 2436 measurement). In practice, the time offsets of clocks at both the 2437 source and destination are needed to estimate the systematic error 2438 due to imperfect clock synchronization (the time offsets are 2439 smoothed, thus the random variation is not usually represented in the 2440 results). 2442 time_offset The time value of the result is expressed in units of 2443 seconds, as a signed value of type decimal64 with fraction digits 2444 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2445 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2446 NTP timestamp as per section 6 of RFC [RFC5905] 2448 When a measurement controller requests a calibration measurement, the 2449 loopback is applied and the result is output in the same format as a 2450 normal measurement with additional indication that it is a 2451 calibration result. In any measurement, the measurement function 2452 SHOULD report its current estimate of time offset as an indicator of 2453 the degree of synchronization. 2455 Both internal loopback calibration and clock synchronization can be 2456 used to estimate the *available accuracy* of the Output Metric Units. 2457 For example, repeated loopback delay measurements will reveal the 2458 portion of the Output result resolution which is the result of system 2459 noise, and thus inaccurate. 2461 8.5. Administrative items 2463 8.5.1. Status 2465 Current 2467 8.5.2. Requestor 2469 This RFC number 2471 8.5.3. Revision 2473 1.0 2475 8.5.4. Revision Date 2477 YYYY-MM-DD 2479 8.6. Comments and Remarks 2481 9. ICMP Round-trip Latency and Loss Registry Entries 2483 This section specifies three initial registry entries for the ICMP 2484 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2486 This section specifies four Registry entries with many common 2487 columns. 2489 All column entries beside the ID, Name, Description, and Output 2490 Reference Method categories are the same, thus this section proposes 2491 two closely-related registry entries. As a result, IANA is also 2492 asked to assign four corresponding URLs to each Named Metric. 2494 9.1. Summary 2496 This category includes multiple indexes to the registry entry: the 2497 element ID and metric name. 2499 9.1.1. ID (Identifier) 2501 IANA is asked to assign different numeric identifiers to each of the 2502 four Named Metrics. 2504 9.1.2. Name 2506 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Seconds_ 2508 where is one of: 2510 o Mean 2512 o Min 2514 o Max 2516 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Percent_LossRatio 2518 9.1.3. URIs 2520 URL: http:/// 2522 9.1.4. Description 2524 RTDelay: This metric assesses the delay of a stream of ICMP packets 2525 exchanged between two hosts (which are the two measurement points), 2526 and the Output is the Round-trip delay for all successfully exchanged 2527 packets expressed as the of their conditional delay 2528 distribution, where is one of: 2530 o Mean 2532 o Min 2534 o Max 2536 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2537 packets exchanged between two hosts (which are the two measurement 2538 points), and the Output is the Round-trip loss ratio for all 2539 successfully exchanged packets expressed as a percentage. 2541 9.1.5. Change Controller 2543 IETF 2545 9.1.6. Version (of Registry Format) 2547 1.0 2549 9.2. Metric Definition 2551 This category includes columns to prompt the entry of all necessary 2552 details related to the metric definition, including the RFC reference 2553 and values of input factors, called fixed parameters. 2555 9.2.1. Reference Definition 2557 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2558 Metric for IPPM", RFC 2681, September 1999. 2560 [RFC2681] 2562 Section 2.4 of [RFC2681] provides the reference definition of the 2563 singleton (single value) Round-trip delay metric. Section 3.4 of 2564 [RFC2681] provides the reference definition expanded to cover a 2565 multi-singleton sample. Note that terms such as singleton and sample 2566 are defined in Section 11 of [RFC2330]. 2568 Note that although the [RFC2681] definition of "Round-trip-Delay 2569 between Src and Dst" is directionally ambiguous in the text, this 2570 metric tightens the definition further to recognize that the host in 2571 the "Src" role will send the first packet to "Dst", and ultimately 2572 receive the corresponding return packet from "Dst" (when neither are 2573 lost). 2575 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2576 the value of Round-trip delay in metric definitions and methods. The 2577 variable "dT" has been re-used in other IPPM literature to refer to 2578 different quantities, and cannot be used as a global variable name. 2580 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2582 [RFC6673] 2584 Both delay and loss metrics employ a maximum waiting time for 2585 received packets, so the count of lost packets to total packets sent 2586 is the basis for the loss ratio calculation as per Section 6.1 of 2587 [RFC6673]. 2589 9.2.2. Fixed Parameters 2591 Type-P as defined in Section 13 of [RFC2330]: 2593 o IPv4 header values: 2595 * DSCP: set to 0 2597 * TTL: set to 255 2599 * Protocol: Set to 01 (ICMP) 2601 o IPv6 header values: 2603 * DSCP: set to 0 2605 * Hop Limit: set to 255 2607 * Protocol: Set to 01 (ICMP) 2609 o ICMP header values: 2611 * Type: 8 (Echo Request) 2613 * Code: 0 2615 * Checksum: the checksum MUST be calculated and included in the 2616 header 2618 * (Identifier and Sequence Number set at Run-Time) 2620 o ICMP Payload 2622 * total of 32 bytes of random info 2624 Other measurement parameters: 2626 o Tmax: a loss threshold waiting time 2628 * 3.0, expressed in units of seconds, as a positive value of type 2629 decimal64 with fraction digits = 4 (see section 9.3 of 2630 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2631 lossless conversion to/from the 32-bit NTP timestamp as per 2632 section 6 of [RFC5905]. 2634 9.3. Method of Measurement 2636 This category includes columns for references to relevant sections of 2637 the RFC(s) and any supplemental information needed to ensure an 2638 unambiguous methods for implementations. 2640 9.3.1. Reference Method 2642 The methodology for this metric is defined as Type-P-Round-trip- 2643 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2644 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2645 Fixed Parameters. 2647 The reference method distinguishes between long-delayed packets and 2648 lost packets by implementing a maximum waiting time for packet 2649 arrival. Tmax is the waiting time used as the threshold to declare a 2650 packet lost. Lost packets SHALL be designated as having undefined 2651 delay, and counted for the RTLoss metric. 2653 The calculations on the delay (RTD) SHALL be performed on the 2654 conditional distribution, conditioned on successful packet arrival 2655 within Tmax. Also, when all packet delays are stored, the process 2656 which calculates the RTD value MAY enforce the Tmax threshold on 2657 stored values before calculations. See section 4.1 of [RFC3393] for 2658 details on the conditional distribution to exclude undefined values 2659 of delay, and Section 5 of [RFC6703] for background on this analysis 2660 choice. 2662 The reference method requires some way to distinguish between 2663 different packets in a stream to establish correspondence between 2664 sending times and receiving times for each successfully-arriving 2665 packet. Sequence numbers or other send-order identification MUST be 2666 retained at the Src or included with each packet to disambiguate 2667 packet reordering if it occurs. 2669 The measurement process will determine the sequence numbers applied 2670 to test packets after the Fixed and Runtime parameters are passed to 2671 that process. The ICMP measurement process and protocol will dictate 2672 the format of sequence numbers and other identifiers. 2674 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2675 instruction to "send a Type-P packet back to the Src as quickly as 2676 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2677 [RFC6673] presents additional requirements which MUST be included in 2678 the method of measurement for this metric. 2680 9.3.2. Packet Stream Generation 2682 This section gives the details of the packet traffic which is the 2683 basis for measurement. In IPPM metrics, this is called the Stream, 2684 and can easily be described by providing the list of stream 2685 parameters. 2687 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2688 On Receive. This is a modification of Section 3 of [RFC3432], which 2689 prescribes the method for generating Periodic streams using 2690 associated parameters: 2692 incT the nominal duration of inter-packet interval, first bit to 2693 first bit 2695 dT the duration of the interval for allowed sample start times 2697 T0 the actual start time of the periodic stream 2698 The incT and T0 stream parameters will be specified as Run-time 2699 parameters, dT is not used in SendOnRcv. 2701 A SendOnRcv sender behaves exactly like a Periodic stream generator 2702 while all reply packets arrive with RTD < incT, and the inter-packet 2703 interval will be constant. 2705 If a reply packet arrives with RTD >= incT, then the inter-packet 2706 interval for the next sending time is nominally RTD. 2708 If a reply packet fails to arrive within Tmax, then the inter-packet 2709 interval for the next sending time is nominally Tmax. 2711 If an immediate send on reply arrival is desired, then set incT=0. 2713 9.3.3. Traffic Filtering (observation) Details 2715 The measured results based on a filtered version of the packets 2716 observed, and this section provides the filter details (when 2717 present). 2719 NA 2721 9.3.4. Sampling Distribution 2723 NA 2725 9.3.5. Run-time Parameters and Data Format 2727 Run-time Parameters are input factors that must be determined, 2728 configured into the measurement system, and reported with the results 2729 for the context to be complete. 2731 Src the IP address of the host in the Src Role (format ipv4-address- 2732 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2733 see Section 4 of [RFC6991]) 2735 Dst the IP address of the host in the Dst Role (format ipv4-address- 2736 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2737 see section 4 of [RFC6991]) 2739 T0 a time, the start of a measurement interval, (format "date-and- 2740 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2741 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2742 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2743 and Tf is to be interpreted as the Duration of the measurement 2744 interval. The start time is controlled through other means. 2746 Count The total count of ICMP Echo Requests to send, formatted as a 2747 uint16, as per section 9.2 of [RFC6020]. 2749 (see the Packet Stream Generation section for additional Run-time 2750 parameters) 2752 9.3.6. Roles 2754 Src launches each packet and waits for return transmissions from 2755 Dst. 2757 Dst waits for each packet from Src and sends a return packet to Src. 2759 9.4. Output 2761 This category specifies all details of the Output of measurements 2762 using the metric. 2764 9.4.1. Type 2766 See subsection titles in Reference Definition for Latency Types. 2768 LossRatio -- the count of lost packets to total packets sent is the 2769 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 2771 9.4.2. Reference Definition 2773 For all output types --- 2775 T0 the start of a measurement interval, (format "date-and-time" as 2776 specified in Section 5.6 of [RFC3339], see also Section 3 of 2777 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2778 [RFC2330]. 2780 Tf the end of a measurement interval, (format "date-and-time" as 2781 specified in Section 5.6 of [RFC3339], see also Section 3 of 2782 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2783 [RFC2330]. 2785 TotalCount the count of packets actually sent by the Src to Dst 2786 during the measurement interval. 2788 For LossRatio -- the count of lost packets to total packets sent is 2789 the basis for the loss ratio calculation as per Section 4.1 of 2790 [RFC7680]. 2792 For each , one of the following sub-sections apply: 2794 9.4.2.1. Mean 2796 The mean SHALL be calculated using the conditional distribution of 2797 all packets with a finite value of Round-trip delay (undefined delays 2798 are excluded), a single value as follows: 2800 See section 4.1 of [RFC3393] for details on the conditional 2801 distribution to exclude undefined values of delay, and Section 5 of 2802 [RFC6703] for background on this analysis choice. 2804 See section 4.2.2 of [RFC6049] for details on calculating this 2805 statistic, and 4.2.3 of [RFC6049]. 2807 Mean The time value of the result is expressed in units of seconds, 2808 as a positive value of type decimal64 with fraction digits = 9 2809 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2810 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2811 NTP timestamp as per section 6 of RFC [RFC5905] 2813 9.4.2.2. Min 2815 The minimum SHALL be calculated using the conditional distribution of 2816 all packets with a finite value of Round-trip delay (undefined delays 2817 are excluded), a single value as follows: 2819 See section 4.1 of [RFC3393] for details on the conditional 2820 distribution to exclude undefined values of delay, and Section 5 of 2821 [RFC6703] for background on this analysis choice. 2823 See section 4.3.2 of [RFC6049] for details on calculating this 2824 statistic, and 4.3.3 of [RFC6049]. 2826 Min The time value of the result is expressed in units of seconds, 2827 as a positive value of type decimal64 with fraction digits = 9 2828 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2829 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2830 NTP timestamp as per section 6 of RFC [RFC5905] 2832 9.4.2.3. Max 2834 The maximum SHALL be calculated using the conditional distribution of 2835 all packets with a finite value of Round-trip delay (undefined delays 2836 are excluded), a single value as follows: 2838 See section 4.1 of [RFC3393] for details on the conditional 2839 distribution to exclude undefined values of delay, and Section 5 of 2840 [RFC6703] for background on this analysis choice. 2842 See section 4.3.2 of [RFC6049] for a closely related method for 2843 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2844 as follows: 2846 Max = (FiniteDelay [j]) 2848 such that for some index, j, where 1 <= j <= N 2849 FiniteDelay[j] >= FiniteDelay[n] for all n 2851 Max The time value of the result is expressed in units of seconds, 2852 as a positive value of type decimal64 with fraction digits = 9 2853 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2854 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2855 NTP timestamp as per section 6 of RFC [RFC5905] 2857 9.4.3. Metric Units 2859 The of Round-trip Delay is expressed in seconds, where 2860 is one of: 2862 o Mean 2864 o Min 2866 o Max 2868 The Round-trip Loss Ratio is expressed as a percentage of lost 2869 packets to total packets sent. 2871 9.4.4. Calibration 2873 Section 3.7.3 of [RFC7679] provides a means to quantify the 2874 systematic and random errors of a time measurement. In-situ 2875 calibration could be enabled with an internal loopback at the Source 2876 host that includes as much of the measurement system as possible, 2877 performs address manipulation as needed, and provides some form of 2878 isolation (e.g., deterministic delay) to avoid send-receive interface 2879 contention. Some portion of the random and systematic error can be 2880 characterized this way. 2882 When a measurement controller requests a calibration measurement, the 2883 loopback is applied and the result is output in the same format as a 2884 normal measurement with additional indication that it is a 2885 calibration result. 2887 Both internal loopback calibration and clock synchronization can be 2888 used to estimate the *available accuracy* of the Output Metric Units. 2889 For example, repeated loopback delay measurements will reveal the 2890 portion of the Output result resolution which is the result of system 2891 noise, and thus inaccurate. 2893 9.5. Administrative items 2895 9.5.1. Status 2897 Current 2899 9.5.2. Requestor 2901 This RFC number 2903 9.5.3. Revision 2905 1.0 2907 9.5.4. Revision Date 2909 YYYY-MM-DD 2911 9.6. Comments and Remarks 2913 None 2915 10. TCP Round-Trip Delay and Loss Registry Entries 2917 This section specifies three initial registry entries for the Passive 2918 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 2919 Round-trip Loss Count. 2921 This section specifies four Registry entries with many common 2922 columns. 2924 All column entries beside the ID, Name, Description, and Output 2925 Reference Method categories are the same, thus this section proposes 2926 four closely-related registry entries. As a result, IANA is also 2927 asked to assign four corresponding URLs to each Named Metric. 2929 10.1. Summary 2931 This category includes multiple indexes to the registry entry: the 2932 element ID and metric name. 2934 10.1.1. ID (Identifier) 2936 IANA is asked to assign different numeric identifiers to each of the 2937 four Named Metrics. 2939 10.1.2. Name 2941 RTDelay_Passive_IP-TCP_RFCXXXXsecY_Seconds_ 2943 where is one of: 2945 o Mean 2947 o Min 2949 o Max 2951 RTDelay_Passive_IP-TCP-HS_RFCXXXXsecY_Seconds_Singleton 2953 Note that a mid-point observer only has the opportuinty to compose a 2954 single RTDelay on the TCP Hand Shake. 2956 RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count 2958 10.1.3. URIs 2960 URL: http:/// 2962 10.1.4. Description 2964 RTDelay: This metric assesses the round-trip delay of TCP packets 2965 constituting a single connection, exchanged between two hosts. We 2966 consider the measurement of round-trip delay based on a single 2967 Observation Point [RFC7011] somewhere in the network. The Output is 2968 the Round-trip delay for all successfully exchanged packets expressed 2969 as the of their conditional delay distribution, where 2970 is one of: 2972 o Mean 2974 o Min 2976 o Max 2978 RTLoss: This metric assesses the estimated loss count for TCP packets 2979 constituting a single connection, exchanged between two hosts. We 2980 consider the measurement of round-trip delay based on a single 2981 Observation Point [RFC7011] somewhere in the network. The Output is 2982 the estimated Loss Count for the measurement interval. 2984 10.1.5. Change Controller 2986 IETF 2988 10.1.6. Version (of Registry Format) 2990 1.0 2992 10.2. Metric Definition 2994 This category includes columns to prompt the entry of all necessary 2995 details related to the metric definition, including the RFC reference 2996 and values of input factors, called fixed parameters. 2998 10.2.1. Reference Definitions 3000 Although there is no RFC that describes passive measurement of Round- 3001 Trip Delay, the parallel definition for Active measurement is: 3003 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 3004 Metric for IPPM", RFC 2681, September 1999. 3006 [RFC2681] 3008 This metric definition uses the terms singleton and sample as defined 3009 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 3010 reference definition of the singleton (single value) Round-trip delay 3011 metric. Section 3.4 of [RFC2681] provides the reference definition 3012 expanded to cover a multi-singleton sample.) 3014 With the Observation Point [RFC7011] (OP) typically located between 3015 the hosts participating in the TCP connection, the Round-trip Delay 3016 metric requires two individual measurements between the OP and each 3017 host, such that the Spatial Composition [RFC6049]of the measurements 3018 yields a Round-trip Delay singleton (we are extending the composition 3019 of one-way subpath delays to subpath round-trip delay). 3021 Using the direction of TCP SYN transmission to anchor the 3022 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3023 during connection establishment. The direction of SYN transfer is 3024 considered the Forward direction of transmission, from A through OP 3025 to B (Reverse is B through OP to A). 3027 Traffic filters reduce the packet stream at the OP to a Qualified 3028 bidirectional flow packets. 3030 In the definitions below, Corresponding Packets are transferred in 3031 different directions and convey a common value in a TCP header field 3032 that establishes correspondence (to the extent possible). Examples 3033 may be found in the TCP timestamp fields. 3035 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3036 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3037 observed a Qualified Packet to host B at wire-time T', that host B 3038 received that packet and sent a Corresponding Packet back to host A, 3039 and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. 3041 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3042 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3043 OP observed a Qualified Packet to host A at wire-time T'', that host 3044 A received that packet and sent a Corresponding Packet back to host 3045 B, and that OP observed the Corresponding Packet at wire-time T'' + 3046 RTD_rev. 3048 Ideally, the packet sent from host B to host A in both definitions 3049 above SHOULD be the same packet (or, when measuring RTD_rev first, 3050 the packet from host A to host B in both definitions should be the 3051 same). 3053 The REQUIRED Composition Function for a singleton of Round-trip Delay 3054 at time T (where T is the earliest of T' and T'' above) is: 3056 RTDelay = RTD_fwd + RTD_rev 3058 Note that when OP is located at host A or host B, one of the terms 3059 composing RTDelay will be zero or negligible. 3061 When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- 3062 SYN-ACK, then RTD_fwd == RTD_HS_fwd. 3064 When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a 3065 TCP-ACK, then RTD_rev == RTD_HS_rev. 3067 The REQUIRED Composition Function for a singleton of Round-trip Delay 3068 for the connection Hand Shake: 3070 RTDelay_HS = RTD_HS_fwd + RTD_HS_rev 3072 The definition of Round-trip Loss Count uses the nomenclature 3073 developed above, based on observation of the TCP header sequence 3074 numbers and storing the sequence number gaps observed. Packet Losses 3075 can be inferred from: 3077 o Out-of-order segments: TCP segments are transmitted with 3078 monotonically increasing sequence numbers, but these segments may 3079 be received out of order. Section 3 of [RFC4737] describes the 3080 notion of "next expected" sequence numbers which can be adapted to 3081 TCP segments (for the purpose of detecting reordered packets). 3082 Observation of out-of-order segments indicates loss on the path 3083 prior to the OP, and creates a gap. 3085 o Duplicate segments: Section 2 of [RFC5560] defines identical 3086 packets and is suitable for evaluation of TCP packets to detect 3087 duplication. Observation of duplicate segments *without a 3088 corresponding gap* indicates loss on the path following the OP 3089 (because they overlap part of the delivered sequence numbers 3090 already observed at OP). 3092 Each observation of an out-of-order or duplicate infers a singleton 3093 of loss, but composition of Round-trip Loss Counts will be conducted 3094 over a measurement interval which is synonymous with a single TCP 3095 connection. 3097 With the above observations in the Forward direction over a 3098 measurement interval, the count of out-of-order and duplicate 3099 segments is defined as RTL_fwd. Comparable observations in the 3100 Reverse direction are defined as RTL_rev. 3102 For a measurement interval (corresponding to a single TCP 3103 connection), T0 to Tf, the REQUIRED Composition Function for a the 3104 two single-direction counts of inferred loss is: 3106 RTLoss = RTL_fwd + RTL_rev 3108 10.2.2. Fixed Parameters 3110 3114 Traffic Filters: 3116 o IPv4 header values: 3118 * DSCP: set to 0 3120 * Protocol: Set to 06 (TCP) 3122 o IPv6 header values: 3124 * DSCP: set to 0 3125 * Protocol: Set to 06 (TCP) 3127 o TCP header values: 3129 * Flags: ACK, SYN, FIN, @@@@@ others?? 3131 * Timestamp Option (TSopt): Set 3133 + Kind: 8 3135 + Length: 10 bytes 3137 o 3139 10.3. Method of Measurement 3141 This category includes columns for references to relevant sections of 3142 the RFC(s) and any supplemental information needed to ensure an 3143 unambiguous methods for implementations. 3145 10.3.1. Reference Methods 3147 The foundation methodology for this metric is defined in Section 4 of 3148 [RFC7323] using the Timestamp Option with modifications that allow 3149 application at a mid-path Observation Point (OP) [RFC7011]. Further 3150 details and applicable heuristics were derived from [Strowes] and 3151 [Trammell-14]. 3153 The Traffic Filter at the OP is configured to observe a single TCP 3154 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3155 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3156 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3157 of RTDelay as RTDelay_HS (composed using the forward and reverse 3158 measurement pair). RTDelay_HS SHALL be treated separately from other 3159 RTDelays on data-bearing packets and their ACKs. The RTDelay_HS 3160 value MAY be used as a sanity check on other Composed values of 3161 RTDelay. 3163 For payload bearing packets, the OP measures the time interval 3164 between observation of a packet with Sequence Number s, and the 3165 corresponding ACK with same Sequence number. When the payload is 3166 transferred from host A to host B, the observed interval is RTD_fwd. 3168 Because many data transfers are unidirectional (say, in the Forward 3169 direction from host A to host B), it is necessary to use pure ACK 3170 packets with Timestamp (TSval) and their Timestamp value echo to 3171 perform a RTD_rev measurement. The time interval between observation 3172 of the ACK from B to A, and the corresponding packet with Timestamp 3173 echo (TSecr) is the RTD_rev. 3175 Delay Measurement Filtering Heuristics: 3177 If Data payloads were transferred in both Forward and Reverse 3178 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3179 of [RFC7323] could be applied. This rule essentially excludes any 3180 measurement using a packet unless it makes progress in the transfer 3181 (advances the left edge of the send window, consistent 3182 with[Strowes]). 3184 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3185 that is larger than previously observed values. This would tend to 3186 exclude Reverse measurements taken when the Application has no data 3187 ready to send, because considerable time could be added to RTD_rev 3188 from this source of error. 3190 Note that the above Heuristic assumes that host A is sending data. 3191 Host A expecting a download would mean that this heuristic should be 3192 applied to RTD_fwd. 3194 The statistic calculations to summarize the delay (RTDelay) SHALL be 3195 performed on the conditional distribution, conditioned on successful 3196 Forward and Reverse measurements which follow the Heuristics. 3198 Method for Inferring Loss: 3200 The OP tracks sequence numbers and stores gaps for each direction of 3201 transmission, as well as the next-expected sequence number as in 3202 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3203 segments and Duplicate segments. 3205 Loss Measurement Filtering Heuristics: 3207 [Trammell-14] adds a window of evaluation based on the RTDelay. 3209 Distinguish Re-ordered from OOO due to loss, because sequence number 3210 gap is filled during the same RTDelay window. Segments detected as 3211 re-ordered according to [RFC4737] MUST reduce the Loss Count inferred 3212 from Out-of-order segments. 3214 Spurious (unneeded) retransmissions (observed as duplicates) can also 3215 be reduced this way, as described in [Trammell-14]. 3217 Sources of Error: 3219 The principal source of RTDelay error is the host processing time to 3220 return a packet that defines the termination of a time interval. The 3221 heuristics above intend to mitigate these errors by excluding 3222 measurements where host processing time is a significant part of 3223 RTD_fwd or RTD_rev. 3225 A key source of RTLoss error is observation loss, described in 3226 section 3 of [Trammell-14]. 3228 10.3.2. Packet Stream Generation 3230 This section gives the details of the packet traffic which is the 3231 basis for measurement. In IPPM metrics, this is called the Stream, 3232 and can easily be described by providing the list of stream 3233 parameters. 3235 NA 3237 10.3.3. Traffic Filtering (observation) Details 3239 The measured results based on a filtered version of the packets 3240 observed, and this section provides the filter details (when 3241 present). 3243 The Fixed Parameters above give a portion of the Traffic Filter. 3244 Other aspects will be supplied as Run-time Parameters (below). 3246 10.3.4. Sampling Distribution 3248 This metric requires a complete sample of all packets that qualify 3249 according to the Traffic Filter criteria. 3251 10.3.5. Run-time Parameters and Data Format 3253 Run-time Parameters are input factors that must be determined, 3254 configured into the measurement system, and reported with the results 3255 for the context to be complete. 3257 Src the IP address of the host in the host A Role (format ipv4- 3258 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3259 IPv6, see Section 4 of [RFC6991]) 3261 Dst the IP address of the host in the host B (format ipv4-address- 3262 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3263 see section 4 of [RFC6991]) 3265 T0 a time, the start of a measurement interval, (format "date-and- 3266 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3267 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3268 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3269 and Td is to be interpreted as the Duration of the measurement 3270 interval. The start time is controlled through other means. 3272 Td Optionally, the end of a measurement interval, (format "date-and- 3273 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3274 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3275 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3276 the measurement interval MAY be controlled by the measured 3277 connection, where the second pair of FIN and ACK packets exchanged 3278 between host A and B effectively ends the interval. 3280 TTL or Hop Limit Set at desired value. 3282 10.3.6. Roles 3284 host A launches the SYN packet to open the connection, and 3285 synonymous with an IP address. 3287 host B replies with the SYN-ACK packet to open the connection, and 3288 synonymous with an IP address. 3290 10.4. Output 3292 This category specifies all details of the Output of measurements 3293 using the metric. 3295 10.4.1. Type 3297 See subsection titles in Reference Definition for RTDelay Types. 3299 For RTLoss -- the count of lost packets. 3301 10.4.2. Reference Definition 3303 For all output types --- 3305 T0 the start of a measurement interval, (format "date-and-time" as 3306 specified in Section 5.6 of [RFC3339], see also Section 3 of 3307 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3308 [RFC2330]. 3310 Tf the end of a measurement interval, (format "date-and-time" as 3311 specified in Section 5.6 of [RFC3339], see also Section 3 of 3312 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3313 [RFC2330]. The end of the measurement interval MAY be controlled 3314 by the measured connection, where the second pair of FIN and ACK 3315 packets exchanged between host A and B effectively ends the 3316 interval. 3318 ... ... 3320 For RTDelay_HS -- the Round trip delay of the Handshake. 3322 For RTLoss -- the count of lost packets. 3324 For each , one of the following sub-sections apply: 3326 10.4.2.1. Mean 3328 The mean SHALL be calculated using the conditional distribution of 3329 all packets with a finite value of Round-trip delay (undefined delays 3330 are excluded), a single value as follows: 3332 See section 4.1 of [RFC3393] for details on the conditional 3333 distribution to exclude undefined values of delay, and Section 5 of 3334 [RFC6703] for background on this analysis choice. 3336 See section 4.2.2 of [RFC6049] for details on calculating this 3337 statistic, and 4.2.3 of [RFC6049]. 3339 Mean The time value of the result is expressed in units of seconds, 3340 as a positive value of type decimal64 with fraction digits = 9 3341 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3342 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3343 NTP timestamp as per section 6 of RFC [RFC5905] 3345 10.4.2.2. Min 3347 The minimum SHALL be calculated using the conditional distribution of 3348 all packets with a finite value of Round-trip delay (undefined delays 3349 are excluded), a single value as follows: 3351 See section 4.1 of [RFC3393] for details on the conditional 3352 distribution to exclude undefined values of delay, and Section 5 of 3353 [RFC6703] for background on this analysis choice. 3355 See section 4.3.2 of [RFC6049] for details on calculating this 3356 statistic, and 4.3.3 of [RFC6049]. 3358 Min The time value of the result is expressed in units of seconds, 3359 as a positive value of type decimal64 with fraction digits = 9 3360 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3361 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3362 NTP timestamp as per section 6 of RFC [RFC5905] 3364 10.4.2.3. Max 3366 The maximum SHALL be calculated using the conditional distribution of 3367 all packets with a finite value of Round-trip delay (undefined delays 3368 are excluded), a single value as follows: 3370 See section 4.1 of [RFC3393] for details on the conditional 3371 distribution to exclude undefined values of delay, and Section 5 of 3372 [RFC6703] for background on this analysis choice. 3374 See section 4.3.2 of [RFC6049] for a closely related method for 3375 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3376 as follows: 3378 Max = (FiniteDelay [j]) 3380 such that for some index, j, where 1 <= j <= N 3381 FiniteDelay[j] >= FiniteDelay[n] for all n 3383 Max The time value of the result is expressed in units of seconds, 3384 as a positive value of type decimal64 with fraction digits = 9 3385 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3386 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3387 NTP timestamp as per section 6 of RFC [RFC5905] 3389 10.4.3. Metric Units 3391 The of Round-trip Delay is expressed in seconds, where 3392 is one of: 3394 o Mean 3396 o Min 3398 o Max 3400 The Round-trip Delay of the Hand Shake is expressed in seconds. 3402 The Round-trip Loss Count is expressed as a number of packets. 3404 10.4.4. Calibration 3406 Passive measurements at an OP could be calibrated against an active 3407 measurement (with loss emulation) at host A or B, where the active 3408 measurement represents the ground-truth. 3410 10.5. Administrative items 3412 10.5.1. Status 3414 Current 3416 10.5.2. Requestor 3418 This RFC 3420 10.5.3. Revision 3422 1.0 3424 10.5.4. Revision Date 3426 YYYY-MM-DD 3428 10.6. Comments and Remarks 3430 None. 3432 11. Security Considerations 3434 These registry entries represent no known implications for Internet 3435 Security. Each referenced Metric contains a Security Considerations 3436 section. 3438 12. IANA Considerations 3440 IANA is requested to populate The Performance Metrics Registry 3441 defined in [I-D.ietf-ippm-metric-registry] with the values defined 3442 above. 3444 See the IANA Considerations section of 3445 [I-D.ietf-ippm-metric-registry] for additional requests and 3446 considerations. 3448 13. Acknowledgements 3450 The authors thank Brian Trammell for suggesting the term "Run-time 3451 Parameters", which led to the distinction between run-time and fixed 3452 parameters implemented in this memo, for identifying the IPFIX metric 3453 with Flow Key as an example, for suggesting the Passive TCP RTD 3454 metric and supporting references, and for many other productive 3455 suggestions. Thanks to Peter Koch, who provided several useful 3456 suggestions for disambiguating successive DNS Queries in the DNS 3457 Response time metric. 3459 The authors also acknowledge the constructive reviews and helpful 3460 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, 3461 Yaakov Stein, and participants in the LMAP working group. Thanks to 3462 Michelle Cotton for her early IANA review, and to Amanda Barber for 3463 answering questions related to the presentation of the registry and 3464 accessibility of the complete template via URL. 3466 14. References 3468 14.1. Normative References 3470 [I-D.ietf-ippm-metric-registry] 3471 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 3472 "Registry for Performance Metrics", Internet Draft (work 3473 in progress) draft-ietf-ippm-metric-registry, 2014. 3475 [RFC1035] Mockapetris, P., "Domain names - implementation and 3476 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3477 November 1987, . 3479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3480 Requirement Levels", BCP 14, RFC 2119, 3481 DOI 10.17487/RFC2119, March 1997, 3482 . 3484 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 3485 "Framework for IP Performance Metrics", RFC 2330, 3486 DOI 10.17487/RFC2330, May 1998, 3487 . 3489 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 3490 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 3491 September 1999, . 3493 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 3494 Packet Loss Metric for IPPM", RFC 2680, 3495 DOI 10.17487/RFC2680, September 1999, 3496 . 3498 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 3499 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 3500 September 1999, . 3502 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3503 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3504 . 3506 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 3507 Metric for IP Performance Metrics (IPPM)", RFC 3393, 3508 DOI 10.17487/RFC3393, November 2002, 3509 . 3511 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 3512 performance measurement with periodic streams", RFC 3432, 3513 DOI 10.17487/RFC3432, November 2002, 3514 . 3516 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 3517 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 3518 DOI 10.17487/RFC4737, November 2006, 3519 . 3521 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 3522 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 3523 RFC 5357, DOI 10.17487/RFC5357, October 2008, 3524 . 3526 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 3527 RFC 5560, DOI 10.17487/RFC5560, May 2009, 3528 . 3530 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 3531 "Network Time Protocol Version 4: Protocol and Algorithms 3532 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 3533 . 3535 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3536 the Network Configuration Protocol (NETCONF)", RFC 6020, 3537 DOI 10.17487/RFC6020, October 2010, 3538 . 3540 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 3541 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 3542 . 3544 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 3545 DOI 10.17487/RFC6673, August 2012, 3546 . 3548 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3549 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3550 . 3552 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3553 "Specification of the IP Flow Information Export (IPFIX) 3554 Protocol for the Exchange of Flow Information", STD 77, 3555 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3556 . 3558 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 3559 Scheffenegger, Ed., "TCP Extensions for High Performance", 3560 RFC 7323, DOI 10.17487/RFC7323, September 2014, 3561 . 3563 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3564 Ed., "A One-Way Delay Metric for IP Performance Metrics 3565 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 3566 2016, . 3568 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 3569 Ed., "A One-Way Loss Metric for IP Performance Metrics 3570 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 3571 2016, . 3573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3575 May 2017, . 3577 14.2. Informative References 3579 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 3580 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 3581 July 1991, . 3583 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 3584 "RTP Control Protocol Extended Reports (RTCP XR)", 3585 RFC 3611, DOI 10.17487/RFC3611, November 2003, 3586 . 3588 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 3589 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 3590 2005, . 3592 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3593 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 3594 July 2006, . 3596 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 3597 Flow Information Export (IPFIX) Applicability", RFC 5472, 3598 DOI 10.17487/RFC5472, March 2009, 3599 . 3601 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 3602 Carle, "Information Model for Packet Sampling Exports", 3603 RFC 5477, DOI 10.17487/RFC5477, March 2009, 3604 . 3606 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 3607 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 3608 March 2009, . 3610 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 3611 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 3612 DOI 10.17487/RFC6248, April 2011, 3613 . 3615 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 3616 Performance Metric Development", BCP 170, RFC 6390, 3617 DOI 10.17487/RFC6390, October 2011, 3618 . 3620 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 3621 IP Network Performance Metrics: Different Points of View", 3622 RFC 6703, DOI 10.17487/RFC6703, August 2012, 3623 . 3625 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 3626 Reporting Using a Source Description (SDES) Item and an 3627 RTCP Extended Report (XR) Block", RFC 6776, 3628 DOI 10.17487/RFC6776, October 2012, 3629 . 3631 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 3632 of the RTP Monitoring Framework", RFC 6792, 3633 DOI 10.17487/RFC6792, November 2012, 3634 . 3636 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 3637 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 3638 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 3639 September 2013, . 3641 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 3642 Aitken, P., and A. Akhter, "A Framework for Large-Scale 3643 Measurement of Broadband Performance (LMAP)", RFC 7594, 3644 DOI 10.17487/RFC7594, September 2015, 3645 . 3647 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, 3648 Communications of the ACM, Vol. 56 No. 10, Pages 57-64", 3649 September 2013. 3651 [Trammell-14] 3652 Trammell, B., "Inline Data Integrity Signals for Passive 3653 Measurement, TMA 2014 3654 https://trammell.ch/pdf/qof-tma14.pdf", March 2014. 3656 Authors' Addresses 3658 Al Morton 3659 AT&T Labs 3660 200 Laurel Avenue South 3661 Middletown,, NJ 07748 3662 USA 3664 Phone: +1 732 420 1571 3665 Fax: +1 732 368 1192 3666 Email: acmorton@att.com 3667 URI: http://home.comcast.net/~acmacm/ 3669 Marcelo Bagnulo 3670 Universidad Carlos III de Madrid 3671 Av. Universidad 30 3672 Leganes, Madrid 28911 3673 SPAIN 3675 Phone: 34 91 6249500 3676 Email: marcelo@it.uc3m.es 3677 URI: http://www.it.uc3m.es 3679 Philip Eardley 3680 BT 3681 Adastral Park, Martlesham Heath 3682 Ipswich 3683 ENGLAND 3685 Email: philip.eardley@bt.com 3686 Kevin D'Souza 3687 AT&T Labs 3688 200 Laurel Avenue South 3689 Middletown,, NJ 07748 3690 USA 3692 Phone: +1 732 420 xxxx 3693 Email: kld@att.com