idnits 2.17.00 (12 Aug 2021) /tmp/idnits50466/draft-morton-ippm-mbm-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 416 has weird spacing: '... Src the IP...' == Line 420 has weird spacing: '... Dst the IP...' == Line 550 has weird spacing: '...s_Ratio the r...' -- The document date (March 13, 2017) is 1888 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: 'RFC1035' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC3432' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'RFC6673' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'Brow00' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'RFC1242' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'RFC3611' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC6776' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'RFC6792' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'RFC7003' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC7594' is defined on line 940, but no explicit reference was found in the text == Outdated reference: draft-ietf-ippm-metric-registry has been published as RFC 8911 == Outdated reference: draft-ietf-ippm-model-based-metrics has been published as RFC 8337 ** Downref: Normative reference to an Experimental draft: draft-ietf-ippm-model-based-metrics (ref. 'I-D.ietf-ippm-model-based-metrics') ** 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: 4 errors (**), 0 flaws (~~), 27 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track M. Mathis 5 Expires: September 14, 2017 Google 6 March 13, 2017 8 Initial Performance Metric Registry Entries Part 2: MBM 9 draft-morton-ippm-mbm-registry-01 11 Abstract 13 This memo defines a Registry Entry for the Performance Metrics 14 Registry based on Model Based Metrics. This entry will be combined 15 with the "initial-registry" draft after review. 17 The string "@@@@" identifies some areas for further discussion to 18 finalize the text. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. MBM Registry Entry . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1.4. Description . . . . . . . . . . . . . . . . . . . . . 4 68 3.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.6. Change Controller . . . . . . . . . . . . . . . . . . 5 70 3.1.7. Version (of Registry Format) . . . . . . . . . . . . 5 71 3.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 5 72 3.2.1. Reference Definition . . . . . . . . . . . . . . . . 5 73 3.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 6 74 3.3. Method of Measurement . . . . . . . . . . . . . . . . . . 7 75 3.3.1. Reference Method . . . . . . . . . . . . . . . . . . 7 76 3.3.2. Packet Stream Generation . . . . . . . . . . . . . . 8 77 3.3.3. Traffic Filtering (observation) Details . . . . . . . 9 78 3.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 9 79 3.3.5. Run-time Parameters and Data Format . . . . . . . . . 9 80 3.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 12 83 3.4.2. Reference Definition . . . . . . . . . . . . . . . . 12 84 3.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 13 85 3.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 13 86 3.5. Administrative items . . . . . . . . . . . . . . . . . . 13 87 3.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 13 89 3.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 13 90 3.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 14 91 3.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 14 92 4. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 14 93 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 14 95 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 14 96 4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 14 97 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 14 98 4.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 14 99 4.1.6. Change Controller . . . . . . . . . . . . . . . . . . 14 100 4.1.7. Version (of Registry Format) . . . . . . . . . . . . 14 101 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 15 102 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 15 103 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 15 104 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 15 105 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 15 106 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 15 107 4.3.3. Traffic Filtering (observation) Details . . . . . . . 15 108 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 15 109 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 16 110 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 16 111 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 16 112 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 16 113 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 16 114 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 16 115 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 16 116 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 117 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 118 4.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 16 119 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 120 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 17 121 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 17 122 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 123 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 124 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 125 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 126 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 127 8.2. Informative References . . . . . . . . . . . . . . . . . 19 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 130 1. Introduction 132 Note: Efforts to synchronize structure and terminology with 133 [I-D.ietf-ippm-metric-registry] will likely be incomplete until both 134 drafts are stable. 136 This memo proposes a (set of) entry(ies) for the Performance Metric 137 Registry, based on Model-Based Metrics (MBM). It uses terms and 138 definitions from the IPPM literature, primarily [RFC2330]. 140 2. Scope 142 This document defines one of the initial set of Performance Metrics 143 Registry entries, for which IETF approval (following development in 144 the IP Performance Metrics (IPPM) Working Group) will satisfy the 145 requirement for Expert Review. Note that all are Active Performance 146 Metrics, which are based on RFCs prepared in the IPPM working group 147 of the IETF, according to their framework [RFC2330] and its updates. 149 3. MBM Registry Entry 151 This section gives an initial registry entry for a Model-Based Metric 152 (MBM) Sustained Burst Metric. 154 3.1. Summary 156 This category includes multiple indexes to the registry entries, the 157 element ID and metric name. 159 3.1.1. ID (Identifier) 161 163 3.1.2. Name 165 167 OWMBM_Active_IP-TCP-SustainedBurst_RFCXXXXsecY_Enumerated_PFI 169 3.1.3. URIs 171 URI: Prefix urn:ietf:metrics:perf: 173 URL: http:\\www.iana.org\ ... 175 3.1.4. Description 177 TBD. 179 3.1.5. Reference 181 183 RFCXXXXsecY 185 3.1.6. Change Controller 187 189 IETF 191 3.1.7. Version (of Registry Format) 193 195 1.0 197 3.2. Metric Definition 199 This category includes columns to prompt the entry of all necessary 200 details related to the metric definition, including the RFC reference 201 and values of input factors, called fixed parameters. 203 3.2.1. Reference Definition 205 207 209 Mathis, M. and A. Morton, "Model Based Metrics for Bulk Transport 210 Capacity", draft-ietf-ippm-model-based- metrics-10 (work in 211 progress), February 2017. 213 The primary metrics of measurement are round-trip delay and one-way 214 loss, measured under the conditions described in Section 8.5.1 of 215 [I-D.ietf-ippm-model-based-metrics]. 217 For loss: 219 Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- 220 Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 221 10.17487/RFC7680, January 2016, . 224 Section 2.4 of [RFC7680] provides the reference definition of the 225 singleton (single value) one-way loss metric. Section 3.4 of 226 [RFC7680] provides the reference definition expanded to cover a 227 multi-singleton sample. Note that terms such as singleton and sample 228 are defined in Section 11 of [RFC2330]. 230 For round-trip delay: 232 Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss 233 Metric for IPPM", RFC 2680, September 1999. 235 [RFC2681] 237 Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- 238 Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 239 7679, DOI 10.17487/RFC7679, January 2016, . 242 [RFC7679] 244 246 Section 2.4 of [RFC2681] provides the reference definition of the 247 singleton (single value) Round-trip delay metric. Section 3.4 of 248 [RFC2681] provides the reference definition expanded to cover a 249 multi-singleton sample. Note that terms such as singleton and sample 250 are defined in Section 11 of [RFC2330]. 252 Note that although the definition of "Round-trip-Delay between Src 253 and Dst" is directionally ambiguous in the text, this metric tightens 254 the definition further to recognize that the host in the "Src" role 255 will send the first packet to "Dst", and ultimately receive the 256 corresponding return packet from "Dst" (when neither are lost). 258 Finally, note that the variable "dT" is used in [RFC2681] to refer to 259 the value of Round-trip delay in metric definitions and methods. The 260 variable "dT" has been re-used in other IPPM literature to refer to 261 different quantities, and cannot be used as a global variable name 262 here. 264 3.2.2. Fixed Parameters 266 270 Type-P as defined in Section 13 of [RFC2330]: 272 o IPv4 header values: 274 * DSCP: set to 0 276 * TTL: set to 255 278 * Protocol: Set to 6 (TCP) 280 o IPv6 header values: 282 * DSCP: set to 0 284 * Hop Count: set to 255 286 * Protocol: Set to 6 (TCP) 288 o TCP header values: 290 * Checksum: the checksum MUST be calculated and included in the 291 header 293 o TCP Payload 295 * see target_MTU in Run-time parameters. 297 Other measurement parameters: 299 o Tmax: a loss threshold waiting time @@@@ Should this be linked to 300 TCP RTO, or target_RTT plus a factor ??? 302 * 3.0, expressed in units of seconds, as a positive value of type 303 decimal64 with fraction digits = 4 (see section 9.3 of 304 [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with 305 lossless conversion to/from the 32-bit NTP timestamp as per 306 section 6 of [RFC5905]. 308 3.3. Method of Measurement 310 This category includes columns for references to relevant sections of 311 the RFC(s) and any supplemental information needed to ensure an 312 unambiguous methods for implementations. 314 3.3.1. Reference Method 316 319 The method of measurement is described in Section 8.5.1 of 320 [I-D.ietf-ippm-model-based-metrics]. 322 The example described in Section 9 of 323 [I-D.ietf-ippm-model-based-metrics] may also help. 325 @@@@ 327 3.3.2. Packet Stream Generation 329 331 The stream generation parameters are described in Section 3 of 332 [I-D.ietf-ippm-model-based-metrics]. They are dependent on the 333 target parameters described in the Run-time parameters section below. 334 They are written here with underscores because they are used in 335 formulas in this note. 337 @@@@ I strongly suggest decimal64 fraction digits = 9 or 12 (i.e 338 nanoseconds or picoseconds). I point out that the average headway 339 for min sized packets on 100Gb/s is already down to 5.1 uS. In 340 either case for decimal64 the max headway is way longer than ever 341 needed (decades or months). --MM-- (@@@@ BTW I think your fraction 342 digits are off --MM--). 344 @@@@ This section has a general problem that it need to better 345 prescribe generic concepts (headway, sizes, rates) and then define 346 multiple distinct parameters needed to properly specify each pattern. 348 packet_headway Time interval between packets, specified from the 349 start of one to the start of the next, as a positive value of type 350 decimal64 with fraction digits = 9 seconds, for a resolution of 1 351 nanosecond. (see section 9.3 of [RFC6020]). @@@@ We need a 352 convention for "back to back" independent of clock accuracy.--MM-- 354 burst_headway Time interval between bursts, specified from the start 355 of the first packet one burst to the start of the first packet of 356 the next burst, specified as a positive value of type decimal64 357 with fraction digits = 9 seconds, for a resolution of 1 358 nanosecond. (see section 9.3 of [RFC6020]). 360 paced_single_packets Send individual packets at the specified packet 361 headway, specified as a positive value of type decimal64 with 362 fraction digits = 9 seconds, for a resolution of 1 nanosecond. 363 (see section 9.3 of [RFC6020]). @@@@ NB: I dropped rate.--MM-- 365 paced_bursts Send bursts on a timer. Specify any 3 of: average data 366 rate, packet size, burst size (number of packets) and burst 367 headway (burst start to start), specified as a positive value of 368 type decimal64 with fraction digits = 9 seconds, for a resolution 369 of 1 nanosecond. (see section 9.3 of [RFC6020]). 371 slowstart_rate The average data rate necessary to mimic TCP 372 slowstart by sending 4 packet paced bursts to mimic a two level 373 burst pattern as described in Section 6.1 of 374 [I-D.ietf-ippm-model-based-metrics]. This rate should be chosen 375 to be twice the implied bottleneck IP capacity (but not more than 376 the sender interface rate). The slowstart_rate is specified as a 377 value of type uint32 (see section 9.2 of [RFC6020]) in units of 378 IP-layer bytes per second. 380 slowstart_burst Mimic one round of TCP slowstart by sending a 381 specified number of packets in a two level burst pattern that 382 resembles slowstart, specified as a number of type uint16 (see 383 section 9.2 of [RFC6020]) in units of packets, and a rate 384 specified as a value of type uint16 (see section 9.2 of [RFC6020]) 385 in units of packets per second. 387 repeated_slowstart_burst Repeat Slowstart bursts once per 388 target_RTT. All Slowstart bursts are the same size in 389 measurements (different from normal TCP sending behavior), 390 specified as a value of type boolean (see section 9.5 of 391 [RFC6020]). @@@@@ I would change this to [slowestart] burst 392 headway, nominally an interval mimicking the RTT and long enough 393 to permit all of the queues to drain between slowstart bursts. 395 3.3.3. Traffic Filtering (observation) Details 397 . 401 NA 403 3.3.4. Sampling Distribution 405 408 NA 410 3.3.5. Run-time Parameters and Data Format 412 . 414 The following parameters are described in [RFC2330] 416 Src the IP address of the host in the Src Role (format ipv4-address- 417 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 418 see Section 4 of [RFC6991]) 420 Dst the IP address of the host in the Dst Role (format ipv4-address- 421 no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, 422 see section 4 of [RFC6991]) 424 T0 a time, the start of a measurement interval, (format "date-and- 425 time" as specified in Section 5.6 of [RFC3339], see also Section 3 426 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of 427 [RFC2330]. When T0 is "all-zeros", a start time is unspecified 428 and Tf is to be interpreted as the Duration of the measurement 429 interval. The start time is controlled through other means. 431 Tf a time, the end of a measurement interval, (format "date-and-time" 432 as specified in Section 5.6 of [RFC3339], see also Section 3 of 433 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 434 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and 435 Tf is interpreted as the Duration of the measurement interval. 437 The following MBM-specific parameters are as defined in Section 3 of 438 [I-D.ietf-ippm-model-based-metrics], and subsequent sections of the 439 memo. 441 target_data_rate The specified application data rate required for an 442 application's proper operation, specified as a value of type 443 uint32 (see section 9.2 of [RFC6020]) in units of IP-layer bytes 444 per second. 446 target_RTT The specified baseline (minimum) RTT of the longest 447 complete path over which the user expects to be able meet the 448 target performance, specified as a positive value of type 449 decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) 450 with resolution of 0.0001 seconds (0.1 ms). 452 target_MTU The specified maximum MTU supported by the complete path 453 the over which the application expects to meet the target 454 performancespecified as a value of type uint16 (see section 9.2 of 455 [RFC6020]) in units of IP-layer bytes. 457 target_window_size The average number of packets in flight (the 458 window size) needed to meet the Target Data Rate, for the 459 specified Target RTT, and MTU, specified as a value of type uint32 460 (see section 9.2 of [RFC6020]) in units of @@@@ packets @@@@ or 461 IP-layer bytes @@@@@. It implies the scale of the bursts that the 462 network might experience. 464 subpath_??? @@@@@ Do we need a subpath-specific parameter? Such as 465 subpath_RTT ??? 467 derating The modeling framework permits some latitude in relaxing or 468 "derating" some test parameters as described in Section 5.3 of 469 [I-D.ietf-ippm-model-based-metrics], in exchange for a more 470 stringent TIDS validation procedures as described in Section 10 of 471 [I-D.ietf-ippm-model-based-metrics]. The use of derated 472 parameters is specified as a value of type boolean (see section 473 9.5 of [RFC6020]). 475 test_window The smallest window sufficient to meet or exceed the 476 target_rate when operating with a pure self-clock over a test 477 path, specified as a value of type uint32 (see section 9.2 of 478 [RFC6020]) in units of @@@@ packets @@@@ or IP-layer bytes @@@@@. 480 The following MBM-specific parameters are as defined in Section of 481 7.2 [I-D.ietf-ippm-model-based-metrics]: 483 H0H1_ratio The value of the multiplier on the Null Hypothesis loss 484 ratio used to calculate the Alternate Hypothesis loss ratio, 485 specified as a value of type uint8 (see section 9.2 of [RFC6020]) 486 and unit-less. 488 alpha_TI_err Measurements support accepting H0 with the specified 489 Type I error = alpha (= 0.05 for example), specified as a positive 490 value of type decimal64 with fraction digits = 4 (see section 9.3 491 of [RFC6020]) with resolution of 0.0001. 493 beta_TII_err Measurements support accepting H1 with the specified 494 Type II error = beta (= 0.05 for example), specified as a positive 495 value of type decimal64 with fraction digits = 4 (see section 9.3 496 of [RFC6020]) with resolution of 0.0001. 498 Additional MBM-specific parameters may be calculated by the 499 measurement system itself, or they may be supplied as additional Run- 500 time parameters: @@@@ Candidates ???? 502 3.3.6. Roles 504 506 data_sender Host sending data and receiving ACKs. 508 data_receiver Host receiving data and sending ACKs. 510 as described in Section 3 of [I-D.ietf-ippm-model-based-metrics]. 512 3.4. Output 514 This category specifies all details of the Output of measurements 515 using the metric. 517 3.4.1. Type 519 521 The primary output type is PFI, or Pass, Fail, Inconclusive, 522 referring to the conclusion of the test. 524 Two secondary output types MAY be reported to support the primary 525 output. 527 Loss Ratio: Singleton 529 Mean Round-trip Time: Singleton 531 3.4.2. Reference Definition 533 535 T0 the start of a measurement interval, (format "date-and-time" as 536 specified in Section 5.6 of [RFC3339], see also Section 3 of 537 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 538 [RFC2330]. 540 Tf the end of a measurement interval, (format "date-and-time" as 541 specified in Section 5.6 of [RFC3339], see also Section 3 of 542 [RFC6991]). The UTC Time Zone is required by Section 6.1 of 543 [RFC2330]. 545 PFI the summarized result of the measurement representing the 546 conclusion of whether or not the target values have been achieved, 547 (format enum as specified in section 9.6 of [RFC6020]) with one of 548 the following enumerations: Pass, Fail, Inconclusive. 550 Loss_Ratio the result of lost (or ECN marked) packet measurement 551 from data_sender to data_receiver, expressed as the ratio of lost 552 packets to total packets sent from the data sender (units). See 553 section 4 of [RFC7680] for details on this calculation. 555 Mean_RTT Mean Round-trip Time: The mean SHALL be calculated using 556 the conditional distribution of all packets with a finite value of 557 round-trip delay (undefined delays are excluded), a single value 558 as follows: 560 * See section 4.1 of [RFC3393] for details on the conditional 561 distribution to exclude undefined values of delay, and 562 Section 5 of [RFC6703] for background on this analysis choice. 564 * See section 4.2.2 of [RFC6049] for details on calculating this 565 statistic, and 4.2.3 of [RFC6049]. 567 * The time value of the result is expressed in units of seconds, 568 as a positive value of type decimal64 with fraction digits = 9 569 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 570 seconds (1.0 ns), and with lossless conversion to/from the 571 64-bit NTP timestamp as per section 6 of RFC [RFC5905]. 573 3.4.3. Metric Units 575 . 578 PFI: Enumerated{Pass, Fail, Inconclusive} 580 Loss Ratio: RatioPercent 582 Mean Round-trip Time: Seconds 584 3.4.4. Calibration 586 590 3.5. Administrative items 592 3.5.1. Status 594 596 3.5.2. Requestor 598 600 3.5.3. Revision 602 1.0 604 3.5.4. Revision Date 606 YYYY-MM-DD 608 3.6. Comments and Remarks 610 Additional (Informational) details for this entry 612 4. ver08 BLANK Registry Entry 614 This section gives an initial registry entry for .... 616 4.1. Summary 618 This category includes multiple indexes to the registry entries, the 619 element ID and metric name. 621 4.1.1. ID (Identifier) 623 625 4.1.2. Name 627 629 4.1.3. URIs 631 URI: Prefix urn:ietf:params:performance:metric 633 URL: 635 4.1.4. Description 637 TBD. 639 4.1.5. Reference 641 643 4.1.6. Change Controller 645 647 4.1.7. Version (of Registry Format) 649 651 4.2. Metric Definition 653 This category includes columns to prompt the entry of all necessary 654 details related to the metric definition, including the RFC reference 655 and values of input factors, called fixed parameters. 657 4.2.1. Reference Definition 659 661 663 4.2.2. Fixed Parameters 665 669 4.3. Method of Measurement 671 This category includes columns for references to relevant sections of 672 the RFC(s) and any supplemental information needed to ensure an 673 unambiguous methods for implementations. 675 4.3.1. Reference Method 677 680 4.3.2. Packet Stream Generation 682 684 4.3.3. Traffic Filtering (observation) Details 686 . 690 4.3.4. Sampling Distribution 692 695 4.3.5. Run-time Parameters and Data Format 697 . 699 4.3.6. Roles 701 703 4.4. Output 705 This category specifies all details of the Output of measurements 706 using the metric. 708 4.4.1. Type 710 712 4.4.2. Reference Definition 714 716 4.4.3. Metric Units 718 . 721 4.4.4. Calibration 723 727 4.5. Administrative items 729 4.5.1. Status 731 733 4.5.2. Requestor 735 737 4.5.3. Revision 739 1.0 741 4.5.4. Revision Date 743 YYYY-MM-DD 745 4.6. Comments and Remarks 747 Additional (Informational) details for this entry 749 5. Security Considerations 751 These registry entries represent no known security implications for 752 Internet Security. Each referenced Metric contains a Security 753 Considerations section. 755 6. IANA Considerations 757 IANA is requested to populate The Performance Metric Registry defined 758 in [I-D.ietf-ippm-metric-registry] with the values defined above. 760 762 7. Acknowledgements 764 The authors thank Brian Trammell for suggesting the term "Run-time 765 Parameters", which led to the distinction between run-time and fixed 766 parameters implemented in this memo, for identifying the IPFIX metric 767 with Flow Key as an example, and for many other productive 768 suggestions. Thanks to Peter Koch, who provided several useful 769 suggestions for disambiguating successive DNS Queries in the DNS 770 Response time metric. 772 The authors also acknowledge the constructive reviews and helpful 773 suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and 774 participants in the LMAP working group. 776 8. References 778 8.1. Normative References 780 [I-D.ietf-ippm-metric-registry] 781 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 782 "Registry for Performance Metrics", Internet Draft (work 783 in progress) draft-ietf-ippm-metric-registry, 2014. 785 [I-D.ietf-ippm-model-based-metrics] 786 Mathis, M. and A. Morton, "Model Based Metrics for Bulk 787 Transport Capacity", draft-ietf-ippm-model-based- 788 metrics-10 (work in progress), February 2017. 790 [RFC1035] Mockapetris, P., "Domain names - implementation and 791 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 792 November 1987, . 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, 796 DOI 10.17487/RFC2119, March 1997, 797 . 799 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 800 "Framework for IP Performance Metrics", RFC 2330, 801 DOI 10.17487/RFC2330, May 1998, 802 . 804 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 805 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 806 September 1999, . 808 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 809 Packet Loss Metric for IPPM", RFC 2680, 810 DOI 10.17487/RFC2680, September 1999, 811 . 813 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 814 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 815 September 1999, . 817 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 818 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 819 . 821 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 822 Metric for IP Performance Metrics (IPPM)", RFC 3393, 823 DOI 10.17487/RFC3393, November 2002, 824 . 826 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 827 performance measurement with periodic streams", RFC 3432, 828 DOI 10.17487/RFC3432, November 2002, 829 . 831 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 832 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 833 DOI 10.17487/RFC4737, November 2006, 834 . 836 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 837 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 838 RFC 5357, DOI 10.17487/RFC5357, October 2008, 839 . 841 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 842 "Network Time Protocol Version 4: Protocol and Algorithms 843 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 844 . 846 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 847 the Network Configuration Protocol (NETCONF)", RFC 6020, 848 DOI 10.17487/RFC6020, October 2010, 849 . 851 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 852 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 853 . 855 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 856 DOI 10.17487/RFC6673, August 2012, 857 . 859 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 860 RFC 6991, DOI 10.17487/RFC6991, July 2013, 861 . 863 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 864 Ed., "A One-Way Delay Metric for IP Performance Metrics 865 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 866 2016, . 868 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 869 Ed., "A One-Way Loss Metric for IP Performance Metrics 870 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 871 2016, . 873 8.2. Informative References 875 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 876 Distributions", March 2000. 878 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 879 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 880 July 1991, . 882 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 883 "RTP Control Protocol Extended Reports (RTCP XR)", 884 RFC 3611, DOI 10.17487/RFC3611, November 2003, 885 . 887 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 888 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 889 2005, . 891 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 892 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 893 July 2006, . 895 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 896 Flow Information Export (IPFIX) Applicability", RFC 5472, 897 DOI 10.17487/RFC5472, March 2009, 898 . 900 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 901 Carle, "Information Model for Packet Sampling Exports", 902 RFC 5477, DOI 10.17487/RFC5477, March 2009, 903 . 905 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 906 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 907 March 2009, . 909 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 910 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 911 DOI 10.17487/RFC6248, April 2011, 912 . 914 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 915 Performance Metric Development", BCP 170, RFC 6390, 916 DOI 10.17487/RFC6390, October 2011, 917 . 919 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 920 IP Network Performance Metrics: Different Points of View", 921 RFC 6703, DOI 10.17487/RFC6703, August 2012, 922 . 924 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 925 Reporting Using a Source Description (SDES) Item and an 926 RTCP Extended Report (XR) Block", RFC 6776, 927 DOI 10.17487/RFC6776, October 2012, 928 . 930 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 931 of the RTP Monitoring Framework", RFC 6792, 932 DOI 10.17487/RFC6792, November 2012, 933 . 935 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 936 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 937 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 938 September 2013, . 940 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 941 Aitken, P., and A. Akhter, "A Framework for Large-Scale 942 Measurement of Broadband Performance (LMAP)", RFC 7594, 943 DOI 10.17487/RFC7594, September 2015, 944 . 946 Authors' Addresses 948 Al Morton 949 AT&T Labs 950 200 Laurel Avenue South 951 Middletown,, NJ 07748 952 USA 954 Phone: +1 732 420 1571 955 Fax: +1 732 368 1192 956 Email: acmorton@att.com 957 URI: http://home.comcast.net/~acmacm/ 959 Matt Mathis 960 Google 962 Email: mattmathis@google.com