idnits 2.17.1 draft-ietf-ippm-initial-registry-07.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 676 has weird spacing: '... Src the IP...' == Line 680 has weird spacing: '... Dst the IP...' == Line 701 has weird spacing: '... Src launch...' == Line 704 has weird spacing: '... Dst waits ...' == Line 749 has weird spacing: '...talPkts the c...' == (25 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 30, 2018) is 2125 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 4156, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 4251, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 4259, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 4264, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 4273, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 4304, 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 (~~), 14 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: January 1, 2019 UC3M 6 P. Eardley 7 BT 8 K. D'Souza 9 AT&T Labs 10 June 30, 2018 12 Initial Performance Metric Registry Entries 13 draft-ietf-ippm-initial-registry-07 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 (from comments). 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", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14[RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 1, 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Registry Categories and Columns . . . . . . . . . . . . . . . 8 71 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 9 72 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 10 74 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 10 77 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 10 78 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 10 79 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 11 80 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 11 81 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 12 82 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 12 83 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 13 84 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 14 85 4.3.3. Traffic Filtering (observation) Details . . . . . . . 14 86 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 15 87 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 15 88 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 16 92 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 17 93 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 17 94 4.5. Administrative items . . . . . . . . . . . . . . . . . . 18 95 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18 96 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 18 97 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 18 98 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 . . . . . . . . . . . . . . . . 28 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 147 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 34 148 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34 149 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 34 150 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 35 151 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 35 152 6.5. Administrative items . . . . . . . . . . . . . . . . . . 35 153 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 35 154 6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 35 155 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 35 156 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 36 157 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 36 158 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 36 159 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36 160 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 36 161 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 36 162 7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 37 163 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 37 164 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 37 165 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 38 166 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 38 167 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 39 168 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 40 169 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 40 170 7.3.3. Traffic Filtering (observation) Details . . . . . . . 41 171 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 41 172 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 41 173 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 42 174 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 42 175 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 42 176 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 42 177 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 45 178 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 45 179 7.5. Administrative items . . . . . . . . . . . . . . . . . . 46 180 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 46 181 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 46 182 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 46 183 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 47 184 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 47 185 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 47 186 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 47 187 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 47 188 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 47 189 8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 48 190 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 48 191 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 48 192 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 49 193 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 49 194 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 50 195 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 51 196 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 51 197 8.3.3. Traffic Filtering (observation) Details . . . . . . . 52 198 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 52 199 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 52 200 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 53 201 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 53 202 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 203 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 53 204 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56 205 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56 206 8.5. Administrative items . . . . . . . . . . . . . . . . . . 57 207 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 57 208 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 57 209 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 57 210 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 58 211 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 58 212 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 58 213 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 58 214 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 58 215 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 58 216 9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 59 217 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 59 218 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 59 219 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 59 220 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 59 221 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 59 222 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 60 223 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 61 224 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 61 225 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 62 226 9.3.3. Traffic Filtering (observation) Details . . . . . . . 63 227 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 63 228 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 63 229 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 64 230 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 64 231 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 64 232 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 64 233 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 66 234 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 67 235 9.5. Administrative items . . . . . . . . . . . . . . . . . . 67 236 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 67 237 9.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 67 238 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 67 239 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 67 240 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 . . . . . . . . . . . . . . . . . 72 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 291 11.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 81 292 11.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 81 293 11.4.2. Reference Definition . . . . . . . . . . . . . . . . 81 294 11.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 81 295 11.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 81 296 11.5. Administrative items . . . . . . . . . . . . . . . . . . 82 297 11.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 82 298 11.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 82 299 11.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 82 300 11.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 82 301 11.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 82 302 12. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 82 303 12.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 82 304 12.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 82 305 12.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 82 306 12.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 83 307 12.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 83 308 12.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 83 309 12.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 83 310 12.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 83 311 12.1.8. Description . . . . . . . . . . . . . . . . . . . . 83 312 12.1.9. Reference Specification(s) . . . . . . . . . . . . . 83 313 12.2. Metric Definition . . . . . . . . . . . . . . . . . . . 83 314 12.2.1. Reference Definition . . . . . . . . . . . . . . . . 83 315 12.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 84 316 12.3. Method of Measurement . . . . . . . . . . . . . . . . . 84 317 12.3.1. Reference Method . . . . . . . . . . . . . . . . . . 84 318 12.3.2. Stream Type and Stream Parameters . . . . . . . . . 85 319 12.3.3. Output Type and Data Format . . . . . . . . . . . . 85 320 12.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 85 321 12.3.5. Run-time Parameters and Data Format . . . . . . . . 85 322 12.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 87 323 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 87 324 14. Security Considerations . . . . . . . . . . . . . . . . . . . 88 325 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 326 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88 327 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 328 17.1. Normative References . . . . . . . . . . . . . . . . . . 88 329 17.2. Informative References . . . . . . . . . . . . . . . . . 91 330 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 332 1. Introduction 334 Note: Efforts to synchronize structure and terminology with 335 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 336 drafts are stable. 338 This memo proposes an initial set of entries for the Performance 339 Metric Registry. It uses terms and definitions from the IPPM 340 literature, primarily [RFC2330]. 342 Although there are several standard templates for organizing 343 specifications of performance metrics (see [RFC2679] for an example 344 of the traditional IPPM template, based to large extent on the 345 Benchmarking Methodology Working Group's traditional template in 346 [RFC1242], and see [RFC6390] for a similar template), none of these 347 templates were intended to become the basis for the columns of an 348 IETF-wide registry of metrics. While examining aspects of metric 349 specifications which need to be registered, it became clear that none 350 of the existing metric templates fully satisfies the particular needs 351 of a registry. 353 Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format 354 for a Performance Metric Registry. Section 5 of 355 [I-D.ietf-ippm-metric-registry] also gives guidelines for those 356 requesting registration of a Metric, that is the creation of entry(s) 357 in the Performance Metric Registry: "In essence, there needs to be 358 evidence that a candidate Registered Performance Metric has 359 significant industry interest, or has seen deployment, and there is 360 agreement that the candidate Registered Performance Metric serves its 361 intended purpose." The process in [I-D.ietf-ippm-metric-registry] 362 also requires that new entries are administered by IANA through 363 Expert Review, which will ensure that the metrics are tightly 364 defined. 366 2. Scope 368 This document defines the initial set of Performance Metrics Registry 369 entries, for which IETF approval (following development in the IP 370 Performance Metrics (IPPM) Working Group) will satisfy the 371 requirement for Expert Review. Most are Active Performance Metrics, 372 which are based on RFCs prepared in the IPPM working group of the 373 IETF, according to their framework [RFC2330] and its updates. 375 3. Registry Categories and Columns 377 This section provides the categories and columns of the registry, for 378 easy reference. An entry (row) therefore gives a complete 379 description of a Registered Metric. 381 Registry Categories and Columns, shown as 382 Category 383 ------------------ 384 Column | Column | 386 Summary 387 ------------------------------------------------------------------------ 388 Identifier | Name | URIs | Desc. | Reference | Change Controller | Ver | 390 Metric Definition 391 ----------------------------------------- 392 Reference Definition | Fixed Parameters | 394 Method of Measurement 395 --------------------------------------------------------------------- 396 Reference | Packet | Traffic | Sampling | Run-time | Role | 397 Method | Stream | Filter | Distribution | Parameters | | 398 | Generation | 399 Output 400 ----------------------------------------- 401 Type | Reference | Units | Calibration | 402 | Definition | | | 404 Administrative Information 405 ---------------------------------- 406 Status |Request | Rev | Rev.Date | 408 Comments and Remarks 409 -------------------- 411 4. UDP Round-trip Latency and Loss Registry Entries 413 This section specifies an initial registry entry for the UDP Round- 414 trip Latency, and another entry for UDP Round-trip Loss Ratio. 416 Note: Each Registry entry only produces a "raw" output or a 417 statistical summary. To describe both "raw" and one or more 418 statistics efficiently, the Identifier, Name, and Output Categories 419 can be split and a single section can specify two or more closely- 420 related metrics. This section specifies two Registry entries with 421 many common columns. See Section 7 for an example specifying 422 multiple Registry entries with many common columns. 424 All column entries beside the ID, Name, Description, and Output 425 Reference Method categories are the same, thus this section proposes 426 two closely-related registry entries. As a result, IANA is also 427 asked to assign corresponding URNs and URLs to each Named Metric. 429 4.1. Summary 431 This category includes multiple indexes to the registry entry: the 432 element ID and metric name. 434 4.1.1. ID (Identifier) 436 438 IANA is asked to assign different numeric identifiers to each of the 439 two Named Metrics. 441 4.1.2. Name 443 445 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 447 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio 449 4.1.3. URIs 451 URN: Prefix urn:ietf:metrics:perf: 453 URL: http:/// 455 4.1.4. Description 457 RTDelay: This metric assesses the delay of a stream of packets 458 exchanged between two hosts (which are the two measurement points), 459 and the Output is the Round-trip delay for all successfully exchanged 460 packets expressed as the 95th percentile of their conditional delay 461 distribution. 463 RTLoss: This metric assesses the loss ratio of a stream of packets 464 exchanged between two hosts (which are the two measurement points), 465 and the Output is the Round-trip loss ratio for all successfully 466 exchanged packets expressed as a percentage. 468 4.1.5. Change Controller 470 IETF 472 4.1.6. Version (of Registry Format) 474 1.0 476 4.2. Metric Definition 478 This category includes columns to prompt the entry of all necessary 479 details related to the metric definition, including the RFC reference 480 and values of input factors, called fixed parameters. 482 4.2.1. Reference Definition 484 486 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 487 Metric for IPPM", RFC 2681, September 1999. 489 [RFC2681] 491 493 Section 2.4 of [RFC2681] provides the reference definition of the 494 singleton (single value) Round-trip delay metric. Section 3.4 of 495 [RFC2681] provides the reference definition expanded to cover a 496 multi-singleton sample. Note that terms such as singleton and sample 497 are defined in Section 11 of [RFC2330]. 499 Note that although the [RFC2681] definition of "Round-trip-Delay 500 between Src and Dst" is directionally ambiguous in the text, this 501 metric tightens the definition further to recognize that the host in 502 the "Src" role will send the first packet to "Dst", and ultimately 503 receive the corresponding return packet from "Dst" (when neither are 504 lost). 506 Finally, note that the variable "dT" is used in [RFC2681] to refer to 507 the value of Round-trip delay in metric definitions and methods. The 508 variable "dT" has been re-used in other IPPM literature to refer to 509 different quantities, and cannot be used as a global variable name. 511 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 513 [RFC6673] 515 Both delay and loss metrics employ a maximum waiting time for 516 received packets, so the count of lost packets to total packets sent 517 is the basis for the loss ratio calculation as per Section 6.1 of 518 [RFC6673]. 520 4.2.2. Fixed Parameters 522 526 Type-P as defined in Section 13 of [RFC2330]: 528 o IPv4 header values: 530 * DSCP: set to 0 532 * TTL: set to 255 534 * Protocol: Set to 17 (UDP) 536 o IPv6 header values: 538 * DSCP: set to 0 540 * Hop Count: set to 255 542 * Protocol: Set to 17 (UDP) 544 o UDP header values: 546 * Checksum: the checksum MUST be calculated and included in the 547 header 549 o UDP Payload 551 * total of 100 bytes 553 Other measurement parameters: 555 o Tmax: a loss threshold waiting time 557 * 3.0, expressed in units of seconds, as a positive value of type 558 decimal64 with fraction digits = 4 (see section 9.3 of 559 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 560 lossless conversion to/from the 32-bit NTP timestamp as per 561 section 6 of [RFC5905]. 563 4.3. Method of Measurement 565 This category includes columns for references to relevant sections of 566 the RFC(s) and any supplemental information needed to ensure an 567 unambiguous methods for implementations. 569 4.3.1. Reference Method 571 574 The methodology for this metric is defined as Type-P-Round-trip- 575 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 576 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 577 Fixed Parameters. However, the Periodic stream will be generated 578 according to [RFC3432]. 580 The reference method distinguishes between long-delayed packets and 581 lost packets by implementing a maximum waiting time for packet 582 arrival. Tmax is the waiting time used as the threshold to declare a 583 packet lost. Lost packets SHALL be designated as having undefined 584 delay, and counted for the RTLoss metric. 586 The calculations on the delay (RTT) SHALL be performed on the 587 conditional distribution, conditioned on successful packet arrival 588 within Tmax. Also, when all packet delays are stored, the process 589 which calculates the RTT value MAY enforce the Tmax threshold on 590 stored values before calculations. See section 4.1 of [RFC3393] for 591 details on the conditional distribution to exclude undefined values 592 of delay, and Section 5 of [RFC6703] for background on this analysis 593 choice. 595 The reference method requires some way to distinguish between 596 different packets in a stream to establish correspondence between 597 sending times and receiving times for each successfully-arriving 598 packet. Sequence numbers or other send-order identification MUST be 599 retained at the Src or included with each packet to disambiguate 600 packet reordering if it occurs. 602 If a standard measurement protocol is employed, then the measurement 603 process will determine the sequence numbers or timestamps applied to 604 test packets after the Fixed and Runtime parameters are passed to 605 that process. The chosen measurement protocol will dictate the 606 format of sequence numbers and time-stamps, if they are conveyed in 607 the packet payload. 609 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 610 instruction to "send a Type-P packet back to the Src as quickly as 611 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 612 [RFC6673] presents additional requirements which MUST be included in 613 the method of measurement for this metric. 615 4.3.2. Packet Stream Generation 617 619 This section gives the details of the packet traffic which is the 620 basis for measurement. In IPPM metrics, this is called the Stream, 621 and can easily be described by providing the list of stream 622 parameters. 624 Section 3 of [RFC3432] prescribes the method for generating Periodic 625 streams using associated parameters. 627 incT the nominal duration of inter-packet interval, first bit to 628 first bit, with value 0.0200, expressed in units of seconds, as a 629 positive value of type decimal64 with fraction digits = 4 (see 630 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 631 (0.1 ms). 633 dT the duration of the interval for allowed sample start times, with 634 value 1.0, expressed in units of seconds, as a positive value of 635 type decimal64 with fraction digits = 4 (see section 9.3 of 636 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 638 T0 the actual start time of the periodic stream, (format "date-and- 639 time" as specified in Section 5.6 of [RFC3339], see also Section 3 640 of [RFC6991]). 642 NOTE: an initiation process with a number of control exchanges 643 resulting in unpredictable start times (within a time interval) may 644 be sufficient to avoid synchronization of periodic streams, and 645 therefore a valid replacement for selecting a start time at random 646 from a fixed interval. 648 The T0 parameter will be reported as a measured parameter. 649 Parameters incT and dT are Fixed Parameters. 651 4.3.3. Traffic Filtering (observation) Details 653 The measured results based on a filtered version of the packets 654 observed, and this section provides the filter details (when 655 present). 657
. 659 NA 661 4.3.4. Sampling Distribution 663 666 NA 668 4.3.5. Run-time Parameters and Data Format 670 Run-time Parameters are input factors that must be determined, 671 configured into the measurement system, and reported with the results 672 for the context to be complete. 674 676 Src the IP address of the host in the Src Role (format ipv4-address- 677 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 678 see Section 4 of [RFC6991]) 680 Dst the IP address of the host in the Dst Role (format ipv4-address- 681 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 682 see section 4 of [RFC6991]) 684 T0 a time, the start of a measurement interval, (format "date-and- 685 time" as specified in Section 5.6 of [RFC3339], see also Section 3 686 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 687 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 688 and Tf is to be interpreted as the Duration of the measurement 689 interval. The start time is controlled through other means. 691 Tf a time, the end of a measurement interval, (format "date-and-time" 692 as specified in Section 5.6 of [RFC3339], see also Section 3 of 693 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 694 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 695 Tf is interpreted as the Duration of the measurement interval. 697 4.3.6. Roles 699 701 Src launches each packet and waits for return transmissions from 702 Dst. 704 Dst waits for each packet from Src and sends a return packet to Src. 706 4.4. Output 708 This category specifies all details of the Output of measurements 709 using the metric. 711 4.4.1. Type 713 715 Percentile -- for the conditional distribution of all packets with a 716 valid value of Round-trip delay (undefined delays are excluded), a 717 single value corresponding to the 95th percentile, as follows: 719 See section 4.1 of [RFC3393] for details on the conditional 720 distribution to exclude undefined values of delay, and Section 5 of 721 [RFC6703] for background on this analysis choice. 723 The percentile = 95, meaning that the reported delay, "95Percentile", 724 is the smallest value of Round-trip delay for which the Empirical 725 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 726 Round-trip delay values in the conditional distribution. See section 727 11.3 of [RFC2330] for the definition of the percentile statistic 728 using the EDF. 730 LossRatio -- the count of lost packets to total packets sent is the 731 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 733 4.4.2. Reference Definition 735 737 For all outputs --- 739 T0 the start of a measurement interval, (format "date-and-time" as 740 specified in Section 5.6 of [RFC3339], see also Section 3 of 741 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 742 [RFC2330]. 744 Tf the end of a measurement interval, (format "date-and-time" as 745 specified in Section 5.6 of [RFC3339], see also Section 3 of 746 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 747 [RFC2330]. 749 TotalPkts the count of packets sent by the Src to Dst during the 750 measurement interval. 752 For 753 RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile: 755 95Percentile The time value of the result is expressed in units of 756 seconds, as a positive value of type decimal64 with fraction 757 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 758 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 759 the 64-bit NTP timestamp as 761 For 763 RTLoss_Active_IP-UDP-Periodic_RFCXXXXsecY_Percent_LossRatio: 765 Percentile The numeric value of the result is expressed in units of 766 lost packets to total packets times 100%, as a positive value of 767 type decimal64 with fraction digits = 9 (see section 9.3 of 768 [RFC6020]) with resolution of 0.0000000001. 770 4.4.3. Metric Units 772 . 775 The 95th Percentile of Round-trip Delay is expressed in seconds. 777 The Round-trip Loss Ratio is expressed as a percentage of lost 778 packets to total packets sent. 780 4.4.4. Calibration 782 Section 3.7.3 of [RFC7679] provides a means to quantify the 783 systematic and random errors of a time measurement. In-situ 784 calibration could be enabled with an internal loopback at the Source 785 host that includes as much of the measurement system as possible, 786 performs address manipulation as needed, and provides some form of 787 isolation (e.g., deterministic delay) to avoid send-receive interface 788 contention. Some portion of the random and systematic error can be 789 characterized this way. 791 When a measurement controller requests a calibration measurement, the 792 loopback is applied and the result is output in the same format as a 793 normal measurement with additional indication that it is a 794 calibration result. 796 Both internal loopback calibration and clock synchronization can be 797 used to estimate the *available accuracy* of the Output Metric Units. 798 For example, repeated loopback delay measurements will reveal the 799 portion of the Output result resolution which is the result of system 800 noise, and thus inaccurate. 802 4.5. Administrative items 804 4.5.1. Status 806 808 4.5.2. Requestor (keep?) 810 name or RFC, etc. 812 4.5.3. Revision 814 1.0 816 4.5.4. Revision Date 818 YYYY-MM-DD 820 4.6. Comments and Remarks 822 Additional (Informational) details for this entry 824 5. Packet Delay Variation Registry Entry 826 This section gives an initial registry entry for a Packet Delay 827 Variation metric. 829 Note: If each Registry entry should only produce a "raw" output or a 830 statistical summary, then the "Output" Category can be split and this 831 section can become two closely-related metrics. 833 5.1. Summary 835 This category includes multiple indexes to the registry entries, the 836 element ID and metric name. 838 840 5.1.1. ID (Identifier) 842 844 5.1.2. Name 846 848 OWPDV_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile 850 5.1.3. URIs 852 URI: Prefix urn:ietf:metrics:perf: 854 URL: http:/// 856 5.1.4. Description 858 An assessment of packet delay variation with respect to the minimum 859 delay observed on the periodic stream, and the Output is expressed as 860 the 95th percentile of the packet delay variation distribution. 862 5.1.5. Change Controller 864 866 IETF 868 5.1.6. Version (of Registry Format) 870 1.0 872 5.2. Metric Definition 874 This category includes columns to prompt the entry of all necessary 875 details related to the metric definition, including the RFC reference 876 and values of input factors, called fixed parameters. 878 5.2.1. Reference Definition 880 882 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 883 Performance Metrics", RFC 2330, May 1998. [RFC2330] 885 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 886 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 887 [RFC3393] 889 Morton, A. and B. Claise, "Packet Delay Variation Applicability 890 Statement", RFC 5481, March 2009. [RFC5481] 892 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 893 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 894 June 2010.[RFC5905] 896 897 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 898 measured are referred to by the variable name "ddT" (applicable to 899 all forms of delay variation). However, this metric entry specifies 900 the PDV form defined in section 4.2 of [RFC5481], where the singleton 901 PDV for packet i is referred to by the variable name "PDV(i)". 903 5.2.2. Fixed Parameters 905 909 o IPv4 header values: 911 * DSCP: set to 0 913 * TTL: set to 255 915 * Protocol: Set to 17 (UDP) 917 o IPv6 header values: 919 * DSCP: set to 0 921 * Hop Count: set to 255 923 * Protocol: Set to 17 (UDP) 925 o UDP header values: 927 * Checksum: the checksum MUST be calculated and included in the 928 header 930 o UDP Payload 932 * total of 200 bytes 934 Other measurement parameters: 936 Tmax: a loss threshold waiting time with value 3.0, expressed in 937 units of seconds, as a positive value of type decimal64 with 938 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 939 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 940 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 942 F a selection function unambiguously defining the packets from the 943 stream selected for the metric. See section 4.2 of [RFC5481] for 944 the PDV form. 946 See the Packet Stream generation category for two additional Fixed 947 Parameters. 949 5.3. Method of Measurement 951 This category includes columns for references to relevant sections of 952 the RFC(s) and any supplemental information needed to ensure an 953 unambiguous methods for implementations. 955 5.3.1. Reference Method 957 960 See section 2.6 and 3.6 of [RFC3393] for general singleton element 961 calculations. This metric entry requires implementation of the PDV 962 form defined in section 4.2 of [RFC5481]. Also see measurement 963 considerations in section 8 of [RFC5481]. 965 The reference method distinguishes between long-delayed packets and 966 lost packets by implementing a maximum waiting time for packet 967 arrival. Tmax is the waiting time used as the threshold to declare a 968 packet lost. Lost packets SHALL be designated as having undefined 969 delay. 971 The calculations on the one-way delay SHALL be performed on the 972 conditional distribution, conditioned on successful packet arrival 973 within Tmax. Also, when all packet delays are stored, the process 974 which calculates the one-way delay value MAY enforce the Tmax 975 threshold on stored values before calculations. See section 4.1 of 976 [RFC3393] for details on the conditional distribution to exclude 977 undefined values of delay, and Section 5 of [RFC6703] for background 978 on this analysis choice. 980 The reference method requires some way to distinguish between 981 different packets in a stream to establish correspondence between 982 sending times and receiving times for each successfully-arriving 983 packet. Sequence numbers or other send-order identification MUST be 984 retained at the Src or included with each packet to disambiguate 985 packet reordering if it occurs. 987 If a standard measurement protocol is employed, then the measurement 988 process will determine the sequence numbers or timestamps applied to 989 test packets after the Fixed and Runtime parameters are passed to 990 that process. The chosen measurement protocol will dictate the 991 format of sequence numbers and time-stamps, if they are conveyed in 992 the packet payload. 994 5.3.2. Packet Stream Generation 996 998 This section gives the details of the packet traffic which is the 999 basis for measurement. In IPPM metrics, this is called the Stream, 1000 and can easily be described by providing the list of stream 1001 parameters. 1003 Section 3 of [RFC3432] prescribes the method for generating Periodic 1004 streams using associated parameters. 1006 incT the nominal duration of inter-packet interval, first bit to 1007 first bit, with value 0.0200, expressed in units of seconds, as a 1008 positive value of type decimal64 with fraction digits = 4 (see 1009 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds 1010 (0.1 ms). 1012 dT the duration of the interval for allowed sample start times, with 1013 value 1.0, expressed in units of seconds, as a positive value of 1014 type decimal64 with fraction digits = 4 (see section 9.3 of 1015 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). 1017 T0 the actual start time of the periodic stream, (format "date-and- 1018 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1019 of [RFC6991]). 1021 NOTE: an initiation process with a number of control exchanges 1022 resulting in unpredictable start times (within a time interval) may 1023 be sufficient to avoid synchronization of periodic streams, and 1024 therefore a valid replacement for selecting a start time at random 1025 from a fixed interval. 1027 The T0 parameter will be reported as a measured parameter. 1028 Parameters incT and dT are Fixed Parameters. 1030 5.3.3. Traffic Filtering (observation) Details 1032 . 1036 NA 1038 5.3.4. Sampling Distribution 1040 1043 NA 1045 5.3.5. Run-time Parameters and Data Format 1047 1049 Src the IP address of the host in the Src Role (format ipv4-address- 1050 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1051 see Section 4 of [RFC6991]) 1053 Dst the IP address of the host in the Dst Role (format ipv4-address- 1054 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1055 see section 4 of [RFC6991]) 1057 T0 a time, the start of a measurement interval, (format "date-and- 1058 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1059 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1060 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1061 and Tf is to be interpreted as the Duration of the measurement 1062 interval. The start time is controlled through other means. 1064 Tf a time, the end of a measurement interval, (format "date-and-time" 1065 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1066 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1067 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1068 Tf is interpreted as the Duration of the measurement interval. 1070 5.3.6. Roles 1072 1074 Src launches each packet to Dst. 1076 Dst waits for each packet from Src. 1078 5.4. Output 1080 This category specifies all details of the Output of measurements 1081 using the metric. 1083 5.4.1. Type 1085 1087 Percentile -- for the conditional distribution of all packets with a 1088 valid value of one-way delay (undefined delays are excluded), a 1089 single value corresponding to the 95th percentile, as follows: 1091 See section 4.1 of [RFC3393] for details on the conditional 1092 distribution to exclude undefined values of delay, and Section 5 of 1093 [RFC6703] for background on this analysis choice. 1095 The percentile = 95, meaning that the reported delay, "95Percentile", 1096 is the smallest value of one-way PDV for which the Empirical 1097 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 1098 one-way PDV values in the conditional distribution. See section 11.3 1099 of [RFC2330] for the definition of the percentile statistic using the 1100 EDF. 1102 5.4.2. Reference Definition 1104 1106 T0 the start of a measurement interval, (format "date-and-time" as 1107 specified in Section 5.6 of [RFC3339], see also Section 3 of 1108 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1109 [RFC2330]. 1111 Tf the end of a measurement interval, (format "date-and-time" as 1112 specified in Section 5.6 of [RFC3339], see also Section 3 of 1113 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1114 [RFC2330]. 1116 95Percentile The time value of the result is expressed in units of 1117 seconds, as a positive value of type decimal64 with fraction 1118 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 1119 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 1120 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 1122 5.4.3. Metric Units 1124 . 1127 The 95th Percentile of one-way PDV is expressed in seconds. 1129 5.4.4. Calibration 1131 Section 3.7.3 of [RFC7679] provides a means to quantify the 1132 systematic and random errors of a time measurement. In-situ 1133 calibration could be enabled with an internal loopback that includes 1134 as much of the measurement system as possible, performs address 1135 manipulation as needed, and provides some form of isolation (e.g., 1136 deterministic delay) to avoid send-receive interface contention. 1137 Some portion of the random and systematic error can be characterized 1138 this way. 1140 For one-way delay measurements, the error calibration must include an 1141 assessment of the internal clock synchronization with its external 1142 reference (this internal clock is supplying timestamps for 1143 measurement). In practice, the time offsets of clocks at both the 1144 source and destination are needed to estimate the systematic error 1145 due to imperfect clock synchronization (the time offsets are 1146 smoothed, thus the random variation is not usually represented in the 1147 results). 1149 time_offset The time value of the result is expressed in units of 1150 seconds, as a signed value of type decimal64 with fraction digits 1151 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 1152 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 1153 NTP timestamp as per section 6 of RFC [RFC5905] 1155 When a measurement controller requests a calibration measurement, the 1156 loopback is applied and the result is output in the same format as a 1157 normal measurement with additional indication that it is a 1158 calibration result. In any measurement, the measurement function 1159 SHOULD report its current estimate of time offset as an indicator of 1160 the degree of synchronization. 1162 Both internal loopback calibration and clock synchronization can be 1163 used to estimate the *available accuracy* of the Output Metric Units. 1164 For example, repeated loopback delay measurements will reveal the 1165 portion of the Output result resolution which is the result of system 1166 noise, and thus inaccurate. 1168 5.5. Administrative items 1170 5.5.1. Status 1172 1174 5.5.2. Requestor (keep?) 1176 1178 5.5.3. Revision 1180 1.0 1182 5.5.4. Revision Date 1184 YYYY-MM-DD 1186 5.6. Comments and Remarks 1188 1190 Lost packets represent a challenge for delay variation metrics. See 1191 section 4.1 of [RFC3393] and the delay variation applicability 1192 statement[RFC5481] for extensive analysis and comparison of PDV and 1193 an alternate metric, IPDV. 1195 6. DNS Response Latency and Loss Registry Entries 1197 @@@@ comment from Brian: there is an interesting method for DNS 1198 measurement by encoding information in the query itself. It is a 1199 question of what exactly we are trying to measure: specific RR, or 1200 the infrastructure itself. (at this time we measure a specific RR). 1202 This section gives initial registry entries for DNS Response Latency 1203 and Loss from a network user's perspective, for a specific named 1204 resource. The metric can be measured repeatedly using different 1205 names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 1206 build on that metric by specifying several of the input parameters to 1207 precisely define two metrics for measuring DNS latency and loss. 1209 Note to IANA: Each Registry "Name" below specifies a single registry 1210 entry, whose output format varies in accordance with the name. 1212 All column entries beside the ID, Name, Description, and Output 1213 Reference Method categories are the same, thus this section proposes 1214 two closely-related registry entries. As a result, IANA is also 1215 asked to assign corresponding URNs and URLs to each Named Metric. 1217 6.1. Summary 1219 This category includes multiple indexes to the registry entries, the 1220 element ID and metric name. 1222 1224 6.1.1. ID (Identifier) 1226 1228 IANA is asked to assign different numeric identifiers to each of the 1229 two Named Metrics. 1231 6.1.2. Name 1233 1235 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw 1237 RLDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Logical_Raw 1239 6.1.3. URI 1241 URI: Prefix urn:ietf:metrics:perf: 1243 URL: http:/// 1245 6.1.4. Description 1247 This is a metric for DNS Response performance from a network user's 1248 perspective, for a specific named resource. The metric can be 1249 measured repeatedly using different resource names. 1251 RTDNS: This metric assesses the response time, the interval from the 1252 query transmission to the response. 1254 RLDNS: This metric indicates that the response was deemed lost. In 1255 other words, the response time exceeded the maximum waiting time. 1257 6.1.5. Change Controller 1259 IETF 1261 6.1.6. Version (of Registry Format) 1263 1.0 1265 6.2. Metric Definition 1267 This category includes columns to prompt the entry of all necessary 1268 details related to the metric definition, including the RFC reference 1269 and values of input factors, called fixed parameters. 1271 6.2.1. Reference Definition 1273 1275 Mockapetris, P., "Domain names - implementation and specification", 1276 STD 13, RFC 1035, November 1987. (and updates) 1278 [RFC1035] 1280 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1281 Metric for IPPM", RFC 2681, September 1999. 1283 [RFC2681] 1285 1287 Section 2.4 of [RFC2681] provides the reference definition of the 1288 singleton (single value) Round-trip delay metric. Section 3.4 of 1289 [RFC2681] provides the reference definition expanded to cover a 1290 multi-singleton sample. Note that terms such as singleton and sample 1291 are defined in Section 11 of [RFC2330]. 1293 For DNS Response Latency, the entities in [RFC1035] must be mapped to 1294 [RFC2681]. The Local Host with its User Program and Resolver take 1295 the role of "Src", and the Foreign Name Server takes the role of 1296 "Dst". 1298 Note that although the [RFC2681] definition of "Round-trip-Delay 1299 between Src and Dst at T" is directionally ambiguous in the text, 1300 this metric tightens the definition further to recognize that the 1301 host in the "Src" role will send the first packet to "Dst", and 1302 ultimately receive the corresponding return packet from "Dst" (when 1303 neither are lost). 1305 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 1307 [RFC6673] 1309 Both response time and loss metrics employ a maximum waiting time for 1310 received responses, so the count of lost packets to total packets 1311 sent is the basis for the loss determination as per Section 4.3 of 1312 [RFC6673]. 1314 6.2.2. Fixed Parameters 1316 1319 Type-P as defined in Section 13 of [RFC2330]: 1321 o IPv4 header values: 1323 * DSCP: set to 0 1325 * TTL set to 255 1327 * Protocol: Set to 17 (UDP) 1329 o IPv6 header values: 1331 * DSCP: set to 0 1333 * Hop Count: set to 255 1335 * Protocol: Set to 17 (UDP) 1337 o UDP header values: 1339 * Source port: 53 1341 * Destination port: 53 1343 * Checksum: the checksum must be calculated and included in the 1344 header 1346 o Payload: The payload contains a DNS message as defined in RFC 1035 1347 [RFC1035] with the following values: 1349 * The DNS header section contains: 1351 + Identification (see the Run-time column) 1353 + QR: set to 0 (Query) 1355 + OPCODE: set to 0 (standard query) 1357 + AA: not set 1359 + TC: not set 1361 + RD: set to one (recursion desired) 1363 + RA: not set 1365 + RCODE: not set 1366 + QDCOUNT: set to one (only one entry) 1368 + ANCOUNT: not set 1370 + NSCOUNT: not set 1372 + ARCOUNT: not set 1374 * The Question section contains: 1376 + QNAME: the Fully Qualified Domain Name (FQDN) provided as 1377 input for the test, see the Run-time column 1379 + QTYPE: the query type provided as input for the test, see 1380 the Run-time column 1382 + QCLASS: set to 1 for IN 1384 * The other sections do not contain any Resource Records. 1386 Other measurement parameters: 1388 o Tmax: a loss threshold waiting time (and to help disambiguate 1389 queries) 1391 * 5.0, expressed in units of seconds, as a positive value of type 1392 decimal64 with fraction digits = 4 (see section 9.3 of 1393 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 1394 lossless conversion to/from the 32-bit NTP timestamp as per 1395 section 6 of [RFC5905]. 1397 Observation: reply packets will contain a DNS response and may 1398 contain RRs. 1400 6.3. Method of Measurement 1402 This category includes columns for references to relevant sections of 1403 the RFC(s) and any supplemental information needed to ensure an 1404 unambiguous methods for implementations. 1406 6.3.1. Reference Method 1408 1411 The methodology for this metric is defined as Type-P-Round-trip- 1412 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1413 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1414 Fixed Parameters. 1416 The reference method distinguishes between long-delayed packets and 1417 lost packets by implementing a maximum waiting time for packet 1418 arrival. Tmax is the waiting time used as the threshold to declare a 1419 packet lost. Lost packets SHALL be designated as having undefined 1420 delay, and counted for the RLDNS metric. 1422 The calculations on the delay (RTT) SHALL be performed on the 1423 conditional distribution, conditioned on successful packet arrival 1424 within Tmax. Also, when all packet delays are stored, the process 1425 which calculates the RTT value MAY enforce the Tmax threshold on 1426 stored values before calculations. See section 4.1 of [RFC3393] for 1427 details on the conditional distribution to exclude undefined values 1428 of delay, and Section 5 of [RFC6703] for background on this analysis 1429 choice. 1431 The reference method requires some way to distinguish between 1432 different packets in a stream to establish correspondence between 1433 sending times and receiving times for each successfully-arriving 1434 reply. Therefore, sequence numbers or other send-order 1435 identification MUST be retained at the Src or included with each 1436 packet to disambiguate packet reordering if it occurs. Sequence 1437 number is part of the payload described under Fixed Parameters. 1439 DNS Messages bearing Queries provide for random ID Numbers in the 1440 Identification header field, so more than one query may be launched 1441 while a previous request is outstanding when the ID Number is used. 1443 IF a DNS response does not arrive within Tmax, the response time is 1444 undefined, and RTDNS = 1. The Message ID SHALL be used to 1445 disambiguate the successive queries. 1447 @@@@ This would require support of ID generation and population in 1448 the Message. An alternative would be to use a random Source port on 1449 the Query Message, but we would choose ONE before proceeding. 1451 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1452 instruction to "send a Type-P packet back to the Src as quickly as 1453 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1454 [RFC6673] presents additional requirements which shall be included in 1455 the method of measurement for this metric. 1457 In addition to operations described in [RFC2681], the Src MUST parse 1458 the DNS headers of the reply and prepare the information for 1459 subsequent reporting as a measured result, along with the Round-Trip 1460 Delay. 1462 6.3.2. Packet Stream Generation 1464 This section gives the details of the packet traffic which is the 1465 basis for measurement. In IPPM metrics, this is called the Stream, 1466 and can easily be described by providing the list of stream 1467 parameters. 1469 1471 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1472 generate Poisson sampling intervals. The reciprocal of lambda is the 1473 average packet rate, thus the Run-time Parameter is Reciprocal_lambda 1474 = 1/lambda, in seconds. 1476 Method 3 is used, where given a start time (Run-time Parameter), the 1477 subsequent send times are all computed prior to measurement by 1478 computing the pseudo-random distribution of inter-packet send times, 1479 (truncating the distribution as specified in the Run-time 1480 Parameters), and the Src sends each packet at the computed times. 1482 Note that Trunc is the upper limit on inter-packet times in the 1483 Poisson distribution. A random value greater than Trunc is set equal 1484 to Trunc instead. 1486 6.3.3. Traffic Filtering (observation) Details 1488 The measured results based on a filtered version of the packets 1489 observed, and this section provides the filter details (when 1490 present). 1492
. 1494 NA 1496 6.3.4. Sampling Distribution 1498 1501 NA 1503 6.3.5. Run-time Parameters and Data Format 1505 Run-time Parameters are input factors that must be determined, 1506 configured into the measurement system, and reported with the results 1507 for the context to be complete. 1509 1510 Src the IP address of the host in the Src Role (format ipv4-address- 1511 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1512 see Section 4 of [RFC6991]) 1514 Dst the IP address of the host in the Dst Role (format ipv4-address- 1515 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1516 see section 4 of [RFC6991]) 1518 T0 a time, the start of a measurement interval, (format "date-and- 1519 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1520 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1521 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1522 and Tf is to be interpreted as the Duration of the measurement 1523 interval. The start time is controlled through other means. 1525 Tf a time, the end of a measurement interval, (format "date-and-time" 1526 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1527 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1528 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1529 Tf is interpreted as the Duration of the measurement interval. 1531 Reciprocal_lambda average packet interval for Poisson Streams 1532 expressed in units of seconds, as a positive value of type 1533 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1534 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1535 conversion to/from the 32-bit NTP timestamp as per section 6 of 1536 [RFC5905]. 1538 Trunc Upper limit on Poisson distribution expressed in units of 1539 seconds, as a positive value of type decimal64 with fraction 1540 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1541 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1542 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1543 this limit will be clipped and set to the limit value). (if fixed, 1544 Trunc = 30.0000 seconds.) 1546 ID The 16-bit identifier assigned by the program that generates the 1547 query, and which must vary in successive queries, see 1548 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1549 corresponding reply and can be used by the requester (Src) to 1550 match-up replies to outstanding queries. 1552 QNAME The domain name of the Query, formatted as specified in 1553 section 4 of [RFC6991]. 1555 QTYPE The Query Type, which will correspond to the IP address family 1556 of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a 1557 uint16, as per section 9.2 of [RFC6020]. 1559 6.3.6. Roles 1561 1563 Src launches each packet and waits for return transmissions from 1564 Dst. 1566 Dst waits for each packet from Src and sends a return packet to Src. 1568 6.4. Output 1570 This category specifies all details of the Output of measurements 1571 using the metric. 1573 6.4.1. Type 1575 1577 Raw -- for each DNS Query packet sent, sets of values as defined in 1578 the next column, including the status of the response, only assigning 1579 delay values to successful query-response pairs. 1581 6.4.2. Reference Definition 1583 1585 For all outputs: 1587 T the time the DNS Query was sent during the measurement interval, 1588 (format "date-and-time" as specified in Section 5.6 of [RFC3339], 1589 see also Section 3 of [RFC6991]). The UTC Time Zone is required 1590 by Section 6.1 of [RFC2330]. 1592 dT The time value of the round-trip delay to receive the DNS 1593 response, expressed in units of seconds, as a positive value of 1594 type decimal64 with fraction digits = 9 (see section 9.3 of 1595 [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and 1596 with lossless conversion to/from the 64-bit NTP timestamp as per 1597 section 6 of RFC [RFC5905]. This value is undefined when the 1598 response packet is not received at Src within waiting time Tmax 1599 seconds. 1601 Rcode The value of the Rcode field in the DNS response header, 1602 expressed as a uint64 as specified in section 9.2 of [RFC6020]. 1603 Non-zero values convey errors in the response, and such replies 1604 must be analyzed separately from successful requests. 1606 6.4.3. Metric Units 1608 . 1611 RTDNS: Round-trip Delay, dT, is expressed in seconds. 1613 RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 1615 6.4.4. Calibration 1617 Section 3.7.3 of [RFC7679] provides a means to quantify the 1618 systematic and random errors of a time measurement. In-situ 1619 calibration could be enabled with an internal loopback at the Source 1620 host that includes as much of the measurement system as possible, 1621 performs address and payload manipulation as needed, and provides 1622 some form of isolation (e.g., deterministic delay) to avoid send- 1623 receive interface contention. Some portion of the random and 1624 systematic error can be characterized this way. 1626 When a measurement controller requests a calibration measurement, the 1627 loopback is applied and the result is output in the same format as a 1628 normal measurement with additional indication that it is a 1629 calibration result. 1631 Both internal loopback calibration and clock synchronization can be 1632 used to estimate the *available accuracy* of the Output Metric Units. 1633 For example, repeated loopback delay measurements will reveal the 1634 portion of the Output result resolution which is the result of system 1635 noise, and thus inaccurate. 1637 6.5. Administrative items 1639 6.5.1. Status 1641 1643 6.5.2. Requestor 1645 name or RFC, etc. 1647 6.5.3. Revision 1649 1.0 1651 6.5.4. Revision Date 1653 YYYY-MM-DD 1655 6.6. Comments and Remarks 1657 Additional (Informational) details for this entry 1659 7. UDP Poisson One-way Delay and Loss Registry Entries 1661 This section specifies five initial registry entries for the UDP 1662 Poisson One-way Delay, and one for UDP Poisson One-way Loss. 1664 IANA Note: Registry "Name" below specifies a single registry entry, 1665 whose output format varies according to the element of 1666 the name that specifies one form of statistical summary. There is an 1667 additional metric name for the Loss metric. 1669 All column entries beside the ID, Name, Description, and Output 1670 Reference Method categories are the same, thus this section proposes 1671 six closely-related registry entries. As a result, IANA is also 1672 asked to assign corresponding URNs and URLs to each Named Metric. 1674 7.1. Summary 1676 This category includes multiple indexes to the registry entries, the 1677 element ID and metric name. 1679 7.1.1. ID (Identifier) 1681 1684 IANA is asked to assign different numeric identifiers to each of the 1685 six Metrics. 1687 7.1.2. Name 1689 1691 OWDelay_Active_IP-UDP-Poisson- 1692 Payload250B_RFCXXXXsecY_Seconds_ 1694 where is one of: 1696 o 95Percentile 1698 o Mean 1699 o Min 1701 o Max 1703 o StdDev 1705 OWLoss_Active_IP-UDP-Poisson- 1706 Payload250B_RFCXXXXsecY_Percent_LossRatio 1708 7.1.3. URI and URL 1710 URI: Prefix urn:ietf:metrics:perf: 1712 URL: http:\\www.iana.org\ ... 1714 7.1.4. Description 1716 OWDelay: This metric assesses the delay of a stream of packets 1717 exchanged between two hosts (or measurement points), and reports the 1718 One-way delay for all successfully exchanged packets 1719 based on their conditional delay distribution. 1721 where is one of: 1723 o 95Percentile 1725 o Mean 1727 o Min 1729 o Max 1731 o StdDev 1733 OWLoss: This metric assesses the loss ratio of a stream of packets 1734 exchanged between two hosts (which are the two measurement points), 1735 and the Output is the One-way loss ratio for all successfully 1736 received packets expressed as a percentage. 1738 7.2. Metric Definition 1740 This category includes columns to prompt the entry of all necessary 1741 details related to the metric definition, including the RFC reference 1742 and values of input factors, called fixed parameters. 1744 7.2.1. Reference Definition 1746 1748 For Delay: 1750 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 1751 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 1752 7679, DOI 10.17487/RFC7679, January 2016, . 1755 [RFC7679] 1757 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 1758 6049, January 2011. 1760 [RFC6049] 1762 1764 Section 3.4 of [RFC7679] provides the reference definition of the 1765 singleton (single value) One-way delay metric. Section 4.4 of 1766 [RFC7679] provides the reference definition expanded to cover a 1767 multi-value sample. Note that terms such as singleton and sample are 1768 defined in Section 11 of [RFC2330]. 1770 Only successful packet transfers with finite delay are included in 1771 the sample, as prescribed in section 4.1.2 of [RFC6049]. 1773 For loss: 1775 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 1776 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 1777 10.17487/RFC7680, January 2016, . 1780 Section 2.4 of [RFC7680] provides the reference definition of the 1781 singleton (single value) one-way loss metric. Section 3.4 of 1782 [RFC7680] provides the reference definition expanded to cover a 1783 multi-singleton sample. Note that terms such as singleton and sample 1784 are defined in Section 11 of [RFC2330]. 1786 7.2.2. Fixed Parameters 1788 1791 Type-P: 1793 o IPv4 header values: 1795 * DSCP: set to 0 1797 * TTL: set to 255 1799 * Protocol: Set to 17 (UDP) 1801 o IPv6 header values: 1803 * DSCP: set to 0 1805 * Hop Count: set to 255 1807 * Protocol: Set to 17 (UDP) 1809 o UDP header values: 1811 * Checksum: the checksum MUST be calculated and included in the 1812 header 1814 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 1816 * Security features in use influence the number of Padding 1817 octets. 1819 * 250 octets total, including the TWAMP format 1821 Other measurement parameters: 1823 Tmax: a loss threshold waiting time with value 3.0, expressed in 1824 units of seconds, as a positive value of type decimal64 with 1825 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 1826 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 1827 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 1829 See the Packet Stream generation category for two additional Fixed 1830 Parameters. 1832 7.3. Method of Measurement 1834 This category includes columns for references to relevant sections of 1835 the RFC(s) and any supplemental information needed to ensure an 1836 unambiguous methods for implementations. 1838 7.3.1. Reference Method 1840 1843 The methodology for this metric is defined as Type-P-One-way-Delay- 1844 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 1845 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 1847 The reference method distinguishes between long-delayed packets and 1848 lost packets by implementing a maximum waiting time for packet 1849 arrival. Tmax is the waiting time used as the threshold to declare a 1850 packet lost. Lost packets SHALL be designated as having undefined 1851 delay, and counted for the OWLoss metric. 1853 The calculations on the one-way delay SHALL be performed on the 1854 conditional distribution, conditioned on successful packet arrival 1855 within Tmax. Also, when all packet delays are stored, the process 1856 which calculates the one-way delay value MAY enforce the Tmax 1857 threshold on stored values before calculations. See section 4.1 of 1858 [RFC3393] for details on the conditional distribution to exclude 1859 undefined values of delay, and Section 5 of [RFC6703] for background 1860 on this analysis choice. 1862 The reference method requires some way to distinguish between 1863 different packets in a stream to establish correspondence between 1864 sending times and receiving times for each successfully-arriving 1865 packet. Sequence numbers or other send-order identification MUST be 1866 retained at the Src or included with each packet to disambiguate 1867 packet reordering if it occurs. 1869 Since a standard measurement protocol is employed [RFC5357], then the 1870 measurement process will determine the sequence numbers or timestamps 1871 applied to test packets after the Fixed and Runtime parameters are 1872 passed to that process. The measurement protocol dictates the format 1873 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 1874 payload. 1876 7.3.2. Packet Stream Generation 1878 This section gives the details of the packet traffic which is the 1879 basis for measurement. In IPPM metrics, this is called the Stream, 1880 and can easily be described by providing the list of stream 1881 parameters. 1883 1884 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1885 generate Poisson sampling intervals. The reciprocal of lambda is the 1886 average packet spacing, thus the Run-time Parameter is 1887 Reciprocal_lambda = 1/lambda, in seconds. 1889 Method 3 SHALL be used, where given a start time (Run-time 1890 Parameter), the subsequent send times are all computed prior to 1891 measurement by computing the pseudo-random distribution of inter- 1892 packet send times, (truncating the distribution as specified in the 1893 Parameter Trunc), and the Src sends each packet at the computed 1894 times. 1896 Note that Trunc is the upper limit on inter-packet times in the 1897 Poisson distribution. A random value greater than Trunc is set equal 1898 to Trunc instead. 1900 Reciprocal_lambda average packet interval for Poisson Streams 1901 expressed in units of seconds, as a positive value of type 1902 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 1903 with resolution of 0.0001 seconds (0.1 ms), and with lossless 1904 conversion to/from the 32-bit NTP timestamp as per section 6 of 1905 [RFC5905]. Reciprocal_lambda = 1 packet per second. 1907 Trunc Upper limit on Poisson distribution expressed in units of 1908 seconds, as a positive value of type decimal64 with fraction 1909 digits = 4 (see section 9.3 of [RFC6020]) with resolution of 1910 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 1911 32-bit NTP timestamp as per section 6 of [RFC5905] (values above 1912 this limit will be clipped and set to the limit value). Trunc = 1913 30.0000 seconds. 1915 7.3.3. Traffic Filtering (observation) Details 1917 NA 1919 7.3.4. Sampling Distribution 1921 NA 1923 7.3.5. Run-time Parameters and Data Format 1925 Run-time Parameters are input factors that must be determined, 1926 configured into the measurement system, and reported with the results 1927 for the context to be complete. 1929 1930 Src the IP address of the host in the Src Role (format ipv4-address- 1931 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1932 see Section 4 of [RFC6991]) 1934 Dst the IP address of the host in the Dst Role (format ipv4-address- 1935 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 1936 see section 4 of [RFC6991]) 1938 T0 a time, the start of a measurement interval, (format "date-and- 1939 time" as specified in Section 5.6 of [RFC3339], see also Section 3 1940 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1941 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 1942 and Tf is to be interpreted as the Duration of the measurement 1943 interval. The start time is controlled through other means. 1945 Tf a time, the end of a measurement interval, (format "date-and-time" 1946 as specified in Section 5.6 of [RFC3339], see also Section 3 of 1947 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1948 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 1949 Tf is interpreted as the Duration of the measurement interval. 1951 7.3.6. Roles 1953 1955 Src launches each packet and waits for return transmissions from 1956 Dst. This is the TWAMP Session-Sender. 1958 Dst waits for each packet from Src and sends a return packet to Src. 1959 This is the TWAMP Session-Reflector. 1961 7.4. Output 1963 This category specifies all details of the Output of measurements 1964 using the metric. 1966 7.4.1. Type 1968 1970 See subsection titles below for Types. 1972 7.4.2. Reference Definition 1974 1976 For all output types --- 1977 T0 the start of a measurement interval, (format "date-and-time" as 1978 specified in Section 5.6 of [RFC3339], see also Section 3 of 1979 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1980 [RFC2330]. 1982 Tf the end of a measurement interval, (format "date-and-time" as 1983 specified in Section 5.6 of [RFC3339], see also Section 3 of 1984 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 1985 [RFC2330]. 1987 For LossRatio -- the count of lost packets to total packets sent is 1988 the basis for the loss ratio calculation as per Section 4.1 of 1989 [RFC7680]. 1991 For each , one of the following sub-sections apply: 1993 7.4.2.1. Percentile95 1995 The 95th percentile SHALL be calculated using the conditional 1996 distribution of all packets with a finite value of One-way delay 1997 (undefined delays are excluded), a single value as follows: 1999 See section 4.1 of [RFC3393] for details on the conditional 2000 distribution to exclude undefined values of delay, and Section 5 of 2001 [RFC6703] for background on this analysis choice. 2003 See section 4.3 of [RFC3393] for details on the percentile statistic 2004 (where Round-trip delay should be substituted for "ipdv"). 2006 The percentile = 95, meaning that the reported delay, "95Percentile", 2007 is the smallest value of one-way delay for which the Empirical 2008 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2009 one-way delay values in the conditional distribution. See section 2010 11.3 of [RFC2330] for the definition of the percentile statistic 2011 using the EDF. 2013 95Percentile The time value of the result is expressed in units of 2014 seconds, as a positive value of type decimal64 with fraction 2015 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2016 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2017 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2019 7.4.2.2. Mean 2021 The mean SHALL be calculated using the conditional distribution of 2022 all packets with a finite value of One-way delay (undefined delays 2023 are excluded), a single value as follows: 2025 See section 4.1 of [RFC3393] for details on the conditional 2026 distribution to exclude undefined values of delay, and Section 5 of 2027 [RFC6703] for background on this analysis choice. 2029 See section 4.2.2 of [RFC6049] for details on calculating this 2030 statistic, and 4.2.3 of [RFC6049]. 2032 Mean The time value of the result is expressed in units of seconds, 2033 as a positive value of type decimal64 with fraction digits = 9 2034 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2035 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2036 NTP timestamp as per section 6 of RFC [RFC5905] 2038 7.4.2.3. Min 2040 The minimum SHALL be calculated using the conditional distribution of 2041 all packets with a finite value of One-way delay (undefined delays 2042 are excluded), a single value as follows: 2044 See section 4.1 of [RFC3393] for details on the conditional 2045 distribution to exclude undefined values of delay, and Section 5 of 2046 [RFC6703] for background on this analysis choice. 2048 See section 4.3.2 of [RFC6049] for details on calculating this 2049 statistic, and 4.3.3 of [RFC6049]. 2051 Min The time value of the result is expressed in units of seconds, 2052 as a positive value of type decimal64 with fraction digits = 9 2053 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2054 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2055 NTP timestamp as per section 6 of RFC [RFC5905] 2057 7.4.2.4. Max 2059 The maximum SHALL be calculated using the conditional distribution of 2060 all packets with a finite value of One-way delay (undefined delays 2061 are excluded), a single value as follows: 2063 See section 4.1 of [RFC3393] for details on the conditional 2064 distribution to exclude undefined values of delay, and Section 5 of 2065 [RFC6703] for background on this analysis choice. 2067 See section 4.3.2 of [RFC6049] for a closely related method for 2068 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2069 as follows: 2071 Max = (FiniteDelay [j]) 2073 such that for some index, j, where 1 <= j <= N 2074 FiniteDelay[j] >= FiniteDelay[n] for all n 2076 Max The time value of the result is expressed in units of seconds, 2077 as a positive value of type decimal64 with fraction digits = 9 2078 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2079 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2080 NTP timestamp as per section 6 of RFC [RFC5905] 2082 7.4.2.5. Std_Dev 2084 The Std_Dev SHALL be calculated using the conditional distribution of 2085 all packets with a finite value of One-way delay (undefined delays 2086 are excluded), a single value as follows: 2088 See section 4.1 of [RFC3393] for details on the conditional 2089 distribution to exclude undefined values of delay, and Section 5 of 2090 [RFC6703] for background on this analysis choice. 2092 See section 4.3.2 of [RFC6049] for a closely related method for 2093 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2094 the classic calculation for standard deviation of a population. 2096 Std_Dev The time value of the result is expressed in units of 2097 seconds, as a positive value of type decimal64 with fraction 2098 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2099 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2100 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2102 7.4.3. Metric Units 2104 . 2107 The of One-way Delay is expressed in seconds. 2109 The One-way Loss Ratio is expressed as a percentage of lost packets 2110 to total packets sent. 2112 7.4.4. Calibration 2114 Section 3.7.3 of [RFC7679] provides a means to quantify the 2115 systematic and random errors of a time measurement. In-situ 2116 calibration could be enabled with an internal loopback that includes 2117 as much of the measurement system as possible, performs address 2118 manipulation as needed, and provides some form of isolation (e.g., 2119 deterministic delay) to avoid send-receive interface contention. 2120 Some portion of the random and systematic error can be characterized 2121 this way. 2123 For one-way delay measurements, the error calibration must include an 2124 assessment of the internal clock synchronization with its external 2125 reference (this internal clock is supplying timestamps for 2126 measurement). In practice, the time offsets of clocks at both the 2127 source and destination are needed to estimate the systematic error 2128 due to imperfect clock synchronization (the time offsets are 2129 smoothed, thus the random variation is not usually represented in the 2130 results). 2132 time_offset The time value of the result is expressed in units of 2133 seconds, as a signed value of type decimal64 with fraction digits 2134 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2135 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2136 NTP timestamp as per section 6 of RFC [RFC5905] 2138 When a measurement controller requests a calibration measurement, the 2139 loopback is applied and the result is output in the same format as a 2140 normal measurement with additional indication that it is a 2141 calibration result. In any measurement, the measurement function 2142 SHOULD report its current estimate of time offset as an indicator of 2143 the degree of synchronization. 2145 Both internal loopback calibration and clock synchronization can be 2146 used to estimate the *available accuracy* of the Output Metric Units. 2147 For example, repeated loopback delay measurements will reveal the 2148 portion of the Output result resolution which is the result of system 2149 noise, and thus inaccurate. 2151 7.5. Administrative items 2153 7.5.1. Status 2155 2157 7.5.2. Requestor (keep?) 2159 name or RFC, etc. 2161 7.5.3. Revision 2163 1.0 2165 7.5.4. Revision Date 2167 YYYY-MM-DD 2169 7.6. Comments and Remarks 2171 Additional (Informational) details for this entry 2173 8. UDP Periodic One-way Delay and Loss Registry Entries 2175 This section specifies five initial registry entries for the UDP 2176 Periodic One-way Delay, and one for UDP Periodic One-way Loss. 2178 IANA Note: Registry "Name" below specifies a single registry entry, 2179 whose output format varies according to the element of 2180 the name that specifies one form of statistical summary. There is an 2181 additional metric name for the Loss metric. 2183 All column entries beside the ID, Name, Description, and Output 2184 Reference Method categories are the same, thus this section proposes 2185 six closely-related registry entries. As a result, IANA is also 2186 asked to assign corresponding URNs and URLs to each Named Metric. 2188 8.1. Summary 2190 This category includes multiple indexes to the registry entries, the 2191 element ID and metric name. 2193 8.1.1. ID (Identifier) 2195 2198 IANA is asked to assign a different numeric identifiers to each of 2199 the six Metrics. 2201 8.1.2. Name 2203 2205 OWDelay_Active_IP-UDP-Periodic- 2206 Payload142B_RFCXXXXsecY_Seconds_ 2208 where is one of: 2210 o 95Percentile 2212 o Mean 2213 o Min 2215 o Max 2217 o StdDev 2219 OWLoss_Active_IP-UDP-Periodic- 2220 Payload142B_RFCXXXXsecY_Percent_LossRatio 2222 8.1.3. URIs 2224 URI: Prefix urn:ietf:metrics:perf: 2226 URL: http:\\www.iana.org\ ... 2228 8.1.4. Description 2230 OWDelay: This metric assesses the delay of a stream of packets 2231 exchanged between two hosts (or measurement points), and reports the 2232 One-way delay for all successfully exchanged packets 2233 based on their conditional delay distribution. 2235 where is one of: 2237 o 95Percentile 2239 o Mean 2241 o Min 2243 o Max 2245 o StdDev 2247 OWLoss: This metric assesses the loss ratio of a stream of packets 2248 exchanged between two hosts (which are the two measurement points), 2249 and the Output is the One-way loss ratio for all successfully 2250 received packets expressed as a percentage. 2252 8.2. Metric Definition 2254 This category includes columns to prompt the entry of all necessary 2255 details related to the metric definition, including the RFC reference 2256 and values of input factors, called fixed parameters. 2258 8.2.1. Reference Definition 2260 2262 For Delay: 2264 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 2265 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 2266 7679, DOI 10.17487/RFC7679, January 2016, . 2269 [RFC7679] 2271 Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 2272 6049, January 2011. 2274 [RFC6049] 2276 2278 Section 3.4 of [RFC7679] provides the reference definition of the 2279 singleton (single value) One-way delay metric. Section 4.4 of 2280 [RFC7679] provides the reference definition expanded to cover a 2281 multi-value sample. Note that terms such as singleton and sample are 2282 defined in Section 11 of [RFC2330]. 2284 Only successful packet transfers with finite delay are included in 2285 the sample, as prescribed in section 4.1.2 of [RFC6049]. 2287 For loss: 2289 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 2290 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 2291 10.17487/RFC7680, January 2016, . 2294 Section 2.4 of [RFC7680] provides the reference definition of the 2295 singleton (single value) one-way loss metric. Section 3.4 of 2296 [RFC7680] provides the reference definition expanded to cover a 2297 multi-singleton sample. Note that terms such as singleton and sample 2298 are defined in Section 11 of [RFC2330]. 2300 8.2.2. Fixed Parameters 2302 2305 Type-P: 2307 o IPv4 header values: 2309 * DSCP: set to 0 2311 * TTL: set to 255 2313 * Protocol: Set to 17 (UDP) 2315 o IPv6 header values: 2317 * DSCP: set to 0 2319 * Hop Count: set to 255 2321 * Protocol: Set to 17 (UDP) 2323 o UDP header values: 2325 * Checksum: the checksum MUST be calculated and included in the 2326 header 2328 o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] 2330 * Security features in use influence the number of Padding 2331 octets. 2333 * 142 octets total, including the TWAMP format 2335 Other measurement parameters: 2337 Tmax: a loss threshold waiting time with value 3.0, expressed in 2338 units of seconds, as a positive value of type decimal64 with 2339 fraction digits = 4 (see section 9.3 of [RFC6020]) and with 2340 resolution of 0.0001 seconds (0.1 ms), with lossless conversion 2341 to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 2343 See the Packet Stream generation category for two additional Fixed 2344 Parameters. 2346 8.3. Method of Measurement 2348 This category includes columns for references to relevant sections of 2349 the RFC(s) and any supplemental information needed to ensure an 2350 unambiguous methods for implementations. 2352 8.3.1. Reference Method 2354 2357 The methodology for this metric is defined as Type-P-One-way-Delay- 2358 Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of 2359 [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. 2360 However, a Periodic stream is used, as defined in [RFC3432]. 2362 The reference method distinguishes between long-delayed packets and 2363 lost packets by implementing a maximum waiting time for packet 2364 arrival. Tmax is the waiting time used as the threshold to declare a 2365 packet lost. Lost packets SHALL be designated as having undefined 2366 delay, and counted for the OWLoss metric. 2368 The calculations on the one-way delay SHALL be performed on the 2369 conditional distribution, conditioned on successful packet arrival 2370 within Tmax. Also, when all packet delays are stored, the process 2371 which calculates the one-way delay value MAY enforce the Tmax 2372 threshold on stored values before calculations. See section 4.1 of 2373 [RFC3393] for details on the conditional distribution to exclude 2374 undefined values of delay, and Section 5 of [RFC6703] for background 2375 on this analysis choice. 2377 The reference method requires some way to distinguish between 2378 different packets in a stream to establish correspondence between 2379 sending times and receiving times for each successfully-arriving 2380 packet. Sequence numbers or other send-order identification MUST be 2381 retained at the Src or included with each packet to disambiguate 2382 packet reordering if it occurs. 2384 Since a standard measurement protocol is employed [RFC5357], then the 2385 measurement process will determine the sequence numbers or timestamps 2386 applied to test packets after the Fixed and Runtime parameters are 2387 passed to that process. The measurement protocol dictates the format 2388 of sequence numbers and time-stamps conveyed in the TWAMP-Test packet 2389 payload. 2391 8.3.2. Packet Stream Generation 2393 2395 This section gives the details of the packet traffic which is the 2396 basis for measurement. In IPPM metrics, this is called the Stream, 2397 and can easily be described by providing the list of stream 2398 parameters. 2400 Section 3 of [RFC3432] prescribes the method for generating Periodic 2401 streams using associated parameters. 2403 incT the nominal duration of inter-packet interval, first bit to 2404 first bit 2406 dT the duration of the interval for allowed sample start times 2408 T0 the actual start time of the periodic stream 2410 NOTE: an initiation process with a number of control exchanges 2411 resulting in unpredictable start times (within a time interval) may 2412 be sufficient to avoid synchronization of periodic streams, and 2413 therefore a valid replacement for selecting a start time at random 2414 from a fixed interval. 2416 These stream parameters will be specified as Run-time parameters. 2418 8.3.3. Traffic Filtering (observation) Details 2420 NA 2422 8.3.4. Sampling Distribution 2424 NA 2426 8.3.5. Run-time Parameters and Data Format 2428 Run-time Parameters are input factors that must be determined, 2429 configured into the measurement system, and reported with the results 2430 for the context to be complete. 2432 2434 Src the IP address of the host in the Src Role (format ipv4-address- 2435 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2436 see Section 4 of [RFC6991]) 2438 Dst the IP address of the host in the Dst Role (format ipv4-address- 2439 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2440 see section 4 of [RFC6991]) 2442 T0 a time, the start of a measurement interval, (format "date-and- 2443 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2444 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2445 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2446 and Tf is to be interpreted as the Duration of the measurement 2447 interval. The start time is controlled through other means. 2449 Tf a time, the end of a measurement interval, (format "date-and-time" 2450 as specified in Section 5.6 of [RFC3339], see also Section 3 of 2451 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2452 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 2453 Tf is interpreted as the Duration of the measurement interval. 2455 @@@@ should Periodic run-time params be fixed instead? Probably yes 2456 if modeling a specific version of tests. Note in the NAME, i.e. 2457 Poisson3.3 2459 8.3.6. Roles 2461 2463 Src launches each packet and waits for return transmissions from 2464 Dst. This is the TWAMP Session-Sender. 2466 Dst waits for each packet from Src and sends a return packet to Src. 2467 This is the TWAMP Session-Reflector. 2469 8.4. Output 2471 This category specifies all details of the Output of measurements 2472 using the metric. 2474 8.4.1. Type 2476 2478 See subsection titles in Reference Definition for Latency Types. 2480 8.4.2. Reference Definition 2482 2484 For all output types --- 2486 T0 the start of a measurement interval, (format "date-and-time" as 2487 specified in Section 5.6 of [RFC3339], see also Section 3 of 2488 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2489 [RFC2330]. 2491 Tf the end of a measurement interval, (format "date-and-time" as 2492 specified in Section 5.6 of [RFC3339], see also Section 3 of 2493 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2494 [RFC2330]. 2496 For LossRatio -- the count of lost packets to total packets sent is 2497 the basis for the loss ratio calculation as per Section 4.1 of 2498 [RFC7680]. 2500 For each , one of the following sub-sections apply: 2502 8.4.2.1. Percentile95 2504 The 95th percentile SHALL be calculated using the conditional 2505 distribution of all packets with a finite value of One-way delay 2506 (undefined delays are excluded), a single value as follows: 2508 See section 4.1 of [RFC3393] for details on the conditional 2509 distribution to exclude undefined values of delay, and Section 5 of 2510 [RFC6703] for background on this analysis choice. 2512 See section 4.3 of [RFC3393] for details on the percentile statistic 2513 (where Round-trip delay should be substituted for "ipdv"). 2515 The percentile = 95, meaning that the reported delay, "95Percentile", 2516 is the smallest value of one-way delay for which the Empirical 2517 Distribution Function (EDF), F(95Percentile) >= 95% of the singleton 2518 one-way delay values in the conditional distribution. See section 2519 11.3 of [RFC2330] for the definition of the percentile statistic 2520 using the EDF. 2522 95Percentile The time value of the result is expressed in units of 2523 seconds, as a positive value of type decimal64 with fraction 2524 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2525 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2526 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2528 8.4.2.2. Mean 2530 The mean SHALL be calculated using the conditional distribution of 2531 all packets with a finite value of One-way delay (undefined delays 2532 are excluded), a single value as follows: 2534 See section 4.1 of [RFC3393] for details on the conditional 2535 distribution to exclude undefined values of delay, and Section 5 of 2536 [RFC6703] for background on this analysis choice. 2538 See section 4.2.2 of [RFC6049] for details on calculating this 2539 statistic, and 4.2.3 of [RFC6049]. 2541 Mean The time value of the result is expressed in units of seconds, 2542 as a positive value of type decimal64 with fraction digits = 9 2543 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2544 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2545 NTP timestamp as per section 6 of RFC [RFC5905] 2547 8.4.2.3. Min 2549 The minimum SHALL be calculated using the conditional distribution of 2550 all packets with a finite value of One-way delay (undefined delays 2551 are excluded), a single value as follows: 2553 See section 4.1 of [RFC3393] for details on the conditional 2554 distribution to exclude undefined values of delay, and Section 5 of 2555 [RFC6703] for background on this analysis choice. 2557 See section 4.3.2 of [RFC6049] for details on calculating this 2558 statistic, and 4.3.3 of [RFC6049]. 2560 Min The time value of the result is expressed in units of seconds, 2561 as a positive value of type decimal64 with fraction digits = 9 2562 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2563 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2564 NTP timestamp as per section 6 of RFC [RFC5905] 2566 8.4.2.4. Max 2568 The maximum SHALL be calculated using the conditional distribution of 2569 all packets with a finite value of One-way delay (undefined delays 2570 are excluded), a single value as follows: 2572 See section 4.1 of [RFC3393] for details on the conditional 2573 distribution to exclude undefined values of delay, and Section 5 of 2574 [RFC6703] for background on this analysis choice. 2576 See section 4.3.2 of [RFC6049] for a closely related method for 2577 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2578 as follows: 2580 Max = (FiniteDelay [j]) 2582 such that for some index, j, where 1 <= j <= N 2583 FiniteDelay[j] >= FiniteDelay[n] for all n 2585 Max The time value of the result is expressed in units of seconds, 2586 as a positive value of type decimal64 with fraction digits = 9 2587 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2588 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2589 NTP timestamp as per section 6 of RFC [RFC5905] 2591 8.4.2.5. Std_Dev 2593 The Std_Dev SHALL be calculated using the conditional distribution of 2594 all packets with a finite value of One-way delay (undefined delays 2595 are excluded), a single value as follows: 2597 See section 4.1 of [RFC3393] for details on the conditional 2598 distribution to exclude undefined values of delay, and Section 5 of 2599 [RFC6703] for background on this analysis choice. 2601 See section 4.3.2 of [RFC6049] for a closely related method for 2602 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 2603 the classic calculation for standard deviation of a population. 2605 Std_Dev The time value of the result is expressed in units of 2606 seconds, as a positive value of type decimal64 with fraction 2607 digits = 9 (see section 9.3 of [RFC6020]) with resolution of 2608 0.000000001 seconds (1.0 ns), and with lossless conversion to/from 2609 the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 2611 8.4.3. Metric Units 2613 . 2616 The of One-way Delay is expressed in seconds, where 2617 is one of: 2619 o 95Percentile 2621 o Mean 2623 o Min 2625 o Max 2627 o StdDev 2629 The One-way Loss Ratio is expressed as a percentage of lost packets 2630 to total packets sent. 2632 8.4.4. Calibration 2634 Section 3.7.3 of [RFC7679] provides a means to quantify the 2635 systematic and random errors of a time measurement. In-situ 2636 calibration could be enabled with an internal loopback that includes 2637 as much of the measurement system as possible, performs address 2638 manipulation as needed, and provides some form of isolation (e.g., 2639 deterministic delay) to avoid send-receive interface contention. 2640 Some portion of the random and systematic error can be characterized 2641 this way. 2643 For one-way delay measurements, the error calibration must include an 2644 assessment of the internal clock synchronization with its external 2645 reference (this internal clock is supplying timestamps for 2646 measurement). In practice, the time offsets of clocks at both the 2647 source and destination are needed to estimate the systematic error 2648 due to imperfect clock synchronization (the time offsets are 2649 smoothed, thus the random variation is not usually represented in the 2650 results). 2652 time_offset The time value of the result is expressed in units of 2653 seconds, as a signed value of type decimal64 with fraction digits 2654 = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 2655 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 2656 NTP timestamp as per section 6 of RFC [RFC5905] 2658 When a measurement controller requests a calibration measurement, the 2659 loopback is applied and the result is output in the same format as a 2660 normal measurement with additional indication that it is a 2661 calibration result. In any measurement, the measurement function 2662 SHOULD report its current estimate of time offset as an indicator of 2663 the degree of synchronization. 2665 Both internal loopback calibration and clock synchronization can be 2666 used to estimate the *available accuracy* of the Output Metric Units. 2667 For example, repeated loopback delay measurements will reveal the 2668 portion of the Output result resolution which is the result of system 2669 noise, and thus inaccurate. 2671 8.5. Administrative items 2673 8.5.1. Status 2675 2677 8.5.2. Requestor (keep?) 2679 name or RFC, etc. 2681 8.5.3. Revision 2683 1.0 2685 8.5.4. Revision Date 2687 YYYY-MM-DD 2689 8.6. Comments and Remarks 2691 Additional (Informational) details for this entry 2693 9. ICMP Round-trip Latency and Loss Registry Entries 2695 This section specifies three initial registry entries for the ICMP 2696 Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. 2698 This section specifies four Registry entries with many common 2699 columns. 2701 All column entries beside the ID, Name, Description, and Output 2702 Reference Method categories are the same, thus this section proposes 2703 two closely-related registry entries. As a result, IANA is also 2704 asked to assign four corresponding URNs and URLs to each Named 2705 Metric. 2707 9.1. Summary 2709 This category includes multiple indexes to the registry entry: the 2710 element ID and metric name. 2712 9.1.1. ID (Identifier) 2714 2716 IANA is asked to assign different numeric identifiers to each of the 2717 four Named Metrics. 2719 9.1.2. Name 2721 2723 RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Seconds_ 2725 where is one of: 2727 o Mean 2729 o Min 2731 o Max 2732 RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsecY_Percent_LossRatio 2734 9.1.3. URIs 2736 URN: Prefix urn:ietf:metrics:perf: 2738 URL: http:/// 2740 9.1.4. Description 2742 RTDelay: This metric assesses the delay of a stream of ICMP packets 2743 exchanged between two hosts (which are the two measurement points), 2744 and the Output is the Round-trip delay for all successfully exchanged 2745 packets expressed as the of their conditional delay 2746 distribution, where is one of: 2748 o Mean 2750 o Min 2752 o Max 2754 RTLoss: This metric assesses the loss ratio of a stream of ICMP 2755 packets exchanged between two hosts (which are the two measurement 2756 points), and the Output is the Round-trip loss ratio for all 2757 successfully exchanged packets expressed as a percentage. 2759 9.1.5. Change Controller 2761 IETF 2763 9.1.6. Version (of Registry Format) 2765 1.0 2767 9.2. Metric Definition 2769 This category includes columns to prompt the entry of all necessary 2770 details related to the metric definition, including the RFC reference 2771 and values of input factors, called fixed parameters. 2773 9.2.1. Reference Definition 2775 2777 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 2778 Metric for IPPM", RFC 2681, September 1999. 2780 [RFC2681] 2782 2784 Section 2.4 of [RFC2681] provides the reference definition of the 2785 singleton (single value) Round-trip delay metric. Section 3.4 of 2786 [RFC2681] provides the reference definition expanded to cover a 2787 multi-singleton sample. Note that terms such as singleton and sample 2788 are defined in Section 11 of [RFC2330]. 2790 Note that although the [RFC2681] definition of "Round-trip-Delay 2791 between Src and Dst" is directionally ambiguous in the text, this 2792 metric tightens the definition further to recognize that the host in 2793 the "Src" role will send the first packet to "Dst", and ultimately 2794 receive the corresponding return packet from "Dst" (when neither are 2795 lost). 2797 Finally, note that the variable "dT" is used in [RFC2681] to refer to 2798 the value of Round-trip delay in metric definitions and methods. The 2799 variable "dT" has been re-used in other IPPM literature to refer to 2800 different quantities, and cannot be used as a global variable name. 2802 Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. 2804 [RFC6673] 2806 Both delay and loss metrics employ a maximum waiting time for 2807 received packets, so the count of lost packets to total packets sent 2808 is the basis for the loss ratio calculation as per Section 6.1 of 2809 [RFC6673]. 2811 9.2.2. Fixed Parameters 2813 2817 Type-P as defined in Section 13 of [RFC2330]: 2819 o IPv4 header values: 2821 * DSCP: set to 0 2823 * TTL: set to 255 2825 * Protocol: Set to 01 (ICMP) 2827 o IPv6 header values: 2829 * DSCP: set to 0 2831 * Hop Limit: set to 255 2833 * Protocol: Set to 01 (ICMP) 2835 o ICMP header values: 2837 * Type: 8 (Echo Request) 2839 * Code: 0 2841 * Checksum: the checksum MUST be calculated and included in the 2842 header 2844 * (Identifier and Sequence Number set at Run-Time) 2846 o ICMP Payload 2848 * total of 32 bytes of random info 2850 Other measurement parameters: 2852 o Tmax: a loss threshold waiting time 2854 * 3.0, expressed in units of seconds, as a positive value of type 2855 decimal64 with fraction digits = 4 (see section 9.3 of 2856 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 2857 lossless conversion to/from the 32-bit NTP timestamp as per 2858 section 6 of [RFC5905]. 2860 9.3. Method of Measurement 2862 This category includes columns for references to relevant sections of 2863 the RFC(s) and any supplemental information needed to ensure an 2864 unambiguous methods for implementations. 2866 9.3.1. Reference Method 2868 2871 The methodology for this metric is defined as Type-P-Round-trip- 2872 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 2873 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under 2874 Fixed Parameters. 2876 The reference method distinguishes between long-delayed packets and 2877 lost packets by implementing a maximum waiting time for packet 2878 arrival. Tmax is the waiting time used as the threshold to declare a 2879 packet lost. Lost packets SHALL be designated as having undefined 2880 delay, and counted for the RTLoss metric. 2882 The calculations on the delay (RTD) SHALL be performed on the 2883 conditional distribution, conditioned on successful packet arrival 2884 within Tmax. Also, when all packet delays are stored, the process 2885 which calculates the RTD value MAY enforce the Tmax threshold on 2886 stored values before calculations. See section 4.1 of [RFC3393] for 2887 details on the conditional distribution to exclude undefined values 2888 of delay, and Section 5 of [RFC6703] for background on this analysis 2889 choice. 2891 The reference method requires some way to distinguish between 2892 different packets in a stream to establish correspondence between 2893 sending times and receiving times for each successfully-arriving 2894 packet. Sequence numbers or other send-order identification MUST be 2895 retained at the Src or included with each packet to disambiguate 2896 packet reordering if it occurs. 2898 The measurement process will determine the sequence numbers applied 2899 to test packets after the Fixed and Runtime parameters are passed to 2900 that process. The ICMP measurement process and protocol will dictate 2901 the format of sequence numbers and other identifiers. 2903 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 2904 instruction to "send a Type-P packet back to the Src as quickly as 2905 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 2906 [RFC6673] presents additional requirements which MUST be included in 2907 the method of measurement for this metric. 2909 9.3.2. Packet Stream Generation 2911 This section gives the details of the packet traffic which is the 2912 basis for measurement. In IPPM metrics, this is called the Stream, 2913 and can easily be described by providing the list of stream 2914 parameters. 2916 The ICMP metrics use a sending discipline called "SendOnRcv" or Send 2917 On Receive. This is a modification of Section 3 of [RFC3432], which 2918 prescribes the method for generating Periodic streams using 2919 associated parameters: 2921 incT the nominal duration of inter-packet interval, first bit to 2922 first bit 2924 dT the duration of the interval for allowed sample start times 2926 T0 the actual start time of the periodic stream 2928 The incT and T0 stream parameters will be specified as Run-time 2929 parameters, dT is not used in SendOnRcv. 2931 A SendOnRcv sender behaves exactly like a Periodic stream generator 2932 while all reply packets arrive with RTD < incT, and the inter-packet 2933 interval will be constant. 2935 If a reply packet arrives with RTD >= incT, then the inter-packet 2936 interval for the next sending time is nominally RTD. 2938 If a reply packet fails to arrive within Tmax, then the inter-packet 2939 interval for the next sending time is nominally Tmax. 2941 If an immediate send on reply arrival is desired, then set incT=0. 2943 9.3.3. Traffic Filtering (observation) Details 2945 The measured results based on a filtered version of the packets 2946 observed, and this section provides the filter details (when 2947 present). 2949
. 2951 NA 2953 9.3.4. Sampling Distribution 2955 2958 NA 2960 9.3.5. Run-time Parameters and Data Format 2962 Run-time Parameters are input factors that must be determined, 2963 configured into the measurement system, and reported with the results 2964 for the context to be complete. 2966 2968 Src the IP address of the host in the Src Role (format ipv4-address- 2969 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2970 see Section 4 of [RFC6991]) 2972 Dst the IP address of the host in the Dst Role (format ipv4-address- 2973 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 2974 see section 4 of [RFC6991]) 2976 T0 a time, the start of a measurement interval, (format "date-and- 2977 time" as specified in Section 5.6 of [RFC3339], see also Section 3 2978 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 2979 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 2980 and Tf is to be interpreted as the Duration of the measurement 2981 interval. The start time is controlled through other means. 2983 Count The total count of ICMP Echo Requests to send, formatted as a 2984 uint16, as per section 9.2 of [RFC6020]. 2986 (see the Packet Stream Generation section for additional Run-time 2987 parameters) 2989 9.3.6. Roles 2991 2993 Src launches each packet and waits for return transmissions from 2994 Dst. 2996 Dst waits for each packet from Src and sends a return packet to Src. 2998 9.4. Output 3000 This category specifies all details of the Output of measurements 3001 using the metric. 3003 9.4.1. Type 3005 3007 See subsection titles in Reference Definition for Latency Types. 3009 LossRatio -- the count of lost packets to total packets sent is the 3010 basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 3012 9.4.2. Reference Definition 3014 3016 For all output types --- 3018 T0 the start of a measurement interval, (format "date-and-time" as 3019 specified in Section 5.6 of [RFC3339], see also Section 3 of 3021 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3022 [RFC2330]. 3024 Tf the end of a measurement interval, (format "date-and-time" as 3025 specified in Section 5.6 of [RFC3339], see also Section 3 of 3026 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3027 [RFC2330]. 3029 TotalCount the count of packets actually sent by the Src to Dst 3030 during the measurement interval. 3032 For LossRatio -- the count of lost packets to total packets sent is 3033 the basis for the loss ratio calculation as per Section 4.1 of 3034 [RFC7680]. 3036 For each , one of the following sub-sections apply: 3038 9.4.2.1. Mean 3040 The mean SHALL be calculated using the conditional distribution of 3041 all packets with a finite value of Round-trip delay (undefined delays 3042 are excluded), a single value as follows: 3044 See section 4.1 of [RFC3393] for details on the conditional 3045 distribution to exclude undefined values of delay, and Section 5 of 3046 [RFC6703] for background on this analysis choice. 3048 See section 4.2.2 of [RFC6049] for details on calculating this 3049 statistic, and 4.2.3 of [RFC6049]. 3051 Mean The time value of the result is expressed in units of seconds, 3052 as a positive value of type decimal64 with fraction digits = 9 3053 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3054 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3055 NTP timestamp as per section 6 of RFC [RFC5905] 3057 9.4.2.2. Min 3059 The minimum SHALL be calculated using the conditional distribution of 3060 all packets with a finite value of Round-trip delay (undefined delays 3061 are excluded), a single value as follows: 3063 See section 4.1 of [RFC3393] for details on the conditional 3064 distribution to exclude undefined values of delay, and Section 5 of 3065 [RFC6703] for background on this analysis choice. 3067 See section 4.3.2 of [RFC6049] for details on calculating this 3068 statistic, and 4.3.3 of [RFC6049]. 3070 Min The time value of the result is expressed in units of seconds, 3071 as a positive value of type decimal64 with fraction digits = 9 3072 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3073 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3074 NTP timestamp as per section 6 of RFC [RFC5905] 3076 9.4.2.3. Max 3078 The maximum SHALL be calculated using the conditional distribution of 3079 all packets with a finite value of Round-trip delay (undefined delays 3080 are excluded), a single value as follows: 3082 See section 4.1 of [RFC3393] for details on the conditional 3083 distribution to exclude undefined values of delay, and Section 5 of 3084 [RFC6703] for background on this analysis choice. 3086 See section 4.3.2 of [RFC6049] for a closely related method for 3087 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3088 as follows: 3090 Max = (FiniteDelay [j]) 3092 such that for some index, j, where 1 <= j <= N 3093 FiniteDelay[j] >= FiniteDelay[n] for all n 3095 Max The time value of the result is expressed in units of seconds, 3096 as a positive value of type decimal64 with fraction digits = 9 3097 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3098 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3099 NTP timestamp as per section 6 of RFC [RFC5905] 3101 9.4.3. Metric Units 3103 . 3106 The of Round-trip Delay is expressed in seconds, where 3107 is one of: 3109 o Mean 3111 o Min 3113 o Max 3115 The Round-trip Loss Ratio is expressed as a percentage of lost 3116 packets to total packets sent. 3118 9.4.4. Calibration 3120 Section 3.7.3 of [RFC7679] provides a means to quantify the 3121 systematic and random errors of a time measurement. In-situ 3122 calibration could be enabled with an internal loopback at the Source 3123 host that includes as much of the measurement system as possible, 3124 performs address manipulation as needed, and provides some form of 3125 isolation (e.g., deterministic delay) to avoid send-receive interface 3126 contention. Some portion of the random and systematic error can be 3127 characterized this way. 3129 When a measurement controller requests a calibration measurement, the 3130 loopback is applied and the result is output in the same format as a 3131 normal measurement with additional indication that it is a 3132 calibration result. 3134 Both internal loopback calibration and clock synchronization can be 3135 used to estimate the *available accuracy* of the Output Metric Units. 3136 For example, repeated loopback delay measurements will reveal the 3137 portion of the Output result resolution which is the result of system 3138 noise, and thus inaccurate. 3140 9.5. Administrative items 3142 9.5.1. Status 3144 3146 9.5.2. Requestor (keep?) 3148 name or RFC, etc. 3150 9.5.3. Revision 3152 1.0 3154 9.5.4. Revision Date 3156 YYYY-MM-DD 3158 9.6. Comments and Remarks 3160 Additional (Informational) details for this entry 3162 10. TCP Round-Trip Delay and Loss Registry Entries 3164 This section specifies three initial registry entries for the Passive 3165 assessment of TCP Round-Trip Delay (RTD) and another entry for TCP 3166 Round-trip Loss Count. 3168 This section specifies four Registry entries with many common 3169 columns. 3171 All column entries beside the ID, Name, Description, and Output 3172 Reference Method categories are the same, thus this section proposes 3173 four closely-related registry entries. As a result, IANA is also 3174 asked to assign four corresponding URNs and URLs to each Named 3175 Metric. 3177 10.1. Summary 3179 This category includes multiple indexes to the registry entry: the 3180 element ID and metric name. 3182 10.1.1. ID (Identifier) 3184 3186 IANA is asked to assign different numeric identifiers to each of the 3187 four Named Metrics. 3189 10.1.2. Name 3191 3193 RTDelay_Passive_IP-TCP_RFCXXXXsecY_Seconds_ 3195 where is one of: 3197 o Mean 3199 o Min 3201 o Max 3203 RTDelay_Passive_IP-TCP-HS_RFCXXXXsecY_Seconds_Singleton 3205 Note that a mid-point observer only has the opportuinty to compose a 3206 single RTDelay on the TCP Hand Shake. 3208 RTLoss_Passive_IP-TCP_RFCXXXXsecY_Packet_Count 3210 10.1.3. URIs 3212 URN: Prefix urn:ietf:metrics:perf: 3214 URL: http:/// 3216 10.1.4. Description 3218 RTDelay: This metric assesses the round-trip delay of TCP packets 3219 constituting a single connection, exchanged between two hosts. We 3220 consider the measurement of round-trip delay based on a single 3221 Observation Point [RFC7011] somewhere in the network. The Output is 3222 the Round-trip delay for all successfully exchanged packets expressed 3223 as the of their conditional delay distribution, where 3224 is one of: 3226 o Mean 3228 o Min 3230 o Max 3232 RTLoss: This metric assesses the estimated loss count for TCP packets 3233 constituting a single connection, exchanged between two hosts. We 3234 consider the measurement of round-trip delay based on a single 3235 Observation Point [RFC7011] somewhere in the network. The Output is 3236 the estimated Loss Count for the measurement interval. 3238 10.1.5. Change Controller 3240 IETF 3242 10.1.6. Version (of Registry Format) 3244 1.0 3246 10.2. Metric Definition 3248 This category includes columns to prompt the entry of all necessary 3249 details related to the metric definition, including the RFC reference 3250 and values of input factors, called fixed parameters. 3252 10.2.1. Reference Definitions 3254 3256 Although there is no RFC that describes passive measurement of Round- 3257 Trip Delay, the parallel definition for Active measurement is: 3259 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 3260 Metric for IPPM", RFC 2681, September 1999. 3262 [RFC2681] 3264 3266 This metric definition uses the terms singleton and sample as defined 3267 in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the 3268 reference definition of the singleton (single value) Round-trip delay 3269 metric. Section 3.4 of [RFC2681] provides the reference definition 3270 expanded to cover a multi-singleton sample.) 3272 With the Observation Point [RFC7011] (OP) typically located between 3273 the hosts participating in the TCP connection, the Round-trip Delay 3274 metric requires two individual measurements between the OP and each 3275 host, such that the Spatial Composition [RFC6049]of the measurements 3276 yields a Round-trip Delay singleton (we are extending the composition 3277 of one-way subpath delays to subpath round-trip delay). 3279 Using the direction of TCP SYN transmission to anchor the 3280 nomenclature, host A sends the SYN and host B replies with SYN-ACK 3281 during connection establishment. The direction of SYN transfer is 3282 considered the Forward direction of transmission, from A through OP 3283 to B (Reverse is B through OP to A). 3285 Traffic filters reduce the packet stream at the OP to a Qualified 3286 bidirectional flow packets. 3288 In the definitions below, Corresponding Packets are transferred in 3289 different directions and convey a common value in a TCP header field 3290 that establishes correspondence (to the extent possible). Examples 3291 may be found in the TCP timestamp fields. 3293 For a real number, RTD_fwd, >> the Round-trip Delay in the Forward 3294 direction from OP to host B at time T' is RTD_fwd << REQUIRES that OP 3295 observed a Qualified Packet to host B at wire-time T', that host B 3296 received that packet and sent a Corresponding Packet back to host A, 3297 and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. 3299 For a real number, RTD_rev, >> the Round-trip Delay in the Reverse 3300 direction from OP to host A at time T'' is RTD_rev << REQUIRES that 3301 OP observed a Qualified Packet to host A at wire-time T'', that host 3302 A received that packet and sent a Corresponding Packet back to host 3303 B, and that OP observed the Corresponding Packet at wire-time T'' + 3304 RTD_rev. 3306 Ideally, the packet sent from host B to host A in both definitions 3307 above SHOULD be the same packet (or, when measuring RTD_rev first, 3308 the packet from host A to host B in both definitions should be the 3309 same). 3311 The REQUIRED Composition Function for a singleton of Round-trip Delay 3312 at time T (where T is the earliest of T' and T'' above) is: 3314 RTDelay = RTD_fwd + RTD_rev 3316 Note that when OP is located at host A or host B, one of the terms 3317 composing RTDelay will be zero or negligible. 3319 When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- 3320 SYN-ACK, then RTD_fwd == RTD_HS_fwd. 3322 When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a 3323 TCP-ACK, then RTD_rev == RTD_HS_rev. 3325 The REQUIRED Composition Function for a singleton of Round-trip Delay 3326 for the connection Hand Shake: 3328 RTDelay_HS = RTD_HS_fwd + RTD_HS_rev 3330 The definition of Round-trip Loss Count uses the nomenclature 3331 developed above, based on observation of the TCP header sequence 3332 numbers and storing the sequence number gaps observed. Packet Losses 3333 can be inferred from: 3335 o Out-of-order segments: TCP segments are transmitted with 3336 monotonically increasing sequence numbers, but these segments may 3337 be received out of order. Section 3 of [RFC4737] describes the 3338 notion of "next expected" sequence numbers which can be adapted to 3339 TCP segments (for the purpose of detecting reordered packets). 3340 Observation of out-of-order segments indicates loss on the path 3341 prior to the OP, and creates a gap. 3343 o Duplicate segments: Section 2 of [RFC5560] defines identical 3344 packets and is suitable for evaluation of TCP packets to detect 3345 duplication. Observation of duplicate segments *without a 3346 corresponding gap* indicates loss on the path following the OP 3347 (because they overlap part of the delivered sequence numbers 3348 already observed at OP). 3350 Each observation of an out-of-order or duplicate infers a singleton 3351 of loss, but composition of Round-trip Loss Counts will be conducted 3352 over a measurement interval which is synonymous with a single TCP 3353 connection. 3355 With the above observations in the Forward direction over a 3356 measurement interval, the count of out-of-order and duplicate 3357 segments is defined as RTL_fwd. Comparable observations in the 3358 Reverse direction are defined as RTL_rev. 3360 For a measurement interval (corresponding to a single TCP 3361 connection), T0 to Tf, the REQUIRED Composition Function for a the 3362 two single-direction counts of inferred loss is: 3364 RTLoss = RTL_fwd + RTL_rev 3366 10.2.2. Fixed Parameters 3368 3372 Traffic Filters: 3374 o IPv4 header values: 3376 * DSCP: set to 0 3378 * Protocol: Set to 06 (TCP) 3380 o IPv6 header values: 3382 * DSCP: set to 0 3384 * Protocol: Set to 06 (TCP) 3386 o TCP header values: 3388 * Flags: ACK, SYN, FIN, @@@@@ others?? 3390 * Timestamp Option (TSopt): Set 3392 + Kind: 8 3394 + Length: 10 bytes 3396 o 3398 10.3. Method of Measurement 3400 This category includes columns for references to relevant sections of 3401 the RFC(s) and any supplemental information needed to ensure an 3402 unambiguous methods for implementations. 3404 10.3.1. Reference Methods 3406 3409 The foundation methodology for this metric is defined in Section 4 of 3410 [RFC7323] using the Timestamp Option with modifications that allow 3411 application at a mid-path Observation Point (OP) [RFC7011]. Further 3412 details and applicable heuristics were derived from [Strowes] and 3413 [Trammell-14]. 3415 The Traffic Filter at the OP is configured to observe a single TCP 3416 connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers 3417 the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK 3418 pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton 3419 of RTDelay as RTDelay_HS (composed using the forward and reverse 3420 measurement pair). RTDelay_HS SHALL be treated separately from other 3421 RTDelays on data-bearing packets and their ACKs. The RTDelay_HS 3422 value MAY be used as a sanity check on other Composed values of 3423 RTDelay. 3425 For payload bearing packets, the OP measures the time interval 3426 between observation of a packet with Sequence Number s, and the 3427 corresponding ACK with same Sequence number. When the payload is 3428 transferred from host A to host B, the observed interval is RTD_fwd. 3430 Because many data transfers are unidirectional (say, in the Forward 3431 direction from host A to host B), it is necessary to use pure ACK 3432 packets with Timestamp (TSval) and their Timestamp value echo to 3433 perform a RTD_rev measurement. The time interval between observation 3434 of the ACK from B to A, and the corresponding packet with Timestamp 3435 echo (TSecr) is the RTD_rev. 3437 Delay Measurement Filtering Heuristics: 3439 If Data payloads were transferred in both Forward and Reverse 3440 directions, then the Round-Trip Time Measurement Rule in Section 4.1 3441 of [RFC7323] could be applied. This rule essentially excludes any 3442 measurement using a packet unless it makes progress in the transfer 3443 (advances the left edge of the send window, consistent 3444 with[Strowes]). 3446 A different heuristic from [Trammell-14] is to exclude any RTD_rev 3447 that is larger than previously observed values. This would tend to 3448 exclude Reverse measurements taken when the Application has no data 3449 ready to send, because considerable time could be added to RTD_rev 3450 from this source of error. 3452 @@@@ Note that the above Heuristic assumes that host A is sending 3453 data. Host A expecting a download would mean that this heuristic 3454 should be applied to RTD_fwd. 3456 The statistic calculations to summarize the delay (RTDelay) SHALL be 3457 performed on the conditional distribution, conditioned on successful 3458 Forward and Reverse measurements which follow the Heuristics. 3460 Method for Inferring Loss: 3462 The OP tracks sequence numbers and stores gaps for each direction of 3463 transmission, as well as the next-expected sequence number as in 3464 [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order 3465 segments and Duplicate segments. 3467 Loss Measurement Filtering Heuristics: 3469 [Trammell-14] adds a window of evaluation based on the RTDelay. 3471 Distinguish Re-ordered from OOO due to loss, because sequence number 3472 gap is filled during the same RTDelay window. Segments detected as 3473 re-ordered according to [RFC4737] MUST reduce the Loss Count inferred 3474 from Out-of-order segments. 3476 Spurious (unneeded) retransmissions (observed as duplicates) can also 3477 be reduced this way, as described in [Trammell-14]. 3479 Sources of Error: 3481 The principal source of RTDelay error is the host processing time to 3482 return a packet that defines the termination of a time interval. The 3483 heuristics above intend to mitigate these errors by excluding 3484 measurements where host processing time is a significant part of 3485 RTD_fwd or RTD_rev. 3487 A key source of RTLoss error is observation loss, described in 3488 section 3 of [Trammell-14]. 3490 10.3.2. Packet Stream Generation 3492 This section gives the details of the packet traffic which is the 3493 basis for measurement. In IPPM metrics, this is called the Stream, 3494 and can easily be described by providing the list of stream 3495 parameters. 3497 NA 3499 10.3.3. Traffic Filtering (observation) Details 3501 The measured results based on a filtered version of the packets 3502 observed, and this section provides the filter details (when 3503 present). 3505 The Fixed Parameters above give a portion of the Traffic Filter. 3506 Other aspects will be supplied as Run-time Parameters (below). 3508 10.3.4. Sampling Distribution 3510 3513 This metric requires a complete sample of all packets that qualify 3514 according to the Traffic Filter criteria. 3516 10.3.5. Run-time Parameters and Data Format 3518 Run-time Parameters are input factors that must be determined, 3519 configured into the measurement system, and reported with the results 3520 for the context to be complete. 3522 3524 Src the IP address of the host in the host A Role (format ipv4- 3525 address-no-zone value for IPv4, or ipv6-address-no-zone value for 3526 IPv6, see Section 4 of [RFC6991]) 3528 Dst the IP address of the host in the host B (format ipv4-address- 3529 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 3530 see section 4 of [RFC6991]) 3532 T0 a time, the start of a measurement interval, (format "date-and- 3533 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3534 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3535 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 3536 and Td is to be interpreted as the Duration of the measurement 3537 interval. The start time is controlled through other means. 3539 Td Optionally, the end of a measurement interval, (format "date-and- 3540 time" as specified in Section 5.6 of [RFC3339], see also Section 3 3541 of [RFC6991]), or the duration (see T0). The UTC Time Zone is 3542 required by Section 6.1 of [RFC2330]. Alternatively, the end of 3543 the measurement interval MAY be controlled by the measured 3544 connection, where the second pair of FIN and ACK packets exchanged 3545 between host A and B effectively ends the interval. 3547 TTL or Hop Limit Set at desired value. 3549 10.3.6. Roles 3551 3553 host A launches the SYN packet to open the connection, and 3554 synonymous with an IP address. 3556 host B replies with the SYN-ACK packet to open the connection, and 3557 synonymous with an IP address. 3559 10.4. Output 3561 This category specifies all details of the Output of measurements 3562 using the metric. 3564 10.4.1. Type 3566 3568 See subsection titles in Reference Definition for RTDelay Types. 3570 For RTLoss -- the count of lost packets. 3572 10.4.2. Reference Definition 3574 3576 For all output types --- 3578 T0 the start of a measurement interval, (format "date-and-time" as 3579 specified in Section 5.6 of [RFC3339], see also Section 3 of 3580 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3581 [RFC2330]. 3583 Tf the end of a measurement interval, (format "date-and-time" as 3584 specified in Section 5.6 of [RFC3339], see also Section 3 of 3585 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 3586 [RFC2330]. The end of the measurement interval MAY be controlled 3587 by the measured connection, where the second pair of FIN and ACK 3588 packets exchanged between host A and B effectively ends the 3589 interval. 3591 ... ... 3593 For RTDelay_HS -- the Round trip delay of the Handshake. 3595 For RTLoss -- the count of lost packets. 3597 For each , one of the following sub-sections apply: 3599 10.4.2.1. Mean 3601 The mean SHALL be calculated using the conditional distribution of 3602 all packets with a finite value of Round-trip delay (undefined delays 3603 are excluded), a single value as follows: 3605 See section 4.1 of [RFC3393] for details on the conditional 3606 distribution to exclude undefined values of delay, and Section 5 of 3607 [RFC6703] for background on this analysis choice. 3609 See section 4.2.2 of [RFC6049] for details on calculating this 3610 statistic, and 4.2.3 of [RFC6049]. 3612 Mean The time value of the result is expressed in units of seconds, 3613 as a positive value of type decimal64 with fraction digits = 9 3614 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3615 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3616 NTP timestamp as per section 6 of RFC [RFC5905] 3618 10.4.2.2. Min 3620 The minimum SHALL be calculated using the conditional distribution of 3621 all packets with a finite value of Round-trip delay (undefined delays 3622 are excluded), a single value as follows: 3624 See section 4.1 of [RFC3393] for details on the conditional 3625 distribution to exclude undefined values of delay, and Section 5 of 3626 [RFC6703] for background on this analysis choice. 3628 See section 4.3.2 of [RFC6049] for details on calculating this 3629 statistic, and 4.3.3 of [RFC6049]. 3631 Min The time value of the result is expressed in units of seconds, 3632 as a positive value of type decimal64 with fraction digits = 9 3633 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3634 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3635 NTP timestamp as per section 6 of RFC [RFC5905] 3637 10.4.2.3. Max 3639 The maximum SHALL be calculated using the conditional distribution of 3640 all packets with a finite value of Round-trip delay (undefined delays 3641 are excluded), a single value as follows: 3643 See section 4.1 of [RFC3393] for details on the conditional 3644 distribution to exclude undefined values of delay, and Section 5 of 3645 [RFC6703] for background on this analysis choice. 3647 See section 4.3.2 of [RFC6049] for a closely related method for 3648 calculating this statistic, and 4.3.3 of [RFC6049]. The formula is 3649 as follows: 3651 Max = (FiniteDelay [j]) 3653 such that for some index, j, where 1 <= j <= N 3654 FiniteDelay[j] >= FiniteDelay[n] for all n 3656 Max The time value of the result is expressed in units of seconds, 3657 as a positive value of type decimal64 with fraction digits = 9 3658 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 3659 seconds (1.0 ns), and with lossless conversion to/from the 64-bit 3660 NTP timestamp as per section 6 of RFC [RFC5905] 3662 10.4.3. Metric Units 3664 . 3667 The of Round-trip Delay is expressed in seconds, where 3668 is one of: 3670 o Mean 3672 o Min 3674 o Max 3676 The Round-trip Delay of the Hand Shake is expressed in seconds. 3678 The Round-trip Loss Count is expressed as a number of packets. 3680 10.4.4. Calibration 3682 Passive measurements at an OP could be calibrated against an active 3683 measurement (with loss emulation) at host A or B, where the active 3684 measurement represents the ground-truth. 3686 10.5. Administrative items 3687 10.5.1. Status 3689 3691 10.5.2. Requestor (keep?) 3693 name or RFC, etc. 3695 10.5.3. Revision 3697 1.0 3699 10.5.4. Revision Date 3701 YYYY-MM-DD 3703 10.6. Comments and Remarks 3705 Additional (Informational) details for this entry 3707 11. ver08 BLANK Registry Entry 3709 This section gives an initial registry entry for .... 3711 11.1. Summary 3713 This category includes multiple indexes to the registry entries, the 3714 element ID and metric name. 3716 11.1.1. ID (Identifier) 3718 3720 11.1.2. Name 3722 3724 11.1.3. URIs 3726 URI: Prefix urn:ietf:metrics:perf: 3728 URL: 3730 11.1.4. Description 3732 TBD. 3734 11.1.5. Reference 3736 3738 11.1.6. Change Controller 3740 3742 11.1.7. Version (of Registry Format) 3744 3746 11.2. Metric Definition 3748 This category includes columns to prompt the entry of all necessary 3749 details related to the metric definition, including the RFC reference 3750 and values of input factors, called fixed parameters. 3752 11.2.1. Reference Definition 3754 3756 3758 11.2.2. Fixed Parameters 3760 3764 11.3. Method of Measurement 3766 This category includes columns for references to relevant sections of 3767 the RFC(s) and any supplemental information needed to ensure an 3768 unambiguous methods for implementations. 3770 11.3.1. Reference Method 3772 3775 11.3.2. Packet Stream Generation 3777 3779 11.3.3. Traffic Filtering (observation) Details 3781 . 3785 11.3.4. Sampling Distribution 3787 3790 11.3.5. Run-time Parameters and Data Format 3792 . 3794 11.3.6. Roles 3796 3798 11.4. Output 3800 This category specifies all details of the Output of measurements 3801 using the metric. 3803 11.4.1. Type 3805 3807 11.4.2. Reference Definition 3809 3811 11.4.3. Metric Units 3813 . 3816 11.4.4. Calibration 3818 3823 11.5. Administrative items 3825 11.5.1. Status 3827 3829 11.5.2. Requestor 3831 3833 11.5.3. Revision 3835 1.0 3837 11.5.4. Revision Date 3839 YYYY-MM-DD 3841 11.6. Comments and Remarks 3843 Additional (Informational) details for this entry 3845 12. Example RTCP-XR Registry Entry 3847 This section is MAY BE DELETED or adapted before submission. 3849 This section gives an example registry entry for the end-point metric 3850 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 3851 reporting. 3853 12.1. Registry Indexes 3855 This category includes multiple indexes to the registry entries, the 3856 element ID and metric name. 3858 12.1.1. Identifier 3860 An integer having enough digits to uniquely identify each entry in 3861 the Registry. 3863 12.1.2. Name 3865 A metric naming convention is TBD. 3867 12.1.3. URI 3869 Prefix urn:ietf:metrics:param: 3871 12.1.4. Status 3873 current 3875 12.1.5. Requestor 3877 Alcelip Mornuley 3879 12.1.6. Revision 3881 1.0 3883 12.1.7. Revision Date 3885 2014-07-04 3887 12.1.8. Description 3889 TBD. 3891 12.1.9. Reference Specification(s) 3893 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 3895 12.2. Metric Definition 3897 This category includes columns to prompt the entry of all necessary 3898 details related to the metric definition, including the RFC reference 3899 and values of input factors, called fixed parameters. Section 3.2 of 3900 [RFC7003] provides the reference information for this category. 3902 12.2.1. Reference Definition 3904 Packets Discarded in Bursts: 3906 The total number of packets discarded during discard bursts. The 3907 measured value is unsigned value. If the measured value exceeds 3908 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 3909 range measurement. If the measurement is unavailable, the value 3910 0xFFFFFF MUST be reported. 3912 12.2.2. Fixed Parameters 3914 Fixed Parameters are input factors that must be determined and 3915 embedded in the measurement system for use when needed. The values 3916 of these parameters is specified in the Registry. 3918 Threshold: 8 bits, set to value = 3 packets. 3920 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 3921 successive packets that must not be discarded prior to and following 3922 a discard packet in order for this discarded packet to be regarded as 3923 part of a gap. Note that the Threshold is set in accordance with the 3924 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 3926 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 3928 This field is used to indicate whether the burst/gap discard metrics 3929 are Sampled, Interval, or Cumulative metrics [RFC6792]: 3931 I=10: Interval Duration - the reported value applies to the most 3932 recent measurement interval duration between successive metrics 3933 reports. 3935 I=11: Cumulative Duration - the reported value applies to the 3936 accumulation period characteristic of cumulative measurements. 3938 Senders MUST NOT use the values I=00 or I=01. 3940 12.3. Method of Measurement 3942 This category includes columns for references to relevant sections of 3943 the RFC(s) and any supplemental information needed to ensure an 3944 unambiguous methods for implementations. For the Burst/Gap Discard 3945 Metric, it appears that the only guidance on methods of measurement 3946 is in Section 3.0 of [RFC7003] and its supporting references. 3947 Relevant information is repeated below, although there appears to be 3948 no section titled "Method of Measurement" in [RFC7003]. 3950 12.3.1. Reference Method 3952 Metrics in this block report on burst/gap discard in the stream 3953 arriving at the RTP system. Measurements of these metrics are made 3954 at the receiving end of the RTP stream. Instances of this metrics 3955 block use the synchronization source (SSRC) to refer to the separate 3956 auxiliary Measurement Information Block [RFC6776], which describes 3957 measurement periods in use (see [RFC6776], Section 4.2). 3959 This metrics block relies on the measurement period in the 3960 Measurement Information Block indicating the span of the report. 3961 Senders MUST send this block in the same compound RTCP packet as the 3962 Measurement Information Block. Receivers MUST verify that the 3963 measurement period is received in the same compound RTCP packet as 3964 this metrics block. If not, this metrics block MUST be discarded. 3966 12.3.2. Stream Type and Stream Parameters 3968 Since RTCP-XR Measurements are conducted on live RTP traffic, the 3969 complete description of the stream is contained in SDP messages that 3970 proceed the establishment of a compatible stream between two or more 3971 communicating hosts. See Run-time Parameters, below. 3973 12.3.3. Output Type and Data Format 3975 The output type defines the type of result that the metric produces. 3977 o Value: Packets Discarded in Bursts 3979 o Data Format: 24 bits 3981 o Reference: Section 3.2 of [RFC7003] 3983 12.3.4. Metric Units 3985 The measured results are apparently expressed in packets, although 3986 there is no section of [RFC7003] titled "Metric Units". 3988 12.3.5. Run-time Parameters and Data Format 3990 Run-Time Parameters are input factors that must be determined, 3991 configured into the measurement system, and reported with the results 3992 for the context to be complete. However, the values of these 3993 parameters is not specified in the Registry, rather these parameters 3994 are listed as an aid to the measurement system implementor or user 3995 (they must be left as variables, and supplied on execution). 3997 The Data Format of each Run-time Parameter SHALL be specified in this 3998 column, to simplify the control and implementation of measurement 3999 devices. 4001 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 4003 SDP Parameters: As defined in [RFC4566] 4005 Session description v= (protocol version number, currently only 0) 4006 o= (originator and session identifier : username, id, version number, 4007 network address) 4009 s= (session name : mandatory with at least one UTF-8-encoded 4010 character) 4012 i=* (session title or short information) u=* (URI of description) 4014 e=* (zero or more email address with optional name of contacts) 4016 p=* (zero or more phone number with optional name of contacts) 4018 c=* (connection information--not required if included in all media) 4020 b=* (zero or more bandwidth information lines) One or more Time 4021 descriptions ("t=" and "r=" lines; see below) 4023 z=* (time zone adjustments) 4025 k=* (encryption key) 4027 a=* (zero or more session attribute lines) 4029 Zero or more Media descriptions (each one starting by an "m=" line; 4030 see below) 4032 m= (media name and transport address) 4034 i=* (media title or information field) 4036 c=* (connection information -- optional if included at session level) 4038 b=* (zero or more bandwidth information lines) 4040 k=* (encryption key) 4042 a=* (zero or more media attribute lines -- overriding the Session 4043 attribute lines) 4045 An example Run-time SDP description follows: 4047 v=0 4049 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 4051 s=SDP Seminar i=A Seminar on the session description protocol 4052 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 4053 Doe) 4055 c=IN IP4 233.252.0.12/127 4057 t=2873397496 2873404696 4059 a=recvonly 4061 m=audio 49170 RTP/AVP 0 4063 m=video 51372 RTP/AVP 99 4065 a=rtpmap:99 h263-1998/90000 4067 12.4. Comments and Remarks 4069 TBD. 4071 13. Revision History 4073 This section may be removed for publication. It contains overview 4074 information on updates. 4076 This draft replaced draft-mornuley-ippm-initial-registry. 4078 In version 02, Section 4 has been edited to reflect recent discussion 4079 on the ippm-list: * Removed the combination or "Raw" and left 95th 4080 percentile. * Hanging Indent on Run-time parameters (Fixed parameters 4081 use bullet lists and other indenting formats. * Payload format for 4082 measurement has been removed. * Explanation of Conditional delay 4083 distribution. 4085 Version 03 addressed Phil Eardley's comments and suggestions in 4086 sections 1-4. and resolved the definition of Percentiles. 4088 Version 04 * All section 4 parameters reference YANG types for 4089 alternate data formats. * Discussion has concluded that usecase(s) 4090 for machine parse-able registry columns are not needed. 4092 Version 05 * Revised several Poisson streams to Periodic, sections 4 4093 & 5. * Addition of ICMP (ping) metrics in section 9. * First 4094 implementation of Passive TCP RTT metrics in section 10. 4096 14. Security Considerations 4098 These registry entries represent no known security implications for 4099 Internet Security. Each referenced Metric contains a Security 4100 Considerations section. 4102 15. IANA Considerations 4104 IANA is requested to populate The Performance Metric Registry defined 4105 in [I-D.ietf-ippm-metric-registry] with the values defined above. 4107 See the IANA Considerations section of 4108 [I-D.ietf-ippm-metric-registry] for additional requests and 4109 considerations. 4111 16. Acknowledgements 4113 The authors thank Brian Trammell for suggesting the term "Run-time 4114 Parameters", which led to the distinction between run-time and fixed 4115 parameters implemented in this memo, for identifying the IPFIX metric 4116 with Flow Key as an example, for suggesting the Passive TCP RTD 4117 metric and supporting references, and for many other productive 4118 suggestions. Thanks to Peter Koch, who provided several useful 4119 suggestions for disambiguating successive DNS Queries in the DNS 4120 Response time metric. 4122 The authors also acknowledge the constructive reviews and helpful 4123 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 4124 participants in the LMAP working group. Thanks to Michelle Cotton 4125 for her early IANA review, and to Amanda Barber for answering 4126 questions related to the presentation of the registry and 4127 accessibility of the complete template via URL. 4129 17. References 4131 17.1. Normative References 4133 [I-D.ietf-ippm-metric-registry] 4134 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 4135 "Registry for Performance Metrics", Internet Draft (work 4136 in progress) draft-ietf-ippm-metric-registry, 2014. 4138 [RFC1035] Mockapetris, P., "Domain names - implementation and 4139 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4140 November 1987, . 4142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4143 Requirement Levels", BCP 14, RFC 2119, 4144 DOI 10.17487/RFC2119, March 1997, 4145 . 4147 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 4148 "Framework for IP Performance Metrics", RFC 2330, 4149 DOI 10.17487/RFC2330, May 1998, 4150 . 4152 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 4153 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 4154 September 1999, . 4156 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 4157 Packet Loss Metric for IPPM", RFC 2680, 4158 DOI 10.17487/RFC2680, September 1999, 4159 . 4161 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 4162 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 4163 September 1999, . 4165 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4166 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4167 . 4169 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 4170 Metric for IP Performance Metrics (IPPM)", RFC 3393, 4171 DOI 10.17487/RFC3393, November 2002, 4172 . 4174 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 4175 performance measurement with periodic streams", RFC 3432, 4176 DOI 10.17487/RFC3432, November 2002, 4177 . 4179 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 4180 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 4181 DOI 10.17487/RFC4737, November 2006, 4182 . 4184 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 4185 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 4186 RFC 5357, DOI 10.17487/RFC5357, October 2008, 4187 . 4189 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 4190 RFC 5560, DOI 10.17487/RFC5560, May 2009, 4191 . 4193 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 4194 "Network Time Protocol Version 4: Protocol and Algorithms 4195 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 4196 . 4198 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 4199 the Network Configuration Protocol (NETCONF)", RFC 6020, 4200 DOI 10.17487/RFC6020, October 2010, 4201 . 4203 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 4204 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 4205 . 4207 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 4208 DOI 10.17487/RFC6673, August 2012, 4209 . 4211 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4212 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4213 . 4215 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 4216 "Specification of the IP Flow Information Export (IPFIX) 4217 Protocol for the Exchange of Flow Information", STD 77, 4218 RFC 7011, DOI 10.17487/RFC7011, September 2013, 4219 . 4221 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 4222 Scheffenegger, Ed., "TCP Extensions for High Performance", 4223 RFC 7323, DOI 10.17487/RFC7323, September 2014, 4224 . 4226 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 4227 Ed., "A One-Way Delay Metric for IP Performance Metrics 4228 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 4229 2016, . 4231 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 4232 Ed., "A One-Way Loss Metric for IP Performance Metrics 4233 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 4234 2016, . 4236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4238 May 2017, . 4240 17.2. Informative References 4242 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 4243 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 4244 July 1991, . 4246 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 4247 "RTP Control Protocol Extended Reports (RTCP XR)", 4248 RFC 3611, DOI 10.17487/RFC3611, November 2003, 4249 . 4251 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 4252 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 4253 2005, . 4255 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4256 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 4257 July 2006, . 4259 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 4260 Flow Information Export (IPFIX) Applicability", RFC 5472, 4261 DOI 10.17487/RFC5472, March 2009, 4262 . 4264 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 4265 Carle, "Information Model for Packet Sampling Exports", 4266 RFC 5477, DOI 10.17487/RFC5477, March 2009, 4267 . 4269 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 4270 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 4271 March 2009, . 4273 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 4274 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 4275 DOI 10.17487/RFC6248, April 2011, 4276 . 4278 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 4279 Performance Metric Development", BCP 170, RFC 6390, 4280 DOI 10.17487/RFC6390, October 2011, 4281 . 4283 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 4284 IP Network Performance Metrics: Different Points of View", 4285 RFC 6703, DOI 10.17487/RFC6703, August 2012, 4286 . 4288 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 4289 Reporting Using a Source Description (SDES) Item and an 4290 RTCP Extended Report (XR) Block", RFC 6776, 4291 DOI 10.17487/RFC6776, October 2012, 4292 . 4294 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 4295 of the RTP Monitoring Framework", RFC 6792, 4296 DOI 10.17487/RFC6792, November 2012, 4297 . 4299 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 4300 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 4301 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 4302 September 2013, . 4304 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 4305 Aitken, P., and A. Akhter, "A Framework for Large-Scale 4306 Measurement of Broadband Performance (LMAP)", RFC 7594, 4307 DOI 10.17487/RFC7594, September 2015, 4308 . 4310 [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, 4311 Communications of the ACM, Vol. 56 No. 10, Pages 57-64", 4312 September 2013. 4314 [Trammell-14] 4315 Trammell, B., "Inline Data Integrity Signals for Passive 4316 Measurement, TMA 2014 4317 https://trammell.ch/pdf/qof-tma14.pdf", March 2014. 4319 Authors' Addresses 4321 Al Morton 4322 AT&T Labs 4323 200 Laurel Avenue South 4324 Middletown,, NJ 07748 4325 USA 4327 Phone: +1 732 420 1571 4328 Fax: +1 732 368 1192 4329 Email: acmorton@att.com 4330 URI: http://home.comcast.net/~acmacm/ 4331 Marcelo Bagnulo 4332 Universidad Carlos III de Madrid 4333 Av. Universidad 30 4334 Leganes, Madrid 28911 4335 SPAIN 4337 Phone: 34 91 6249500 4338 Email: marcelo@it.uc3m.es 4339 URI: http://www.it.uc3m.es 4341 Philip Eardley 4342 BT 4343 Adastral Park, Martlesham Heath 4344 Ipswich 4345 ENGLAND 4347 Email: philip.eardley@bt.com 4349 Kevin D'Souza 4350 AT&T Labs 4351 200 Laurel Avenue South 4352 Middletown,, NJ 07748 4353 USA 4355 Phone: +1 732 420 xxxx 4356 Email: kld@att.com