idnits 2.17.1 draft-mornuley-ippm-initial-registry-00.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 -- The document date (September 11, 2014) is 3508 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 1870, but no explicit reference was found in the text == Unused Reference: 'RFC3432' is defined on line 1880, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 1884, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 1888, but no explicit reference was found in the text == Unused Reference: 'Brow00' is defined on line 1901, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lmap-framework' is defined on line 1904, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 1917, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 1923, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 1927, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 1934, 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) == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-08 -- 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 (~~), 12 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: March 15, 2015 UC3M 6 P. Eardley 7 BT 8 September 11, 2014 10 Initial Performance Metric Registry Entries 11 draft-mornuley-ippm-initial-registry-00 13 Abstract 15 This memo defines the Initial Entries for the Performance Metrics 16 Registry. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 15, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Registry Categories and Columns . . . . . . . . . . . . . . . 6 61 4. UDP Round-trip Latency Registry Entry . . . . . . . . . . . . 7 62 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 7 64 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 8 68 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 8 69 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 8 70 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 9 71 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 9 72 4.3.2. Packet Generation Stream . . . . . . . . . . . . . . 10 73 4.3.3. Traffic Filtering (observation) Details . . . . . . . 10 74 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 10 75 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 10 76 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.4.1. Type/Value (two diff terms used) . . . . . . . . . . 11 79 4.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 12 80 4.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 13 81 4.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 13 82 4.5. Administrative items . . . . . . . . . . . . . . . . . . 13 83 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 13 85 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 13 86 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 13 87 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 13 88 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 13 89 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 14 91 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 14 94 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 14 95 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 14 96 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 15 98 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 15 99 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 15 100 5.3.2. Packet Generation Stream . . . . . . . . . . . . . . 15 101 5.3.3. Traffic Filtering (observation) Details . . . . . . . 16 102 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 16 103 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 16 104 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 16 105 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 5.4.1. Type/Value (two diff terms used) . . . . . . . . . . 17 107 5.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 17 108 5.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 18 109 5.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 18 110 5.5. Administrative items . . . . . . . . . . . . . . . . . . 18 111 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18 112 5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 19 113 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 19 114 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 19 115 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 19 116 6. DNS Response Latency Registry Entry . . . . . . . . . . . . . 19 117 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19 118 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 19 119 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 19 120 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 20 121 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 20 122 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 20 123 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 20 124 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 21 125 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 22 126 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 22 127 6.3.2. Packet Generation Stream . . . . . . . . . . . . . . 23 128 6.3.3. Traffic Filtering (observation) Details . . . . . . . 23 129 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 23 130 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 24 131 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 25 132 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 25 133 6.4.1. Type/Value (two diff terms used) . . . . . . . . . . 25 134 6.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 25 135 6.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 26 136 6.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 26 137 6.5. Administrative items . . . . . . . . . . . . . . . . . . 26 138 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 26 139 6.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 27 140 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 27 141 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 27 142 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 27 143 7. partly BLANK Registry Entry . . . . . . . . . . . . . . . . . 27 144 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 27 145 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 27 146 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 27 147 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27 148 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 27 149 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 28 150 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 28 151 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 28 152 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 29 153 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 29 154 7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 29 155 7.3.3. Traffic Filtering (observation) Details . . . . . . . 29 156 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 157 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 30 158 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 159 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 160 7.4.1. Type/Value (two diff terms used) . . . . . . . . . . 30 161 7.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 30 162 7.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 30 163 7.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 30 164 7.5. Administrative items . . . . . . . . . . . . . . . . . . 31 165 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 31 166 7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 31 167 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 31 168 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 31 169 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 31 170 8. BLANK Registry Entry . . . . . . . . . . . . . . . . . . . . 31 171 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 172 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 31 173 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 31 174 8.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 31 175 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 32 176 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 32 177 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 32 178 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 32 179 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 32 180 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 32 181 8.3.2. Packet Generation Stream . . . . . . . . . . . . . . 32 182 8.3.3. Traffic Filtering (observation) Details . . . . . . . 32 183 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 32 184 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 33 185 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 33 186 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 33 187 8.4.1. Type/Value (two diff terms used) . . . . . . . . . . 33 188 8.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 33 189 8.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 33 190 8.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 33 191 8.5. Administrative items . . . . . . . . . . . . . . . . . . 33 192 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 33 193 8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 33 194 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 33 195 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 34 196 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 34 197 9. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 34 198 9.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 34 199 9.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 34 200 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 34 201 9.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 34 202 9.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 34 203 9.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . . 34 204 9.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 34 205 9.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 35 206 9.1.8. Description . . . . . . . . . . . . . . . . . . . . . 35 207 9.1.9. Reference Specification(s) . . . . . . . . . . . . . 35 208 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 35 209 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 35 210 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 211 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36 212 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 213 9.3.2. Stream Type and Stream Parameters . . . . . . . . . . 36 214 9.3.3. Output Type and Data Format . . . . . . . . . . . . . 36 215 9.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 37 216 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 217 9.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 38 218 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 219 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 220 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 221 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 222 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 223 13.2. Informative References . . . . . . . . . . . . . . . . . 41 224 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 226 1. Introduction 228 Note: Efforts to synchronize structure and terminology with 229 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 230 drafts are stable. 232 This memo defines the Initial set of entries for the Performance 233 Metric Registry. The registry will contain Active Performance 234 Metrics, especially those defined in RFCs prepared in the IP 235 Performance Metrics (IPPM) Working Group of the IETF, according to 236 their framework [RFC2330]. Three aspects make IPPM metric 237 registration difficult: (1) Use of the Type-P notion to allow users 238 to specify their own packet types. (2) Use of Flexible input 239 variables, called Parameters in IPPM definitions, some which 240 determine the quantity measured and others which should not be 241 specified until execution of the measurement. (3) Allowing 242 flexibility in choice of statistics to summarize the results on a 243 stream of measurement packets. This memo uses terms and definitions 244 from the IPPM literature, primarily [RFC2330], and the reader is 245 assumed familiar with them or may refer questions there as necessary. 247 Although there are several standard templates for organizing 248 specifications of performance metrics (see [RFC2679] for an example 249 of the traditional IPPM template, based to large extent on the 250 Benchmarking Methodology Working Group's traditional template in 251 [RFC1242], and see [RFC6390] for a similar template), none of these 252 templates were intended to become the basis for the columns of an 253 IETF-wide registry of metrics. As we examined the aspects of metric 254 specifications which need to be registered, it was clear that none of 255 the existing metric templates fully satisfies the particular needs of 256 a registry. 258 2. Scope 260 [I-D.ietf-ippm-metric-registry] defines the overall structure for a 261 Performance Metric Registry and provides guidance for the process to 262 examine proposed metrics and maitain Registered Metrics. 264 This document defines the initial set of Performance Metrics Registry 265 entries; all are active metrics, or those where the packets measured 266 have been specially generated for the purpose. 268 A row in the registry corresponds to one Registered Performance 269 Metric, with entries in the various columns specifying the metric. 271 As discussed in [I-D.ietf-ippm-metric-registry], each entry (row) 272 must be tightly defined; the definition must leave open only a few 273 parameters that do not change the fundamental nature of the 274 measurement (such as source and destination addresses), and so 275 promotes comparable results across independent implementations. 276 Also, each registered entry must be based on existing reference RFCs 277 (or other standards) for performance metrics, and must be 278 operationally useful and have significant industry interest. This is 279 ensured by expert review for every entry before IANA action. 281 3. Registry Categories and Columns 283 This section defines the categories and columns of the registry. 284 Below, categories are described at the 3.x heading level, and columns 285 are at the 3.x.y heading level. The Figure below illustrates this 286 organization. An entry (row) therefore gives a complete description 287 of a Registered Metric. 289 Each column serves as a check-list item and helps to avoid omissions 290 during registration and expert review. In some cases an entry (row) 291 may have some columns without specific entries, marked Not Applicable 292 (NA). 294 THIS NEEDS UPDATING 296 Registry Categories and Columns, shown as 297 Category 298 ------------------ 299 Column | Column | 301 Comments and Remarks 302 -------------------- 304 4. UDP Round-trip Latency Registry Entry 306 This section gives an initial registry entry for the UDP Round-trip 307 Latency. 309 Note: If each Registry entry should only produce a "raw" output or a 310 statistical summary, then the "Output" Category can be split and this 311 section can become two closely-related metrics. 313 4.1. Summary 315 This category includes multiple indexes to the registry entries, the 316 element ID and metric name. 318 4.1.1. ID (Identifier) 320 322 4.1.2. Name 324 326 Act_IP_UDP_Round-trip_Delay_Raw_95th-percentile_Poisson 328 URL: ?? 330 4.1.3. URI 332 URI: Prefix urn:ietf:params:performance:metric... 334 4.1.4. Description 336 This metric assesses the delay of a stream of packets exchanged 337 between two hosts (or measurement points), and reports the Round-trip 338 delay for all successfully exchanged packets and the 95th percentile 339 of their conditional delay distribution. 341 4.2. Metric Definition 343 This category includes columns to prompt the entry of all necessary 344 details related to the metric definition, including the RFC reference 345 and values of input factors, called fixed parameters. 347 4.2.1. Reference Definition 349 351 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 352 Metric for IPPM", RFC 2681, September 1999. 354 [RFC2681] 356 358 Section 2.4 of [RFC2681] provides the reference definition of the 359 singleton (single value) Round-trip delay metric. Section 3.4 of 360 [RFC2681] provides the reference definition expanded to cover a 361 multi-value sample. Note that terms such as singleton and sample are 362 defined in Section 11 of [RFC2330]. 364 Note that although the definition of "Round-trip-Delay between Src 365 and Dst at T" is directionally ambiguous in the text, this metric 366 tightens the definition further to recognize that the host in the 367 "Src" role will send the first packet to "Dst", and ultimately 368 receive the corresponding return packet from "Dst" (when neither are 369 lost). 371 4.2.2. Fixed Parameters 373 377 Type-P: 379 o IPv4 header values: 381 * DSCP: set to 0 382 * TTL set to 255 384 * Protocol: Set to 17 (UDP) 386 o UDP header values: 388 * Checksum: the checksum must be calculated 390 o Payload 392 * Sequence number: 8-byte integer 394 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 395 as per section 6 of RFC 5905 [RFC5905] 397 * No padding (total of 9 bytes) 399 Timeout, Tmax: 3 seconds 401 4.3. Method of Measurement 403 This category includes columns for references to relevant sections of 404 the RFC(s) and any supplemental information needed to ensure an 405 unambiguous methods for implementations. 407 4.3.1. Reference Method 409 412 The methodology for this metric is defined as Type-P-Round-trip- 413 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 414 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 415 Fixed Parameters. 417 The method requires sequence numbers or other send-order information 418 to be retained at the Src or included with each packet to dis- 419 ambiguate packet reordering if it occurs. Sequence number is part of 420 the payload described under Fixed Parameters. 422 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 423 instruction to "send a Type-P packet back to the Src as quickly as 424 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 425 [RFC6673] presents additional requirements which shall be included in 426 the method of measurement for this metric. 428 4.3.2. Packet Generation Stream 430 This section gives the details of the packet traffic which is the 431 basis for measurement. In IPPM metrics, this is called the Stream, 432 and can easily be dscribed by providing the list of stream 433 parameters. 435 437 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 438 generate Poisson sampling intervals. the reciprocal of lambda is the 439 average packet rate, thus the Run-time Parameter is 1/lambda. 441 >>> Check with Sam, most likely it is this... 443 Method 3 is used, where given a start time (Run-time Parameter), the 444 subsequent send times are all computed prior to measurement by 445 computing the pseudo-random distribution of inter-packet send times, 446 (truncating the distribution as specified in the Run-time 447 Parameters), and the Src sends each packet at the computed times. 449 4.3.3. Traffic Filtering (observation) Details 451 The measured results based on a filtered version of the packets 452 observed, and this section provides the filter details (when 453 present). 455
. 457 NA 459 4.3.4. Sampling Distribution 461 464 NA 466 4.3.5. Run-time Parameters and Data Format 468 Run-time Parameters are input factors that must be determined, 469 configured into the measurement system, and reported with the results 470 for the context to be complete. 472 474 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 475 value for IPv6) 477 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 478 value for IPv6) 480 o T0, a time (start of measurement interval, 128-bit NTP Date 481 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 482 start time is unspecified and Tf is to be interpreted as the 483 Duration of the measurement interval. 485 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 486 see section 6 of [RFC5905]), interpreted as the Duration of the 487 measurement interval. 489 o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 490 1 packet per second, if fixed) 492 o Upper limit on Poisson distribution (values above this limit will 493 be clipped and set to the limit value). (if fixed, Upper limit = 494 30 seconds.) 496 The format for 1/lambda and Upper limit of Poisson Dist. are the 497 short format in [RFC5905] (32 bits) and is as follows: the first 16 498 bits represent the integer number of seconds; the next 16 bits 499 represent the fractional part of a second. 501 >>> should Poisson run-time params be fixed instead? probably yes if 502 modeling a specific version of MBA tests. 504 4.3.6. Roles 506 508 Src - launches each packet and waits for return transmissions from 509 Dst. 511 Dst - waits for each packet from Src and sends a return packet to 512 Src. 514 4.4. Output 516 This category specifies all details of the Output of measurements 517 using the metric. 519 4.4.1. Type/Value (two diff terms used) 521 523 Raw -- for each packet sent, pairs of values. 525 Percentile -- for the conditional distribution of all packets with a 526 valid value of Round-trip delay (undefined delays are excluded), a 527 single value corresponding to the 95th percentile. 529 4.4.2. Data Format 531 533 For all outputs --- 535 o T0, a time (start of measurement interval, 128-bit NTP Date 536 Format, see section 6 of [RFC5905]) 538 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 539 see section 6 of [RFC5905]) 541 Raw -- for each packet sent, pairs of values as follows: 543 o T, the time when the packet was sent from Src, 128-bit NTP Date 544 Format, see section 6 of [RFC5905]) 546 o dT, a value of Round-trip delay, format is *similar to* the 32-bit 547 short NTP Time format in Section 6 of [RFC5905] and is as follows: 548 the first 16 bits represent the *signed* integer number of 549 seconds; the next 16 bits represent the fractional part of a 550 second. 552 o dT is undefined when the packet is not received at Src in waiting 553 time Tmxax seconds (need undefined code) 555 Percentile -- for the conditional distribution of all packets with a 556 valid value of Round-trip delay (undefined delays are excluded), a 557 single value as follows: 559 See section 4.1 of [RFC3393] for details on the conditional 560 distribution to exclude undefined values of delay, and Section 5 of 561 [RFC6703] for background on this analysis choice. 563 See section 4.3 of [RFC3393] for details on the percentile statistic 564 (where Round-trip delay should be substituted for "ipdv"). 566 The percentile = 95. 568 Data format is a 32-bit signed value, *similar to* the 32-bit short 569 NTP Time format in Section 6 of [RFC5905] and is as follows: the 570 first 16 bits represent the *signed* integer number of seconds; the 571 next 16 bits represent the fractional part of a second. 573 4.4.3. Reference 575 577 See the Data Format column for references. 579 4.4.4. Metric Units 581 . 584 Round-trip Delay, dT, is expressed in seconds. 586 The 95th Percentile of Round-trip Delay is expressed in seconds. 588 4.5. Administrative items 590 4.5.1. Status 592 594 4.5.2. Requestor (keep?) 596 name or RFC, etc. 598 4.5.3. Revision 600 1.0 602 4.5.4. Revision Date 604 YYYY-MM-DD 606 4.6. Comments and Remarks 608 Additional (Informational) details for this entry 610 5. Packet Delay Variation Registry Entry 612 This section gives an initial registry entry for a Packet Delay 613 Variation metric. 615 Note: If each Registry entry should only produce a "raw" output or a 616 statistical summary, then the "Output" Category can be split and this 617 section can become two closely-related metrics. 619 5.1. Summary 621 This category includes multiple indexes to the registry entries, the 622 element ID and metric name. 624 626 5.1.1. ID (Identifier) 628 630 5.1.2. Name 632 634 Act_IP-UDP-One-way-pdv-95th-percentile-Poisson 636 URL: ?? 638 5.1.3. URI 640 URI: Prefix urn:ietf:params:performance:metric 642 5.1.4. Description 644 An assessment of packet delay variation with respect to the minimum 645 delay observed on the stream. 647 5.2. Metric Definition 649 This category includes columns to prompt the entry of all necessary 650 details related to the metric definition, including the RFC reference 651 and values of input factors, called fixed parameters. 653 5.2.1. Reference Definition 655 657 Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP 658 Performance Metrics", RFC 2330, May 1998. [RFC2330] 660 Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric 661 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 662 [RFC3393] 664 Morton, A. and B. Claise, "Packet Delay Variation Applicability 665 Statement", RFC 5481, March 2009. [RFC5481] 666 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 667 Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, 668 June 2010.[RFC5905] 670 672 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 673 measured are referred to by the variable name "ddT". 675 5.2.2. Fixed Parameters 677 681 o F, a selection function defining unambiguously the packets from 682 the stream selected for the metric. See section 4.2 of [RFC5481] 683 for the PDV form. 685 o L, a packet length in bits. L = 200 bits. 687 o Tmax, a maximum waiting time for packets to arrive at Dst, set 688 sufficiently long to disambiguate packets with long delays from 689 packets that are discarded (lost). Tmax = 3 seconds. 691 o Type-P, as defined in [RFC2330], which includes any field that may 692 affect a packet's treatment as it traverses the network. The 693 packets are IP/UDP, with DSCP = 0 (BE). 695 5.3. Method of Measurement 697 This category includes columns for references to relevant sections of 698 the RFC(s) and any supplemental information needed to ensure an 699 unambiguous methods for implementations. 701 5.3.1. Reference Method 703 706 See section 2.6 and 3.6 of [RFC3393] for singleton elements. 708 5.3.2. Packet Generation Stream 710 712 Poisson distributed as described in [RFC2330], with the following 713 Parameters. 715 o lambda, a rate in reciprocal seconds (for Poisson Streams). 716 lambda = 1 packet per second 718 o Upper limit on Poisson distribution (values above this limit will 719 be clipped and set to the limit value). Upper limit = 30 seconds. 721 5.3.3. Traffic Filtering (observation) Details 723 . 727 NA 729 5.3.4. Sampling Distribution 731 734 NA 736 5.3.5. Run-time Parameters and Data Format 738 . 740 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 741 value for IPv6) 743 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 744 value for IPv6) 746 o T, a time (start of measurement interval, 128-bit NTP Date Format, 747 see section 6 of [RFC5905]). When T0 is "all-zeros", a start time 748 is unspecified and Tf is to be interpreted as the Duration of the 749 measurement interval. 751 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 752 see section 6 of [RFC5905]), interpreted as the Duration of the 753 measurement interval. 755 5.3.6. Roles 757 759 Src - the host that sends the stream of packets. 761 Dst - the host that receives the stream of packets. 763 5.4. Output 765 This category specifies all details of the Output of measurements 766 using the metric. 768 5.4.1. Type/Value (two diff terms used) 770 772 Raw -- for each packet sent, pairs of values. 774 Percentile -- for the conditional distribution of all packets with a 775 valid value of one-way delay (undefined delays are excluded), a 776 single value corresponding to the 95th percentile of the singletons, 777 ddT. 779 5.4.2. Data Format 781 783 For all Output types 785 o T, a time (start of measurement interval, 128-bit NTP Date Format, 786 see section 6 of [RFC5905]) 788 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 789 see section 6 of [RFC5905]) 791 Raw - 793 o T1, the wire time of the first packet in a pair, measured at 794 MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see 795 section 6 of [RFC5905]). 797 o T2, the wire time of the second packet in a pair, measured at 798 MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see 799 section 6 of [RFC5905]). 801 o I(i),I(i+1), i >=0, pairs of times which mark the beginning and 802 ending of the intervals in which the packet stream from which the 803 measurement is taken occurs. Here, I(0) = T0 and assuming that n 804 is the largest index, I(n) = Tf (pairs of 64-bit NTP Timestamp 805 Format, see section 6 of [RFC5905]). 807 o When the one-way delay of a packet in the calculation pair for ddT 808 is undefined, then ddT is undefined for that pair. 810 Percentile -- for the conditional distribution of all packets with a 811 valid value of one-way delay (undefined delays are excluded), a 812 single value as follows: 814 See section 4.1 of [RFC3393] for details on the conditional 815 distribution to exclude undefined values of delay, and Section 5 of 816 [RFC6703] for background on this analysis choice. 818 See section 4.3 of [RFC3393] for details on the percentile statistic 819 (where pdv should be substituted for "ipdv"). 821 The percentile = 95. 823 Data format is a 32-bit signed floating point value, *similar to* the 824 32-bit short NTP Time format in Section 6 of [RFC5905] and is as 825 follows: the first 16 bits represent the *signed* integer number of 826 seconds; the next 16 bits represent the fractional part of a second. 828 5.4.3. Reference 830 832 see Data Format column. 834 5.4.4. Metric Units 836 . 839 See section 3.3 of [RFC3393] for singleton elements, ddT. The units 840 are seconds, and the same units are used for 95th percentile. 842 [RFC2330] recommends that when a time is given, it will be expressed 843 in UTC. 845 The timestamp format (for T, Tf, etc.) is the same as in [RFC5905] 846 (64 bits) and is as follows: the first 32 bits represent the unsigned 847 integer number of seconds elapsed since 0h on 1 January 1900; the 848 next 32 bits represent the fractional part of a second that has 849 elapsed since then. 851 5.5. Administrative items 853 5.5.1. Status 855 857 5.5.2. Requestor (keep?) 859 861 5.5.3. Revision 863 1.0 865 5.5.4. Revision Date 867 YYYY-MM-DD 869 5.6. Comments and Remarks 871 873 Lost packets represent a challenge for delay variation metrics. See 874 section 4.1 of [RFC3393] and the delay variation applicability 875 statement[RFC5481] for extensive analysis and comparison of PDV and 876 an alternate metric, IPDV. 878 6. DNS Response Latency Registry Entry 880 This section gives an initial registry entry for DNS Response 881 Latency. RFC 2681 [RFC2681] defines a Round-trip delay metric. We 882 build on that metric by specifying several of the input parameters to 883 precisely define a metric for measuring DNS latency. 885 6.1. Summary 887 This category includes multiple indexes to the registry entries, the 888 element ID and metric name. 890 892 6.1.1. ID (Identifier) 894 896 6.1.2. Name 898 900 URL: ?? 902 6.1.3. URI 904 URI: Prefix urn:ietf:params:performance:metric 906 6.1.4. Description 908 This metric assesses the response time, the interval from the query 909 transmission to the response. 911 6.2. Metric Definition 913 This category includes columns to prompt the entry of all necessary 914 details related to the metric definition, including the RFC reference 915 and values of input factors, called fixed parameters. 917 6.2.1. Reference Definition 919 921 Mockapetris, P., "Domain names - implementation and specification", 922 STD 13, RFC 1035, November 1987. (and updates) 924 [RFC1035] 926 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 927 Metric for IPPM", RFC 2681, September 1999. 929 [RFC2681] 931 933 Section 2.4 of [RFC2681] provides the reference definition of the 934 singleton (single value) Round-trip delay metric. Section 3.4 of 935 [RFC2681] provides the reference definition expanded to cover a 936 multi-value sample. Note that terms such as singleton and sample are 937 defined in Section 11 of [RFC2330]. 939 For DNS Response Latency, the entities in [RFC1035] must be mapped to 940 [RFC2681]. The Local Host with its User Program and Resolver take 941 the role of "Src", and the Foreign Name Server takes the role of 942 "Dst". 944 Note that although the definition of "Round-trip-Delay between Src 945 and Dst at T" is directionally ambiguous in the text, this metric 946 tightens the definition further to recognize that the host in the 947 "Src" role will send the first packet to "Dst", and ultimately 948 receive the corresponding return packet from "Dst" (when neither are 949 lost). 951 6.2.2. Fixed Parameters 953 957 Type-P: 959 o IPv4 header values: 961 * DSCP: set to 0 963 * TTL set to 255 965 * Protocol: Set to 17 (UDP) 967 o UDP header values: 969 * Source port: 53 971 * Destination port: 53 973 * Checksum: the checksum must be calculated 975 o Payload: The payload contains a DNS message as defined in RFC 1035 976 [RFC1035] with the following values: 978 * The DNS header section contains: 980 + QR: set to 0 (Query) 982 + OPCODE: set to 0 (standard query) 984 + AA: not set 986 + TC: not set 988 + RD: set to one (recursion desired) 990 + RA: not set 992 + RCODE: not set 994 + QDCOUNT: set to one (only one entry) 996 + ANCOUNT: not set 998 + NSCOUNT: not set 999 + ARCOUNT: not set 1001 * The Question section contains: 1003 + QNAME: the FQDN provided as input for the test 1005 + QTYPE: the query type provided as input for the test 1007 + QCLASS: set to IN 1009 * The other sections do not contain any Resource Records. 1011 Observation: reply packets will contain a DNS response and may 1012 contain RRs. 1014 Timeout: Tmax = 5 seconds (to help disambiguate queries) 1016 6.3. Method of Measurement 1018 This category includes columns for references to relevant sections of 1019 the RFC(s) and any supplemental information needed to ensure an 1020 unambiguous methods for implementations. 1022 6.3.1. Reference Method 1024 1027 The methodology for this metric is defined as Type-P-Round-trip- 1028 Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 1029 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under 1030 Fixed Parameters. 1032 The method requires sequence numbers or other send-order information 1033 to be retained at the Src or included with each packet to dis- 1034 ambiguate packet reordering if it occurs. Sequence number is part of 1035 the payload described under Fixed Parameters. 1037 DNS Messages bearing Queries provide for random ID Numbers, so more 1038 than one query may be launched while a previous request is 1039 outstanding when the ID Number is used. 1041 IF a DNS response does not arrive within Tmax, the result is 1042 undefined. The Message ID SHALL be used to disambiguate the 1043 successive queries. 1045 >>> This would require support of ID generation and population in the 1046 Message. An alternative would be to use a random Source port on the 1047 Query Message, but we would choose ONE before proceding. 1049 Refer to Section 4.4 of [RFC6673] for expanded discussion of the 1050 instruction to "send a Type-P packet back to the Src as quickly as 1051 possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of 1052 [RFC6673] presents additional requirements which shall be included in 1053 the method of measurement for this metric. 1055 6.3.2. Packet Generation Stream 1057 This section gives the details of the packet traffic which is the 1058 basis for measurement. In IPPM metrics, this is called the Stream, 1059 and can easily be dscribed by providing the list of stream 1060 parameters. 1062 1064 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to 1065 generate Poisson sampling intervals. the reciprocal of lambda is the 1066 average packet rate, thus the Run-time Parameter is 1/lambda. 1068 >>> Check with Sam, most likely it is this... 1070 Method 3 is used, where given a start time (Run-time Parameter), the 1071 subsequent send times are all computed prior to measurement by 1072 computing the pseudo-random distribution of inter-packet send times, 1073 (truncating the distribution as specified in the Run-time 1074 Parameters), and the Src sends each packet at the computed times. 1076 6.3.3. Traffic Filtering (observation) Details 1078 The measured results based on a filtered version of the packets 1079 observed, and this section provides the filter details (when 1080 present). 1082
. 1084 NA 1086 6.3.4. Sampling Distribution 1088 1091 NA 1093 6.3.5. Run-time Parameters and Data Format 1095 Run-time Parameters are input factors that must be determined, 1096 configured into the measurement system, and reported with the results 1097 for the context to be complete. 1099 1101 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 1102 value for IPv6) 1104 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 1105 value for IPv6) 1107 o T0, a time (start of measurement interval, 128-bit NTP Date 1108 Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a 1109 start time is unspecified and Tf is to be interpreted as the 1110 Duration of the measurement interval. 1112 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1113 see section 6 of [RFC5905]), interpreted as the Duration of the 1114 measurement interval. 1116 o 1/lambda, average packet rate (for Poisson Streams). (1/lambda = 1117 0.1 packet per second, if fixed) 1119 o Upper limit on Poisson distribution (values above this limit will 1120 be clipped and set to the limit value). (if fixed, Upper limit = 1121 300 seconds.) 1123 o ID, the 16-bit identifier assigned by the program that generates 1124 the query, and which must vary in successive queries, see 1125 Section 4.1.1 of [RFC1035]. This identifier is copied into the 1126 corresponding reply and can be used by the requester to match-up 1127 replies to outstanding queries. 1129 The format for 1/lambda and Upper limit of Poisson Dist. are the 1130 short format in [RFC5905] (32 bits) and is as follows: the first 16 1131 bits represent the integer number of seconds; the next 16 bits 1132 represent the fractional part of a second. 1134 >>> should Poisson run-time params be fixed instead? probably yes if 1135 modeling a specific version of MBA tests. 1137 6.3.6. Roles 1139 1141 Src - launches each packet and waits for return transmissions from 1142 Dst. 1144 Dst - waits for each packet from Src and sends a return packet to 1145 Src. 1147 6.4. Output 1149 This category specifies all details of the Output of measurements 1150 using the metric. 1152 6.4.1. Type/Value (two diff terms used) 1154 1156 For all output types: 1158 o T0, a time (start of measurement interval, 128-bit NTP Date 1159 Format, see section 6 of [RFC5905]) 1161 o Tf, a time (end of measurement interval, 128-bit NTP Date Format, 1162 see section 6 of [RFC5905]) 1164 Raw -- for each packet sent, pairs of values. 1166 >>> and the status of the response, only assigning values to 1167 successful query-response pairs. 1169 Percentile -- for the conditional distribution of all packets with a 1170 valid value of Round-trip delay (undefined delays are excluded), a 1171 single value corresponding to the 95th percentile. 1173 6.4.2. Data Format 1175 1177 Raw -- for each packet sent, pairs of values as follows: 1179 o T, the time when the packet was sent from Src, 128-bit NTP Date 1180 Format, see section 6 of [RFC5905]) 1182 o dT, a value of Round-trip delay, format is *similar to* the 32-bit 1183 short NTP Time format in Section 6 of [RFC5905] and is as follows: 1184 the first 16 bits represent the *signed* integer number of 1185 seconds; the next 16 bits represent the fractional part of a 1186 second. 1188 o dT is undefined when the packet is not received at Src in waiting 1189 time Tmxax seconds (need undefined code for no-response or un- 1190 successful response) 1192 Percentile -- for the conditional distribution of all packets with a 1193 valid value of Round-trip delay (undefined delays are excluded), a 1194 single value as follows: 1196 See section 4.1 of [RFC3393] for details on the conditional 1197 distribution to exclude undefined values of delay, and Section 5 of 1198 [RFC6703] for background on this analysis choice. 1200 See section 4.3 of [RFC3393] for details on the percentile statistic 1201 (where Round-trip delay should be substituted for "ipdv"). 1203 The percentile = 95. 1205 Data format is a 32-bit signed floating point value, *similar to* the 1206 32-bit short NTP Time format in Section 6 of [RFC5905] and is as 1207 follows: the first 16 bits represent the *signed* integer number of 1208 seconds; the next 16 bits represent the fractional part of a second. 1210 6.4.3. Reference 1212 1214 See the Data Format column for references. 1216 6.4.4. Metric Units 1218 . 1221 Round-trip Delay, dT, is expressed in seconds. 1223 The 95th Percentile of Round-trip Delay is expressed in seconds. 1225 6.5. Administrative items 1227 6.5.1. Status 1229 1231 6.5.2. Requestor (keep?) 1233 name or RFC, etc. 1235 6.5.3. Revision 1237 1.0 1239 6.5.4. Revision Date 1241 YYYY-MM-DD 1243 6.6. Comments and Remarks 1245 Additional (Informational) details for this entry 1247 7. partly BLANK Registry Entry 1249 This section gives an initial registry entry for .... 1251 7.1. Summary 1253 This category includes multiple indexes to the registry entries, the 1254 element ID and metric name. 1256 1258 7.1.1. ID (Identifier) 1260 1262 7.1.2. Name 1264 1266 URL: ?? 1268 7.1.3. URI 1270 URI: Prefix urn:ietf:params:performance:metric 1272 7.1.4. Description 1274 TBD. 1276 7.2. Metric Definition 1278 This category includes columns to prompt the entry of all necessary 1279 details related to the metric definition, including the RFC reference 1280 and values of input factors, called fixed parameters. 1282 7.2.1. Reference Definition 1284 1286 Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 1287 Metric for IPPM", RFC 2681, September 1999. 1289 1291 Section 2.4 of [RFC2681] provides the reference definition of the 1292 singleton (single value) Round-trip delay metric. Section 3.4 of 1293 [RFC2681] provides the reference definition expanded to cover a 1294 multi-value sample. Note that terms such as singleton and sample are 1295 defined in Section 11 of [RFC2330]. 1297 Note that although the definition of "Round-trip-Delay between Src 1298 and Dst at T" is directionally ambiguous in the text, this metric 1299 tightens the definition further to recognize that the host in the 1300 "Src" role will send the first packet to "Dst", and ultimately 1301 receive the corresponding return packet from "Dst" (when neither are 1302 lost). 1304 <<< Check how the Methodology also makes this clear (or not) >>> 1306 7.2.2. Fixed Parameters 1308 1312 Type-P: 1314 o IPv4 header values: 1316 * DSCP: set to 0 1318 * TTL set to 255 1320 * Protocol: Set to 17 (UDP) 1322 o UDP header values: 1324 * Checksum: the checksum must be calculated 1326 o Payload 1328 * Sequence number: 8-byte integer 1330 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 1331 as per section 6 of RFC 5905 [RFC5905] 1333 * No padding (total of 9 bytes) 1335 Timeout: 3 seconds 1337 7.3. Method of Measurement 1339 This category includes columns for references to relevant sections of 1340 the RFC(s) and any supplemental information needed to ensure an 1341 unambiguous methods for implementations. 1343 7.3.1. Reference Method 1345 1348 7.3.2. Packet Generation Stream 1350 This section gives the details of the packet traffic which is the 1351 basis for measurement. In IPPM metrics, this is called the Stream, 1352 and can easily be dscribed by providing the list of stream 1353 parameters. 1355 1357 7.3.3. Traffic Filtering (observation) Details 1359 The measured results based on a filtered version of the packets 1360 observed, and this section provides the filter details (when 1361 present). 1363
. 1365 7.3.4. Sampling Distribution 1367 1370 7.3.5. Run-time Parameters and Data Format 1372 Run-time Parameters are input factors that must be determined, 1373 configured into the measurement system, and reported with the results 1374 for the context to be complete. 1376 1378 . 1380 7.3.6. Roles 1382 1384 7.4. Output 1386 This category specifies all details of the Output of measurements 1387 using the metric. 1389 7.4.1. Type/Value (two diff terms used) 1391 1393 7.4.2. Data Format 1395 1397 o Value: 1399 o Data Format: (There may be some precedent to follow here, but 1400 otherwise use 64-bit NTP Timestamp Format, see section 6 of 1401 [RFC5905]). 1403 o Reference:
1405 7.4.3. Reference 1407 1409 7.4.4. Metric Units 1411 . 1414 7.5. Administrative items 1416 7.5.1. Status 1418 1420 7.5.2. Requestor (keep?) 1422 name or RFC, etc. 1424 7.5.3. Revision 1426 1.0 1428 7.5.4. Revision Date 1430 YYYY-MM-DD 1432 7.6. Comments and Remarks 1434 Additional (Informational) details for this entry 1436 8. BLANK Registry Entry 1438 This section gives an initial registry entry for .... 1440 8.1. Summary 1442 This category includes multiple indexes to the registry entries, the 1443 element ID and metric name. 1445 1447 8.1.1. ID (Identifier) 1449 1451 8.1.2. Name 1453 1455 URL: ?? 1457 8.1.3. URI 1459 URI: Prefix urn:ietf:params:performance:metric 1461 8.1.4. Description 1463 TBD. 1465 8.2. Metric Definition 1467 This category includes columns to prompt the entry of all necessary 1468 details related to the metric definition, including the RFC reference 1469 and values of input factors, called fixed parameters. 1471 8.2.1. Reference Definition 1473 1475 1477 8.2.2. Fixed Parameters 1479 1483 8.3. Method of Measurement 1485 This category includes columns for references to relevant sections of 1486 the RFC(s) and any supplemental information needed to ensure an 1487 unambiguous methods for implementations. 1489 8.3.1. Reference Method 1491 1494 8.3.2. Packet Generation Stream 1496 1498 8.3.3. Traffic Filtering (observation) Details 1500 . 1504 8.3.4. Sampling Distribution 1506 1509 8.3.5. Run-time Parameters and Data Format 1511 . 1513 8.3.6. Roles 1515 1517 8.4. Output 1519 This category specifies all details of the Output of measurements 1520 using the metric. 1522 8.4.1. Type/Value (two diff terms used) 1524 1526 8.4.2. Data Format 1528 1530 8.4.3. Reference 1532 1534 8.4.4. Metric Units 1536 . 1539 8.5. Administrative items 1541 8.5.1. Status 1543 1545 8.5.2. Requestor (keep?) 1547 1549 8.5.3. Revision 1551 1.0 1553 8.5.4. Revision Date 1555 YYYY-MM-DD 1557 8.6. Comments and Remarks 1559 Additional (Informational) details for this entry 1561 9. Example RTCP-XR Registry Entry 1563 This section is MAY BE DELETED or adapted before submission. 1565 This section gives an example registry entry for the end-point metric 1566 described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap Discard Metric 1567 reporting. 1569 9.1. Registry Indexes 1571 This category includes multiple indexes to the registry entries, the 1572 element ID and metric name. 1574 9.1.1. Identifier 1576 An integer having enough digits to uniquely identify each entry in 1577 the Registry. 1579 9.1.2. Name 1581 A metric naming convention is TBD. 1583 9.1.3. URI 1585 Prefix urn:ietf:params:performance:metric 1587 9.1.4. Status 1589 current 1591 9.1.5. Requestor 1593 Alcelip Mornuley 1595 9.1.6. Revision 1597 1.0 1599 9.1.7. Revision Date 1601 2014-07-04 1603 9.1.8. Description 1605 TBD. 1607 9.1.9. Reference Specification(s) 1609 [RFC3611][RFC4566][RFC6776][RFC6792][RFC7003] 1611 9.2. Metric Definition 1613 This category includes columns to prompt the entry of all necessary 1614 details related to the metric definition, including the RFC reference 1615 and values of input factors, called fixed parameters. Section 3.2 of 1616 [RFC7003] provides the reference information for this category. 1618 9.2.1. Reference Definition 1620 Packets Discarded in Bursts: 1622 The total number of packets discarded during discard bursts. The 1623 measured value is unsigned value. If the measured value exceeds 1624 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 1625 range measurement. If the measurement is unavailable, the value 1626 0xFFFFFF MUST be reported. 1628 9.2.2. Fixed Parameters 1630 Fixed Parameters are input factors that must be determined and 1631 embedded in the measurement system for use when needed. The values 1632 of these parameters is specified in the Registry. 1634 Threshold: 8 bits, set to value = 3 packets. 1636 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 1637 successive packets that must not be discarded prior to and following 1638 a discard packet in order for this discarded packet to be regarded as 1639 part of a gap. Note that the Threshold is set in accordance with the 1640 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 1642 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 1644 This field is used to indicate whether the burst/gap discard metrics 1645 are Sampled, Interval, or Cumulative metrics [RFC6792]: 1647 I=10: Interval Duration - the reported value applies to the most 1648 recent measurement interval duration between successive metrics 1649 reports. 1651 I=11: Cumulative Duration - the reported value applies to the 1652 accumulation period characteristic of cumulative measurements. 1654 Senders MUST NOT use the values I=00 or I=01. 1656 9.3. Method of Measurement 1658 This category includes columns for references to relevant sections of 1659 the RFC(s) and any supplemental information needed to ensure an 1660 unambiguous methods for implementations. For the Burst/Gap Discard 1661 Metric, it appears that the only guidance on methods of measurement 1662 is in Section 3.0 of [RFC7003] and its supporting references. 1663 Relevant information is repeated below, although there appears to be 1664 no section titled "Method of Measurement" in [RFC7003]. 1666 9.3.1. Reference Method 1668 Metrics in this block report on burst/gap discard in the stream 1669 arriving at the RTP system. Measurements of these metrics are made 1670 at the receiving end of the RTP stream. Instances of this metrics 1671 block use the synchronization source (SSRC) to refer to the separate 1672 auxiliary Measurement Information Block [RFC6776], which describes 1673 measurement periods in use (see [RFC6776], Section 4.2). 1675 This metrics block relies on the measurement period in the 1676 Measurement Information Block indicating the span of the report. 1677 Senders MUST send this block in the same compound RTCP packet as the 1678 Measurement Information Block. Receivers MUST verify that the 1679 measurement period is received in the same compound RTCP packet as 1680 this metrics block. If not, this metrics block MUST be discarded. 1682 9.3.2. Stream Type and Stream Parameters 1684 Since RTCP-XR Measurements are conducted on live RTP traffic, the 1685 complete description of the stream is contained in SDP messages that 1686 proceed the establishment of a compatible stream between two or more 1687 communicating hosts. See Run-time Parameters, below. 1689 9.3.3. Output Type and Data Format 1691 The output type defines the type of result that the metric produces. 1693 o Value: Packets Discarded in Bursts 1694 o Data Format: 24 bits 1696 o Reference: Section 3.2 of [RFC7003] 1698 9.3.4. Metric Units 1700 The measured results are apparently expressed in packets, although 1701 there is no section of [RFC7003] titled "Metric Units". 1703 9.3.5. Run-time Parameters and Data Format 1705 Run-Time Parameters are input factors that must be determined, 1706 configured into the measurement system, and reported with the results 1707 for the context to be complete. However, the values of these 1708 parameters is not specified in the Registry, rather these parameters 1709 are listed as an aid to the measurement system implementor or user 1710 (they must be left as variables, and supplied on execution). 1712 The Data Format of each Run-time Parameter SHALL be specified in this 1713 column, to simplify the control and implementation of measurement 1714 devices. 1716 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 1718 SDP Parameters: As defined in [RFC4566] 1720 Session description v= (protocol version number, currently only 0) 1722 o= (originator and session identifier : username, id, version number, 1723 network address) 1725 s= (session name : mandatory with at least one UTF-8-encoded 1726 character) 1728 i=* (session title or short information) u=* (URI of description) 1730 e=* (zero or more email address with optional name of contacts) 1732 p=* (zero or more phone number with optional name of contacts) 1734 c=* (connection information--not required if included in all media) 1736 b=* (zero or more bandwidth information lines) One or more Time 1737 descriptions ("t=" and "r=" lines; see below) 1739 z=* (time zone adjustments) 1741 k=* (encryption key) 1742 a=* (zero or more session attribute lines) 1744 Zero or more Media descriptions (each one starting by an "m=" line; 1745 see below) 1747 m= (media name and transport address) 1749 i=* (media title or information field) 1751 c=* (connection information -- optional if included at session level) 1753 b=* (zero or more bandwidth information lines) 1755 k=* (encryption key) 1757 a=* (zero or more media attribute lines -- overriding the Session 1758 attribute lines) 1760 An example Run-time SDP description follows: 1762 v=0 1764 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 1766 s=SDP Seminar i=A Seminar on the session description protocol 1768 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 1769 Doe) 1771 c=IN IP4 233.252.0.12/127 1773 t=2873397496 2873404696 1775 a=recvonly 1777 m=audio 49170 RTP/AVP 0 1779 m=video 51372 RTP/AVP 99 1781 a=rtpmap:99 h263-1998/90000 1783 9.4. Comments and Remarks 1785 TBD. 1787 10. Security Considerations 1789 These registry entries represent no known security implications for 1790 Internet Security. Each referenced Metric contains a Security 1791 Considerations section. 1793 11. IANA Considerations 1795 IANA is requested to create The Active Performance Metric Sub- 1796 registry within the Performance Metric Registry defined in 1797 [I-D.ietf-ippm-metric-registry]. The Sub-registry will contain the 1798 following categories and (bullet) columns, (as defined in section 3 1799 above): 1801 Common Registry Indexes and Info 1803 o Identifier 1805 o Name 1807 o Status 1809 o Requester 1811 o Revision 1813 o Revision Date 1815 o Description 1817 o Reference Specification(s) 1819 Metric Definition 1821 o Reference Definition 1823 o Fixed Parameters 1825 Method of Measurement 1827 o Reference Method 1829 o Stream Type and Parameters 1831 o Output type and Data format 1833 o Metric Units 1834 o Run-time Parameters 1836 Comments and Remarks 1838 12. Acknowledgements 1840 The authors thank Brian Trammell for suggesting the term "Run-time 1841 Parameters", which led to the distinction between run-time and fixed 1842 parameters implemented in this memo, for raising the IPFIX metric 1843 with Flow Key as an example, and for many other productive 1844 suggestions.Thanks to Peter Koch, who provided several useful 1845 suggestions for disambiguating successive DNS Queries in the DNS 1846 Response time metric. 1848 13. References 1850 13.1. Normative References 1852 [I-D.ietf-ippm-metric-registry] 1853 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 1854 "Registry for Performance Metrics", Internet Draft (work 1855 in progress) draft-ietf-ippm-metric-registry, 2014. 1857 [RFC1035] Mockapetris, P., "Domain names - implementation and 1858 specification", STD 13, RFC 1035, November 1987. 1860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1861 Requirement Levels", BCP 14, RFC 2119, March 1997. 1863 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1864 "Framework for IP Performance Metrics", RFC 2330, May 1865 1998. 1867 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1868 Delay Metric for IPPM", RFC 2679, September 1999. 1870 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1871 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1873 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1874 Delay Metric for IPPM", RFC 2681, September 1999. 1876 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1877 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1878 November 2002. 1880 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1881 performance measurement with periodic streams", RFC 3432, 1882 November 2002. 1884 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1885 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 1886 November 2006. 1888 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1889 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1890 RFC 5357, October 2008. 1892 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1893 Time Protocol Version 4: Protocol and Algorithms 1894 Specification", RFC 5905, June 2010. 1896 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 1897 August 2012. 1899 13.2. Informative References 1901 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 1902 Distributions", March 2000. 1904 [I-D.ietf-lmap-framework] 1905 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1906 Aitken, P., and A. Akhter, "A framework for large-scale 1907 measurement platforms (LMAP)", draft-ietf-lmap- 1908 framework-08 (work in progress), August 2014. 1910 [RFC1242] Bradner, S., "Benchmarking terminology for network 1911 interconnection devices", RFC 1242, July 1991. 1913 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1914 Protocol Extended Reports (RTCP XR)", RFC 3611, November 1915 2003. 1917 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1918 Registry", BCP 108, RFC 4148, August 2005. 1920 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1921 Description Protocol", RFC 4566, July 2006. 1923 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1924 Flow Information Export (IPFIX) Applicability", RFC 5472, 1925 March 2009. 1927 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1928 Carle, "Information Model for Packet Sampling Exports", 1929 RFC 5477, March 2009. 1931 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1932 Applicability Statement", RFC 5481, March 2009. 1934 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 1935 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 1936 2011. 1938 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1939 Performance Metric Development", BCP 170, RFC 6390, 1940 October 2011. 1942 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 1943 IP Network Performance Metrics: Different Points of View", 1944 RFC 6703, August 2012. 1946 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 1947 Reporting Using a Source Description (SDES) Item and an 1948 RTCP Extended Report (XR) Block", RFC 6776, October 2012. 1950 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 1951 RTP Monitoring Framework", RFC 6792, November 2012. 1953 [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol 1954 (RTCP) Extended Report (XR) Block for Burst/Gap Discard 1955 Metric Reporting", RFC 7003, September 2013. 1957 Authors' Addresses 1959 Al Morton 1960 AT&T Labs 1961 200 Laurel Avenue South 1962 Middletown,, NJ 07748 1963 USA 1965 Phone: +1 732 420 1571 1966 Fax: +1 732 368 1192 1967 Email: acmorton@att.com 1968 URI: http://home.comcast.net/~acmacm/ 1969 Marcelo Bagnulo 1970 Universidad Carlos III de Madrid 1971 Av. Universidad 30 1972 Leganes, Madrid 28911 1973 SPAIN 1975 Phone: 34 91 6249500 1976 Email: marcelo@it.uc3m.es 1977 URI: http://www.it.uc3m.es 1979 Philip Eardley 1980 BT 1981 Adastral Park, Martlesham Heath 1982 Ipswich 1983 ENGLAND 1985 Email: philip.eardley@bt.com