idnits 2.17.1 draft-ietf-ippm-metric-registry-04.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 (July 20, 2015) is 3196 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3986' is mentioned on line 562, but not defined == Missing Reference: 'RFC 2141' is mentioned on line 557, but not defined ** Obsolete undefined reference: RFC 2141 (Obsoleted by RFC 8141) == Unused Reference: 'RFC2141' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC6776' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'RFC6792' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'RFC7003' is defined on line 1122, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6248 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-06) exists of draft-ietf-ippm-active-passive-00 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Best Current Practice B. Claise 5 Expires: January 21, 2016 Cisco Systems, Inc. 6 P. Eardley 7 BT 8 A. Morton 9 AT&T Labs 10 A. Akhter 11 Consultant 12 July 20, 2015 14 Registry for Performance Metrics 15 draft-ietf-ippm-metric-registry-04 17 Abstract 19 This document defines the IANA Registry for Performance Metrics. 20 This document also gives a set of guidelines for Registered 21 Performance Metric requesters and reviewers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 21, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Motivation for a Performance Metrics Registry . . . . . . . . 6 61 4.1. Interoperability . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Single point of reference for Performance Metrics . . . . 7 63 4.3. Side benefits . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Criteria for Performance Metrics Registration . . . . . . . . 8 65 6. Performance Metric Registry: Prior attempt . . . . . . . . . 9 66 6.1. Why this Attempt Will Succeed . . . . . . . . . . . . . . 9 67 7. Definition of the Performance Metric Registry . . . . . . . . 10 68 7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 11 69 7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 11 70 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 13 73 7.2. Metric Definition Category . . . . . . . . . . . . . . . 13 74 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 13 75 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 13 76 7.3. Method of Measurement Category . . . . . . . . . . . . . 14 77 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 14 78 7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 14 79 7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 15 80 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 15 81 7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 16 82 7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 16 84 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 17 86 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 17 87 7.5. Administrative information . . . . . . . . . . . . . . . 17 88 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 17 89 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 17 90 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 17 91 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 18 92 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 18 93 8. The Life-Cycle of Registered Performance Metrics . . . . . . 18 94 8.1. Adding new Performance Metrics to the Performance Metrics 95 Registry . . . . . . . . . . . . . . . . . . . . . . . . 18 96 8.2. Revising Registered Performance Metrics . . . . . . . . . 19 97 8.3. Deprecating Registered Performance Metrics . . . . . . . 20 98 9. Security considerations . . . . . . . . . . . . . . . . . . . 21 99 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 103 12.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 The IETF specifies and uses Performance Metrics of protocols and 109 applications transported over its protocols. Performance metrics are 110 such an important part of the operations of IETF protocols that 111 [RFC6390] specifies guidelines for their development. 113 The definition and use of Performance Metrics in the IETF happens in 114 various working groups (WG), most notably: 116 The "IP Performance Metrics" (IPPM) WG is the WG primarily 117 focusing on Performance Metrics definition at the IETF. 119 The "Metric Blocks for use with RTCP's Extended Report Framework" 120 (XRBLOCK) WG recently specified many Performance Metrics related 121 to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], 122 which establishes a framework to allow new information to be 123 conveyed in RTCP, supplementing the original report blocks defined 124 in "RTP: A Transport Protocol for Real-Time Applications", 125 [RFC3550]. 127 The "Benchmarking Methodology" WG (BMWG) defined many Performance 128 Metrics for use in laboratory benchmarking of inter-networking 129 technologies. 131 The "IP Flow Information eXport" (IPFIX) concluded WG specified an 132 IANA process for new Information Elements. Some Performance 133 Metrics related Information Elements are proposed on regular 134 basis. 136 The "Performance Metrics for Other Layers" (PMOL) concluded WG, 137 defined some Performance Metrics related to Session Initiation 138 Protocol (SIP) voice quality [RFC6035]. 140 It is expected that more Performance Metrics will be defined in the 141 future, not only IP-based metrics, but also metrics which are 142 protocol-specific and application-specific. 144 However, despite the importance of Performance Metrics, there are two 145 related problems for the industry. First, how to ensure that when 146 one party requests another party to measure (or report or in some way 147 act on) a particular Performance Metric, then both parties have 148 exactly the same understanding of what Performance Metric is being 149 referred to. Second, how to discover which Performance Metrics have 150 been specified, so as to avoid developing new Performance Metric that 151 is very similar, but not quite inter-operable. The problems can be 152 addressed by creating a registry of performance metrics. The usual 153 way in which IETF organizes namespaces is with Internet Assigned 154 Numbers Authority (IANA) registries, and there is currently no 155 Performance Metrics Registry maintained by the IANA. 157 This document therefore creates an IANA-maintained Performance 158 Metrics Registry. It also provides best practices on how to specify 159 new entries or update ones in the Performance Metrics Registry. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in 166 [RFC2119]. 168 Performance Metric: A Performance Metric is a quantitative measure 169 of performance, targeted to an IETF-specified protocol or targeted 170 to an application transported over an IETF-specified protocol. 171 Examples of Performance Metrics are the FTP response time for a 172 complete file download, the DNS response time to resolve the IP 173 address, a database logging time, etc. This definition is 174 consistent with the definition of metric in [RFC2330] and broader 175 than the definition of performance metric in [RFC6390]. 177 Registered Performance Metric: A Registered Performance Metric is a 178 Performance Metric expressed as an entry in the Performance Metric 179 Registry, administered by IANA. Such a performance metric has met 180 all the registry review criteria defined in this document in order 181 to included in the registry. 183 Performance Metrics Registry: The IANA registry containing 184 Registered Performance Metrics. 186 Proprietary Registry: A set of metrics that are registered in a 187 proprietary registry, as opposed to Performance Metrics Registry. 189 Performance Metrics Experts: The Performance Metrics Experts is a 190 group of designated experts [RFC5226] selected by the IESG to 191 validate the Performance Metrics before updating the Performance 192 Metrics Registry. The Performance Metrics Experts work closely 193 with IANA. 195 Parameter: An input factor defined as a variable in the definition 196 of a Performance Metric. A numerical or other specified factor 197 forming one of a set that defines a metric or sets the conditions 198 of its operation. All Parameters must be known to measure using a 199 metric and interpret the results. There are two types of 200 Parameters, Fixed and Run-time parameters. For the Fixed 201 Parameters, the value of the variable is specified in the 202 Performance Metrics Registry entry and different Fixed Parameter 203 values results in different Registered Performance Metrics. For 204 the Run-time Parameters, the value of the variable is defined when 205 the metric measurement method is executed and a given Registered 206 Performance Metric supports multiple values for the parameter. 207 Although Run-time Parameters do not change the fundamental nature 208 of the Performance Metric's definition, some have substantial 209 influence on the network property being assessed and 210 interpretation of the results. 212 Note: Consider the case of packet loss in the following two 213 Active Measurement Method cases. The first case is packet loss 214 as background loss where the Run-time Parameter set includes a 215 very sparse Poisson stream, and only characterizes the times 216 when packets were lost. Actual user streams likely see much 217 higher loss at these times, due to tail drop or radio errors. 218 The second case is packet loss as inverse of throughput where 219 the Run-time Parameter set includes a very dense, bursty 220 stream, and characterizes the loss experienced by a stream that 221 approximates a user stream. These are both "loss metrics", but 222 the difference in interpretation of the results is highly 223 dependent on the Run-time Parameters (at least), to the extreme 224 where we are actually using loss to infer its compliment: 225 delivered throughput. 227 Active Measurement Method: Methods of Measurement conducted on 228 traffic which serves only the purpose of measurement and is 229 generated for that reason alone, and whose traffic characteristics 230 are known a priori. A detailed definition of Active Measurement 231 Method is provided in [I-D.ietf-ippm-active-passive]. Examples of 232 Active Measurement Methods are the measurement methods for the One 233 way delay metric defined in [RFC2679] and the one for round trip 234 delay defined in [RFC2681]. 236 Passive Measurement Method: Methods of Measurement conducted on 237 network traffic, generated either from the end users or from 238 network elements that would exist regardless whether the 239 measurement was being conducted or not. One characteristic of 240 Passive Measurement Methods is that sensitive information may be 241 observed, and as a consequence, stored in the measurement system. 242 A detailed definition of Passive Measurement Method is provided in 243 [I-D.ietf-ippm-active-passive]. 245 3. Scope 247 This document is meant for two different audiences. For those 248 defining new Registered Performance Metrics, it provides 249 specifications and best practices to be used in deciding which 250 Registered Performance Metrics are useful for a measurement study, 251 instructions for writing the text for each column of the Registered 252 Performance Metrics, and information on the supporting documentation 253 required for the new Performance Metrics Registry entry (up to and 254 including the publication of one or more RFCs or I-Ds describing it). 255 For the appointed Performance Metrics Experts and for IANA personnel 256 administering the new IANA Performance Metric Registry, it defines a 257 set of acceptance criteria against which these proposed Registered 258 Performance Metrics should be evaluated. 260 This Performance Metric Registry is applicable to Performance Metrics 261 issued from Active Measurement, Passive Measurement, and any other 262 form of Performance Metric. This registry is designed to encompass 263 Performance Metrics developed throughout the IETF and especially for 264 the technologies specified in the following working groups: IPPM, 265 XRBLOCK, IPFIX, and BMWG. This document analyzes an prior attempt to 266 set up a Performance Metric Registry, and the reasons why this design 267 was inadequate [RFC6248]. Finally, this document gives a set of 268 guidelines for requesters and expert reviewers of candidate 269 Registered Performance Metrics. 271 This document makes no attempt to populate the Performance Metrics 272 Registry with initial entries. It does provides a few examples that 273 are merely illustrations and should not be included in the registry 274 at this point in time. 276 Based on [RFC5226] Section 4.3, this document is processed as Best 277 Current Practice (BCP) [RFC2026]. 279 4. Motivation for a Performance Metrics Registry 281 In this section, we detail several motivations for the Performance 282 Metric Registry. 284 4.1. Interoperability 286 As any IETF registry, the primary use for a registry is to manage a 287 namespace for its use within one or more protocols. In the 288 particular case of the Performance Metric Registry, there are two 289 types of protocols that will use the Performance Metrics in the 290 Performance Metrics Registry during their operation (by referring to 291 the Index values): 293 o Control protocol: this type of protocols is used to allow one 294 entity to request another entity to perform a measurement using a 295 specific metric defined by the Performance Metrics Registry. One 296 particular example is the LMAP framework 297 [I-D.ietf-lmap-framework]. Using the LMAP terminology, the 298 Performance Metrics Registry is used in the LMAP Control protocol 299 to allow a Controller to request a measurement task to one or more 300 Measurement Agents. In order to enable this use case, the entries 301 of the Performance Metric Registry must be well enough defined to 302 allow a Measurement Agent implementation to trigger a specific 303 measurement task upon the reception of a control protocol message. 304 This requirement heavily constrains the type of entries that are 305 acceptable for the Performance Metric Registry. 307 o Report protocol: This type of protocols is used to allow an entity 308 to report measurement results to another entity. By referencing 309 to a specific Performance Metric Registry, it is possible to 310 properly characterize the measurement result data being reported. 311 Using the LMAP terminology, the Performance Metrics Registry is 312 used in the Report protocol to allow a Measurement Agent to report 313 measurement results to a Collector. 315 4.2. Single point of reference for Performance Metrics 317 A Performance Metrics Registry serves as a single point of reference 318 for Performance Metrics defined in different working groups in the 319 IETF. As we mentioned earlier, there are several WGs that define 320 Performance Metrics in the IETF and it is hard to keep track of all 321 them. This results in multiple definitions of similar Performance 322 Metrics that attempt to measure the same phenomena but in slightly 323 different (and incompatible) ways. Having a registry would allow 324 both the IETF community and external people to have a single list of 325 relevant Performance Metrics defined by the IETF (and others, where 326 appropriate). The single list is also an essential aspect of 327 communication about Performance Metrics, where different entities 328 that request measurements, execute measurements, and report the 329 results can benefit from a common understanding of the referenced 330 Performance Metric. 332 4.3. Side benefits 334 There are a couple of side benefits of having such a registry. 335 First, the Performance Metrics Registry could serve as an inventory 336 of useful and used Performance Metrics, that are normally supported 337 by different implementations of measurement agents. Second, the 338 results of measurements using the Performance Metrics would be 339 comparable even if they are performed by different implementations 340 and in different networks, as the Performance Metric is properly 341 defined. BCP 176 [RFC6576] examines whether the results produced by 342 independent implementations are equivalent in the context of 343 evaluating the completeness and clarity of metric specifications. 344 This BCP defines the standards track advancement testing for (active) 345 IPPM metrics, and the same process will likely suffice to determine 346 whether Registered Performance Metrics are sufficiently well 347 specified to result in comparable (or equivalent) results. 348 Registered Performance Metrics which have undergone such testing 349 SHOULD be noted, with a reference to the test results. 351 5. Criteria for Performance Metrics Registration 353 It is neither possible nor desirable to populate the Performance 354 Metrics Registry with all combinations of Parameters of all 355 Performance Metrics. The Registered Performance Metrics should be: 357 1. interpretable by the user. 359 2. implementable by the software designer, 361 3. deployable by network operators, 363 4. accurate, for interoperability and deployment across vendors, 365 5. Operationally useful, so that it has significant industry 366 interest and/or has seen deployment, 368 6. Sufficiently tightly defined, so that different values for the 369 Run-time Parameters does not change the fundamental nature of the 370 measurement, nor change the practicality of its implementation. 372 In essence, there needs to be evidence that a candidate Registered 373 Performance Metric has significant industry interest, or has seen 374 deployment, and there is agreement that the candidate Registered 375 Performance Metric serves its intended purpose. 377 6. Performance Metric Registry: Prior attempt 379 There was a previous attempt to define a metric registry RFC 4148 380 [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because 381 it was "found to be insufficiently detailed to uniquely identify IPPM 382 metrics... [there was too much] variability possible when 383 characterizing a metric exactly" which led to the RFC4148 registry 384 having "very few users, if any". 386 A couple of interesting additional quotes from RFC 6248 might help 387 understand the issues related to that registry. 389 1. "It is not believed to be feasible or even useful to register 390 every possible combination of Type P, metric parameters, and 391 Stream parameters using the current structure of the IPPM Metrics 392 Registry." 394 2. "The registry structure has been found to be insufficiently 395 detailed to uniquely identify IPPM metrics." 397 3. "Despite apparent efforts to find current or even future users, 398 no one responded to the call for interest in the RFC 4148 399 registry during the second half of 2010." 401 The current approach learns from this by tightly defining each 402 Registered Performance Metric with only a few variable (Run-time) 403 Parameters to be specified by the measurement designer, if any. The 404 idea is that entries in the Performance Metrics Registry stem from 405 different measurement methods which require input (Run-time) 406 parameters to set factors like source and destination addresses 407 (which do not change the fundamental nature of the measurement). The 408 downside of this approach is that it could result in a large number 409 of entries in the Performance Metrics Registry. There is agreement 410 that less is more in this context - it is better to have a reduced 411 set of useful metrics rather than a large set of metrics, some with 412 with questionable usefulness. 414 6.1. Why this Attempt Will Succeed 416 As mentioned in the previous section, one of the main issues with the 417 previous registry was that the metrics contained in the registry were 418 too generic to be useful. This document specifies stricter criteria 419 for performance metric registration (see section 6), and imposes a 420 group of Performance Metrics Experts that will provide guidelines to 421 assess if a Performance Metric is properly specified. 423 Another key difference between this attempt and the previous one is 424 that in this case there is at least one clear user for the 425 Performance Metrics Registry: the LMAP framework and protocol. 426 Because the LMAP protocol will use the Performance Metrics Registry 427 values in its operation, this actually helps to determine if a metric 428 is properly defined. In particular, since we expect that the LMAP 429 control protocol will enable a controller to request a measurement 430 agent to perform a measurement using a given metric by embedding the 431 Performance Metric Registry value in the protocol, a metric is 432 properly specified if it is defined well-enough so that it is 433 possible (and practical) to implement the metric in the measurement 434 agent. This was the failure of the previous attempt: a registry 435 entry with an undefined Type-P (section 13 of RFC 2330 [RFC2330]) 436 allows implementation to be ambiguous. 438 7. Definition of the Performance Metric Registry 440 In this section we define the columns of the Performance Metric 441 Registry. This Performance Metric Registry is applicable to 442 Performance Metrics issued from Active Measurement, Passive 443 Measurement, and any other form of Performance Metric. Because of 444 that, it may be the case that some of the columns defined are not 445 applicable for a given type of metric. If this is the case, the 446 column(s) SHOULD be populated with the "NA" value (Non Applicable). 447 However, the "NA" value MUST NOT be used by any metric in the 448 following columns: Identifier, Name, URI, Status, Requester, 449 Revision, Revision Date, Description. In addition, it may be 450 possible that, in the future, a new type of metric requires 451 additional columns. Should that be the case, it is possible to add 452 new columns to the registry. The specification defining the new 453 column(s) must define how to populate the new column(s) for existing 454 entries. 456 The columns of the Performance Metric Registry are defined next. The 457 columns are grouped into "Categories" to facilitate the use of the 458 registry. Categories are described at the 8.x heading level, and 459 columns are at the 8.x.y heading level. The Figure below illustrates 460 this organization. An entry (row) therefore gives a complete 461 description of a Registered Performance Metric. 463 Each column serves as a check-list item and helps to avoid omissions 464 during registration and expert review. 466 Registry Categories and Columns, shown as 467 Category 468 ------------------ 469 Column | Column | 471 Summary 472 ------------------------------- 473 Identifier | Name | URIs | Description | 475 Metric Definition 476 ----------------------------------------- 477 Reference Definition | Fixed Parameters | 479 Method of Measurement 480 --------------------------------------------------------------------- 481 Reference | Packet | Traffic | Sampling | Run-time | Role | 482 Method | Generation | Filter | Distribution | Parameters | | 483 | Stream | 484 Output 485 ----------------------------- 486 | Type | Reference | Units | 487 | | Definition | | 489 Administrative Information 490 ---------------------------------- 491 Status |Request | Rev | Rev.Date | 493 Comments and Remarks 494 -------------------- 496 7.1. Summary Category 498 7.1.1. Identifier 500 A numeric identifier for the Registered Performance Metric. This 501 identifier MUST be unique within the Performance Metric Registry. 503 The Registered Performance Metric unique identifier is a 16-bit 504 integer (range 0 to 65535). When adding newly Registered Performance 505 Metrics to the Performance Metric Registry, IANA should assign the 506 lowest available identifier to the next Registered Performance 507 Metric. 509 7.1.2. Name 511 As the name of a Registered Performance Metric is the first thing a 512 potential implementor will use when determining whether it is 513 suitable for a given application, it is important to be as precise 514 and descriptive as possible. 516 New names of Registered Performance Metrics: 518 1. "MUST be chosen carefully to describe the Registered Performance 519 Metric and the context in which it will be used." 521 2. "MUST be unique within the Performance Metric Registry." 523 3. "MUST use capital letters for the first letter of each component. 524 All other letters MUST be lowercase, even for acronyms. 525 Exceptions are made for acronyms containing a mixture of 526 lowercase and capital letters, such as 'IPv4' and 'IPv6'." 528 4. MUST use '_' between each component of the Registered Performance 529 Metric name. 531 5. MUST start with prefix Act_ for active measurement Registered 532 Performance Metric. 534 6. MUST start with prefix Pas_ for passive monitoring Registered 535 Performance Metric. 537 7. Other types of Performance Metric should define a proper prefix 538 for identifying the type. 540 8. The remaining rules for naming are left for the Performance 541 Metric Experts to determine as they gather experience, so this is 542 an area of planned update by a future RFC 544 An example is "Act_UDP_Latency_Poisson_mean" for a active monitoring 545 UDP latency metric using a Poisson stream of packets and producing 546 the mean as output. 548 Some examples of names of passive metrics might be: Pas_L3_L4_Octets 549 (Layer 3 and 4 level accounting of bytes observed), Pas_DNS_RTT 550 (Round Trip Time of in DNS query response of observed traffic), and 551 Pas_L3_TCP_RTT (Passively observed round trip time in TCP handshake 552 organized with L3 addresses) 554 7.1.3. URI 556 The URIs column MUST contain a URI [RFC 3986] that uniquely 557 identifies the metric. This URI is a URN [RFC 2141]. The URI is 558 automatically generated by prepending the prefix 559 urn:ietf:params:ippm:metric: to the metric name. The resulting URI 560 is globally unique. 562 The URIs column MUST contain a second URI which is a URL [RFC 3986] 563 and uniquely identifies and locates the metric entry so it is 564 accessible through the Internet. The exact composition of each 565 metric URL will be determined by IANA, but there will be some overlap 566 with the URN described above. 568 7.1.4. Description 570 A Registered Performance Metric description is a written 571 representation of a particular Performance Metrics Registry entry. 572 It supplements the Registered Performance Metric name to help 573 Performance Metrics Registry users select relevant Registered 574 Performance Metrics. 576 7.2. Metric Definition Category 578 This category includes columns to prompt all necessary details 579 related to the metric definition, including the RFC reference and 580 values of input factors, called fixed parameters, which are left open 581 in the RFC but have a particular value defined by the performance 582 metric. 584 7.2.1. Reference Definition 586 This entry provides a reference (or references) to the relevant 587 section(s) of the document(s) that define the metric, as well as any 588 supplemental information needed to ensure an unambiguous definition 589 for implementations. The reference needs to be an immutable 590 document, such as an RFC; for other standards bodies, it is likely to 591 be necessary to reference a specific, dated version of a 592 specification. 594 7.2.2. Fixed Parameters 596 Fixed Parameters are Paremeters whose value must be specified in the 597 Performance Metrics Registry. The measurement system uses these 598 values. 600 Where referenced metrics supply a list of Parameters as part of their 601 descriptive template, a sub-set of the Parameters will be designated 602 as Fixed Parameters. For example, for active metrics, Fixed 603 Parameters determine most or all of the IPPM Framework convention 604 "packets of Type-P" as described in [RFC2330], such as transport 605 protocol, payload length, TTL, etc. An example for passive metrics 606 is for RTP packet loss calculation that relies on the validation of a 607 packet as RTP which is a multi-packet validation controlled by 608 MIN_SEQUENTIAL as defined by [RFC3550]. Varying MIN_SEQUENTIAL 609 values can alter the loss report and this value could be set as a 610 Fixed Parameter 612 A Parameter which is a Fixed Parameter for one Performance Metrics 613 Registry entry may be designated as a Run-time Parameter for another 614 Performance Metrics Registry entry. 616 7.3. Method of Measurement Category 618 This category includes columns for references to relevant sections of 619 the RFC(s) and any supplemental information needed to ensure an 620 unambiguous method for implementations. 622 7.3.1. Reference Method 624 This entry provides references to relevant sections of the RFC(s) 625 describing the method of measurement, as well as any supplemental 626 information needed to ensure unambiguous interpretation for 627 implementations referring to the RFC text. 629 Specifically, this section should include pointers to pseudocode or 630 actual code that could be used for an unambigious implementation. 632 7.3.2. Packet Generation Stream 634 This column applies to Performance Metrics that generate traffic for 635 a part of their Measurement Method purposes including but not 636 necessarily limited to Active metrics. The generated traffic is 637 referred as stream and this columns describe its characteristics. 639 Each entry for this column contains the following information: 641 o Value: The name of the packet stream scheduling discipline 643 o Stream Parameters: The values and formats of input factors for 644 each type of stream. For example, the average packet rate and 645 distribution truncation value for streams with Poisson-distributed 646 inter-packet sending times. 648 o Reference: the specification where the stream is defined 649 The simplest example of stream specification is Singleton scheduling 650 (see [RFC2330]), where a single atomic measurement is conducted. 651 Each atomic measurement could consist of sending a single packet 652 (such as a DNS request) or sending several packets (for example, to 653 request a webpage). Other streams support a series of atomic 654 measurements in a "sample", with a schedule defining the timing 655 between each transmitted packet and subsequent measurement. 656 Principally, two different streams are used in IPPM metrics, Poisson 657 distributed as described in [RFC2330] and Periodic as described in 658 [RFC3432]. Both Poisson and Periodic have their own unique 659 parameters, and the relevant set of values is specified in this 660 column. 662 7.3.3. Traffic Filter 664 This column applies to Performance Metrics that observe packets 665 flowing through (the device with) the measurement agent i.e. that is 666 not necessarily addressed to the measurement agent. This includes 667 but is not limited to Passive Metrics. The filter specifies the 668 traffic that is measured. This includes protocol field values/ 669 ranges, such as address ranges, and flow or session identifiers. 671 The traffic filter itself depends on needs of the metric itself and a 672 balance of operators measurement needs and user's need for privacy. 673 Mechanics for conveying the filter criteria might be the BPF (Berkley 674 Packet Filter) or PSAMP [RFC5475] Property Match Filtering which 675 reuses IPFIX [RFC7012]. An example BPF string for matching TCP/80 676 traffic to remote destination net 192.0.2.0/24 would be "dst net 677 192.0.2.0/24 and tcp dst port 80". More complex filter engines might 678 be supported by the implementation that might allow for matching 679 using Deep Packet Inspection (DPI) technology. 681 The traffic filter includes the following information: 683 Type: the type of traffic filter used, e.g. BPF, PSAMP, OpenFlow 684 rule, etc. as defined by a normative reference 686 Value: the actual set of rules expressed 688 7.3.4. Sampling Distribution 690 The sampling distribution defines out of all the packets that match 691 the traffic filter, which one of those are actually used for the 692 measurement. One possibility is "all" which implies that all packets 693 matching the Traffic filter are considered, but there may be other 694 sampling strategies. It includes the following information: 696 Value: the name of the sampling distribution 697 Parameters: if any. 699 Reference definition: pointer to the specification where the 700 sampling distribution is properly defined. 702 Sampling and Filtering Techniques for IP Packet Selection are 703 documented in the PSAMP (Packet Sampling) [RFC5475], while the 704 Framework for Packet Selection and Reporting, [RFC5474] provides more 705 background information. The sampling distribution parameters might 706 be expressed in terms of the Information Model for Packet Sampling 707 Exports, [RFC5477], and the Flow Selection Techniques, [RFC7014]. 709 7.3.5. Run-time Parameters 711 Run-Time Parameters are Parameters that must be determined, 712 configured into the measurement system, and reported with the results 713 for the context to be complete. However, the values of these 714 parameters is not specified in the Performance Metrics Registry (like 715 the Fixed Parameters), rather these parameters are listed as an aid 716 to the measurement system implementer or user (they must be left as 717 variables, and supplied on execution). 719 Where metrics supply a list of Parameters as part of their 720 descriptive template, a sub-set of the Parameters will be designated 721 as Run-Time Parameters. 723 Examples of Run-time Parameters include IP addresses, measurement 724 point designations, start times and end times for measurement, and 725 other information essential to the method of measurement. 727 7.3.6. Role 729 In some method of measurements, there may be several roles defined 730 e.g. on a one-way packet delay active measurement, there is one 731 measurement agent that generates the packets and the other one that 732 receives the packets. This column contains the name of the role for 733 this particular entry. In the previous example, there should be two 734 entries in the registry, one for each role, so that when a 735 measurement agent is instructed to perform the one way delay source 736 metric know that it is supposed to generate packets. The values for 737 this field are defined in the reference method of measurement. 739 7.4. Output Category 741 For entries which involve a stream and many singleton measurements, a 742 statistic may be specified in this column to summarize the results to 743 a single value. If the complete set of measured singletons is 744 output, this will be specified here. 746 Some metrics embed one specific statistic in the reference metric 747 definition, while others allow several output types or statistics. 749 7.4.1. Type 751 This column contain the name of the output type. The output type 752 defines the type of result that the metric produces. It can be the 753 raw results or it can be some form of statistic. The specification 754 of the output type must define the format of the output. In some 755 systems, format specifications will simplify both measurement 756 implementation and collection/storage tasks. Note that if two 757 different statistics are required from a single measurement (for 758 example, both "Xth percentile mean" and "Raw"), then a new output 759 type must be defined ("Xth percentile mean AND Raw"). 761 7.4.2. Reference Definition 763 This column contains a pointer to the specification where the output 764 type is defined 766 7.4.3. Metric Units 768 The measured results must be expressed using some standard dimension 769 or units of measure. This column provides the units. 771 When a sample of singletons (see [RFC2330] for definitions of these 772 terms) is collected, this entry will specify the units for each 773 measured value. 775 7.5. Administrative information 777 7.5.1. Status 779 The status of the specification of this Registered Performance 780 Metric. Allowed values are 'current' and 'deprecated'. All newly 781 defined Information Elements have 'current' status. 783 7.5.2. Requester 785 The requester for the Registered Performance Metric. The requester 786 MAY be a document, such as RFC, or person. 788 7.5.3. Revision 790 The revision number of a Registered Performance Metric, starting at 0 791 for Registered Performance Metrics at time of definition and 792 incremented by one for each revision. 794 7.5.4. Revision Date 796 The date of acceptance or the most recent revision for the Registered 797 Performance Metric. 799 7.6. Comments and Remarks 801 Besides providing additional details which do not appear in other 802 categories, this open Category (single column) allows for unforeseen 803 issues to be addressed by simply updating this informational entry. 805 8. The Life-Cycle of Registered Performance Metrics 807 Once a Performance Metric or set of Performance Metrics has been 808 identified for a given application, candidate Performance Metrics 809 Registry entry specifications in accordance with Section 7 are 810 submitted to IANA to follow the process for review by the Performance 811 Metric Experts, as defined below. This process is also used for 812 other changes to the Performance Metric Registry, such as deprecation 813 or revision, as described later in this section. 815 It is also desirable that the author(s) of a candidate Performance 816 Metrics Registry entry seek review in the relevant IETF working 817 group, or offer the opportunity for review on the WG mailing list. 819 8.1. Adding new Performance Metrics to the Performance Metrics Registry 821 Requests to change Registered Performance Metrics in the Performance 822 Metric Registry are submitted to IANA, which forwards the request to 823 a designated group of experts (Performance Metric Experts) appointed 824 by the IESG; these are the reviewers called for by the Expert Review 825 RFC5226 policy defined for the Performance Metric Registry. The 826 Performance Metric Experts review the request for such things as 827 compliance with this document, compliance with other applicable 828 Performance Metric-related RFCs, and consistency with the currently 829 defined set of Registered Performance Metrics. 831 Authors are expected to review compliance with the specifications in 832 this document to check their submissions before sending them to IANA. 834 The Performance Metric Experts should endeavor to complete referred 835 reviews in a timely manner. If the request is acceptable, the 836 Performance Metric Experts signify their approval to IANA, which 837 updates the Performance Metric Registry. If the request is not 838 acceptable, the Performance Metric Experts can coordinate with the 839 requester to change the request to be compliant. The Performance 840 Metric Experts may also choose in exceptional circumstances to reject 841 clearly frivolous or inappropriate change requests outright. 843 This process should not in any way be construed as allowing the 844 Performance Metric Experts to overrule IETF consensus. Specifically, 845 any Registered Performance Metrics that were added with IETF 846 consensus require IETF consensus for revision or deprecation. 848 Decisions by the Performance Metric Experts may be appealed as in 849 Section 7 of RFC5226. 851 8.2. Revising Registered Performance Metrics 853 A request for Revision is only permissible when the changes maintain 854 backward-compatibility with implementations of the prior Performance 855 Metrics Registry entry describing a Registered Performance Metric 856 (entries with lower revision numbers, but the same Identifier and 857 Name). 859 The purpose of the Status field in the Performance Metric Registry is 860 to indicate whether the entry for a Registered Performance Metric is 861 'current' or 'deprecated'. 863 In addition, no policy is defined for revising IANA Performance 864 Metric entries or addressing errors therein. To be certain, changes 865 and deprecations within the Performance Metric Registry are not 866 encouraged, and should be avoided to the extent possible. However, 867 in recognition that change is inevitable, the provisions of this 868 section address the need for revisions. 870 Revisions are initiated by sending a candidate Registered Performance 871 Metric definition to IANA, as in Section 8, identifying the existing 872 Performance Metrics Registry entry. 874 The primary requirement in the definition of a policy for managing 875 changes to existing Registered Performance Metrics is avoidance of 876 interoperability problems; Performance Metric Experts must work to 877 maintain interoperability above all else. Changes to Registered 878 Performance Metrics may only be done in an inter-operable way; 879 necessary changes that cannot be done in a way to allow 880 interoperability with unchanged implementations must result in the 881 creation of a new Registered Performance Metric and possibly the 882 deprecation of the earlier metric. 884 A change to a Registered Performance Metric is held to be backward- 885 compatible only when: 887 1. "it involves the correction of an error that is obviously only 888 editorial; or" 890 2. "it corrects an ambiguity in the Registered Performance Metric's 891 definition, which itself leads to issues severe enough to prevent 892 the Registered Performance Metric's usage as originally defined; 893 or" 895 3. "it corrects missing information in the metric definition without 896 changing its meaning (e.g., the explicit definition of 'quantity' 897 semantics for numeric fields without a Data Type Semantics 898 value); or" 900 4. "it harmonizes with an external reference that was itself 901 corrected." 903 If an Performance Metric revision is deemed permissible by the 904 Performance Metric Experts, according to the rules in this document, 905 IANA makes the change in the Performance Metric Registry. The 906 requester of the change is appended to the requester in the 907 Performance Metrics Registry. 909 Each Registered Performance Metric in the Performance Metrics 910 Registry has a revision number, starting at zero. Each change to a 911 Registered Performance Metric following this process increments the 912 revision number by one. 914 When a revised Registered Performance Metric is accepted into the 915 Performance Metric Registry, the date of acceptance of the most 916 recent revision is placed into the revision Date column of the 917 registry for that Registered Performance Metric. 919 Where applicable, additions to Registered Performance Metrics in the 920 form of text Comments or Remarks should include the date, but such 921 additions may not constitute a revision according to this process. 923 Older version(s) of the updated metric entries are kept in the 924 registry for archival purposes. The older entries are kept with all 925 fields unmodified (version, revision date) except for the status 926 field that is changed to "Deprecated". 928 8.3. Deprecating Registered Performance Metrics 930 Changes that are not permissible by the above criteria for Registered 931 Performance Metric's revision may only be handled by deprecation. A 932 Registered Performance Metric MAY be deprecated and replaced when: 934 1. "the Registered Performance Metric definition has an error or 935 shortcoming that cannot be permissibly changed as in 936 Section Revising Registered Performance Metrics; or" 938 2. "the deprecation harmonizes with an external reference that was 939 itself deprecated through that reference's accepted deprecation 940 method; or" 942 A request for deprecation is sent to IANA, which passes it to the 943 Performance Metric Expert for review. When deprecating an 944 Performance Metric, the Performance Metric description in the 945 Performance Metric Registry must be updated to explain the 946 deprecation, as well as to refer to any new Performance Metrics 947 created to replace the deprecated Performance Metric. 949 The revision number of a Registered Performance Metric is incremented 950 upon deprecation, and the revision Date updated, as with any 951 revision. 953 The use of deprecated Registered Performance Metrics should result in 954 a log entry or human-readable warning by the respective application. 956 Names and Metric ID of deprecated Registered Performance Metrics must 957 not be reused. 959 The deprecated entries are kept with all fields unmodified, except 960 the version, revision date, and the status field (changed to 961 "Deprecated"). 963 9. Security considerations 965 This draft doesn't introduce any new security considerations for the 966 Internet. However, the definition of Performance Metrics may 967 introduce some security concerns, and should be reviewed with 968 security in mind. 970 10. IANA Considerations 972 This document specifies the procedure for Performance Metrics 973 Registry setup. IANA is requested to create a new registry for 974 Performance Metrics called "Registered Performance Metrics" with the 975 columns defined in Section 7. 977 New assignments for Performance Metric Registry will be administered 978 by IANA through Expert Review [RFC5226], i.e., review by one of a 979 group of experts, the Performance Metric Experts, appointed by the 980 IESG upon recommendation of the Transport Area Directors. The 981 experts can be initially drawn from the Working Group Chairs and 982 document editors of the Performance Metrics Directorate among other 983 sources of experts. 985 The Identifier values from 64512 to 65536 are reserved for private 986 use. The name starting with the prefix Priv- are reserved for 987 private use. 989 This document requests the allocation of the URI prefix 990 urn:ietf:params:ippm:metric for the purpose of generating URIs for 991 Registered Performance Metrics. 993 11. Acknowledgments 995 Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading 996 some brainstorming sessions on this topic. 998 12. References 1000 12.1. Normative References 1002 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1003 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1004 . 1006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1007 Requirement Levels", BCP 14, RFC 2119, 1008 DOI 10.17487/RFC2119, March 1997, 1009 . 1011 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1012 May 1997, . 1014 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1015 "Framework for IP Performance Metrics", RFC 2330, 1016 DOI 10.17487/RFC2330, May 1998, 1017 . 1019 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1020 Resource Identifier (URI): Generic Syntax", STD 66, 1021 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1022 . 1024 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1025 Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 1026 2005, . 1028 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1029 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1030 DOI 10.17487/RFC5226, May 2008, 1031 . 1033 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 1034 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 1035 DOI 10.17487/RFC6248, April 2011, 1036 . 1038 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1039 Performance Metric Development", BCP 170, RFC 6390, 1040 DOI 10.17487/RFC6390, October 2011, 1041 . 1043 [RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, 1044 "IP Performance Metrics (IPPM) Standard Advancement 1045 Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 1046 2012, . 1048 12.2. Informative References 1050 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1051 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1052 September 1999, . 1054 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1055 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1056 September 1999, . 1058 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1059 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1060 DOI 10.17487/RFC3393, November 2002, 1061 . 1063 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1064 performance measurement with periodic streams", RFC 3432, 1065 DOI 10.17487/RFC3432, November 2002, 1066 . 1068 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1069 Jacobson, "RTP: A Transport Protocol for Real-Time 1070 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1071 July 2003, . 1073 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 1074 "RTP Control Protocol Extended Reports (RTCP XR)", 1075 RFC 3611, DOI 10.17487/RFC3611, November 2003, 1076 . 1078 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1079 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1080 July 2006, . 1082 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 1083 Grossglauser, M., and J. Rexford, "A Framework for Packet 1084 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 1085 March 2009, . 1087 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 1088 Raspall, "Sampling and Filtering Techniques for IP Packet 1089 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 1090 . 1092 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1093 Carle, "Information Model for Packet Sampling Exports", 1094 RFC 5477, DOI 10.17487/RFC5477, March 2009, 1095 . 1097 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1098 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 1099 March 2009, . 1101 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1102 "Network Time Protocol Version 4: Protocol and Algorithms 1103 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1104 . 1106 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, 1107 "Session Initiation Protocol Event Package for Voice 1108 Quality Reporting", RFC 6035, DOI 10.17487/RFC6035, 1109 November 2010, . 1111 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 1112 Reporting Using a Source Description (SDES) Item and an 1113 RTCP Extended Report (XR) Block", RFC 6776, 1114 DOI 10.17487/RFC6776, October 2012, 1115 . 1117 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 1118 of the RTP Monitoring Framework", RFC 6792, 1119 DOI 10.17487/RFC6792, November 2012, 1120 . 1122 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 1123 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 1124 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 1125 September 2013, . 1127 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1128 for IP Flow Information Export (IPFIX)", RFC 7012, 1129 DOI 10.17487/RFC7012, September 2013, 1130 . 1132 [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow 1133 Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, 1134 September 2013, . 1136 [I-D.ietf-lmap-framework] 1137 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1138 Aitken, P., and A. Akhter, "A framework for Large-Scale 1139 Measurement of Broadband Performance (LMAP)", draft-ietf- 1140 lmap-framework-14 (work in progress), April 2015. 1142 [I-D.ietf-ippm-active-passive] 1143 Morton, A., "Active and Passive Metrics and Methods (and 1144 everything in-between, or Hybrid)", draft-ietf-ippm- 1145 active-passive-00 (work in progress), June 2015. 1147 Authors' Addresses 1149 Marcelo Bagnulo 1150 Universidad Carlos III de Madrid 1151 Av. Universidad 30 1152 Leganes, Madrid 28911 1153 SPAIN 1155 Phone: 34 91 6249500 1156 Email: marcelo@it.uc3m.es 1157 URI: http://www.it.uc3m.es 1159 Benoit Claise 1160 Cisco Systems, Inc. 1161 De Kleetlaan 6a b1 1162 1831 Diegem 1163 Belgium 1165 Email: bclaise@cisco.com 1166 Philip Eardley 1167 BT 1168 Adastral Park, Martlesham Heath 1169 Ipswich 1170 ENGLAND 1172 Email: philip.eardley@bt.com 1174 Al Morton 1175 AT&T Labs 1176 200 Laurel Avenue South 1177 Middletown, NJ 1178 USA 1180 Email: acmorton@att.com 1182 Aamer Akhter 1183 Consultant 1184 118 Timber Hitch 1185 Cary, NC 1186 USA 1188 Email: aakhter@gmail.com