idnits 2.17.1 draft-ietf-ippm-initial-registry-06.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 675 has weird spacing: '... Src the IP...' == Line 679 has weird spacing: '... Dst the IP...' == Line 700 has weird spacing: '... Src launch...' == Line 703 has weird spacing: '... Dst waits ...' == Line 748 has weird spacing: '...talPkts the c...' == (25 more instances...) -- The document date (March 4, 2018) is 2243 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 4149, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 4240, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 4248, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 4253, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 4262, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 4293, 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 (~~), 13 warnings (==), 4 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 5, 2018 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 March 4, 2018 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-06 15 Abstract 17 This memo defines the Initial Entries for the Performance Metrics 18 Registry. This version includes: 20 * Revised implementation of Passive TCP RTT metrics in section 10 21 (Adding HandShake metric). 23 * remaining question on DNS measurement method(s) 25 Still need: Add MBM metric entry. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 5, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Registry Categories and Columns . . . . . . . . . . . . . . . 8 70 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 9 71 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 10 73 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 10 76 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 10 77 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 10 78 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 11 79 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 11 80 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 12 81 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 12 82 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 13 83 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 14 84 4.3.3. Traffic Filtering (observation) Details . . . . . . . 14 85 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 15 86 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 15 87 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 16 91 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 17 92 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 17 93 4.5. Administrative items . . . . . . . . . . . . . . . . . . 18 94 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18 95 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 18 96 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 18 97 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 18 99 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 18 100 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 18 101 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 18 103 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 18 104 5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 19 105 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 19 106 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 19 107 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 19 108 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 19 109 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 19 110 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 20 111 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 21 112 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 21 113 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 22 114 5.3.3. Traffic Filtering (observation) Details . . . . . . . 22 115 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 23 116 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 23 117 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 23 118 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 23 119 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 24 120 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 24 121 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 24 122 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 25 123 5.5. Administrative items . . . . . . . . . . . . . . . . . . 25 124 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 25 125 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 26 126 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 26 127 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 26 128 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 26 129 6. DNS Response Latency and Loss Registry Entries . . . . . . . 26 130 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 131 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 27 132 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 27 133 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27 134 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 27 135 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 27 136 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 27 137 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 27 138 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 27 139 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 28 140 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 30 141 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 30 142 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 32 143 6.3.3. Traffic Filtering (observation) Details . . . . . . . 32 144 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 32 145 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 32 146 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 34 148 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34 149 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34 150 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 34 151 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 35 152 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 35 153 6.5. Administrative items . . . . . . . . . . . . . . . . . . 35 154 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 35 155 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 35 156 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 35 157 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 36 158 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 36 159 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 36 160 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36 161 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 36 162 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 36 163 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 37 164 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 37 165 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 37 166 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 38 167 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 38 168 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 39 169 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 40 170 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 40 171 7.3.3. Traffic Filtering (observation) Details . . . . . . . 41 172 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 41 173 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 41 174 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 42 175 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 42 176 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 42 177 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 42 178 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 45 179 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 45 180 7.5. Administrative items . . . . . . . . . . . . . . . . . . 46 181 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 46 182 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 46 183 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 46 184 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 47 185 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 47 186 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 47 187 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 47 188 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 47 189 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 47 190 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 48 191 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 48 192 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 48 193 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 49 194 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 49 195 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 50 196 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 51 197 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 51 198 8.3.3. Traffic Filtering (observation) Details . . . . . . . 52 199 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 52 200 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 52 201 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 53 202 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 53 203 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 204 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 53 205 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56 206 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56 207 8.5. Administrative items . . . . . . . . . . . . . . . . . . 57 208 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 57 209 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 57 210 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 57 211 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 58 212 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 58 213 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 58 214 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 58 215 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 58 216 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 58 217 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 59 218 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 59 219 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 59 220 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 59 221 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 59 222 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 59 223 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 60 224 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 61 225 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 61 226 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 62 227 9.3.3. Traffic Filtering (observation) Details . . . . . . . 63 228 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 63 229 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 63 230 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 64 231 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 64 232 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 64 233 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 64 234 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 66 235 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 67 236 9.5. Administrative items . . . . . . . . . . . . . . . . . . 67 237 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 67 238 9.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 67 239 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 67 240 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 67 241 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 67 242 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 68 243 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 68 244 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 68 245 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 68 246 10.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 69 247 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 69 248 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 69 249 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 69 250 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 69 251 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 69 252 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 72 253 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 73 254 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 73 255 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 74 256 10.3.3. Traffic Filtering (observation) Details . . . . . . 75 257 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 75 258 10.3.5. Run-time Parameters and Data Format . . . . . . . . 75 259 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 76 260 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 76 261 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 76 262 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 76 263 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 78 264 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 78 265 10.5. Administrative items . . . . . . . . . . . . . . . . . . 78 266 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 79 267 10.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . 79 268 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 79 269 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 79 270 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 79 271 11. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 79 272 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 79 273 11.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 79 274 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 79 275 11.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 79 276 11.1.4. Description . . . . . . . . . . . . . . . . . . . . 79 277 11.1.5. Reference . . . . . . . . . . . . . . . . . . . . . 80 278 11.1.6. Change Controller . . . . . . . . . . . . . . . . . 80 279 11.1.7. Version (of Registry Format) . . . . . . . . . . . . 80 280 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 80 281 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 80 282 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 80 283 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 80 284 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 80 285 11.3.2. Packet Stream Generation . . . . . . . . . . . . . . 80 286 11.3.3. Traffic Filtering (observation) Details . . . . . . 81 287 11.3.4. Sampling Distribution . . . . . . . . . . . . . . . 81 288 11.3.5. Run-time Parameters and Data Format . . . . . . . . 81 289 11.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 81 290 11.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 81 291 11.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 81 292 11.4.2. Reference Definition . . . . . . . . . . . . . . . . 81 293 11.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 81 294 11.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 81 295 11.5. Administrative items . . . . . . . . . . . . . . . . . . 82 296 11.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 82 297 11.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 82 298 11.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 82 299 11.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 82 300 11.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 82 301 12. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 82 302 12.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 82 303 12.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 82 304 12.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 82 305 12.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 83 306 12.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 83 307 12.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 83 308 12.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 83 309 12.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 83 310 12.1.8. Description . . . . . . . . . . . . . . . . . . . . 83 311 12.1.9. Reference Specification(s) . . . . . . . . . . . . . 83 312 12.2. Metric Definition . . . . . . . . . . . . . . . . . . . 83 313 12.2.1. Reference Definition . . . . . . . . . . . . . . . . 83 314 12.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 84 315 12.3. Method of Measurement . . . . . . . . . . . . . . . . . 84 316 12.3.1. Reference Method . . . . . . . . . . . . . . . . . . 84 317 12.3.2. Stream Type and Stream Parameters . . . . . . . . . 85 318 12.3.3. Output Type and Data Format . . . . . . . . . . . . 85 319 12.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 85 320 12.3.5. Run-time Parameters and Data Format . . . . . . . . 85 321 12.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 87 322 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 87 323 14. Security Considerations . . . . . . . . . . . . . . . . . . . 88 324 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 325 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88 326 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 327 17.1. Normative References . . . . . . . . . . . . . . . . . . 88 328 17.2. Informative References . . . . . . . . . . . . . . . . . 91 329 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 331 1. Introduction 333 Note: Efforts to synchronize structure and terminology with 334 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 335 drafts are stable. 337 This memo proposes an initial set of entries for the Performance 338 Metric Registry. It uses terms and definitions from the IPPM 339 literature, primarily [RFC2330]. 341 Although there are several standard templates for organizing 342 specifications of performance metrics (see [RFC2679] for an example 343 of the traditional IPPM template, based to large extent on the 344 Benchmarking Methodology Working Group's traditional template in 345 [RFC1242], and see [RFC6390] for a similar template), none of these 346 templates were intended to become the basis for the columns of an 347 IETF-wide registry of metrics. While examinating aspects of metric 348 specifications which need to be registered, it became clear that none 349 of the existing metric templates fully satisfies the particular needs 350 of a registry. 352 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 353 for a Performance Metric Registry. Section 5 of 354 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 355 requesting registration of a Metric, that is the creation of entry(s) 356 in the Performance Metric Registry: "In essence, there needs to be 357 evidence that a candidate Registered Performance Metric has 358 significant industry interest, or has seen deployment, and there is 359 agreement that the candidate Registered Performance Metric serves its 360 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 361 also requires that new entries are administered by IANA through 362 Expert Review, which will ensure that the metrics are tightly 363 defined. 365 2. Scope 367 This document defines the initial set of Performance Metrics Registry 368 entries, for which IETF approval (following development in the IP 369 Performance Metrics (IPPM) Working Group) will satisfy the 370 requirement for Expert Review. Most are Active Performance Metrics, 371 which are based on RFCs prepared in the IPPM working group of the 372 IETF, according to their framework [RFC2330] and its updates. 374 3. Registry Categories and Columns 376 This section provides the categories and columns of the registry, for 377 easy reference. An entry (row) therefore gives a complete 378 description of a Registered Metric. 380 Registry Categories and Columns, shown as 381 Category 382 ------------------ 383 Column | Column | 385 Summary 386 ------------------------------------------------------------------------ 387 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 389 Metric Definition 390 ----------------------------------------- 391 Reference Definition | Fixed Parameters | 393 Method of Measurement 394 --------------------------------------------------------------------- 395 Reference | Packet | Traffic | Sampling | Run-time | Role | 396 Method | Stream | Filter | Distribution | Parameters | | 397 | Generation | 398 Output 399 ----------------------------------------- 400 Type | Reference | Units | Calibration | 401 | Definition | | | 403 Administrative Information 404 ---------------------------------- 405 Status |Request | Rev | Rev.Date | 407 Comments and Remarks 408 -------------------- 410 4. UDP Round-trip Latency and Loss Registry Entries 412 This section specifies an initial registry entry for the UDP Round- 413 trip Latency, and another entry for UDP Round-trip Loss Ratio. 415 Note: Each Registry entry only produces a "raw" output or a 416 statistical summary. To describe both "raw" and one or more 417 statistics efficiently, the Identifier, Name, and Output Categories 418 can be split and a single section can specify two or more closely- 419 related metrics. This section specifies two Registry entries with 420 many common columns. See Section 7 for an example specifying 421 multiple Registry entries with many common columns. 423 All column entries beside the ID, Name, Description, and Output 424 Reference Method categories are the same, thus this section proposes 425 two closely-related registry entries. As a result, IANA is also 426 asked to assign corresponding URNs and URLs to each Named Metric. 428 4.1. Summary 430 This category includes multiple indexes to the registry entry: the 431 element ID and metric name. 433 4.1.1. ID (Identifier) 435 437 IANA is asked to assign different numeric identifiers to each of the 438 two Named Metrics. 440 4.1.2. Name 442 444 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 446 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio 448 4.1.3. URIs 450 URN: Prefix urn:ietf:metrics:perf: 452 URL: http:/// 454 4.1.4. Description 456 RTDelay: This metric assesses the delay of a stream of packets 457 exchanged between two hosts (which are the two measurement points), 458 and the Output is the Round-trip delay for all successfully exchanged 459 packets expressed as the 95th percentile of their conditional delay 460 distribution. 462 RTLoss: This metric assesses the loss ratio of a stream of packets 463 exchanged between two hosts (which are the two measurement points), 464 and the Output is the Round-trip loss ratio for all successfully 465 exchanged packets expressed as a percentage. 467 4.1.5. Change Controller 469 IETF 471 4.1.6. Version (of Registry Format) 473 1.0 475 4.2. Metric Definition 477 This category includes columns to prompt the entry of all necessary 478 details related to the metric definition, including the RFC reference 479 and values of input factors, called fixed parameters. 481 4.2.1. Reference Definition 483 485 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 486 Metric for IPPM", RFC 2681, September 1999. 488 [RFC2681] 490 492 Section 2.4 of [RFC2681] provides the reference definition of the 493 singleton (single value) Round-trip delay metric. Section 3.4 of 494 [RFC2681] provides the reference definition expanded to cover a 495 multi-singleton sample. Note that terms such as singleton and sample 496 are defined in Section 11 of [RFC2330]. 498 Note that although the [RFC2681] definition of "Round-trip-Delay 499 between Src and Dst" is directionally ambiguous in the text, this 500 metric tightens the definition further to recognize that the host in 501 the "Src" role will send the first packet to "Dst", and ultimately 502 receive the corresponding return packet from "Dst" (when neither are 503 lost). 505 Finally, note that the variable "dT" is used in [RFC2681] to refer to 506 the value of Round-trip delay in metric definitions and methods. The 507 variable "dT" has been re-used in other IPPM literature to refer to 508 different quantities, and cannot be used as a global variable name. 510 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 512 [RFC6673] 514 Both delay and loss metrics employ a maximum waiting time for 515 received packets, so the count of lost packets to total packets sent 516 is the basis for the loss ratio calculation as per Section 6.1 of 517 [RFC6673]. 519 4.2.2. Fixed Parameters 521 525 Type-P as defined in Section 13 of [RFC2330]: 527 o IPv4 header values: 529 * DSCP: set to 0 531 * TTL: set to 255 533 * Protocol: Set to 17 (UDP) 535 o IPv6 header values: 537 * DSCP: set to 0 539 * Hop Count: set to 255 541 * Protocol: Set to 17 (UDP) 543 o UDP header values: 545 * Checksum: the checksum MUST be calculated and included in the 546 header 548 o UDP Payload 550 * total of 100 bytes 552 Other measurement parameters: 554 o Tmax: a loss threshold waiting time 556 * 3.0, expressed in units of seconds, as a positive value of type 557 decimal64 with fraction digits = 4 (see section 9.3 of 558 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 559 lossless conversion to/from the 32-bit NTP timestamp as per 560 section 6 of [RFC5905]. 562 4.3. Method of Measurement 564 This category includes columns for references to relevant sections of 565 the RFC(s) and any supplemental information needed to ensure an 566 unambiguous methods for implementations. 568 4.3.1. Reference Method 570 573 The methodology for this metric is defined as Type-P-Round-trip- 574 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 575 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 576 Fixed Parameters. However, the Periodic stream will be generated 577 according to [RFC3432]. 579 The reference method distinguishes between long-delayed packets and 580 lost packets by implementing a maximum waiting time for packet 581 arrival. Tmax is the waiting time used as the threshold to declare a 582 packet lost. Lost packets SHALL be designated as having undefined 583 delay, and counted for the RTLoss metric. 585 The calculations on the delay (RTT) SHALL be performed on the 586 conditional distribution, conditioned on successful packet arrival 587 within Tmax. Also, when all packet delays are stored, the process 588 which calculates the RTT value MAY enforce the Tmax threshold on 589 stored values before calculations. See section 4.1 of [RFC3393] for 590 details on the conditional distribution to exclude undefined values 591 of delay, and Section 5 of [RFC6703] for background on this analysis 592 choice. 594 The reference method requires some way to distinguish between 595 different packets in a stream to establish correspondence between 596 sending times and receiving times for each successfully-arriving 597 packet. Sequence numbers or other send-order identification MUST be 598 retained at the Src or included with each packet to disambiguate 599 packet reordering if it occurs. 601 If a standard measurement protocol is employed, then the measurement 602 process will determine the sequence numbers or timestamps applied to 603 test packets after the Fixed and Runtime parameters are passed to 604 that process. The chosen measurement protocol will dictate the 605 format of sequence numbers and time-stamps, if they are conveyed in 606 the packet payload. 608 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 609 instruction to "send a Type-P packet back to the Src as quickly as 610 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 611 [RFC6673] presents additional requirements which MUST be included in 612 the method of measurement for this metric. 614 4.3.2. Packet Stream Generation 616 618 This section gives the details of the packet traffic which is the 619 basis for measurement. In IPPM metrics, this is called the Stream, 620 and can easily be described by providing the list of stream 621 parameters. 623 Section 3 of [RFC3432] prescribes the method for generating Periodic 624 streams using associated parameters. 626 incT the nominal duration of inter-packet interval, first bit to 627 first bit, with value 0.0200, expressed in units of seconds, as a 628 positive value of type decimal64 with fraction digits = 4 (see 629 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 630 (0.1 ms). 632 dT the duration of the interval for allowed sample start times, with 633 value 1.0, expressed in units of seconds, as a positive value of 634 type decimal64 with fraction digits = 4 (see section 9.3 of 635 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 637 T0 the actual start time of the periodic stream, (format "date-and- 638 time" as specified in Section 5.6 of [RFC3339], see also Section 3 639 of [RFC6991]). 641 NOTE: an initiation process with a number of control exchanges 642 resulting in unpredictable start times (within a time interval) may 643 be sufficient to avoid synchronization of periodic streams, and 644 therefore a valid replacement for selecting a start time at random 645 from a fixed interval. 647 The T0 parameter will be reported as a measured parameter. 648 Parameters incT and dT are Fixed Parameters. 650 4.3.3. Traffic Filtering (observation) Details 652 The measured results based on a filtered version of the packets 653 observed, and this section provides the filter details (when 654 present). 656
. 658 NA 660 4.3.4. Sampling Distribution 662 665 NA 667 4.3.5. Run-time Parameters and Data Format 669 Run-time Parameters are input factors that must be determined, 670 configured into the measurement system, and reported with the results 671 for the context to be complete. 673 675 Src the IP address of the host in the Src Role (format ipv4-address- 676 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 677 see Section 4 of [RFC6991]) 679 Dst the IP address of the host in the Dst Role (format ipv4-address- 680 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 681 see section 4 of [RFC6991]) 683 T0 a time, the start of a measurement interval, (format "date-and- 684 time" as specified in Section 5.6 of [RFC3339], see also Section 3 685 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 686 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 687 and Tf is to be interpreted as the Duration of the measurement 688 interval. The start time is controlled through other means. 690 Tf a time, the end of a measurement interval, (format "date-and-time" 691 as specified in Section 5.6 of [RFC3339], see also Section 3 of 692 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 693 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 694 Tf is interpreted as the Duration of the measurement interval. 696 4.3.6. Roles 698 700 Src launches each packet and waits for return transmissions from 701 Dst. 703 Dst waits for each packet from Src and sends a return packet to Src. 705 4.4. Output 707 This category specifies all details of the Output of measurements 708 using the metric. 710 4.4.1. Type 712 714 Percentile -- for the conditional distribution of all packets with a 715 valid value of Round-trip delay (undefined delays are excluded), a 716 single value corresponding to the 95th percentile, as follows: 718 See section 4.1 of [RFC3393] for details on the conditional 719 distribution to exclude undefined values of delay, and Section 5 of 720 [RFC6703] for background on this analysis choice. 722 The percentile = 95, meaning that the reported delay, "95Percentile", 723 is the smallest value of Round-trip delay for which the Empirical 724 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 725 Round-trip delay values in the conditional distribution. See section 726 11.3 of [RFC2330] for the definition of the percentile statistic 727 using the EDF. 729 LossRatio -- the count of lost packets to total packets sent is the 730 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 732 4.4.2. Reference Definition 734 736 For all outputs --- 738 T0 the start of a measurement interval, (format "date-and-time" as 739 specified in Section 5.6 of [RFC3339], see also Section 3 of 740 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 741 [RFC2330]. 743 Tf the end of a measurement interval, (format "date-and-time" as 744 specified in Section 5.6 of [RFC3339], see also Section 3 of 745 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 746 [RFC2330]. 748 TotalPkts the count of packets sent by the Src to Dst during the 749 measurement interval. 751 For 752 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile: 754 95Percentile The time value of the result is expressed in units of 755 seconds, as a positive value of type decimal64 with fraction 756 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 757 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 758 the 64-bit NTP timestamp as 760 For 762 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio: 764 Percentile The numeric value of the result is expressed in units of 765 lost packets to total packets times 100%, as a positive value of 766 type decimal64 with fraction digits = 9 (see section 9.3 of 767 [RFC6020]) with resolution of 0.0000000001. 769 4.4.3. Metric Units 771 . 774 The 95th Percentile of Round-trip Delay is expressed in seconds. 776 The Round-trip Loss Ratio is expressed as a percentage of lost 777 packets to total packets sent. 779 4.4.4. Calibration 781 Section 3.7.3 of [RFC7679] provides a means to quantify the 782 systematic and random errors of a time measurement. In-situ 783 calibration could be enabled with an internal loopback at the Source 784 host that includes as much of the measurement system as possible, 785 performs address manipulation as needed, and provides some form of 786 isolation (e.g., deterministic delay) to avoid send-receive interface 787 contention. Some portion of the random and systematic error can be 788 characterized this way. 790 When a measurement controller requests a calibration measurement, the 791 loopback is applied and the result is output in the same format as a 792 normal measurement with additional indication that it is a 793 calibration result. 795 Both internal loopback calibration and clock synchronization can be 796 used to estimate the *available accuracy* of the Output Metric Units. 797 For example, repeated loopback delay measurements will reveal the 798 portion of the Output result resolution which is the result of system 799 noise, and thus inaccurate. 801 4.5. Administrative items 803 4.5.1. Status 805 807 4.5.2. Requestor (keep?) 809 name or RFC, etc. 811 4.5.3. Revision 813 1.0 815 4.5.4. Revision Date 817 YYYY-MM-DD 819 4.6. Comments and Remarks 821 Additional (Informational) details for this entry 823 5. Packet Delay Variation Registry Entry 825 This section gives an initial registry entry for a Packet Delay 826 Variation metric. 828 Note: If each Registry entry should only produce a "raw" output or a 829 statistical summary, then the "Output" Category can be split and this 830 section can become two closely-related metrics. 832 5.1. Summary 834 This category includes multiple indexes to the registry entries, the 835 element ID and metric name. 837 839 5.1.1. ID (Identifier) 841 843 5.1.2. Name 845 847 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 849 5.1.3. URIs 851 URI: Prefix urn:ietf:metrics:perf: 853 URL: http:/// 855 5.1.4. Description 857 An assessment of packet delay variation with respect to the minimum 858 delay observed on the periodic stream, and the Output is expressed as 859 the 95th percentile of the packet delay variation distribution. 861 5.1.5. Change Controller 863 865 IETF 867 5.1.6. Version (of Registry Format) 869 1.0 871 5.2. Metric Definition 873 This category includes columns to prompt the entry of all necessary 874 details related to the metric definition, including the RFC reference 875 and values of input factors, called fixed parameters. 877 5.2.1. Reference Definition 879 881 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 882 Performance Metrics", RFC 2330, May 1998. [RFC2330] 884 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 885 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 886 [RFC3393] 888 Morton, A. and B. Claise, "Packet Delay Variation Applicability 889 Statement", RFC 5481, March 2009. [RFC5481] 891 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 892 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 893 June 2010.[RFC5905] 895 896 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 897 measured are referred to by the variable name "ddT" (applicable to 898 all forms of delay variation). However, this metric entry specifies 899 the PDV form defined in section 4.2 of [RFC5481], where the singleton 900 PDV for packet i is referred to by the variable name "PDV(i)". 902 5.2.2. Fixed Parameters 904 908 o IPv4 header values: 910 * DSCP: set to 0 912 * TTL: set to 255 914 * Protocol: Set to 17 (UDP) 916 o IPv6 header values: 918 * DSCP: set to 0 920 * Hop Count: set to 255 922 * Protocol: Set to 17 (UDP) 924 o UDP header values: 926 * Checksum: the checksum MUST be calculated and included in the 927 header 929 o UDP Payload 931 * total of 200 bytes 933 Other measurement parameters: 935 Tmax: a loss threshold waiting time with value 3.0, expressed in 936 units of seconds, as a positive value of type decimal64 with 937 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 938 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 939 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 941 F a selection function unambiguously defining the packets from the 942 stream selected for the metric. See section 4.2 of [RFC5481] for 943 the PDV form. 945 See the Packet Stream generation category for two additional Fixed 946 Parameters. 948 5.3. Method of Measurement 950 This category includes columns for references to relevant sections of 951 the RFC(s) and any supplemental information needed to ensure an 952 unambiguous methods for implementations. 954 5.3.1. Reference Method 956 959 See section 2.6 and 3.6 of [RFC3393] for general singleton element 960 calculations. This metric entry requires implementation of the PDV 961 form defined in section 4.2 of [RFC5481]. Also see measurement 962 considerations in section 8 of [RFC5481]. 964 The reference method distinguishes between long-delayed packets and 965 lost packets by implementing a maximum waiting time for packet 966 arrival. Tmax is the waiting time used as the threshold to declare a 967 packet lost. Lost packets SHALL be designated as having undefined 968 delay. 970 The calculations on the one-way delay SHALL be performed on the 971 conditional distribution, conditioned on successful packet arrival 972 within Tmax. Also, when all packet delays are stored, the process 973 which calculates the one-way delay value MAY enforce the Tmax 974 threshold on stored values before calculations. See section 4.1 of 975 [RFC3393] for details on the conditional distribution to exclude 976 undefined values of delay, and Section 5 of [RFC6703] for background 977 on this analysis choice. 979 The reference method requires some way to distinguish between 980 different packets in a stream to establish correspondence between 981 sending times and receiving times for each successfully-arriving 982 packet. Sequence numbers or other send-order identification MUST be 983 retained at the Src or included with each packet to disambiguate 984 packet reordering if it occurs. 986 If a standard measurement protocol is employed, then the measurement 987 process will determine the sequence numbers or timestamps applied to 988 test packets after the Fixed and Runtime parameters are passed to 989 that process. The chosen measurement protocol will dictate the 990 format of sequence numbers and time-stamps, if they are conveyed in 991 the packet payload. 993 5.3.2. Packet Stream Generation 995 997 This section gives the details of the packet traffic which is the 998 basis for measurement. In IPPM metrics, this is called the Stream, 999 and can easily be described by providing the list of stream 1000 parameters. 1002 Section 3 of [RFC3432] prescribes the method for generating Periodic 1003 streams using associated parameters. 1005 incT the nominal duration of inter-packet interval, first bit to 1006 first bit, with value 0.0200, expressed in units of seconds, as a 1007 positive value of type decimal64 with fraction digits = 4 (see 1008 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 1009 (0.1 ms). 1011 dT the duration of the interval for allowed sample start times, with 1012 value 1.0, expressed in units of seconds, as a positive value of 1013 type decimal64 with fraction digits = 4 (see section 9.3 of 1014 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 1016 T0 the actual start time of the periodic stream, (format "date-and- 1017 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1018 of [RFC6991]). 1020 NOTE: an initiation process with a number of control exchanges 1021 resulting in unpredictable start times (within a time interval) may 1022 be sufficient to avoid synchronization of periodic streams, and 1023 therefore a valid replacement for selecting a start time at random 1024 from a fixed interval. 1026 The T0 parameter will be reported as a measured parameter. 1027 Parameters incT and dT are Fixed Parameters. 1029 5.3.3. Traffic Filtering (observation) Details 1031 . 1035 NA 1037 5.3.4. Sampling Distribution 1039 1042 NA 1044 5.3.5. Run-time Parameters and Data Format 1046 1048 Src the IP address of the host in the Src Role (format ipv4-address- 1049 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1050 see Section 4 of [RFC6991]) 1052 Dst the IP address of the host in the Dst Role (format ipv4-address- 1053 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1054 see section 4 of [RFC6991]) 1056 T0 a time, the start of a measurement interval, (format "date-and- 1057 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1058 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1059 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1060 and Tf is to be interpreted as the Duration of the measurement 1061 interval. The start time is controlled through other means. 1063 Tf a time, the end of a measurement interval, (format "date-and-time" 1064 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1065 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1066 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1067 Tf is interpreted as the Duration of the measurement interval. 1069 5.3.6. Roles 1071 1073 Src launches each packet to Dst. 1075 Dst waits for each packet from Src. 1077 5.4. Output 1079 This category specifies all details of the Output of measurements 1080 using the metric. 1082 5.4.1. Type 1084 1086 Percentile -- for the conditional distribution of all packets with a 1087 valid value of one-way delay (undefined delays are excluded), a 1088 single value corresponding to the 95th percentile, as follows: 1090 See section 4.1 of [RFC3393] for details on the conditional 1091 distribution to exclude undefined values of delay, and Section 5 of 1092 [RFC6703] for background on this analysis choice. 1094 The percentile = 95, meaning that the reported delay, "95Percentile", 1095 is the smallest value of one-way PDV for which the Empirical 1096 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1097 one-way PDV values in the conditional distribution. See section 11.3 1098 of [RFC2330] for the definition of the percentile statistic using the 1099 EDF. 1101 5.4.2. Reference Definition 1103 1105 T0 the start of a measurement interval, (format "date-and-time" as 1106 specified in Section 5.6 of [RFC3339], see also Section 3 of 1107 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1108 [RFC2330]. 1110 Tf the end of a measurement interval, (format "date-and-time" as 1111 specified in Section 5.6 of [RFC3339], see also Section 3 of 1112 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1113 [RFC2330]. 1115 95Percentile The time value of the result is expressed in units of 1116 seconds, as a positive value of type decimal64 with fraction 1117 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1118 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1119 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1121 5.4.3. Metric Units 1123 . 1126 The 95th Percentile of one-way PDV is expressed in seconds. 1128 5.4.4. Calibration 1130 Section 3.7.3 of [RFC7679] provides a means to quantify the 1131 systematic and random errors of a time measurement. In-situ 1132 calibration could be enabled with an internal loopback that includes 1133 as much of the measurement system as possible, performs address 1134 manipulation as needed, and provides some form of isolation (e.g., 1135 deterministic delay) to avoid send-receive interface contention. 1136 Some portion of the random and systematic error can be characterized 1137 this way. 1139 For one-way delay measurements, the error calibration must include an 1140 assessment of the internal clock synchronization with its external 1141 reference (this internal clock is supplying timestamps for 1142 measurement). In practice, the time offsets of clocks at both the 1143 source and destination are needed to estimate the systematic error 1144 due to imperfect clock synchronization (the time offsets are 1145 smoothed, thus the random variation is not usually represented in the 1146 results). 1148 time_offset The time value of the result is expressed in units of 1149 seconds, as a signed value of type decimal64 with fraction digits 1150 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1151 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1152 NTP timestamp as per section 6 of RFC [RFC5905] 1154 When a measurement controller requests a calibration measurement, the 1155 loopback is applied and the result is output in the same format as a 1156 normal measurement with additional indication that it is a 1157 calibration result. In any measurement, the measurement function 1158 SHOULD report its current estimate of time offset as an indicator of 1159 the degree of synchronization. 1161 Both internal loopback calibration and clock synchronization can be 1162 used to estimate the *available accuracy* of the Output Metric Units. 1163 For example, repeated loopback delay measurements will reveal the 1164 portion of the Output result resolution which is the result of system 1165 noise, and thus inaccurate. 1167 5.5. Administrative items 1169 5.5.1. Status 1171 1173 5.5.2. Requestor (keep?) 1175 1177 5.5.3. Revision 1179 1.0 1181 5.5.4. Revision Date 1183 YYYY-MM-DD 1185 5.6. Comments and Remarks 1187 1189 Lost packets represent a challenge for delay variation metrics. See 1190 section 4.1 of [RFC3393] and the delay variation applicability 1191 statement[RFC5481] for extensive analysis and comparison of PDV and 1192 an alternate metric, IPDV. 1194 6. DNS Response Latency and Loss Registry Entries 1196 @@@@ comment from Brian: there is an interesting method for DNS 1197 measurement by encoding information in the query itself. It is a 1198 question of what exactly we are trying to measure: specific RR, or 1199 the infrastructure itself. (at this time we measure a specific RR). 1201 This section gives initial registry entries for DNS Response Latency 1202 and Loss. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1203 build on that metric by specifying several of the input parameters to 1204 precisely define two metrics for measuring DNS latency and loss. 1206 Note to IANA: Each Registry "Name" below specifies a single registry 1207 entry, whose output format varies in accordance with the name. 1209 All column entries beside the ID, Name, Description, and Output 1210 Reference Method categories are the same, thus this section proposes 1211 two closely-related registry entries. As a result, IANA is also 1212 asked to assign corresponding URNs and URLs to each Named Metric. 1214 6.1. Summary 1216 This category includes multiple indexes to the registry entries, the 1217 element ID and metric name. 1219 1221 6.1.1. ID (Identifier) 1223 1225 IANA is asked to assign different numeric identifiers to each of the 1226 two Named Metrics. 1228 6.1.2. Name 1230 1232 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1234 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw 1236 6.1.3. URI 1238 URI: Prefix urn:ietf:metrics:perf: 1240 URL: http:/// 1242 6.1.4. Description 1244 RTDNS: This metric assesses the response time, the interval from the 1245 query transmission to the response. 1247 RLDNS: This metric indicates that the response was deemed lost. In 1248 other words, the response time exceeded the maximum waiting time. 1250 6.1.5. Change Controller 1252 IETF 1254 6.1.6. Version (of Registry Format) 1256 1.0 1258 6.2. Metric Definition 1260 This category includes columns to prompt the entry of all necessary 1261 details related to the metric definition, including the RFC reference 1262 and values of input factors, called fixed parameters. 1264 6.2.1. Reference Definition 1266 1267 Mockapetris, P., "Domain names - implementation and specification", 1268 STD 13, RFC 1035, November 1987. (and updates) 1270 [RFC1035] 1272 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1273 Metric for IPPM", RFC 2681, September 1999. 1275 [RFC2681] 1277 1279 Section 2.4 of [RFC2681] provides the reference definition of the 1280 singleton (single value) Round-trip delay metric. Section 3.4 of 1281 [RFC2681] provides the reference definition expanded to cover a 1282 multi-singleton sample. Note that terms such as singleton and sample 1283 are defined in Section 11 of [RFC2330]. 1285 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1286 [RFC2681]. The Local Host with its User Program and Resolver take 1287 the role of "Src", and the Foreign Name Server takes the role of 1288 "Dst". 1290 Note that although the [RFC2681] definition of "Round-trip-Delay 1291 between Src and Dst at T" is directionally ambiguous in the text, 1292 this metric tightens the definition further to recognize that the 1293 host in the "Src" role will send the first packet to "Dst", and 1294 ultimately receive the corresponding return packet from "Dst" (when 1295 neither are lost). 1297 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1299 [RFC6673] 1301 Both response time and loss metrics employ a maximum waiting time for 1302 received responses, so the count of lost packets to total packets 1303 sent is the basis for the loss determination as per Section 4.3 of 1304 [RFC6673]. 1306 6.2.2. Fixed Parameters 1308 1312 Type-P as defined in Section 13 of [RFC2330]: 1314 o IPv4 header values: 1316 * DSCP: set to 0 1318 * TTL set to 255 1320 * Protocol: Set to 17 (UDP) 1322 o IPv6 header values: 1324 * DSCP: set to 0 1326 * Hop Count: set to 255 1328 * Protocol: Set to 17 (UDP) 1330 o UDP header values: 1332 * Source port: 53 1334 * Destination port: 53 1336 * Checksum: the checksum must be calculated and included in the 1337 header 1339 o Payload: The payload contains a DNS message as defined in RFC 1035 1340 [RFC1035] with the following values: 1342 * The DNS header section contains: 1344 + Identification (see the Run-time column) 1346 + QR: set to 0 (Query) 1348 + OPCODE: set to 0 (standard query) 1350 + AA: not set 1352 + TC: not set 1354 + RD: set to one (recursion desired) 1356 + RA: not set 1358 + RCODE: not set 1360 + QDCOUNT: set to one (only one entry) 1362 + ANCOUNT: not set 1363 + NSCOUNT: not set 1365 + ARCOUNT: not set 1367 * The Question section contains: 1369 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1370 input for the test, see the Run-time column 1372 + QTYPE: the query type provided as input for the test, see 1373 the Run-time column 1375 + QCLASS: set to 1 for IN 1377 * The other sections do not contain any Resource Records. 1379 Other measurement parameters: 1381 o Tmax: a loss threshold waiting time (and to help disambiguate 1382 queries) 1384 * 5.0, expressed in units of seconds, as a positive value of type 1385 decimal64 with fraction digits = 4 (see section 9.3 of 1386 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1387 lossless conversion to/from the 32-bit NTP timestamp as per 1388 section 6 of [RFC5905]. 1390 Observation: reply packets will contain a DNS response and may 1391 contain RRs. 1393 6.3. Method of Measurement 1395 This category includes columns for references to relevant sections of 1396 the RFC(s) and any supplemental information needed to ensure an 1397 unambiguous methods for implementations. 1399 6.3.1. Reference Method 1401 1404 The methodology for this metric is defined as Type-P-Round-trip- 1405 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1406 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1407 Fixed Parameters. 1409 The reference method distinguishes between long-delayed packets and 1410 lost packets by implementing a maximum waiting time for packet 1411 arrival. Tmax is the waiting time used as the threshold to declare a 1412 packet lost. Lost packets SHALL be designated as having undefined 1413 delay, and counted for the RLDNS metric. 1415 The calculations on the delay (RTT) SHALL be performed on the 1416 conditional distribution, conditioned on successful packet arrival 1417 within Tmax. Also, when all packet delays are stored, the process 1418 which calculates the RTT value MAY enforce the Tmax threshold on 1419 stored values before calculations. See section 4.1 of [RFC3393] for 1420 details on the conditional distribution to exclude undefined values 1421 of delay, and Section 5 of [RFC6703] for background on this analysis 1422 choice. 1424 The reference method requires some way to distinguish between 1425 different packets in a stream to establish correspondence between 1426 sending times and receiving times for each successfully-arriving 1427 reply. Therefore, sequence numbers or other send-order 1428 identification MUST be retained at the Src or included with each 1429 packet to disambiguate packet reordering if it occurs. Sequence 1430 number is part of the payload described under Fixed Parameters. 1432 DNS Messages bearing Queries provide for random ID Numbers in the 1433 Identification header field, so more than one query may be launched 1434 while a previous request is outstanding when the ID Number is used. 1436 IF a DNS response does not arrive within Tmax, the response time is 1437 undefined, and RTDNS = 1. The Message ID SHALL be used to 1438 disambiguate the successive queries. 1440 @@@@ This would require support of ID generation and population in 1441 the Message. An alternative would be to use a random Source port on 1442 the Query Message, but we would choose ONE before proceeding. 1444 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1445 instruction to "send a Type-P packet back to the Src as quickly as 1446 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1447 [RFC6673] presents additional requirements which shall be included in 1448 the method of measurement for this metric. 1450 In addition to operations described in [RFC2681], the Src MUST parse 1451 the DNS headers of the reply and prepare the information for 1452 subsequent reporting as a measured result, along with the Round-Trip 1453 Delay. 1455 6.3.2. Packet Stream Generation 1457 This section gives the details of the packet traffic which is the 1458 basis for measurement. In IPPM metrics, this is called the Stream, 1459 and can easily be described by providing the list of stream 1460 parameters. 1462 1464 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1465 generate Poisson sampling intervals. The reciprocal of lambda is the 1466 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1467 = 1/lambda, in seconds. 1469 Method 3 is used, where given a start time (Run-time Parameter), the 1470 subsequent send times are all computed prior to measurement by 1471 computing the pseudo-random distribution of inter-packet send times, 1472 (truncating the distribution as specified in the Run-time 1473 Parameters), and the Src sends each packet at the computed times. 1475 Note that Trunc is the upper limit on inter-packet times in the 1476 Poisson distribution. A random value greater than Trunc is set equal 1477 to Trunc instead. 1479 6.3.3. Traffic Filtering (observation) Details 1481 The measured results based on a filtered version of the packets 1482 observed, and this section provides the filter details (when 1483 present). 1485
. 1487 NA 1489 6.3.4. Sampling Distribution 1491 1494 NA 1496 6.3.5. Run-time Parameters and Data Format 1498 Run-time Parameters are input factors that must be determined, 1499 configured into the measurement system, and reported with the results 1500 for the context to be complete. 1502 1503 Src the IP address of the host in the Src Role (format ipv4-address- 1504 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1505 see Section 4 of [RFC6991]) 1507 Dst the IP address of the host in the Dst Role (format ipv4-address- 1508 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1509 see section 4 of [RFC6991]) 1511 T0 a time, the start of a measurement interval, (format "date-and- 1512 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1513 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1514 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1515 and Tf is to be interpreted as the Duration of the measurement 1516 interval. The start time is controlled through other means. 1518 Tf a time, the end of a measurement interval, (format "date-and-time" 1519 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1520 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1521 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1522 Tf is interpreted as the Duration of the measurement interval. 1524 Reciprocal_lambda average packet interval for Poisson Streams 1525 expressed in units of seconds, as a positive value of type 1526 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1527 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1528 conversion to/from the 32-bit NTP timestamp as per section 6 of 1529 [RFC5905]. 1531 Trunc Upper limit on Poisson distribution expressed in units of 1532 seconds, as a positive value of type decimal64 with fraction 1533 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1534 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1535 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1536 this limit will be clipped and set to the limit value). (if fixed, 1537 Trunc = 30.0000 seconds.) 1539 ID The 16-bit identifier assigned by the program that generates the 1540 query, and which must vary in successive queries, see 1541 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1542 corresponding reply and can be used by the requester (Src) to 1543 match-up replies to outstanding queries. 1545 QNAME The domain name of the Query, formatted as specified in 1546 section 4 of [RFC6991]. 1548 QTYPE The Query Type, which will correspond to the IP address family 1549 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1550 uint16, as per section 9.2 of [RFC6020]. 1552 6.3.6. Roles 1554 1556 Src launches each packet and waits for return transmissions from 1557 Dst. 1559 Dst waits for each packet from Src and sends a return packet to Src. 1561 6.4. Output 1563 This category specifies all details of the Output of measurements 1564 using the metric. 1566 6.4.1. Type 1568 1570 Raw -- for each DNS Query packet sent, sets of values as defined in 1571 the next column, including the status of the response, only assigning 1572 delay values to successful query-response pairs. 1574 6.4.2. Reference Definition 1576 1578 For all outputs: 1580 T the time the DNS Query was sent during the measurement interval, 1581 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1582 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1583 by Section 6.1 of [RFC2330]. 1585 dT The time value of the round-trip delay to receive the DNS 1586 response, expressed in units of seconds, as a positive value of 1587 type decimal64 with fraction digits = 9 (see section 9.3 of 1588 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1589 with lossless conversion to/from the 64-bit NTP timestamp as per 1590 section 6 of RFC [RFC5905]. This value is undefined when the 1591 response packet is not received at Src within waiting time Tmax 1592 seconds. 1594 Rcode The value of the Rcode field in the DNS response header, 1595 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1596 Non-zero values convey errors in the response, and such replies 1597 must be analyzed separately from successful requests. 1599 6.4.3. Metric Units 1601 . 1604 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1606 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1608 6.4.4. Calibration 1610 Section 3.7.3 of [RFC7679] provides a means to quantify the 1611 systematic and random errors of a time measurement. In-situ 1612 calibration could be enabled with an internal loopback at the Source 1613 host that includes as much of the measurement system as possible, 1614 performs address and payload manipulation as needed, and provides 1615 some form of isolation (e.g., deterministic delay) to avoid send- 1616 receive interface contention. Some portion of the random and 1617 systematic error can be characterized this way. 1619 When a measurement controller requests a calibration measurement, the 1620 loopback is applied and the result is output in the same format as a 1621 normal measurement with additional indication that it is a 1622 calibration result. 1624 Both internal loopback calibration and clock synchronization can be 1625 used to estimate the *available accuracy* of the Output Metric Units. 1626 For example, repeated loopback delay measurements will reveal the 1627 portion of the Output result resolution which is the result of system 1628 noise, and thus inaccurate. 1630 6.5. Administrative items 1632 6.5.1. Status 1634 1636 6.5.2. Requestor 1638 name or RFC, etc. 1640 6.5.3. Revision 1642 1.0 1644 6.5.4. Revision Date 1646 YYYY-MM-DD 1648 6.6. Comments and Remarks 1650 Additional (Informational) details for this entry 1652 7. UDP Poisson One-way Delay and Loss Registry Entries 1654 This section specifies five initial registry entries for the UDP 1655 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1657 IANA Note: Registry "Name" below specifies a single registry entry, 1658 whose output format varies according to the element of 1659 the name that specifies one form of statistical summary. There is an 1660 additional metric name for the Loss metric. 1662 All column entries beside the ID, Name, Description, and Output 1663 Reference Method categories are the same, thus this section proposes 1664 six closely-related registry entries. As a result, IANA is also 1665 asked to assign corresponding URNs and URLs to each Named Metric. 1667 7.1. Summary 1669 This category includes multiple indexes to the registry entries, the 1670 element ID and metric name. 1672 7.1.1. ID (Identifier) 1674 1677 IANA is asked to assign different numeric identifiers to each of the 1678 six Metrics. 1680 7.1.2. Name 1682 1684 OWDelay_Active_IP-UDP-Poisson- 1685 Payload250B_RFCXXXXsecY_Seconds_ 1687 where is one of: 1689 o 95Percentile 1691 o Mean 1692 o Min 1694 o Max 1696 o StdDev 1698 OWLoss_Active_IP-UDP-Poisson- 1699 Payload250B_RFCXXXXsecY_Percent_LossRatio 1701 7.1.3. URI and URL 1703 URI: Prefix urn:ietf:metrics:perf: 1705 URL: http:\\www.iana.org\ ... 1707 7.1.4. Description 1709 OWDelay: This metric assesses the delay of a stream of packets 1710 exchanged between two hosts (or measurement points), and reports the 1711 One-way delay for all successfully exchanged packets 1712 based on their conditional delay distribution. 1714 where is one of: 1716 o 95Percentile 1718 o Mean 1720 o Min 1722 o Max 1724 o StdDev 1726 OWLoss: This metric assesses the loss ratio of a stream of packets 1727 exchanged between two hosts (which are the two measurement points), 1728 and the Output is the One-way loss ratio for all successfully 1729 received packets expressed as a percentage. 1731 7.2. Metric Definition 1733 This category includes columns to prompt the entry of all necessary 1734 details related to the metric definition, including the RFC reference 1735 and values of input factors, called fixed parameters. 1737 7.2.1. Reference Definition 1739 1741 For Delay: 1743 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1744 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1745 7679, DOI 10.17487/RFC7679, January 2016, . 1748 [RFC7679] 1750 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1751 6049, January 2011. 1753 [RFC6049] 1755 1757 Section 3.4 of [RFC7679] provides the reference definition of the 1758 singleton (single value) One-way delay metric. Section 4.4 of 1759 [RFC7679] provides the reference definition expanded to cover a 1760 multi-value sample. Note that terms such as singleton and sample are 1761 defined in Section 11 of [RFC2330]. 1763 Only successful packet transfers with finite delay are included in 1764 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1766 For loss: 1768 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1769 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1770 10.17487/RFC7680, January 2016, . 1773 Section 2.4 of [RFC7680] provides the reference definition of the 1774 singleton (single value) one-way loss metric. Section 3.4 of 1775 [RFC7680] provides the reference definition expanded to cover a 1776 multi-singleton sample. Note that terms such as singleton and sample 1777 are defined in Section 11 of [RFC2330]. 1779 7.2.2. Fixed Parameters 1781 1784 Type-P: 1786 o IPv4 header values: 1788 * DSCP: set to 0 1790 * TTL: set to 255 1792 * Protocol: Set to 17 (UDP) 1794 o IPv6 header values: 1796 * DSCP: set to 0 1798 * Hop Count: set to 255 1800 * Protocol: Set to 17 (UDP) 1802 o UDP header values: 1804 * Checksum: the checksum MUST be calculated and included in the 1805 header 1807 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1809 * Security features in use influence the number of Padding 1810 octets. 1812 * 250 octets total, including the TWAMP format 1814 Other measurement parameters: 1816 Tmax: a loss threshold waiting time with value 3.0, expressed in 1817 units of seconds, as a positive value of type decimal64 with 1818 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1819 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1820 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1822 See the Packet Stream generation category for two additional Fixed 1823 Parameters. 1825 7.3. Method of Measurement 1827 This category includes columns for references to relevant sections of 1828 the RFC(s) and any supplemental information needed to ensure an 1829 unambiguous methods for implementations. 1831 7.3.1. Reference Method 1833 1836 The methodology for this metric is defined as Type-P-One-way-Delay- 1837 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1838 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1840 The reference method distinguishes between long-delayed packets and 1841 lost packets by implementing a maximum waiting time for packet 1842 arrival. Tmax is the waiting time used as the threshold to declare a 1843 packet lost. Lost packets SHALL be designated as having undefined 1844 delay, and counted for the OWLoss metric. 1846 The calculations on the one-way delay SHALL be performed on the 1847 conditional distribution, conditioned on successful packet arrival 1848 within Tmax. Also, when all packet delays are stored, the process 1849 which calculates the one-way delay value MAY enforce the Tmax 1850 threshold on stored values before calculations. See section 4.1 of 1851 [RFC3393] for details on the conditional distribution to exclude 1852 undefined values of delay, and Section 5 of [RFC6703] for background 1853 on this analysis choice. 1855 The reference method requires some way to distinguish between 1856 different packets in a stream to establish correspondence between 1857 sending times and receiving times for each successfully-arriving 1858 packet. Sequence numbers or other send-order identification MUST be 1859 retained at the Src or included with each packet to disambiguate 1860 packet reordering if it occurs. 1862 Since a standard measurement protocol is employed [RFC5357], then the 1863 measurement process will determine the sequence numbers or timestamps 1864 applied to test packets after the Fixed and Runtime parameters are 1865 passed to that process. The measurement protocol dictates the format 1866 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1867 payload. 1869 7.3.2. Packet Stream Generation 1871 This section gives the details of the packet traffic which is the 1872 basis for measurement. In IPPM metrics, this is called the Stream, 1873 and can easily be described by providing the list of stream 1874 parameters. 1876 1877 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1878 generate Poisson sampling intervals. The reciprocal of lambda is the 1879 average packet spacing, thus the Run-time Parameter is 1880 Reciprocal_lambda = 1/lambda, in seconds. 1882 Method 3 SHALL be used, where given a start time (Run-time 1883 Parameter), the subsequent send times are all computed prior to 1884 measurement by computing the pseudo-random distribution of inter- 1885 packet send times, (truncating the distribution as specified in the 1886 Parameter Trunc), and the Src sends each packet at the computed 1887 times. 1889 Note that Trunc is the upper limit on inter-packet times in the 1890 Poisson distribution. A random value greater than Trunc is set equal 1891 to Trunc instead. 1893 Reciprocal_lambda average packet interval for Poisson Streams 1894 expressed in units of seconds, as a positive value of type 1895 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1896 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1897 conversion to/from the 32-bit NTP timestamp as per section 6 of 1898 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1900 Trunc Upper limit on Poisson distribution expressed in units of 1901 seconds, as a positive value of type decimal64 with fraction 1902 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1903 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1904 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1905 this limit will be clipped and set to the limit value). Trunc = 1906 30.0000 seconds. 1908 7.3.3. Traffic Filtering (observation) Details 1910 NA 1912 7.3.4. Sampling Distribution 1914 NA 1916 7.3.5. Run-time Parameters and Data Format 1918 Run-time Parameters are input factors that must be determined, 1919 configured into the measurement system, and reported with the results 1920 for the context to be complete. 1922 1923 Src the IP address of the host in the Src Role (format ipv4-address- 1924 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1925 see Section 4 of [RFC6991]) 1927 Dst the IP address of the host in the Dst Role (format ipv4-address- 1928 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1929 see section 4 of [RFC6991]) 1931 T0 a time, the start of a measurement interval, (format "date-and- 1932 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1933 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1934 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1935 and Tf is to be interpreted as the Duration of the measurement 1936 interval. The start time is controlled through other means. 1938 Tf a time, the end of a measurement interval, (format "date-and-time" 1939 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1940 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1941 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1942 Tf is interpreted as the Duration of the measurement interval. 1944 7.3.6. Roles 1946 1948 Src launches each packet and waits for return transmissions from 1949 Dst. This is the TWAMP Session-Sender. 1951 Dst waits for each packet from Src and sends a return packet to Src. 1952 This is the TWAMP Session-Reflector. 1954 7.4. Output 1956 This category specifies all details of the Output of measurements 1957 using the metric. 1959 7.4.1. Type 1961 1963 See subsection titles below for Types. 1965 7.4.2. Reference Definition 1967 1969 For all output types --- 1970 T0 the start of a measurement interval, (format "date-and-time" as 1971 specified in Section 5.6 of [RFC3339], see also Section 3 of 1972 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1973 [RFC2330]. 1975 Tf the end of a measurement interval, (format "date-and-time" as 1976 specified in Section 5.6 of [RFC3339], see also Section 3 of 1977 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1978 [RFC2330]. 1980 For LossRatio -- the count of lost packets to total packets sent is 1981 the basis for the loss ratio calculation as per Section 4.1 of 1982 [RFC7680]. 1984 For each , one of the following sub-sections apply: 1986 7.4.2.1. Percentile95 1988 The 95th percentile SHALL be calculated using the conditional 1989 distribution of all packets with a finite value of One-way delay 1990 (undefined delays are excluded), a single value as follows: 1992 See section 4.1 of [RFC3393] for details on the conditional 1993 distribution to exclude undefined values of delay, and Section 5 of 1994 [RFC6703] for background on this analysis choice. 1996 See section 4.3 of [RFC3393] for details on the percentile statistic 1997 (where Round-trip delay should be substituted for "ipdv"). 1999 The percentile = 95, meaning that the reported delay, "95Percentile", 2000 is the smallest value of one-way delay for which the Empirical 2001 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2002 one-way delay values in the conditional distribution. See section 2003 11.3 of [RFC2330] for the definition of the percentile statistic 2004 using the EDF. 2006 95Percentile The time value of the result is expressed in units of 2007 seconds, as a positive value of type decimal64 with fraction 2008 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2009 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2010 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2012 7.4.2.2. Mean 2014 The mean SHALL be calculated using the conditional distribution of 2015 all packets with a finite value of One-way delay (undefined delays 2016 are excluded), a single value as follows: 2018 See section 4.1 of [RFC3393] for details on the conditional 2019 distribution to exclude undefined values of delay, and Section 5 of 2020 [RFC6703] for background on this analysis choice. 2022 See section 4.2.2 of [RFC6049] for details on calculating this 2023 statistic, and 4.2.3 of [RFC6049]. 2025 Mean The time value of the result is expressed in units of seconds, 2026 as a positive value of type decimal64 with fraction digits = 9 2027 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2028 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2029 NTP timestamp as per section 6 of RFC [RFC5905] 2031 7.4.2.3. Min 2033 The minimum SHALL be calculated using the conditional distribution of 2034 all packets with a finite value of One-way delay (undefined delays 2035 are excluded), a single value as follows: 2037 See section 4.1 of [RFC3393] for details on the conditional 2038 distribution to exclude undefined values of delay, and Section 5 of 2039 [RFC6703] for background on this analysis choice. 2041 See section 4.3.2 of [RFC6049] for details on calculating this 2042 statistic, and 4.3.3 of [RFC6049]. 2044 Min The time value of the result is expressed in units of seconds, 2045 as a positive value of type decimal64 with fraction digits = 9 2046 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2047 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2048 NTP timestamp as per section 6 of RFC [RFC5905] 2050 7.4.2.4. Max 2052 The maximum SHALL be calculated using the conditional distribution of 2053 all packets with a finite value of One-way delay (undefined delays 2054 are excluded), a single value as follows: 2056 See section 4.1 of [RFC3393] for details on the conditional 2057 distribution to exclude undefined values of delay, and Section 5 of 2058 [RFC6703] for background on this analysis choice. 2060 See section 4.3.2 of [RFC6049] for a closely related method for 2061 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2062 as follows: 2064 Max = (FiniteDelay [j]) 2066 such that for some index, j, where 1 <= j <= N 2067 FiniteDelay[j] >= FiniteDelay[n] for all n 2069 Max The time value of the result is expressed in units of seconds, 2070 as a positive value of type decimal64 with fraction digits = 9 2071 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2072 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2073 NTP timestamp as per section 6 of RFC [RFC5905] 2075 7.4.2.5. Std_Dev 2077 The Std_Dev SHALL be calculated using the conditional distribution of 2078 all packets with a finite value of One-way delay (undefined delays 2079 are excluded), a single value as follows: 2081 See section 4.1 of [RFC3393] for details on the conditional 2082 distribution to exclude undefined values of delay, and Section 5 of 2083 [RFC6703] for background on this analysis choice. 2085 See section 4.3.2 of [RFC6049] for a closely related method for 2086 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2087 the classic calculation for standard deviation of a population. 2089 Std_Dev The time value of the result is expressed in units of 2090 seconds, as a positive value of type decimal64 with fraction 2091 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2092 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2093 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2095 7.4.3. Metric Units 2097 . 2100 The of One-way Delay is expressed in seconds. 2102 The One-way Loss Ratio is expressed as a percentage of lost packets 2103 to total packets sent. 2105 7.4.4. Calibration 2107 Section 3.7.3 of [RFC7679] provides a means to quantify the 2108 systematic and random errors of a time measurement. In-situ 2109 calibration could be enabled with an internal loopback that includes 2110 as much of the measurement system as possible, performs address 2111 manipulation as needed, and provides some form of isolation (e.g., 2112 deterministic delay) to avoid send-receive interface contention. 2113 Some portion of the random and systematic error can be characterized 2114 this way. 2116 For one-way delay measurements, the error calibration must include an 2117 assessment of the internal clock synchronization with its external 2118 reference (this internal clock is supplying timestamps for 2119 measurement). In practice, the time offsets of clocks at both the 2120 source and destination are needed to estimate the systematic error 2121 due to imperfect clock synchronization (the time offsets are 2122 smoothed, thus the random variation is not usually represented in the 2123 results). 2125 time_offset The time value of the result is expressed in units of 2126 seconds, as a signed value of type decimal64 with fraction digits 2127 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2128 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2129 NTP timestamp as per section 6 of RFC [RFC5905] 2131 When a measurement controller requests a calibration measurement, the 2132 loopback is applied and the result is output in the same format as a 2133 normal measurement with additional indication that it is a 2134 calibration result. In any measurement, the measurement function 2135 SHOULD report its current estimate of time offset as an indicator of 2136 the degree of synchronization. 2138 Both internal loopback calibration and clock synchronization can be 2139 used to estimate the *available accuracy* of the Output Metric Units. 2140 For example, repeated loopback delay measurements will reveal the 2141 portion of the Output result resolution which is the result of system 2142 noise, and thus inaccurate. 2144 7.5. Administrative items 2146 7.5.1. Status 2148 2150 7.5.2. Requestor (keep?) 2152 name or RFC, etc. 2154 7.5.3. Revision 2156 1.0 2158 7.5.4. Revision Date 2160 YYYY-MM-DD 2162 7.6. Comments and Remarks 2164 Additional (Informational) details for this entry 2166 8. UDP Periodic One-way Delay and Loss Registry Entries 2168 This section specifies five initial registry entries for the UDP 2169 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 2171 IANA Note: Registry "Name" below specifies a single registry entry, 2172 whose output format varies according to the element of 2173 the name that specifies one form of statistical summary. There is an 2174 additional metric name for the Loss metric. 2176 All column entries beside the ID, Name, Description, and Output 2177 Reference Method categories are the same, thus this section proposes 2178 six closely-related registry entries. As a result, IANA is also 2179 asked to assign corresponding URNs and URLs to each Named Metric. 2181 8.1. Summary 2183 This category includes multiple indexes to the registry entries, the 2184 element ID and metric name. 2186 8.1.1. ID (Identifier) 2188 2191 IANA is asked to assign a different numeric identifiers to each of 2192 the six Metrics. 2194 8.1.2. Name 2196 2198 OWDelay_Active_IP-UDP-Periodic- 2199 Payload142B_RFCXXXXsecY_Seconds_ 2201 where is one of: 2203 o 95Percentile 2205 o Mean 2206 o Min 2208 o Max 2210 o StdDev 2212 OWLoss_Active_IP-UDP-Periodic- 2213 Payload142B_RFCXXXXsecY_Percent_LossRatio 2215 8.1.3. URIs 2217 URI: Prefix urn:ietf:metrics:perf: 2219 URL: http:\\www.iana.org\ ... 2221 8.1.4. Description 2223 OWDelay: This metric assesses the delay of a stream of packets 2224 exchanged between two hosts (or measurement points), and reports the 2225 One-way delay for all successfully exchanged packets 2226 based on their conditional delay distribution. 2228 where is one of: 2230 o 95Percentile 2232 o Mean 2234 o Min 2236 o Max 2238 o StdDev 2240 OWLoss: This metric assesses the loss ratio of a stream of packets 2241 exchanged between two hosts (which are the two measurement points), 2242 and the Output is the One-way loss ratio for all successfully 2243 received packets expressed as a percentage. 2245 8.2. Metric Definition 2247 This category includes columns to prompt the entry of all necessary 2248 details related to the metric definition, including the RFC reference 2249 and values of input factors, called fixed parameters. 2251 8.2.1. Reference Definition 2253 2255 For Delay: 2257 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2258 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2259 7679, DOI 10.17487/RFC7679, January 2016, . 2262 [RFC7679] 2264 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2265 6049, January 2011. 2267 [RFC6049] 2269 2271 Section 3.4 of [RFC7679] provides the reference definition of the 2272 singleton (single value) One-way delay metric. Section 4.4 of 2273 [RFC7679] provides the reference definition expanded to cover a 2274 multi-value sample. Note that terms such as singleton and sample are 2275 defined in Section 11 of [RFC2330]. 2277 Only successful packet transfers with finite delay are included in 2278 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2280 For loss: 2282 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2283 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2284 10.17487/RFC7680, January 2016, . 2287 Section 2.4 of [RFC7680] provides the reference definition of the 2288 singleton (single value) one-way loss metric. Section 3.4 of 2289 [RFC7680] provides the reference definition expanded to cover a 2290 multi-singleton sample. Note that terms such as singleton and sample 2291 are defined in Section 11 of [RFC2330]. 2293 8.2.2. Fixed Parameters 2295 2298 Type-P: 2300 o IPv4 header values: 2302 * DSCP: set to 0 2304 * TTL: set to 255 2306 * Protocol: Set to 17 (UDP) 2308 o IPv6 header values: 2310 * DSCP: set to 0 2312 * Hop Count: set to 255 2314 * Protocol: Set to 17 (UDP) 2316 o UDP header values: 2318 * Checksum: the checksum MUST be calculated and included in the 2319 header 2321 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2323 * Security features in use influence the number of Padding 2324 octets. 2326 * 142 octets total, including the TWAMP format 2328 Other measurement parameters: 2330 Tmax: a loss threshold waiting time with value 3.0, expressed in 2331 units of seconds, as a positive value of type decimal64 with 2332 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2333 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2334 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2336 See the Packet Stream generation category for two additional Fixed 2337 Parameters. 2339 8.3. Method of Measurement 2341 This category includes columns for references to relevant sections of 2342 the RFC(s) and any supplemental information needed to ensure an 2343 unambiguous methods for implementations. 2345 8.3.1. Reference Method 2347 2350 The methodology for this metric is defined as Type-P-One-way-Delay- 2351 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2352 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2353 However, a Periodic stream is used, as defined in [RFC3432]. 2355 The reference method distinguishes between long-delayed packets and 2356 lost packets by implementing a maximum waiting time for packet 2357 arrival. Tmax is the waiting time used as the threshold to declare a 2358 packet lost. Lost packets SHALL be designated as having undefined 2359 delay, and counted for the OWLoss metric. 2361 The calculations on the one-way delay SHALL be performed on the 2362 conditional distribution, conditioned on successful packet arrival 2363 within Tmax. Also, when all packet delays are stored, the process 2364 which calculates the one-way delay value MAY enforce the Tmax 2365 threshold on stored values before calculations. See section 4.1 of 2366 [RFC3393] for details on the conditional distribution to exclude 2367 undefined values of delay, and Section 5 of [RFC6703] for background 2368 on this analysis choice. 2370 The reference method requires some way to distinguish between 2371 different packets in a stream to establish correspondence between 2372 sending times and receiving times for each successfully-arriving 2373 packet. Sequence numbers or other send-order identification MUST be 2374 retained at the Src or included with each packet to disambiguate 2375 packet reordering if it occurs. 2377 Since a standard measurement protocol is employed [RFC5357], then the 2378 measurement process will determine the sequence numbers or timestamps 2379 applied to test packets after the Fixed and Runtime parameters are 2380 passed to that process. The measurement protocol dictates the format 2381 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2382 payload. 2384 8.3.2. Packet Stream Generation 2386 2388 This section gives the details of the packet traffic which is the 2389 basis for measurement. In IPPM metrics, this is called the Stream, 2390 and can easily be described by providing the list of stream 2391 parameters. 2393 Section 3 of [RFC3432] prescribes the method for generating Periodic 2394 streams using associated parameters. 2396 incT the nominal duration of inter-packet interval, first bit to 2397 first bit 2399 dT the duration of the interval for allowed sample start times 2401 T0 the actual start time of the periodic stream 2403 NOTE: an initiation process with a number of control exchanges 2404 resulting in unpredictable start times (within a time interval) may 2405 be sufficient to avoid synchronization of periodic streams, and 2406 therefore a valid replacement for selecting a start time at random 2407 from a fixed interval. 2409 These stream parameters will be specified as Run-time parameters. 2411 8.3.3. Traffic Filtering (observation) Details 2413 NA 2415 8.3.4. Sampling Distribution 2417 NA 2419 8.3.5. Run-time Parameters and Data Format 2421 Run-time Parameters are input factors that must be determined, 2422 configured into the measurement system, and reported with the results 2423 for the context to be complete. 2425 2427 Src the IP address of the host in the Src Role (format ipv4-address- 2428 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2429 see Section 4 of [RFC6991]) 2431 Dst the IP address of the host in the Dst Role (format ipv4-address- 2432 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2433 see section 4 of [RFC6991]) 2435 T0 a time, the start of a measurement interval, (format "date-and- 2436 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2437 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2438 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2439 and Tf is to be interpreted as the Duration of the measurement 2440 interval. The start time is controlled through other means. 2442 Tf a time, the end of a measurement interval, (format "date-and-time" 2443 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2444 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2445 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2446 Tf is interpreted as the Duration of the measurement interval. 2448 @@@@ should Periodic run-time params be fixed instead? Probably yes 2449 if modeling a specific version of tests. Note in the NAME, i.e. 2450 Poisson3.3 2452 8.3.6. Roles 2454 2456 Src launches each packet and waits for return transmissions from 2457 Dst. This is the TWAMP Session-Sender. 2459 Dst waits for each packet from Src and sends a return packet to Src. 2460 This is the TWAMP Session-Reflector. 2462 8.4. Output 2464 This category specifies all details of the Output of measurements 2465 using the metric. 2467 8.4.1. Type 2469 2471 See subsection titles in Reference Definition for Latency Types. 2473 8.4.2. Reference Definition 2475 2477 For all output types --- 2479 T0 the start of a measurement interval, (format "date-and-time" as 2480 specified in Section 5.6 of [RFC3339], see also Section 3 of 2481 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2482 [RFC2330]. 2484 Tf the end of a measurement interval, (format "date-and-time" as 2485 specified in Section 5.6 of [RFC3339], see also Section 3 of 2486 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2487 [RFC2330]. 2489 For LossRatio -- the count of lost packets to total packets sent is 2490 the basis for the loss ratio calculation as per Section 4.1 of 2491 [RFC7680]. 2493 For each , one of the following sub-sections apply: 2495 8.4.2.1. Percentile95 2497 The 95th percentile SHALL be calculated using the conditional 2498 distribution of all packets with a finite value of One-way delay 2499 (undefined delays are excluded), a single value as follows: 2501 See section 4.1 of [RFC3393] for details on the conditional 2502 distribution to exclude undefined values of delay, and Section 5 of 2503 [RFC6703] for background on this analysis choice. 2505 See section 4.3 of [RFC3393] for details on the percentile statistic 2506 (where Round-trip delay should be substituted for "ipdv"). 2508 The percentile = 95, meaning that the reported delay, "95Percentile", 2509 is the smallest value of one-way delay for which the Empirical 2510 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2511 one-way delay values in the conditional distribution. See section 2512 11.3 of [RFC2330] for the definition of the percentile statistic 2513 using the EDF. 2515 95Percentile The time value of the result is expressed in units of 2516 seconds, as a positive value of type decimal64 with fraction 2517 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2518 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2519 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2521 8.4.2.2. Mean 2523 The mean SHALL be calculated using the conditional distribution of 2524 all packets with a finite value of One-way delay (undefined delays 2525 are excluded), a single value as follows: 2527 See section 4.1 of [RFC3393] for details on the conditional 2528 distribution to exclude undefined values of delay, and Section 5 of 2529 [RFC6703] for background on this analysis choice. 2531 See section 4.2.2 of [RFC6049] for details on calculating this 2532 statistic, and 4.2.3 of [RFC6049]. 2534 Mean The time value of the result is expressed in units of seconds, 2535 as a positive value of type decimal64 with fraction digits = 9 2536 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2537 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2538 NTP timestamp as per section 6 of RFC [RFC5905] 2540 8.4.2.3. Min 2542 The minimum SHALL be calculated using the conditional distribution of 2543 all packets with a finite value of One-way delay (undefined delays 2544 are excluded), a single value as follows: 2546 See section 4.1 of [RFC3393] for details on the conditional 2547 distribution to exclude undefined values of delay, and Section 5 of 2548 [RFC6703] for background on this analysis choice. 2550 See section 4.3.2 of [RFC6049] for details on calculating this 2551 statistic, and 4.3.3 of [RFC6049]. 2553 Min The time value of the result is expressed in units of seconds, 2554 as a positive value of type decimal64 with fraction digits = 9 2555 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2556 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2557 NTP timestamp as per section 6 of RFC [RFC5905] 2559 8.4.2.4. Max 2561 The maximum SHALL be calculated using the conditional distribution of 2562 all packets with a finite value of One-way delay (undefined delays 2563 are excluded), a single value as follows: 2565 See section 4.1 of [RFC3393] for details on the conditional 2566 distribution to exclude undefined values of delay, and Section 5 of 2567 [RFC6703] for background on this analysis choice. 2569 See section 4.3.2 of [RFC6049] for a closely related method for 2570 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2571 as follows: 2573 Max = (FiniteDelay [j]) 2575 such that for some index, j, where 1 <= j <= N 2576 FiniteDelay[j] >= FiniteDelay[n] for all n 2578 Max The time value of the result is expressed in units of seconds, 2579 as a positive value of type decimal64 with fraction digits = 9 2580 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2581 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2582 NTP timestamp as per section 6 of RFC [RFC5905] 2584 8.4.2.5. Std_Dev 2586 The Std_Dev SHALL be calculated using the conditional distribution of 2587 all packets with a finite value of One-way delay (undefined delays 2588 are excluded), a single value as follows: 2590 See section 4.1 of [RFC3393] for details on the conditional 2591 distribution to exclude undefined values of delay, and Section 5 of 2592 [RFC6703] for background on this analysis choice. 2594 See section 4.3.2 of [RFC6049] for a closely related method for 2595 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2596 the classic calculation for standard deviation of a population. 2598 Std_Dev The time value of the result is expressed in units of 2599 seconds, as a positive value of type decimal64 with fraction 2600 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2601 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2602 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2604 8.4.3. Metric Units 2606 . 2609 The of One-way Delay is expressed in seconds, where 2610 is one of: 2612 o 95Percentile 2614 o Mean 2616 o Min 2618 o Max 2620 o StdDev 2622 The One-way Loss Ratio is expressed as a percentage of lost packets 2623 to total packets sent. 2625 8.4.4. Calibration 2627 Section 3.7.3 of [RFC7679] provides a means to quantify the 2628 systematic and random errors of a time measurement. In-situ 2629 calibration could be enabled with an internal loopback that includes 2630 as much of the measurement system as possible, performs address 2631 manipulation as needed, and provides some form of isolation (e.g., 2632 deterministic delay) to avoid send-receive interface contention. 2633 Some portion of the random and systematic error can be characterized 2634 this way. 2636 For one-way delay measurements, the error calibration must include an 2637 assessment of the internal clock synchronization with its external 2638 reference (this internal clock is supplying timestamps for 2639 measurement). In practice, the time offsets of clocks at both the 2640 source and destination are needed to estimate the systematic error 2641 due to imperfect clock synchronization (the time offsets are 2642 smoothed, thus the random variation is not usually represented in the 2643 results). 2645 time_offset The time value of the result is expressed in units of 2646 seconds, as a signed value of type decimal64 with fraction digits 2647 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2648 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2649 NTP timestamp as per section 6 of RFC [RFC5905] 2651 When a measurement controller requests a calibration measurement, the 2652 loopback is applied and the result is output in the same format as a 2653 normal measurement with additional indication that it is a 2654 calibration result. In any measurement, the measurement function 2655 SHOULD report its current estimate of time offset as an indicator of 2656 the degree of synchronization. 2658 Both internal loopback calibration and clock synchronization can be 2659 used to estimate the *available accuracy* of the Output Metric Units. 2660 For example, repeated loopback delay measurements will reveal the 2661 portion of the Output result resolution which is the result of system 2662 noise, and thus inaccurate. 2664 8.5. Administrative items 2666 8.5.1. Status 2668 2670 8.5.2. Requestor (keep?) 2672 name or RFC, etc. 2674 8.5.3. Revision 2676 1.0 2678 8.5.4. Revision Date 2680 YYYY-MM-DD 2682 8.6. Comments and Remarks 2684 Additional (Informational) details for this entry 2686 9. ICMP Round-trip Latency and Loss Registry Entries 2688 This section specifies three initial registry entries for the ICMP 2689 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2691 This section specifies four Registry entries with many common 2692 columns. 2694 All column entries beside the ID, Name, Description, and Output 2695 Reference Method categories are the same, thus this section proposes 2696 two closely-related registry entries. As a result, IANA is also 2697 asked to assign four corresponding URNs and URLs to each Named 2698 Metric. 2700 9.1. Summary 2702 This category includes multiple indexes to the registry entry: the 2703 element ID and metric name. 2705 9.1.1. ID (Identifier) 2707 2709 IANA is asked to assign different numeric identifiers to each of the 2710 four Named Metrics. 2712 9.1.2. Name 2714 2716 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Seconds_ 2718 where is one of: 2720 o Mean 2722 o Min 2724 o Max 2725 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Percent_LossRatio 2727 9.1.3. URIs 2729 URN: Prefix urn:ietf:metrics:perf: 2731 URL: http:/// 2733 9.1.4. Description 2735 RTDelay: This metric assesses the delay of a stream of ICMP packets 2736 exchanged between two hosts (which are the two measurement points), 2737 and the Output is the Round-trip delay for all successfully exchanged 2738 packets expressed as the of their conditional delay 2739 distribution, where is one of: 2741 o Mean 2743 o Min 2745 o Max 2747 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2748 packets exchanged between two hosts (which are the two measurement 2749 points), and the Output is the Round-trip loss ratio for all 2750 successfully exchanged packets expressed as a percentage. 2752 9.1.5. Change Controller 2754 IETF 2756 9.1.6. Version (of Registry Format) 2758 1.0 2760 9.2. Metric Definition 2762 This category includes columns to prompt the entry of all necessary 2763 details related to the metric definition, including the RFC reference 2764 and values of input factors, called fixed parameters. 2766 9.2.1. Reference Definition 2768 2770 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2771 Metric for IPPM", RFC 2681, September 1999. 2773 [RFC2681] 2775 2777 Section 2.4 of [RFC2681] provides the reference definition of the 2778 singleton (single value) Round-trip delay metric. Section 3.4 of 2779 [RFC2681] provides the reference definition expanded to cover a 2780 multi-singleton sample. Note that terms such as singleton and sample 2781 are defined in Section 11 of [RFC2330]. 2783 Note that although the [RFC2681] definition of "Round-trip-Delay 2784 between Src and Dst" is directionally ambiguous in the text, this 2785 metric tightens the definition further to recognize that the host in 2786 the "Src" role will send the first packet to "Dst", and ultimately 2787 receive the corresponding return packet from "Dst" (when neither are 2788 lost). 2790 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2791 the value of Round-trip delay in metric definitions and methods. The 2792 variable "dT" has been re-used in other IPPM literature to refer to 2793 different quantities, and cannot be used as a global variable name. 2795 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2797 [RFC6673] 2799 Both delay and loss metrics employ a maximum waiting time for 2800 received packets, so the count of lost packets to total packets sent 2801 is the basis for the loss ratio calculation as per Section 6.1 of 2802 [RFC6673]. 2804 9.2.2. Fixed Parameters 2806 2810 Type-P as defined in Section 13 of [RFC2330]: 2812 o IPv4 header values: 2814 * DSCP: set to 0 2816 * TTL: set to 255 2818 * Protocol: Set to 01 (ICMP) 2820 o IPv6 header values: 2822 * DSCP: set to 0 2824 * Hop Limit: set to 255 2826 * Protocol: Set to 01 (ICMP) 2828 o ICMP header values: 2830 * Type: 8 (Echo Request) 2832 * Code: 0 2834 * Checksum: the checksum MUST be calculated and included in the 2835 header 2837 * (Identifier and Sequence Number set at Run-Time) 2839 o ICMP Payload 2841 * total of 32 bytes of random info 2843 Other measurement parameters: 2845 o Tmax: a loss threshold waiting time 2847 * 3.0, expressed in units of seconds, as a positive value of type 2848 decimal64 with fraction digits = 4 (see section 9.3 of 2849 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2850 lossless conversion to/from the 32-bit NTP timestamp as per 2851 section 6 of [RFC5905]. 2853 9.3. Method of Measurement 2855 This category includes columns for references to relevant sections of 2856 the RFC(s) and any supplemental information needed to ensure an 2857 unambiguous methods for implementations. 2859 9.3.1. Reference Method 2861 2864 The methodology for this metric is defined as Type-P-Round-trip- 2865 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2866 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2867 Fixed Parameters. 2869 The reference method distinguishes between long-delayed packets and 2870 lost packets by implementing a maximum waiting time for packet 2871 arrival. Tmax is the waiting time used as the threshold to declare a 2872 packet lost. Lost packets SHALL be designated as having undefined 2873 delay, and counted for the RTLoss metric. 2875 The calculations on the delay (RTD) SHALL be performed on the 2876 conditional distribution, conditioned on successful packet arrival 2877 within Tmax. Also, when all packet delays are stored, the process 2878 which calculates the RTD value MAY enforce the Tmax threshold on 2879 stored values before calculations. See section 4.1 of [RFC3393] for 2880 details on the conditional distribution to exclude undefined values 2881 of delay, and Section 5 of [RFC6703] for background on this analysis 2882 choice. 2884 The reference method requires some way to distinguish between 2885 different packets in a stream to establish correspondence between 2886 sending times and receiving times for each successfully-arriving 2887 packet. Sequence numbers or other send-order identification MUST be 2888 retained at the Src or included with each packet to disambiguate 2889 packet reordering if it occurs. 2891 The measurement process will determine the sequence numbers applied 2892 to test packets after the Fixed and Runtime parameters are passed to 2893 that process. The ICMP measurement process and protocol will dictate 2894 the format of sequence numbers and other identifiers. 2896 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2897 instruction to "send a Type-P packet back to the Src as quickly as 2898 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2899 [RFC6673] presents additional requirements which MUST be included in 2900 the method of measurement for this metric. 2902 9.3.2. Packet Stream Generation 2904 This section gives the details of the packet traffic which is the 2905 basis for measurement. In IPPM metrics, this is called the Stream, 2906 and can easily be described by providing the list of stream 2907 parameters. 2909 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2910 On Receive. This is a modification of Section 3 of [RFC3432], which 2911 prescribes the method for generating Periodic streams using 2912 associated parameters: 2914 incT the nominal duration of inter-packet interval, first bit to 2915 first bit 2917 dT the duration of the interval for allowed sample start times 2919 T0 the actual start time of the periodic stream 2921 The incT and T0 stream parameters will be specified as Run-time 2922 parameters, dT is not used in SendOnRcv. 2924 A SendOnRcv sender behaves exactly like a Periodic stream generator 2925 while all reply packets arrive with RTD < incT, and the inter-packet 2926 interval will be constant. 2928 If a reply packet arrives with RTD >= incT, then the inter-packet 2929 interval for the next sending time is nominally RTD. 2931 If a reply packet fails to arrive within Tmax, then the inter-packet 2932 interval for the next sending time is nominally Tmax. 2934 If an immediate send on reply arrival is desired, then set incT=0. 2936 9.3.3. Traffic Filtering (observation) Details 2938 The measured results based on a filtered version of the packets 2939 observed, and this section provides the filter details (when 2940 present). 2942
. 2944 NA 2946 9.3.4. Sampling Distribution 2948 2951 NA 2953 9.3.5. Run-time Parameters and Data Format 2955 Run-time Parameters are input factors that must be determined, 2956 configured into the measurement system, and reported with the results 2957 for the context to be complete. 2959 2961 Src the IP address of the host in the Src Role (format ipv4-address- 2962 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2963 see Section 4 of [RFC6991]) 2965 Dst the IP address of the host in the Dst Role (format ipv4-address- 2966 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2967 see section 4 of [RFC6991]) 2969 T0 a time, the start of a measurement interval, (format "date-and- 2970 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2971 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2972 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2973 and Tf is to be interpreted as the Duration of the measurement 2974 interval. The start time is controlled through other means. 2976 Count The total count of ICMP Echo Requests to send, formatted as a 2977 uint16, as per section 9.2 of [RFC6020]. 2979 (see the Packet Stream Generation section for additional Run-time 2980 parameters) 2982 9.3.6. Roles 2984 2986 Src launches each packet and waits for return transmissions from 2987 Dst. 2989 Dst waits for each packet from Src and sends a return packet to Src. 2991 9.4. Output 2993 This category specifies all details of the Output of measurements 2994 using the metric. 2996 9.4.1. Type 2998 3000 See subsection titles in Reference Definition for Latency Types. 3002 LossRatio -- the count of lost packets to total packets sent is the 3003 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 3005 9.4.2. Reference Definition 3007 3009 For all output types --- 3011 T0 the start of a measurement interval, (format "date-and-time" as 3012 specified in Section 5.6 of [RFC3339], see also Section 3 of 3014 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3015 [RFC2330]. 3017 Tf the end of a measurement interval, (format "date-and-time" as 3018 specified in Section 5.6 of [RFC3339], see also Section 3 of 3019 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3020 [RFC2330]. 3022 TotalCount the count of packets actually sent by the Src to Dst 3023 during the measurement interval. 3025 For LossRatio -- the count of lost packets to total packets sent is 3026 the basis for the loss ratio calculation as per Section 4.1 of 3027 [RFC7680]. 3029 For each , one of the following sub-sections apply: 3031 9.4.2.1. Mean 3033 The mean SHALL be calculated using the conditional distribution of 3034 all packets with a finite value of Round-trip delay (undefined delays 3035 are excluded), a single value as follows: 3037 See section 4.1 of [RFC3393] for details on the conditional 3038 distribution to exclude undefined values of delay, and Section 5 of 3039 [RFC6703] for background on this analysis choice. 3041 See section 4.2.2 of [RFC6049] for details on calculating this 3042 statistic, and 4.2.3 of [RFC6049]. 3044 Mean The time value of the result is expressed in units of seconds, 3045 as a positive value of type decimal64 with fraction digits = 9 3046 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3047 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3048 NTP timestamp as per section 6 of RFC [RFC5905] 3050 9.4.2.2. Min 3052 The minimum SHALL be calculated using the conditional distribution of 3053 all packets with a finite value of Round-trip delay (undefined delays 3054 are excluded), a single value as follows: 3056 See section 4.1 of [RFC3393] for details on the conditional 3057 distribution to exclude undefined values of delay, and Section 5 of 3058 [RFC6703] for background on this analysis choice. 3060 See section 4.3.2 of [RFC6049] for details on calculating this 3061 statistic, and 4.3.3 of [RFC6049]. 3063 Min The time value of the result is expressed in units of seconds, 3064 as a positive value of type decimal64 with fraction digits = 9 3065 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3066 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3067 NTP timestamp as per section 6 of RFC [RFC5905] 3069 9.4.2.3. Max 3071 The maximum SHALL be calculated using the conditional distribution of 3072 all packets with a finite value of Round-trip delay (undefined delays 3073 are excluded), a single value as follows: 3075 See section 4.1 of [RFC3393] for details on the conditional 3076 distribution to exclude undefined values of delay, and Section 5 of 3077 [RFC6703] for background on this analysis choice. 3079 See section 4.3.2 of [RFC6049] for a closely related method for 3080 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3081 as follows: 3083 Max = (FiniteDelay [j]) 3085 such that for some index, j, where 1 <= j <= N 3086 FiniteDelay[j] >= FiniteDelay[n] for all n 3088 Max The time value of the result is expressed in units of seconds, 3089 as a positive value of type decimal64 with fraction digits = 9 3090 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3091 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3092 NTP timestamp as per section 6 of RFC [RFC5905] 3094 9.4.3. Metric Units 3096 . 3099 The of Round-trip Delay is expressed in seconds, where 3100 is one of: 3102 o Mean 3104 o Min 3106 o Max 3108 The Round-trip Loss Ratio is expressed as a percentage of lost 3109 packets to total packets sent. 3111 9.4.4. Calibration 3113 Section 3.7.3 of [RFC7679] provides a means to quantify the 3114 systematic and random errors of a time measurement. In-situ 3115 calibration could be enabled with an internal loopback at the Source 3116 host that includes as much of the measurement system as possible, 3117 performs address manipulation as needed, and provides some form of 3118 isolation (e.g., deterministic delay) to avoid send-receive interface 3119 contention. Some portion of the random and systematic error can be 3120 characterized this way. 3122 When a measurement controller requests a calibration measurement, the 3123 loopback is applied and the result is output in the same format as a 3124 normal measurement with additional indication that it is a 3125 calibration result. 3127 Both internal loopback calibration and clock synchronization can be 3128 used to estimate the *available accuracy* of the Output Metric Units. 3129 For example, repeated loopback delay measurements will reveal the 3130 portion of the Output result resolution which is the result of system 3131 noise, and thus inaccurate. 3133 9.5. Administrative items 3135 9.5.1. Status 3137 3139 9.5.2. Requestor (keep?) 3141 name or RFC, etc. 3143 9.5.3. Revision 3145 1.0 3147 9.5.4. Revision Date 3149 YYYY-MM-DD 3151 9.6. Comments and Remarks 3153 Additional (Informational) details for this entry 3155 10. TCP Round-Trip Delay and Loss Registry Entries 3157 This section specifies three initial registry entries for the Passive 3158 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 3159 Round-trip Loss Count. 3161 This section specifies four Registry entries with many common 3162 columns. 3164 All column entries beside the ID, Name, Description, and Output 3165 Reference Method categories are the same, thus this section proposes 3166 four closely-related registry entries. As a result, IANA is also 3167 asked to assign four corresponding URNs and URLs to each Named 3168 Metric. 3170 10.1. Summary 3172 This category includes multiple indexes to the registry entry: the 3173 element ID and metric name. 3175 10.1.1. ID (Identifier) 3177 3179 IANA is asked to assign different numeric identifiers to each of the 3180 four Named Metrics. 3182 10.1.2. Name 3184 3186 RTDelay_Passive_IP-TCP_RFCXXXXsecY_Seconds_ 3188 where is one of: 3190 o Mean 3192 o Min 3194 o Max 3196 RTDelay_Passive_IP-TCP-HS_RFCXXXXsecY_Seconds_Singleton 3198 @@@@ Note that a mid-point observer only has the opportuinty to 3199 compose a single RTDelay on the TSC Hand Shake. 3201 RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count 3203 10.1.3. URIs 3205 URN: Prefix urn:ietf:metrics:perf: 3207 URL: http:/// 3209 10.1.4. Description 3211 RTDelay: This metric assesses the round-trip delay of TCP packets 3212 constituting a single connection, exchanged between two hosts. The 3213 Observation Point [RFC7011] is assumed to be in the network at a 3214 remote point from the end hosts. The Output is the Round-trip delay 3215 for all successfully exchanged packets expressed as the 3216 of their conditional delay distribution, where is one of: 3218 o Mean 3220 o Min 3222 o Max 3224 RTLoss: This metric assesses the estimated loss count for TCP packets 3225 constituting a single connection, exchanged between two hosts. The 3226 Observation Point [RFC7011] is assumed to be in the network at a 3227 remote point from the end hosts. The Output is the estimated Loss 3228 Count for the measurement interval. 3230 10.1.5. Change Controller 3232 IETF 3234 10.1.6. Version (of Registry Format) 3236 1.0 3238 10.2. Metric Definition 3240 This category includes columns to prompt the entry of all necessary 3241 details related to the metric definition, including the RFC reference 3242 and values of input factors, called fixed parameters. 3244 10.2.1. Reference Definitions 3246 3248 Although there is no RFC that describes passive measurement of Round- 3249 Trip Delay, the parallel definition for Active measurement is: 3251 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 3252 Metric for IPPM", RFC 2681, September 1999. 3254 [RFC2681] 3256 3258 This metric definition uses the terms singleton and sample as defined 3259 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 3260 reference definition of the singleton (single value) Round-trip delay 3261 metric. Section 3.4 of [RFC2681] provides the reference definition 3262 expanded to cover a multi-singleton sample.) 3264 With the Observation Point [RFC7011] (OP) located between the hosts 3265 participating in the TCP connection, the Round-trip Delay metric 3266 requires two individual measurements between the OP and each host, 3267 such that the Spatial Composition [RFC6049]of the measurements yields 3268 a Round-trip Delay singleton. 3270 Using the direction of TCP SYN transmission to anchor the 3271 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3272 during connection establishment. The direction of SYN transfer is 3273 the Forward direction of transmission, from A through OP to B 3274 (Reverse is B through OP to A). 3276 Traffic filters reduce the packet stream at the OP to a Qualified 3277 bidirectional flow packets. 3279 In the definitions below, Corresponding Packets are transferred in 3280 different directions and convey a common value in a TCP header field 3281 that establishes correspondence (to the extent possible). Examples 3282 may be found in the TCP timestamp fields. 3284 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3285 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3286 observed a Qualified packet to host B at wire-time T', that host B 3287 received that packet and sent a Corresponding Packet back to host A, 3288 and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. 3290 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3291 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3292 OP observed a Qualified packet to host A at wire-time T'', that host 3293 A received that packet and sent a Corresponding Packet back to host 3294 B, and that OP observed the Corresponding Packet at wire-time T'' + 3295 RTD_rev. 3297 Ideally, the packet sent from host B to host A in both definitions 3298 above SHOULD be the same packet (or, when measuring RTD_rev first, 3299 the packet from host A to host B in both definitions should be the 3300 same). 3302 The REQUIRED Composition Function for a singleton of Round-trip Delay 3303 at time T (where T is the earliest of T' and T'' above) is: 3305 RTDelay = RTD_fwd + RTD_rev 3307 Note that when OP is located at host A or host B, one of the terms 3308 composing RTDelay will be zero or negligible. 3310 @@@@ NEW HS STUFF @@@@ 3312 When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- 3313 SYN-ACK, then RTD_fwd == RTD_HS_fwd. 3315 When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a 3316 TCP-ACK, then RTD_rev == RTD_HS_rev. 3318 The REQUIRED Composition Function for a singleton of Round-trip Delay 3319 for the connection Hand Shake: 3321 RTDelay_HS = RTD_HS_fwd + RTD_HS_rev 3323 @@@@ END new stuff 3325 The definition of Round-trip Loss Count uses the nomenclature 3326 developed above, based on observation of the TCP header sequence 3327 numbers and storing the sequence number gaps observed. Packet Losses 3328 can be inferred from: 3330 o Out-of-order segments: TCP segments are normally monotonically 3331 increasing. Section 3 of [RFC4737] describes the notion of "next 3332 expected" sequence numbers which can be adapted to TCP segments 3333 (for the purpose of detecting reordered packets). Observation of 3334 out-of-order segments indicates loss on the path prior to the OP, 3335 and creates a gap. 3337 o Duplicate segments: Section 2 of [RFC5560] defines identical 3338 packets and is suitable for evaluation of TCP packets to detect 3339 duplication. Observation of duplicate segments *without a 3340 corresponding gap* indicates loss on the path following the OP 3341 (because they overlap part of the delivered sequence numbers 3342 already observed at OP). 3344 Each observation of an out-of-order or duplicate infers a singleton 3345 of loss, but composition of Round-trip Loss Counts will be conducted 3346 over a measurement interval which is synonymous with a single TCP 3347 connection. 3349 With the above observations in the Forward direction over a 3350 measurement interval, the count of out-of-order and duplicate 3351 segments is defined as RTL_fwd. Comparable observations in the 3352 Reverse direction are defined as RTL_rev. 3354 For a measurement interval (corresponding to a single TCP 3355 connection), T0 to Tf, the REQUIRED Composition Function for a the 3356 two single-direction counts of inferred loss is: 3358 RTLoss = RTL_fwd + RTL_rev 3360 10.2.2. Fixed Parameters 3362 3366 Traffic Filters: 3368 o IPv4 header values: 3370 * DSCP: set to 0 3372 * Protocol: Set to 06 (TCP) 3374 o IPv6 header values: 3376 * DSCP: set to 0 3378 * Protocol: Set to 06 (TCP) 3380 o TCP header values: 3382 * Flags: ACK, SYN, @@@@@ others?? 3384 * Checksum: the checksum MUST be calculated and included in the 3385 header 3387 * Timestamp Option (TSopt): Set 3389 + Kind: 8 3391 + Length: 10 bytes 3393 o 3395 10.3. Method of Measurement 3397 This category includes columns for references to relevant sections of 3398 the RFC(s) and any supplemental information needed to ensure an 3399 unambiguous methods for implementations. 3401 10.3.1. Reference Methods 3403 3406 The foundation methodology for this metric is defined in Section 4 of 3407 [RFC7323] using the Timestamp Option with modifications that allow 3408 application at a mid-path Observation Point (OP) [RFC7011]. Further 3409 details and applicable heuristics were derived from [Strowes] and 3410 [Trammell-14]. 3412 The Traffic Filter at the OP is configured to observe a single TCP 3413 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3414 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3415 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3416 of RTDelay as RTDelay_HS (composed using the forward and reverse 3417 measurement pair). RTDelay_HS SHALL be treated separately from other 3418 RTDelays on data-bearing packets and their ACKs. The RTDelay_HS 3419 value MAY be used as a sanity check on other Composed values of 3420 RTDelay. 3422 For payload bearing packets, the OP measures the time interval 3423 between observation of a packet with Sequence Number s, and the 3424 corresponding ACK with same Sequence number. When the payload is 3425 transferred from host A to host B, the observed interval is RTD_fwd. 3427 Because many data transfers are unidirectional (say, in the Forward 3428 direction from host A to host B), it is necessary to use pure ACK 3429 packets with Timestamp (TSval) and their Timestamp value echo to 3430 perform a RTD_rev measurement. The time interval between observation 3431 of the ACK from B to A, and the corresponding packet with Timestamp 3432 echo (TSecr) is the RTD_rev. 3434 Delay Measurement Filtering Heuristics: 3436 If Data payloads were transferred in both Forward and Reverse 3437 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3438 of [RFC7323] could be applied. This rule essentially excludes any 3439 measurement using a packet unless it makes progress in the transfer 3440 (advances the left edge of the send window, consistent 3441 with[Strowes]). 3443 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3444 that is larger than previously observed values. This would tend to 3445 exclude Reverse measurements taken when the Application has no data 3446 ready to send, because considerable time could be added to RTD_rev 3447 from this source of error. 3449 The statistic calculations to summarize the delay (RTDelay) SHALL be 3450 performed on the conditional distribution, conditioned on successful 3451 Forward and Reverse measurements which follow the Heuristics. 3453 Method for Inferring Loss: 3455 The OP tracks sequence numbers and stores gaps for each direction of 3456 transmission, as well as the next-expected sequence number as in 3457 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3458 segments and Duplicate segments. 3460 Loss Measurement Filtering Heuristics: 3462 [Trammell-14] adds a window of evaluation based on the RTDelay. 3464 Distinguish Re-ordered from OOO due to loss, because sequence number 3465 gap is filled during the same RTDelay window. Segments detected as 3466 re-ordered according to [RFC4737] MUST reduce the Loss Count inferred 3467 from Out-of-order segments. 3469 Spurious (unneeded) retransmissions (observed as duplicates) can also 3470 be reduced this way, as described in [Trammell-14]. 3472 Sources of Error: 3474 The principal source of RTDelay error is the host processing time to 3475 return a packet that defines the termination of a time interval. The 3476 heuristics above intend to mitigate these errors by excluding 3477 measurements where host processing time is a significant part of 3478 RTD_fwd or RTD_rev. 3480 A key source of RTLoss error is observation loss, described in 3481 section 3 of [Trammell-14]. 3483 10.3.2. Packet Stream Generation 3485 This section gives the details of the packet traffic which is the 3486 basis for measurement. In IPPM metrics, this is called the Stream, 3487 and can easily be described by providing the list of stream 3488 parameters. 3490 NA 3492 10.3.3. Traffic Filtering (observation) Details 3494 The measured results based on a filtered version of the packets 3495 observed, and this section provides the filter details (when 3496 present). 3498 The Fixed Parameters above give a portion of the Traffic Filter. 3499 Other aspects will be supplied as Run-time Parameters (below). 3501 10.3.4. Sampling Distribution 3503 3506 This metric requires a complete sample of all packets that qualify 3507 according to the Traffic Filter criteria. 3509 10.3.5. Run-time Parameters and Data Format 3511 Run-time Parameters are input factors that must be determined, 3512 configured into the measurement system, and reported with the results 3513 for the context to be complete. 3515 3517 Src the IP address of the host in the host A Role (format ipv4- 3518 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3519 IPv6, see Section 4 of [RFC6991]) 3521 Dst the IP address of the host in the host B (format ipv4-address- 3522 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3523 see section 4 of [RFC6991]) 3525 T0 a time, the start of a measurement interval, (format "date-and- 3526 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3527 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3528 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3529 and Td is to be interpreted as the Duration of the measurement 3530 interval. The start time is controlled through other means. 3532 Td Optionally, the end of a measurement interval, (format "date-and- 3533 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3534 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3535 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3536 the measurement interval MAY be controlled by the measured 3537 connection, where the second pair of FIN and ACK packets exchanged 3538 between host A and B effectively ends the interval. 3540 ... ... 3542 10.3.6. Roles 3544 3546 host A launches the SYN packet to open the connection, and 3547 synonymous with an IP address. 3549 host B replies with the SYN-ACK packet to open the connection, and 3550 synonymous with an IP address. 3552 10.4. Output 3554 This category specifies all details of the Output of measurements 3555 using the metric. 3557 10.4.1. Type 3559 3561 See subsection titles in Reference Definition for RTDelay Types. 3563 For RTLoss -- the count of lost packets. 3565 10.4.2. Reference Definition 3567 3569 For all output types --- 3571 T0 the start of a measurement interval, (format "date-and-time" as 3572 specified in Section 5.6 of [RFC3339], see also Section 3 of 3573 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3574 [RFC2330]. 3576 Tf the end of a measurement interval, (format "date-and-time" as 3577 specified in Section 5.6 of [RFC3339], see also Section 3 of 3578 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3579 [RFC2330]. The end of the measurement interval MAY be controlled 3580 by the measured connection, where the second pair of FIN and ACK 3581 packets exchanged between host A and B effectively ends the 3582 interval. 3584 ... ... 3586 For RTDelay_HS -- the Round trip delay of the Handshake. 3588 For RTLoss -- the count of lost packets. 3590 For each , one of the following sub-sections apply: 3592 10.4.2.1. Mean 3594 The mean SHALL be calculated using the conditional distribution of 3595 all packets with a finite value of Round-trip delay (undefined delays 3596 are excluded), a single value as follows: 3598 See section 4.1 of [RFC3393] for details on the conditional 3599 distribution to exclude undefined values of delay, and Section 5 of 3600 [RFC6703] for background on this analysis choice. 3602 See section 4.2.2 of [RFC6049] for details on calculating this 3603 statistic, and 4.2.3 of [RFC6049]. 3605 Mean The time value of the result is expressed in units of seconds, 3606 as a positive value of type decimal64 with fraction digits = 9 3607 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3608 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3609 NTP timestamp as per section 6 of RFC [RFC5905] 3611 10.4.2.2. Min 3613 The minimum SHALL be calculated using the conditional distribution of 3614 all packets with a finite value of Round-trip delay (undefined delays 3615 are excluded), a single value as follows: 3617 See section 4.1 of [RFC3393] for details on the conditional 3618 distribution to exclude undefined values of delay, and Section 5 of 3619 [RFC6703] for background on this analysis choice. 3621 See section 4.3.2 of [RFC6049] for details on calculating this 3622 statistic, and 4.3.3 of [RFC6049]. 3624 Min The time value of the result is expressed in units of seconds, 3625 as a positive value of type decimal64 with fraction digits = 9 3626 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3627 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3628 NTP timestamp as per section 6 of RFC [RFC5905] 3630 10.4.2.3. Max 3632 The maximum SHALL be calculated using the conditional distribution of 3633 all packets with a finite value of Round-trip delay (undefined delays 3634 are excluded), a single value as follows: 3636 See section 4.1 of [RFC3393] for details on the conditional 3637 distribution to exclude undefined values of delay, and Section 5 of 3638 [RFC6703] for background on this analysis choice. 3640 See section 4.3.2 of [RFC6049] for a closely related method for 3641 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3642 as follows: 3644 Max = (FiniteDelay [j]) 3646 such that for some index, j, where 1 <= j <= N 3647 FiniteDelay[j] >= FiniteDelay[n] for all n 3649 Max The time value of the result is expressed in units of seconds, 3650 as a positive value of type decimal64 with fraction digits = 9 3651 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3652 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3653 NTP timestamp as per section 6 of RFC [RFC5905] 3655 10.4.3. Metric Units 3657 . 3660 The of Round-trip Delay is expressed in seconds, where 3661 is one of: 3663 o Mean 3665 o Min 3667 o Max 3669 The Round-trip Delay of the Hand Shake is expressed in seconds. 3671 The Round-trip Loss Count is expressed as a number of packets. 3673 10.4.4. Calibration 3675 Passive measurements at an OP could be calibrated against an active 3676 measurement (with loss emulation) at host A or B, where the active 3677 measurement represents the ground-truth. 3679 10.5. Administrative items 3680 10.5.1. Status 3682 3684 10.5.2. Requestor (keep?) 3686 name or RFC, etc. 3688 10.5.3. Revision 3690 1.0 3692 10.5.4. Revision Date 3694 YYYY-MM-DD 3696 10.6. Comments and Remarks 3698 Additional (Informational) details for this entry 3700 11. ver08 BLANK Registry Entry 3702 This section gives an initial registry entry for .... 3704 11.1. Summary 3706 This category includes multiple indexes to the registry entries, the 3707 element ID and metric name. 3709 11.1.1. ID (Identifier) 3711 3713 11.1.2. Name 3715 3717 11.1.3. URIs 3719 URI: Prefix urn:ietf:metrics:perf: 3721 URL: 3723 11.1.4. Description 3725 TBD. 3727 11.1.5. Reference 3729 3731 11.1.6. Change Controller 3733 3735 11.1.7. Version (of Registry Format) 3737 3739 11.2. Metric Definition 3741 This category includes columns to prompt the entry of all necessary 3742 details related to the metric definition, including the RFC reference 3743 and values of input factors, called fixed parameters. 3745 11.2.1. Reference Definition 3747 3749 3751 11.2.2. Fixed Parameters 3753 3757 11.3. Method of Measurement 3759 This category includes columns for references to relevant sections of 3760 the RFC(s) and any supplemental information needed to ensure an 3761 unambiguous methods for implementations. 3763 11.3.1. Reference Method 3765 3768 11.3.2. Packet Stream Generation 3770 3772 11.3.3. Traffic Filtering (observation) Details 3774 . 3778 11.3.4. Sampling Distribution 3780 3783 11.3.5. Run-time Parameters and Data Format 3785 . 3787 11.3.6. Roles 3789 3791 11.4. Output 3793 This category specifies all details of the Output of measurements 3794 using the metric. 3796 11.4.1. Type 3798 3800 11.4.2. Reference Definition 3802 3804 11.4.3. Metric Units 3806 . 3809 11.4.4. Calibration 3811 3816 11.5. Administrative items 3818 11.5.1. Status 3820 3822 11.5.2. Requestor 3824 3826 11.5.3. Revision 3828 1.0 3830 11.5.4. Revision Date 3832 YYYY-MM-DD 3834 11.6. Comments and Remarks 3836 Additional (Informational) details for this entry 3838 12. Example RTCP-XR Registry Entry 3840 This section is MAY BE DELETED or adapted before submission. 3842 This section gives an example registry entry for the end-point metric 3843 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 3844 reporting. 3846 12.1. Registry Indexes 3848 This category includes multiple indexes to the registry entries, the 3849 element ID and metric name. 3851 12.1.1. Identifier 3853 An integer having enough digits to uniquely identify each entry in 3854 the Registry. 3856 12.1.2. Name 3858 A metric naming convention is TBD. 3860 12.1.3. URI 3862 Prefix urn:ietf:metrics:param: 3864 12.1.4. Status 3866 current 3868 12.1.5. Requestor 3870 Alcelip Mornuley 3872 12.1.6. Revision 3874 1.0 3876 12.1.7. Revision Date 3878 2014-07-04 3880 12.1.8. Description 3882 TBD. 3884 12.1.9. Reference Specification(s) 3886 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 3888 12.2. Metric Definition 3890 This category includes columns to prompt the entry of all necessary 3891 details related to the metric definition, including the RFC reference 3892 and values of input factors, called fixed parameters. Section 3.2 of 3893 [RFC7003] provides the reference information for this category. 3895 12.2.1. Reference Definition 3897 Packets Discarded in Bursts: 3899 The total number of packets discarded during discard bursts. The 3900 measured value is unsigned value. If the measured value exceeds 3901 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 3902 range measurement. If the measurement is unavailable, the value 3903 0xFFFFFF MUST be reported. 3905 12.2.2. Fixed Parameters 3907 Fixed Parameters are input factors that must be determined and 3908 embedded in the measurement system for use when needed. The values 3909 of these parameters is specified in the Registry. 3911 Threshold: 8 bits, set to value = 3 packets. 3913 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 3914 successive packets that must not be discarded prior to and following 3915 a discard packet in order for this discarded packet to be regarded as 3916 part of a gap. Note that the Threshold is set in accordance with the 3917 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 3919 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 3921 This field is used to indicate whether the burst/gap discard metrics 3922 are Sampled, Interval, or Cumulative metrics [RFC6792]: 3924 I=10: Interval Duration - the reported value applies to the most 3925 recent measurement interval duration between successive metrics 3926 reports. 3928 I=11: Cumulative Duration - the reported value applies to the 3929 accumulation period characteristic of cumulative measurements. 3931 Senders MUST NOT use the values I=00 or I=01. 3933 12.3. Method of Measurement 3935 This category includes columns for references to relevant sections of 3936 the RFC(s) and any supplemental information needed to ensure an 3937 unambiguous methods for implementations. For the Burst/Gap Discard 3938 Metric, it appears that the only guidance on methods of measurement 3939 is in Section 3.0 of [RFC7003] and its supporting references. 3940 Relevant information is repeated below, although there appears to be 3941 no section titled "Method of Measurement" in [RFC7003]. 3943 12.3.1. Reference Method 3945 Metrics in this block report on burst/gap discard in the stream 3946 arriving at the RTP system. Measurements of these metrics are made 3947 at the receiving end of the RTP stream. Instances of this metrics 3948 block use the synchronization source (SSRC) to refer to the separate 3949 auxiliary Measurement Information Block [RFC6776], which describes 3950 measurement periods in use (see [RFC6776], Section 4.2). 3952 This metrics block relies on the measurement period in the 3953 Measurement Information Block indicating the span of the report. 3954 Senders MUST send this block in the same compound RTCP packet as the 3955 Measurement Information Block. Receivers MUST verify that the 3956 measurement period is received in the same compound RTCP packet as 3957 this metrics block. If not, this metrics block MUST be discarded. 3959 12.3.2. Stream Type and Stream Parameters 3961 Since RTCP-XR Measurements are conducted on live RTP traffic, the 3962 complete description of the stream is contained in SDP messages that 3963 proceed the establishment of a compatible stream between two or more 3964 communicating hosts. See Run-time Parameters, below. 3966 12.3.3. Output Type and Data Format 3968 The output type defines the type of result that the metric produces. 3970 o Value: Packets Discarded in Bursts 3972 o Data Format: 24 bits 3974 o Reference: Section 3.2 of [RFC7003] 3976 12.3.4. Metric Units 3978 The measured results are apparently expressed in packets, although 3979 there is no section of [RFC7003] titled "Metric Units". 3981 12.3.5. Run-time Parameters and Data Format 3983 Run-Time Parameters are input factors that must be determined, 3984 configured into the measurement system, and reported with the results 3985 for the context to be complete. However, the values of these 3986 parameters is not specified in the Registry, rather these parameters 3987 are listed as an aid to the measurement system implementor or user 3988 (they must be left as variables, and supplied on execution). 3990 The Data Format of each Run-time Parameter SHALL be specified in this 3991 column, to simplify the control and implementation of measurement 3992 devices. 3994 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 3996 SDP Parameters: As defined in [RFC4566] 3998 Session description v= (protocol version number, currently only 0) 3999 o= (originator and session identifier : username, id, version number, 4000 network address) 4002 s= (session name : mandatory with at least one UTF-8-encoded 4003 character) 4005 i=* (session title or short information) u=* (URI of description) 4007 e=* (zero or more email address with optional name of contacts) 4009 p=* (zero or more phone number with optional name of contacts) 4011 c=* (connection information--not required if included in all media) 4013 b=* (zero or more bandwidth information lines) One or more Time 4014 descriptions ("t=" and "r=" lines; see below) 4016 z=* (time zone adjustments) 4018 k=* (encryption key) 4020 a=* (zero or more session attribute lines) 4022 Zero or more Media descriptions (each one starting by an "m=" line; 4023 see below) 4025 m= (media name and transport address) 4027 i=* (media title or information field) 4029 c=* (connection information -- optional if included at session level) 4031 b=* (zero or more bandwidth information lines) 4033 k=* (encryption key) 4035 a=* (zero or more media attribute lines -- overriding the Session 4036 attribute lines) 4038 An example Run-time SDP description follows: 4040 v=0 4042 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 4044 s=SDP Seminar i=A Seminar on the session description protocol 4045 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 4046 Doe) 4048 c=IN IP4 233.252.0.12/127 4050 t=2873397496 2873404696 4052 a=recvonly 4054 m=audio 49170 RTP/AVP 0 4056 m=video 51372 RTP/AVP 99 4058 a=rtpmap:99 h263-1998/90000 4060 12.4. Comments and Remarks 4062 TBD. 4064 13. Revision History 4066 This section may be removed for publication. It contains overview 4067 information on updates. 4069 This draft replaced draft-mornuley-ippm-initial-registry. 4071 In version 02, Section 4 has been edited to reflect recent discussion 4072 on the ippm-list: * Removed the combination or "Raw" and left 95th 4073 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 4074 use bullet lists and other indenting formats. * Payload format for 4075 measurement has been removed. * Explanation of Conditional delay 4076 distribution. 4078 Version 03 addressed Phil Eardley's comments and suggestions in 4079 sections 1-4. and resolved the definition of Percentiles. 4081 Version 04 * All section 4 parameters reference YANG types for 4082 alternate data formats. * Discussion has concluded that usecase(s) 4083 for machine parse-able registry columns are not needed. 4085 Version 05 * Revised several Poisson streams to Periodic, sections 4 4086 & 5. * Addition of ICMP (ping) metrics in section 9. * First 4087 implementation of Passive TCP RTT metrics in section 10. 4089 14. Security Considerations 4091 These registry entries represent no known security implications for 4092 Internet Security. Each referenced Metric contains a Security 4093 Considerations section. 4095 15. IANA Considerations 4097 IANA is requested to populate The Performance Metric Registry defined 4098 in [I-D.ietf-ippm-metric-registry] with the values defined above. 4100 See the IANA Considerations section of 4101 [I-D.ietf-ippm-metric-registry] for additional requests and 4102 considerations. 4104 16. Acknowledgements 4106 The authors thank Brian Trammell for suggesting the term "Run-time 4107 Parameters", which led to the distinction between run-time and fixed 4108 parameters implemented in this memo, for identifying the IPFIX metric 4109 with Flow Key as an example, for suggesting the Passive TCP RTD 4110 metric and supporting references, and for many other productive 4111 suggestions. Thanks to Peter Koch, who provided several useful 4112 suggestions for disambiguating successive DNS Queries in the DNS 4113 Response time metric. 4115 The authors also acknowledge the constructive reviews and helpful 4116 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 4117 participants in the LMAP working group. Thanks to Michelle Cotton 4118 for her early IANA review, and to Amanda Barber for answering 4119 questions related to the presentation of the registry and 4120 accessibility of the complete template via URL. 4122 17. References 4124 17.1. Normative References 4126 [I-D.ietf-ippm-metric-registry] 4127 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 4128 "Registry for Performance Metrics", Internet Draft (work 4129 in progress) draft-ietf-ippm-metric-registry, 2014. 4131 [RFC1035] Mockapetris, P., "Domain names - implementation and 4132 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4133 November 1987, . 4135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4136 Requirement Levels", BCP 14, RFC 2119, 4137 DOI 10.17487/RFC2119, March 1997, 4138 . 4140 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 4141 "Framework for IP Performance Metrics", RFC 2330, 4142 DOI 10.17487/RFC2330, May 1998, 4143 . 4145 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 4146 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 4147 September 1999, . 4149 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 4150 Packet Loss Metric for IPPM", RFC 2680, 4151 DOI 10.17487/RFC2680, September 1999, 4152 . 4154 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 4155 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 4156 September 1999, . 4158 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4159 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4160 . 4162 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 4163 Metric for IP Performance Metrics (IPPM)", RFC 3393, 4164 DOI 10.17487/RFC3393, November 2002, 4165 . 4167 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 4168 performance measurement with periodic streams", RFC 3432, 4169 DOI 10.17487/RFC3432, November 2002, 4170 . 4172 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 4173 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 4174 DOI 10.17487/RFC4737, November 2006, 4175 . 4177 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 4178 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 4179 RFC 5357, DOI 10.17487/RFC5357, October 2008, 4180 . 4182 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 4183 RFC 5560, DOI 10.17487/RFC5560, May 2009, 4184 . 4186 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 4187 "Network Time Protocol Version 4: Protocol and Algorithms 4188 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 4189 . 4191 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 4192 the Network Configuration Protocol (NETCONF)", RFC 6020, 4193 DOI 10.17487/RFC6020, October 2010, 4194 . 4196 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 4197 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 4198 . 4200 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 4201 DOI 10.17487/RFC6673, August 2012, 4202 . 4204 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4205 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4206 . 4208 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 4209 "Specification of the IP Flow Information Export (IPFIX) 4210 Protocol for the Exchange of Flow Information", STD 77, 4211 RFC 7011, DOI 10.17487/RFC7011, September 2013, 4212 . 4214 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 4215 Scheffenegger, Ed., "TCP Extensions for High Performance", 4216 RFC 7323, DOI 10.17487/RFC7323, September 2014, 4217 . 4219 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 4220 Ed., "A One-Way Delay Metric for IP Performance Metrics 4221 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 4222 2016, . 4224 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 4225 Ed., "A One-Way Loss Metric for IP Performance Metrics 4226 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 4227 2016, . 4229 17.2. Informative References 4231 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 4232 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 4233 July 1991, . 4235 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 4236 "RTP Control Protocol Extended Reports (RTCP XR)", 4237 RFC 3611, DOI 10.17487/RFC3611, November 2003, 4238 . 4240 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 4241 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 4242 2005, . 4244 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4245 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 4246 July 2006, . 4248 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 4249 Flow Information Export (IPFIX) Applicability", RFC 5472, 4250 DOI 10.17487/RFC5472, March 2009, 4251 . 4253 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 4254 Carle, "Information Model for Packet Sampling Exports", 4255 RFC 5477, DOI 10.17487/RFC5477, March 2009, 4256 . 4258 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 4259 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 4260 March 2009, . 4262 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 4263 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 4264 DOI 10.17487/RFC6248, April 2011, 4265 . 4267 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 4268 Performance Metric Development", BCP 170, RFC 6390, 4269 DOI 10.17487/RFC6390, October 2011, 4270 . 4272 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 4273 IP Network Performance Metrics: Different Points of View", 4274 RFC 6703, DOI 10.17487/RFC6703, August 2012, 4275 . 4277 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 4278 Reporting Using a Source Description (SDES) Item and an 4279 RTCP Extended Report (XR) Block", RFC 6776, 4280 DOI 10.17487/RFC6776, October 2012, 4281 . 4283 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 4284 of the RTP Monitoring Framework", RFC 6792, 4285 DOI 10.17487/RFC6792, November 2012, 4286 . 4288 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 4289 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 4290 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 4291 September 2013, . 4293 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 4294 Aitken, P., and A. Akhter, "A Framework for Large-Scale 4295 Measurement of Broadband Performance (LMAP)", RFC 7594, 4296 DOI 10.17487/RFC7594, September 2015, 4297 . 4299 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times", 4300 September 2013. 4302 [Trammell-14] 4303 Trammell, B., "Inline Data Integrity Signals for Passive 4304 Measurement", March 2014. 4306 Authors' Addresses 4308 Al Morton 4309 AT&T Labs 4310 200 Laurel Avenue South 4311 Middletown,, NJ 07748 4312 USA 4314 Phone: +1 732 420 1571 4315 Fax: +1 732 368 1192 4316 Email: acmorton@att.com 4317 URI: http://home.comcast.net/~acmacm/ 4318 Marcelo Bagnulo 4319 Universidad Carlos III de Madrid 4320 Av. Universidad 30 4321 Leganes, Madrid 28911 4322 SPAIN 4324 Phone: 34 91 6249500 4325 Email: marcelo@it.uc3m.es 4326 URI: http://www.it.uc3m.es 4328 Philip Eardley 4329 BT 4330 Adastral Park, Martlesham Heath 4331 Ipswich 4332 ENGLAND 4334 Email: philip.eardley@bt.com 4336 Kevin D'Souza 4337 AT&T Labs 4338 200 Laurel Avenue South 4339 Middletown,, NJ 07748 4340 USA 4342 Phone: +1 732 420 xxxx 4343 Email: kld@att.com