idnits 2.17.1 draft-mornulo-ippm-registry-columns-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3833 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) == Missing Reference: 'RFC3611' is mentioned on line 598, but not defined == Missing Reference: 'RFC6792' is mentioned on line 526, but not defined == Missing Reference: 'RFC6776' is mentioned on line 559, but not defined == Missing Reference: 'RFC4566' is mentioned on line 600, but not defined ** Obsolete undefined reference: RFC 4566 (Obsoleted by RFC 8866) == Unused Reference: 'RFC2680' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 986, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track A. Morton 5 Expires: April 24, 2014 AT&T Labs 6 P. Eardley 7 BT 8 October 21, 2013 10 A(nother) Registry for Performance Metrics 11 draft-mornulo-ippm-registry-columns-01 13 Abstract 15 This memo investigates a scheme to organize registry entries, 16 especially those defined in RFCs prepared in the IP Performance 17 Metrics (IPPM) Working Group of the IETF, and applicable to all IETF 18 metrics. Three aspects make IPPM metric registration difficult: (1) 19 Use of the Type-P notion to allow users to specify their own packet 20 types. (2) Use of flexible input variables, called Parameters in IPPM 21 definitions, some which determine the quantity measured and others 22 which should not be specified until execution of the measurement. (3) 23 Allowing flexibility in choice of statistics to summarize the results 24 on a stream of measurement packets. Specifically, this memo proposes 25 a way to organize registry entries into columns that are well- 26 defined, permiting consistent development of entries over time. 27 Also, this fosters development of registry entries based on existing 28 reference RFCs for performance metrics, and requires expert review 29 for every entry before IANA action. 31 This version contains an example registry entry for a passive 32 endpoint metric based on RFC7003, an example active metric entry 33 based on RFC3393 and RFC5481, and an example pure passive metric 34 based on RFC5472. Also, this version *continues* to allow blank 35 entries in columns which have no applicability to a specific metric, 36 or class of metrics. This is preferred to more general registry 37 organization because each column serves as a check-list item and 38 helps to avoid omissions during registration and expert review. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on April 24, 2014. 62 Copyright Notice 64 Copyright (c) 2013 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 1.1. Background and Motivation . . . . . . . . . . . . . . . . 5 81 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 83 3.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . . 8 84 3.1.1. Element ID . . . . . . . . . . . . . . . . . . . . . . 8 85 3.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 8 86 3.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 87 3.2.1. Reference Definition . . . . . . . . . . . . . . . . . 9 88 3.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . . 9 89 3.2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 9 90 3.3. Method of Measurement . . . . . . . . . . . . . . . . . . 10 91 3.3.1. Reference Method . . . . . . . . . . . . . . . . . . . 10 92 3.3.2. Stream Type and Stream Parameters . . . . . . . . . . 10 93 3.3.3. Output Type and Data Format . . . . . . . . . . . . . 10 94 3.3.4. Run-time Parameters and Data Format . . . . . . . . . 11 95 3.4. Comments and Remarks . . . . . . . . . . . . . . . . . . . 11 96 4. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . . 12 97 4.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . . 12 98 4.1.1. Element ID . . . . . . . . . . . . . . . . . . . . . . 12 99 4.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 12 100 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 12 101 4.2.1. Reference Definition . . . . . . . . . . . . . . . . . 12 102 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . . 12 103 4.2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 13 104 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 13 105 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . . 13 106 4.3.2. Stream Type and Stream Parameters . . . . . . . . . . 14 107 4.3.3. Output Type and Data Format . . . . . . . . . . . . . 14 108 4.3.4. Run-time Parameters and Data Format . . . . . . . . . 14 109 4.4. Comments and Remarks . . . . . . . . . . . . . . . . . . . 16 110 5. Example IPPM Active Registry Entry . . . . . . . . . . . . . . 16 111 5.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . . 16 112 5.1.1. Element ID . . . . . . . . . . . . . . . . . . . . . . 16 113 5.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 16 114 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 16 115 5.2.1. Reference Definition . . . . . . . . . . . . . . . . . 16 116 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . . 17 117 5.2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 17 118 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 17 119 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . . 17 120 5.3.2. Stream Type and Stream Parameters . . . . . . . . . . 17 121 5.3.3. Output Type and Data Format . . . . . . . . . . . . . 18 122 5.3.4. Run-time Parameters and Data Format . . . . . . . . . 18 123 5.4. Comments and Remarks . . . . . . . . . . . . . . . . . . . 19 124 6. Example IPFIX RTT Pair Matching Registry Entry . . . . . . . . 19 125 6.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . . 19 126 6.1.1. Element ID . . . . . . . . . . . . . . . . . . . . . . 19 127 6.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 19 128 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 19 129 6.2.1. Reference Definition . . . . . . . . . . . . . . . . . 20 130 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . . 20 131 6.2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 20 132 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 20 133 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . . 20 134 6.3.2. Stream Type and Stream Parameters . . . . . . . . . . 21 135 6.3.3. Output Type and Data Format . . . . . . . . . . . . . 21 136 6.3.4. Run-time Parameters and Data Format . . . . . . . . . 21 137 6.4. Comments and Remarks . . . . . . . . . . . . . . . . . . . 21 138 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 139 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 140 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 141 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 142 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 143 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 146 1. Introduction 148 This memo investigates a scheme to organize registry entries, 149 especially those defined in RFCs prepared in the IP Performance 150 Metrics (IPPM) Working Group of the IETF, according to their 151 framework [RFC2330]. Three aspects make IPPM metric registration 152 difficult: (1) Use of the Type-P notion to allow users to specify 153 their own packet types. (2) Use of Flexible input variables, called 154 Parameters in IPPM definitions, some which determine the quantity 155 measured and others which should not be specified until execution of 156 the measurement. (3) Allowing flexibility in choice of statistics to 157 summarize the results on a stream of measurement packets. This memo 158 uses terms and definitions from the IPPM literature, primarily 159 [RFC2330], and the reader is assumed familiar with them or may refer 160 questions there as necessary. 162 Although there are several standard templates for organizing 163 specifications of performance metrics (see [RFC2679] for an example 164 of the traditional IPPM template, based to large extent on the 165 Benchmarking Methodology Working Group's traditional template in 166 [RFC1242], and see [RFC6390] for a similar template), none of these 167 templates was intended to become the basis for the columns of an 168 IETF-wide registry of metrics. As we examine the aspects of metric 169 specifications which need to be registered, we will see that none of 170 the existing metric templates fully satisfies the needs of a 171 registry. 173 The authors of [draft-bagnulo-ippm-new-registry] and 174 [draft-bagnulo-ippm-new-registry-independent] made important 175 contributions to this memo in the registry column structure, and the 176 problem of registry development in general. We also acknowledge 177 input from the authors of [draft-claise-ippm-perf-metric-registry], 178 especially the value of an Element ID and the need for naming 179 conventions. 181 1.1. Background and Motivation 183 The motivation for having such registry is to allow a controller to 184 request a measurement agent to execute a measurement using a specific 185 metric. Such request can be performed using any control protocol 186 that refers to the value assigned to the specific metric in the 187 registry. Similarly, the measurement agent can report the results of 188 the measurement and by referring to the metric value it can 189 unequivocally identify the metric that the results correspond to. 191 There was a previous attempt to define a metric registry RFC 4148 192 [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because 193 it was "found to be insufficiently detailed to uniquely identify IPPM 194 metrics... [there was too much] variability possible when 195 characterizing a metric exactly" which led to the RFC4148 registry 196 having "very few users, if any". 198 Our approach learns from this, by tightly defining each entry in the 199 registry with only a few parameters open for each. The idea is that 200 the entries in the registry represent different measurement tests, 201 whilst the run-time parameters set things like source and destination 202 addresses that don't change the fundamental nature of the test. The 203 downside of this approach is that it could result in an explosion in 204 the number of entries in the registry. We believe that less is more 205 in this context - it is better to have a reduced set of useful 206 metrics rather than a large set of metrics with questionable 207 usefulness. Therefore this document defines that the registry only 208 includes commonly used metrics that are well defined; hence we 209 require both reference specification required AND expert review 210 policies for the assignment of values in the registry. 212 There are several side benefits of having such a registry. First the 213 registry could serve as an inventory of useful and used metrics, that 214 are normally supported by different implementations of measurement 215 agents. Second, the results of the metrics would be comparable even 216 if they are performed by different implementations and in different 217 networks, as the metric is properly defined. 219 The registry forms part of a Characterization Plan. It describes 220 various factors that need to be set by the party controlling the 221 measurements, for example: specific values for the parameters 222 associated with the selected registry entry (for instance, source and 223 destination addresses); and how often the measurement is made. The 224 Characterization Plan determines the individual Measurement 225 Instructions that will be communicated to measurement agents, whose 226 task is then to execute the Instruction autonomously. 228 Measurement Instructions might look something like: "Dear measurement 229 agent: Please start test DNS(example.com) and RTT(server.com,150) 230 every day at 2000 GMT. Run the DNS test 5 times and the RTT test 50 231 times. Do that when the network is idle. Generate both raw results 232 and 99th percentile mean. Send measurement results to collector.com 233 in IPFIX format". The Characterization Plan depends on the 234 requirements of the controlling party. For instance the broadband 235 consumer might want a one-off measurement made immediately to one 236 specific server; a regulator might want the same measurement made 237 once a day until further notice to the 'top 10' servers; whilst an 238 operator might want a varying series of tests (some of which will be 239 beyond those defined in the registry) as determined from time to time 240 by their operational support system. While the registries defined in 241 this document help to define the Characterization Plan, its full 242 specification falls outside the scope of this document, and other 243 IETF work as currently chartered. 245 2. Scope 247 Specifically, this memo proposes a way to organize registry entries 248 into columns that are well-defined, permiting consistent development 249 of entries over time. Also, this fosters development of registry 250 entries based on existing reference RFCs for performance metrics, and 251 requires expert review for every entry before IANA action. 253 In this memo, we attempt a combinatoric registry, where all factors 254 that can be reasonably specified ARE specified, and changing even one 255 factor would require a new registry entry (row). It is believed that 256 this exercise can also be instructive for a registry based on 257 independent factors, [draft-bagnulo-ippm-new-registry-independent] 258 but that topic is beyond the scope of this effort. 260 Entries in the registry must reference an existing RFC or other 261 recognized standard, and are subject to expert review. The expert 262 review must make sure that the proposed metric is operationally 263 useful. This means that the metric has proven to be useful in 264 operational/real scenarios. 266 3. Registry Categories and Columns 268 This section briefly describes the categories and columns proposed 269 for the registry, as this is likely to be a topic for discussion and 270 revision. Below, categories are described at the 3.x heading level, 271 and columns are at the 3.x.y heading level. The Figure below 272 illustrates this organization. 274 Taken as a whole, the entries in the columns give a registered 275 instance of a metric with sufficient specificity to promote 276 comparable results across independent implementations. In other 277 words, a *complete description* of a Metric Instance. Some instances 278 may not require entries in all columns, but this is preferred to more 279 general organization because each column serves as a check-list item 280 and helps to avoid omissions during registration and expert review. 282 Registry Categories and Columns, shown as 283 Category 284 ------------------ 285 Column | Column | 286 Registry Indexes 287 --------------------------- 288 Element ID | Metric Name | 290 Metric Definition 291 -------------------------------------------------------- 292 Reference Definition | Fixed Parameters | Metric Units | 294 Method of Measurement 295 ------------------------------------------------------------------------- 296 Reference Method | Stream Type and Param | Output Type | Run-time Param | 298 Comments and Remarks 299 -------------------- 301 3.1. Registry Indexes 303 This category includes multiple indexes to the registry entries, the 304 element ID and metric name. 306 3.1.1. Element ID 308 An integer having enough digits to uniquely identify each entry in 309 the Registry. 311 3.1.2. Metric Name 313 A metric naming convention is TBD. 315 The current guidance from Section 13 of [RFC2330], where Type-P is a 316 feature of all IPPM metric names, is: 318 "... we introduce the generic notion of a "packet of type P", where 319 in some contexts P will be explicitly defined (i.e., exactly what 320 type of packet we mean), partially defined (e.g., "with a payload of 321 B octets"), or left generic. Thus we may talk about generic IP-type- 322 P-connectivity or more specific IP-port-HTTP-connectivity. Some 323 metrics and methodologies may be fruitfully defined using generic 324 type P definitions which are then made specific when performing 325 actual measurements. Whenever a metric's value depends on the type 326 of the packets involved in the metric, the metric's name will include 327 either a specific type or a phrase such as "type-P". ..." 329 Registry entries are a context where Type-P must be defined. 331 IPPM Metric names have also included the typically included the 332 stream type, to distinguish between singleton and sample metrics (see 333 [RFC2330] for the definition of these terms). 335 3.2. Metric Definition 337 This category includes columns to prompt the entry of all necessary 338 detalis related to the metric definition, including the RFC reference 339 and values of input factors, called fixed parameters. 341 3.2.1. Reference Definition 343 This entry provides references to relevant sections of the RFC(s) 344 defining the metric, as well as any supplemental information needed 345 to ensure an unambiguous definition for implementations. 347 3.2.2. Fixed Parameters 349 Fixed Parameters are input factors that must be determined and 350 embedded in the measurement system for use when needed. The values 351 of these parameters is specified in the Registry. 353 Where referenced metrics supply a list of Parameters as part of their 354 descriptive template, a sub-set of the Parameters will be designated 355 as Fixed Parameters. For example, Fixed Parameters determine most or 356 all of the IPPM Framework convention "packets of Type-P" as described 357 in [RFC2330], such as transport protocol, payload length, TTL, etc. 359 A Parameter which is Fixed for one Registry entry may be designated 360 as a Run-time Parameter for another Registry entry. 362 3.2.3. Metric Units 364 The measured results of a metric must be expressed using some 365 standard dimension or units of measure. This column provides the 366 units (and if possible, the data format, whose specification will 367 simplify both measurement implementation and collection/storage 368 tasks, see the Output Type column below). 370 When a sample of singletons (see [RFC2330] for definitions of these 371 terms) is collected, this entry will specify the units for each 372 measured value. 374 3.3. Method of Measurement 376 This category includes columns for references to relevant sections of 377 the RFC(s) and any supplemental information needed to ensure an 378 unambiguous methods for implementations. 380 3.3.1. Reference Method 382 This entry provides references to relevant sections of the RFC(s) 383 describing the method of measurement, as well as any supplemental 384 information needed to ensure unambiguous interpretation for 385 implementations referring to the RFC text. 387 3.3.2. Stream Type and Stream Parameters 389 Principally, two different streams are used in IPPM metrics, Poisson 390 distributed as described in [RFC2330] and Periodic as described in 391 [RFC3432]. Both Poisson and Periodic have their own unique 392 parameters, and the relevant set of values is specified in this 393 column. 395 Some metrics, such as those intended for passive monitoring or RTCP 396 and RTCP-XR metrics, will not specifiy an entry for this column. 398 Each entry for this column contains the following information: 400 o Value: The name of the packet stream scheduling disipline 402 o Stream Parameters: The values and formats of input factors for 403 each type of stream. For example, the average packet rate and 404 distribution truncation value for streams with Poisson-distributed 405 inter-packet sending times. 407 o Reference: the specification where the stream is defined 409 The simplest example of stream specification is Singleton scheduling, 410 where a single atomic measurement is conducted. Each atomic 411 measurement could consist of sending a single packet (such as a DNS 412 request) or sending several packets (for example, to request a a 413 webpage). Other streams support a series of atomic measurements in a 414 "sample", with a schedule defining the timing between each transmited 415 packet and subsequent measurement. 417 3.3.3. Output Type and Data Format 419 For entries which involve a stream and many singleton measurements, a 420 statistic may be specified in this column to summarize the results to 421 a single value. If the complete set of measured singletons is 422 output, this will be specified here. 424 Some metrics embed one specific statistic in the reference metric 425 definition, while others allow several output types or statistics. 427 Each entry in the output type column contains the following 428 information: 430 o Value: The name of the output type 432 o Data Format: provided to simplify the communication with 433 collection systems and implementation of measurement devices. 435 o Reference: the specification where the output type is defined 437 The output type defines the type of result that the metric produces. 438 It can be the raw results or it can be some form of statistic. The 439 specification of the output type must define the format of the 440 output. Note that if two different statistics are required from a 441 single measurement (for example, both "Xth percentile mean" and 442 "Raw"), then a new output type must be defined ("Xth percentile mean 443 AND Raw"). 445 3.3.4. Run-time Parameters and Data Format 447 Run-Time Parameters are input factors that must be determined, 448 configured into the measurement system, and reported with the results 449 for the context to be complete. However, the values of these 450 parameters is not specified in the Registry, rather these parameters 451 are listed as an aid to the measurement system implementor or user 452 (they must be left as variables, and supplied on execution). 454 Where metrics supply a list of Parameters as part of their 455 descriptive template, a sub-set of the Parameters will be designated 456 as Run-Time Parameters. 458 The Data Format of each Run-time Parameter SHALL be specified in this 459 column, to simplify the control and implementation of measurement 460 devices. 462 Examples of Run-time Parameters include IP addresses, measurement 463 point designations, start times and end times for measurement, and 464 other measurement-specific information. 466 3.4. Comments and Remarks 468 Besides providing additional details which do not appear in other 469 categories, this open Category (single column) allows for unforeseen 470 issues to be addressed by simply updating this Informational entry. 472 4. Example RTCP-XR Registry Entry 474 This section gives an example registry entry for the passive (end- 475 point) metric described in RFC 7003 [RFC7003], for RTCP-XR Burst/Gap 476 Discard Metric reporting. 478 4.1. Registry Indexes 480 This category includes multiple indexes to the registry entries, the 481 element ID and metric name. 483 4.1.1. Element ID 485 An integer having enough digits to uniquely identify each entry in 486 the Registry. 488 4.1.2. Metric Name 490 A metric naming convention is TBD. 492 4.2. Metric Definition 494 This category includes columns to prompt the entry of all necessary 495 detalis related to the metric definition, including the RFC reference 496 and values of input factors, called fixed parameters. Section 3.2 of 497 [RFC7003] provides the reference information for this category. 499 4.2.1. Reference Definition 501 Packets Discarded in Bursts: 503 The total number of packets discarded during discard bursts. The 504 measured value is unsigned value. If the measured value exceeds 505 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over- 506 range measurement. If the measurement is unavailable, the value 507 0xFFFFFF MUST be reported. 509 4.2.2. Fixed Parameters 511 Fixed Parameters are input factors that must be determined and 512 embedded in the measurement system for use when needed. The values 513 of these parameters is specified in the Registry. 515 Threshold: 8 bits, set to value = 3 packets. 517 The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of 518 successive packets that must not be discarded prior to and following 519 a discard packet in order for this discarded packet to be regarded as 520 part of a gap. Note that the Threshold is set in accordance with the 521 Gmin calculation defined in Section 4.7.2 of [RFC3611]. 523 Interval Metric flag: 2 bits, set to value 11=Cumulative Duration 525 This field is used to indicate whether the burst/gap discard metrics 526 are Sampled, Interval, or Cumulative metrics [RFC6792]: 528 I=10: Interval Duration - the reported value applies to the most 529 recent measurement interval duration between successive metrics 530 reports. 532 I=11: Cumulative Duration - the reported value applies to the 533 accumulation period characteristic of cumulative measurements. 535 Senders MUST NOT use the values I=00 or I=01. 537 4.2.3. Metric Units 539 The measured results are apparently expressed in packets, although 540 there is no section of [RFC7003] titled "Metric Units". 542 4.3. Method of Measurement 544 This category includes columns for references to relevant sections of 545 the RFC(s) and any supplemental information needed to ensure an 546 unambiguous methods for implementations. For the Burst/Gap Discard 547 Metric, it appears that the only guidance on methods of measurement 548 is in Section 3.0 of [RFC7003] and its supporting references. 549 Relevant information is repeated below, although there appears to be 550 no section titled "Method of Measurement" in [RFC7003]. 552 4.3.1. Reference Method 554 Metrics in this block report on burst/gap discard in the stream 555 arriving at the RTP system. Measurements of these metrics are made 556 at the receiving end of the RTP stream. Instances of this metrics 557 block use the synchronization source (SSRC) to refer to the separate 558 auxiliary Measurement Information Block [RFC6776], which describes 559 measurement periods in use (see [RFC6776], Section 4.2). 561 This metrics block relies on the measurement period in the 562 Measurement Information Block indicating the span of the report. 563 Senders MUST send this block in the same compound RTCP packet as the 564 Measurement Information Block. Receivers MUST verify that the 565 measurement period is received in the same compound RTCP packet as 566 this metrics block. If not, this metrics block MUST be discarded. 568 4.3.2. Stream Type and Stream Parameters 570 Since RTCP-XR Measurements are conducted on live RTP traffic, the 571 complete description of the stream is contained in SDP messages that 572 proceed the establishment of a compatible stream between two or more 573 communicating hosts. See Run-time Parameters, below. 575 4.3.3. Output Type and Data Format 577 The output type defines the type of result that the metric produces. 579 o Value: Packets Discarded in Bursts 581 o Data Format: 24 bits 583 o Reference: Section 3.2 of [RFC7003] 585 4.3.4. Run-time Parameters and Data Format 587 Run-Time Parameters are input factors that must be determined, 588 configured into the measurement system, and reported with the results 589 for the context to be complete. However, the values of these 590 parameters is not specified in the Registry, rather these parameters 591 are listed as an aid to the measurement system implementor or user 592 (they must be left as variables, and supplied on execution). 594 The Data Format of each Run-time Parameter SHALL be specified in this 595 column, to simplify the control and implementation of measurement 596 devices. 598 SSRC of Source: 32 bits As defined in Section 4.1 of [RFC3611]. 600 SDP Parameters: As defined in [RFC4566] 602 Session description v= (protocol version number, currently only 0) 604 o= (originator and session identifier : username, id, version number, 605 network address) 607 s= (session name : mandatory with at least one UTF-8-encoded 608 character) 610 i=* (session title or short information) u=* (URI of description) 612 e=* (zero or more email address with optional name of contacts) 613 p=* (zero or more phone number with optional name of contacts) 615 c=* (connection information--not required if included in all media) 617 b=* (zero or more bandwidth information lines) One or more Time 618 descriptions ("t=" and "r=" lines; see below) 620 z=* (time zone adjustments) 622 k=* (encryption key) 624 a=* (zero or more session attribute lines) 626 Zero or more Media descriptions (each one starting by an "m=" line; 627 see below) 629 m= (media name and transport address) 631 i=* (media title or information field) 633 c=* (connection information -- optional if included at session level) 635 b=* (zero or more bandwidth information lines) 637 k=* (encryption key) 639 a=* (zero or more media attribute lines -- overriding the Session 640 attribute lines) 642 An example Run-time SDP description follows: 644 v=0 646 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 648 s=SDP Seminar i=A Seminar on the session description protocol 650 u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane 651 Doe) 653 c=IN IP4 224.2.17.12/127 655 t=2873397496 2873404696 657 a=recvonly 659 m=audio 49170 RTP/AVP 0 660 m=video 51372 RTP/AVP 99 662 a=rtpmap:99 h263-1998/90000 664 4.4. Comments and Remarks 666 Besides providing additional details which do not appear in other 667 categories, this open Category (single column) allows for unforeseen 668 issues to be addressed by simply updating this Informational entry. 670 5. Example IPPM Active Registry Entry 672 This section gives an example registry entry for the active metric 673 described in [RFC3393], on Packet Delay Variation. 675 5.1. Registry Indexes 677 This category includes multiple indexes to the registry entries, the 678 element ID and metric name. 680 5.1.1. Element ID 682 An integer having enough digits to uniquely identify each entry in 683 the Registry. 685 5.1.2. Metric Name 687 A metric naming convention is TBD. 689 One possibility based on IPPM's framework is: 691 IP-UDP-One-way-pdv-95th-percentile-Poisson 693 5.2. Metric Definition 695 This category includes columns to prompt the entry of all necessary 696 detalis related to the metric definition, including the RFC reference 697 and values of input factors, called fixed parameters. 699 5.2.1. Reference Definition 701 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 702 measured are referred to by the variable name "ddT". 704 5.2.2. Fixed Parameters 706 Where metrics supply a list of Parameters as part of their 707 descriptive template, a sub-set of the Parameters will be designated 708 as Fixed Parameters. 710 o F, a selection function defining unambiguously the packets from 711 the stream selected for the metric. See section 4.2 of [RFC5481] 712 for the PDV form. 714 o L, a packet length in bits. L = 200 bits. 716 o Tmax, a maximum waiting time for packets to arrive at Dst, set 717 sufficiently long to disambiguate packets with long delays from 718 packets that are discarded (lost). Tmax = 3 seconds. 720 o Type-P, as defined in [RFC2330], which includes any field that may 721 affect a packet's treatment as it traverses the network. The 722 packets are IP/UDP, with DSCP = 0 (BE). 724 5.2.3. Metric Units 726 See section 3.3 of [RFC3393] for singleton elements. 728 [RFC2330] recommends that when a time is given, it will be expressed 729 in UTC. 731 The timestamp format (for T, Tf, etc.) is the same as in [RFC5905] 732 (64 bits) and is as follows: the first 32 bits represent the unsigned 733 integer number of seconds elapsed since 0h on 1 January 1900; the 734 next 32 bits represent the fractional part of a second that has 735 elapsed since then. 737 5.3. Method of Measurement 739 This category includes columns for references to relevant sections of 740 the RFC(s) and any supplemental information needed to ensure an 741 unambiguous methods for implementations. 743 5.3.1. Reference Method 745 See section 2.6 and 3.6 of [RFC3393] for singleton elements. 747 5.3.2. Stream Type and Stream Parameters 749 Poisson distributed as described in [RFC2330], with the following 750 Parameters. 752 o lambda, a rate in reciprocal seconds (for Poisson Streams). lambda 753 = 1 packet per second 755 o Upper limit on Poisson distribution (values above this limit will 756 be clipped and set to the limit value). Upper limit = 30 seconds. 758 5.3.3. Output Type and Data Format 760 See section 4.3 of [RFC3393] for details on the percentile statistic. 762 The percentile = 95. 764 Data format is a 32-bit unsigned floating point value. 766 Individual results (singletons) should be represented by the 767 following triple 769 o T1 and T2, times as described below in the Run-time parameters 770 section. 772 o ddT as defined in section 2.4 of [RFC3393] 774 if needed. The result format for ddT is *similar to* the short 775 format in [RFC5905] (32 bits) and is as follows: the first 16 bits 776 represent the *signed* integer number of seconds; the next 16 bits 777 represent the fractional part of a second. 779 5.3.4. Run-time Parameters and Data Format 781 Where metrics supply a list of Parameters as part of their 782 descriptive template, a sub-set of the Parameters will be designated 783 as Run-Time Parameters. In related registry entries, some of the 784 parameters below may be designated as Fixed Parameters instead. 786 o Src, the IP address of a host (32-bit value for IPv4, 128-bit 787 value for IPv6) 789 o Dst, the IP address of a host (32-bit value for IPv4, 128-bit 790 value for IPv6) 792 o T, a time (start of test interval, 128-bit NTP Date Format, see 793 section 6 of [RFC5905]) 795 o Tf, a time (end of test interval, 128-bit NTP Date Format, see 796 section 6 of [RFC5905]) 798 o T1, the wire time of the first packet in a pair, measured at 799 MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see 800 section 6 of [RFC5905]). 802 o T2, the wire time of the second packet in a pair, measured at 803 MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see 804 section 6 of [RFC5905]). 806 o I(i),I(i+1), i >=0, pairs of times which mark the beginning and 807 ending of the intervals in which the packet stream from which the 808 measurement is taken occurs. Here, I(0) = T0 and assuming that n 809 is the largest index, I(n) = Tf (pairs of 64-bit NTP Timestamp 810 Format, see section 6 of [RFC5905]). 812 5.4. Comments and Remarks 814 Lost packets represent a challenge for delay variation metrics. See 815 section 4.1 of [RFC3393] and the delay variation applicability 816 statement[RFC5481] for extensive analysis and comparison of PDV and 817 IPDV. 819 6. Example IPFIX RTT Pair Matching Registry Entry 821 This section gives an example registry entry for the passive metric 822 described in section 2.5.2.1 of [RFC5472], for Round-Trip Time (RTT) 823 Measurements with Packet Pair Matching (Single-Point). 825 6.1. Registry Indexes 827 This category includes multiple indexes to the registry entries, the 828 element ID and metric name. 830 6.1.1. Element ID 832 An integer having enough digits to uniquely identify each entry in 833 the Registry. 835 6.1.2. Metric Name 837 A metric naming convention is TBD. 839 6.2. Metric Definition 841 This category includes columns to prompt the entry of all necessary 842 details related to the metric definition, including the RFC reference 843 and values of input factors, called fixed parameters. Section 844 2.5.2.1 of [RFC5472] provides the reference information for this 845 category. 847 6.2.1. Reference Definition 849 Observations of both directions are required to correlate request/ 850 response packet pairs. 852 Pair matching techniques are described in [Brow00]. 854 6.2.2. Fixed Parameters 856 Fixed Parameters are input factors that must be determined and 857 embedded in the measurement system for use when needed. The values 858 of these parameters is specified in the Registry. 860 Protocol (Pair Type): TCP (SYN/SYN_ACK) 862 Note: other possibilities are DNS, ICMP, SNMP or TCP (DATA/ACK), 863 discussed in [Brow00]. 865 6.2.3. Metric Units 867 The measured results are expressed in microseconds, which follows the 868 format of Information Elements per observed packet, see section 8.4.3 869 of[RFC5477] titled "observationTimeMicroseconds". 871 6.3. Method of Measurement 873 This category includes columns for references to relevant sections of 874 the RFC(s) and any supplemental information needed to ensure an 875 unambiguous methods for implementations. 877 6.3.1. Reference Method 879 For the TCP(SYN/SYN_ACK) RTT metric, the guidance on methods of 880 measurement is in slides 12 and 15 of [Brow00]. 882 Recognition of request response pairs is a REQUIRED function, as is 883 the correlation of data from both directions of transmission, see 884 section 2.5.2.1 of [RFC5472]. 886 The method requires the collection of the following Information 887 Elements per packet: 889 o Packet arrival time: observationTimeMicroseconds, see section 890 8.4.3 of[RFC5477] 892 o TCP header: ipPayloadPacketSection, see section 8.5.2 of[RFC5477] 894 6.3.2. Stream Type and Stream Parameters 896 Since IPFIX passive Measurements are conducted on live/production 897 network traffic, the measurement methods rely on user-generated 898 packet flows. Such flows are not described in this column. 900 6.3.3. Output Type and Data Format 902 The output type defines the type of result that the metric produces. 904 o Value: RTT in microseconds 906 o Data Format: (There may be some precedent to follow here, but 907 otherwise use 64-bit NTP Timestamp Format, see section 6 of 908 [RFC5905]). 910 o Reference: Section 2.5.2.1 of [RFC5472] 912 6.3.4. Run-time Parameters and Data Format 914 Run-time Parameters are input factors that must be determined, 915 configured into the measurement system, and reported with the results 916 for the context to be complete. However, the list of Run-time 917 parameters is not specified for purely passive metrics, as there are 918 infinite possibilities. 920 A likely Run-time parameter is the Destination host, which may be 921 given as a Fully-Qualified Domain Name as done in [Brow00], or an IP 922 address of the host (32-bit value for IPv4, 128-bit value for IPv6). 924 6.4. Comments and Remarks 926 Additional (Informational) details for this entry, from [Brow00]: 928 Can't get RTT for every packet, only those which are ACKed. 930 Overlapping packets (resent) are counted as lost, but not queued. 931 This means the first copy of resent packets are used for RTTs, giving 932 a high RTT estimate. 934 7. Security Considerations 936 This registry has no known implications on Internet Security. 938 8. IANA Considerations 940 Metrics previously defined in IETF were registered in the IANA IPPM 941 METRICS REGISTRY, however this process was discontinued when the 942 registry structure was found to be inadequate, and the registry was 943 declared Obsolete [RFC6248]. 945 The form of metric registration will finalized in the future, and no 946 IANA Action is requested at this time. 948 9. Acknowledgements 950 The author thanks Brian Trammell for suggesting the term "Run-time 951 Parameters", which led to the distinction between run-time and fixed 952 parameters implemented in this memo. 954 10. References 956 10.1. Normative References 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, March 1997. 961 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 962 "Framework for IP Performance Metrics", RFC 2330, 963 May 1998. 965 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 966 Delay Metric for IPPM", RFC 2679, September 1999. 968 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 969 Packet Loss Metric for IPPM", RFC 2680, September 1999. 971 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 972 Delay Metric for IPPM", RFC 2681, September 1999. 974 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 975 Metric for IP Performance Metrics (IPPM)", RFC 3393, 976 November 2002. 978 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 979 performance measurement with periodic streams", RFC 3432, 980 November 2002. 982 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 983 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 984 November 2006. 986 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 987 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 988 RFC 5357, October 2008. 990 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 991 Time Protocol Version 4: Protocol and Algorithms 992 Specification", RFC 5905, June 2010. 994 10.2. Informative References 996 [Brow00] Brownlee, N., "Packet Matching for NeTraMet 997 Distributions", March 2000. 999 [RFC1242] Bradner, S., "Benchmarking terminology for network 1000 interconnection devices", RFC 1242, July 1991. 1002 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1003 Registry", BCP 108, RFC 4148, August 2005. 1005 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1006 Flow Information Export (IPFIX) Applicability", RFC 5472, 1007 March 2009. 1009 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1010 Carle, "Information Model for Packet Sampling Exports", 1011 RFC 5477, March 2009. 1013 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1014 Applicability Statement", RFC 5481, March 2009. 1016 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 1017 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 1018 April 2011. 1020 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1021 Performance Metric Development", BCP 170, RFC 6390, 1022 October 2011. 1024 [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol 1025 (RTCP) Extended Report (XR) Block for Burst/Gap Discard 1026 Metric Reporting", RFC 7003, September 2013. 1028 Authors' Addresses 1030 Marcelo Bagnulo 1031 Universidad Carlos III de Madrid 1032 Av. Universidad 30 1033 Leganes, Madrid 28911 1034 SPAIN 1036 Phone: 34 91 6249500 1037 Email: marcelo@it.uc3m.es 1038 URI: http://www.it.uc3m.es 1040 Al Morton 1041 AT&T Labs 1042 200 Laurel Avenue South 1043 Middletown,, NJ 07748 1044 USA 1046 Phone: +1 732 420 1571 1047 Fax: +1 732 368 1192 1048 Email: acmorton@att.com 1049 URI: http://home.comcast.net/~acmacm/ 1051 Philip Eardley 1052 British Telecom 1053 Adastral Park, Martlesham Heath 1054 Ipswich 1055 ENGLAND 1057 Email: philip.eardley@bt.com