idnits 2.17.1 draft-bagnulo-ippm-new-registry-independent-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 329: '...odic sampling, T0 MUST NOT be strictly...' RFC 2119 keyword, line 332: '...Also, the duration of the test MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2013) is 3913 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2679' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 771, 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) ** Downref: Normative reference to an Informational RFC: RFC 5481 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-lmap-path-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ippm-lmap-path (ref. 'I-D.ietf-ippm-lmap-path') -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 6 errors (**), 0 flaws (~~), 6 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 T. Burbridge 5 Expires: January 13, 2014 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 July 12, 2013 14 A registry for commonly used metrics. Independent registries 15 draft-bagnulo-ippm-new-registry-independent-01 17 Abstract 19 This document creates a registry for commonly used metrics, defines 20 the rules for assignments in the new registry and performs initial 21 allocations. This document proposes one particular registry 22 structure with independent registries for each of the fields 23 involved. A companion document draft-bagnulo-ippm-new-registry 24 explores an alternative structure with a single registry with 25 multiple sub-registries. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 13, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. The commonly used metrics registry . . . . . . . . . . . . . . 5 63 2.1. The metrics registry . . . . . . . . . . . . . . . . . . . 5 64 2.2. The Scheduling registry . . . . . . . . . . . . . . . . . 6 65 2.3. The Environment registry . . . . . . . . . . . . . . . . . 7 66 2.4. The Output type registry . . . . . . . . . . . . . . . . . 7 67 3. Initial assignment for the Scheduling registry . . . . . . . . 7 68 3.1. Common parameter definitions . . . . . . . . . . . . . . . 7 69 3.2. Poisson scheduling . . . . . . . . . . . . . . . . . . . . 8 70 3.3. Periodic scheduling . . . . . . . . . . . . . . . . . . . 8 71 3.4. Singleton scheduling . . . . . . . . . . . . . . . . . . . 9 72 4. Initial assignments for the Output Type registry . . . . . . . 9 73 4.1. Raw . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.2. Xth percentile interval . . . . . . . . . . . . . . . . . 9 75 4.3. Xth percentile mean . . . . . . . . . . . . . . . . . . . 10 76 5. Initial assignments for the Environment registry . . . . . . . 10 77 5.1. Undefined . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2. No cross traffic . . . . . . . . . . . . . . . . . . . . . 10 79 6. Initial assignments for the Metric registry . . . . . . . . . 12 80 6.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.2. UDP related metrics . . . . . . . . . . . . . . . . . . . 12 82 6.2.1. Parameters for UDP metrics . . . . . . . . . . . . . . 12 83 6.2.2. Round-trip UDP latency metric . . . . . . . . . . . . 12 84 6.2.3. Round-trip UDP packet-loss metric . . . . . . . . . . 13 85 7. ICMP related metrics . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. ICMP Parameters . . . . . . . . . . . . . . . . . . . . . 13 87 7.2. ICMP packet-loss metric . . . . . . . . . . . . . . . . . 14 88 8. DNS related metrics . . . . . . . . . . . . . . . . . . . . . 14 89 8.1. DNS parameters . . . . . . . . . . . . . . . . . . . . . . 14 90 8.2. DNS latency metric . . . . . . . . . . . . . . . . . . . . 15 91 9. Some examples of measurement plans . . . . . . . . . . . . . . 16 92 10. Security considerations . . . . . . . . . . . . . . . . . . . 17 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 97 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 This document creates a registry for commonly used metrics. In order 103 to do that, it creates a number of namespaces whose values will be 104 recorded by the registry and will uniquely and precisely identify 105 metrics. 107 The motivation for having such registry is to allow a controller to 108 request a measurement agent to execute a measurement using a specific 109 metric. Such request can be performed using any control protocol 110 that refers to the value assigned to the specific metric in the 111 registry. Similarly, the measurement agent can report the results of 112 the measurement and by referring to the metric value it can 113 unequivocally identify the metric that the results correspond to. 115 There was a previous attempt to define a metric registry RFC 4148 116 [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because 117 it was "found to be insufficiently detailed to uniquely identify IPPM 118 metrics... [there was too much] variability possible when 119 characterizing a metric exactly" which led to the RFC4148 registry 120 having "very few users, if any". 122 Our approach learns from this, by tightly defining each entry in the 123 registry with only a few parameters open for each. The idea is that 124 the entries in the registry represent different measurement tests, 125 whilst the parameters set things like source and destination 126 addresses that don't change the fundamental nature of the test. The 127 downside of this approach is that it could result in an explosion in 128 the number of entries in the registry. We believe that less is more 129 in this context - it is better to have a reduced set of useful 130 metrics rather than a large set of metrics with questionable 131 usefulness. Therefore this document defines that the registry only 132 includes commonly used metrics that are well defined; hence we 133 require both specification required AND expert review policies for 134 the assignment of values in the registry. 136 There are a couple of side benefits of having such registry. First 137 the registry could serve as an inventory of useful and used metrics, 138 that are normally supported by different implementations of 139 measurement agents. Second, the results of the metrics would be 140 comparable even if they are performed by different implementations 141 and in different networks, as the metric is properly defined. 143 This version of the document defines a set of independent registries, 144 that limits the explosion of registry entries by allowing arbitrary 145 combinations of entries in the different entries. The downside is 146 that the list of useful metrics is less defined, as any combination 147 would be defined. Which approach is better is up for discussion. 149 The registry forms part of an Instruction {as defined in the proposed 150 terminology memo, draft-eardley-lmap-terminology-02}. It describes 151 various factors that need to be set by the party controlling the 152 measurements, for example: specific values for the parameters 153 associated with the selected registry entry (for instance, source and 154 destination addresses); and how often the measurement is made. The 155 Instruction might look something like: "Dear measurement agent: 156 Please start test DNS(example.com) and RTT(server.com,150) every day 157 at 2000 GMT. Run the DNS test 5 times and the RTT test 50 times. Do 158 that when the network is idle. Generate both raw results and 99th 159 percentile mean. Send measurement results to collector.com in IPFIX 160 format". The Instruction depends on the requirements of the 161 controlling party. For instance the broadband consumer might want a 162 one-off measurement made immediately to one specific server; a 163 regulator might want the same measurement made once a day until 164 further notice to the 'top 10' servers; whilst an operator might want 165 a varying series of tests (some of which will be beyond those defined 166 in the registry) as determined from time to time by their operational 167 support system. While the registries defined in this document help 168 to define the Instruction its full specification falls outside the 169 scope of this document. 171 2. The commonly used metrics registry 173 In this section we define the registry for commonly used metrics. It 174 is composed by the following sub-registries: 175 o Scheduling registry 176 o Environment registry 177 o Output-type registry 178 o Metric registry 180 The rationale for the registry structure is to allow flexibility but 181 yet precise definition of metrics. The metric registry defines the 182 metric itself while the other registries define additional aspects 183 that are needed for the measurement plan and that are needed to fully 184 specify a measurement request from a controller to a measurement 185 agent. 187 2.1. The metrics registry 189 The metrics registry contains two categories of metrics: 191 1. Where a relevant metric specification exists, the Registry relies 192 on a reference to one or more specifications where the required 193 information can be found. 195 2. Where the Registry defines new metrics, the specifications 196 provided follow the format defined in RFC 6390 [RFC6390] (with 197 some exceptions noted below). Also, if the Registry relies on 198 specifications that contain rich options or non-specific 199 concepts, then the Registry will define a very tight 200 specification, essentially a new metric. 201 Each Registry entry for new metrics (as described above contain the 202 following information, based on the Normative sections recommended in 203 RFC 6390 [RFC6390]: 204 o Metric Name: A text string that uniquely identifies the metric. 205 o Metric Definition: The concise specification of the quantity 206 assessed by the metric. 207 o Method of Measurement or calculation: 208 o Units of Measurement. 209 o Measurement Accuracy: Required accuracy, including calibration and 210 identification of errors and uncertainties. 211 o Discussion: Any additional information, such as the recommended 212 range of measurement intervals or sample sizes, restrictions on 213 measurement points if applicable, and other specific guidance. 215 Ideally, metrics can be applied at any relevant test point, so the 216 Registry leaves measurement points as an open parameter (omitting the 217 "Measurement Point(s) with potential Measurement Domain" section from 218 RFC 6390 [RFC6390]). A canonical reference path is defined in 219 [I-D.ietf-ippm-lmap-path]. 221 The policy for the assignments in the metric registry is both 222 specification required AND expert review. This means that in order 223 to create an entry for the metric value a specification defining the 224 metric is required and when that happens, the request for allocation 225 will be reviewed by an expert. 227 The specification must define the input parameters for the metric as 228 well as the output of the metric. The metric must be well defined, 229 in the sense that two independent implementations must produce 230 uniform and comparable results. 232 The expert review must make sure that the proposed metric is 233 operationally useful. This means that the metric has proven to be 234 useful in operational/real scenarios. 236 2.2. The Scheduling registry 238 Each entry for the scheduling registry contain the following 239 information: 240 o Value: The name of the scheduling 241 o Reference: the specification where the scheduling is defined 243 The scheduling defines the scheduling strategy for the metric. 244 Simplest is Singleton scheduling, where an atomic measurement is 245 made. Other strategies make a series of atomic measurements in a 246 "sample" or "stream", with the schedule defining the timing between 247 each distinct measurement. Each atomic measurement could consist of 248 sending a single packet (such as a DNS request) or sending several 249 packets (for example a webpage). A scheduling strategy requires 250 input parameter(s). Assignment in this registry follows the 251 specification required policy. 253 2.3. The Environment registry 255 Each entry for the environment registry contain the following 256 information: 257 o Value: The name of the environment 258 o Reference: the specification where the environment is defined 260 The environment defines the conditions where the metric is expected 261 to be used. It does not define the metric itself, but the context 262 where the metric is executed. Assignment in this registry follows 263 the specification required policy. 265 2.4. The Output type registry 267 Each entry for the output type registry contain the following 268 information: 269 o Value: The name of the output type 270 o Reference: the specification where the output type is defined 272 The output type define the type of output that the metric produces. 273 It can be the raw results or it can be some form of statistic. 274 Assignment in this registry follows the specification required 275 policy. The specification of the output type must define the format 276 of the output. 278 3. Initial assignment for the Scheduling registry 280 3.1. Common parameter definitions 282 Although each IPPM RFC defines individual parameters and uses them 283 consistently, the parameter names are not completely consistent 284 across the RFC set. For example, the variable "dT" is used in 285 several different ways. This memo uses one set of parameter names, 286 and the reader is cautioned to map the names according to their 287 definitions. 289 We define some parameters that are used by several types of 290 scheduling: 292 o T0: time to begin a test 293 o Tf: time to end a test 294 T0 and Tf are both in seconds and use the date (yyyy-mm-dd) and NTP 295 64 bit timestamp. T0 includes any control handshaking before the 296 test stream or singleton. Tf is the time the last test data is sent. 298 As a result, we have: 300 o Time when test devices may close the test socket: Tf + Waiting 301 Time (the time to wait before declaring a packet lost is fixed for 302 each metric) 303 o Total duration of the test: Tf - T0 + Waiting Time 305 3.2. Poisson scheduling 307 The values for this entry are as follows: 308 o Value: Poisson 309 o Reference: draft-bagnulo-ippm-new-registry 311 The Poisson scheduling is defined in section 11.1.1 of RFC 2330 312 [RFC2330] and needs input parameters: 314 o T0 and Tf: defined above 315 o lambda: the parameter defining the Poisson distribution. Lambda 316 is the mean number of distinct measurements per second in the 317 sample. 319 3.3. Periodic scheduling 321 The values for this entry are as follows: 322 o Value: Periodic 323 o Reference: draft-bagnulo-ippm-new-registry 325 The Periodic sampling is defined in RFC 3432 [RFC3432]. The 326 additional input parameters for the metric required by Periodic 327 scheduling are: 328 o T0 and Tf: defined above 329 * Note that with Periodic sampling, T0 MUST NOT be strictly 330 periodic with other tests of the same type. RFC 3432 [RFC3432] 331 requires randomized start times and describes one way to 332 accomplish this. Also, the duration of the test MUST be 333 limited. 334 o incT: the time in seconds between one distinct event and the next, 335 where events typically result in repeating singleton measurements 336 of various types (illustrated below). 338 * for a periodic stream this is the time between packets in the 339 sample, first bit to first bit 340 * for measurements on a process this is the time between the 341 first packets of the process, for example first bit to first 342 bit of the SYN in a TCP 3-way handshake 344 3.4. Singleton scheduling 346 The values for this entry are as follows: 347 o Value: singleton 348 o Reference: draft-bagnulo-ippm-new-registry 350 The singleton scheduling covers the case when an atomic metric is 351 performed as per RFC 2330 [RFC2330]. The additional input parameter 352 for the metric required by Singleton scheduling is: 354 o T0: defined above 356 4. Initial assignments for the Output Type registry 358 4.1. Raw 360 The values for this entry are as follows: 361 o Value: Raw 362 o Reference: draft-bagnulo-ippm-new-registry 364 The results of the metric are delivered in the exact way they are 365 produced by the measurements without any further processing or 366 filtering. 368 4.2. Xth percentile interval 370 The values for this entry are as follows: 371 o Value: Xth-percentile 372 o Reference: draft-bagnulo-ippm-new-registry 374 The additional input parameter for the metric is: 376 o X: the percentile (e.g, if the X input parameter is 99, then the 377 output will be the 99th percentile interval.) 378 The output when using this Output type will be a couple of values, 379 expressed in the same units as the raw output, that is the Xth 380 percentile interval, as defined in section 1.3 of RFC 2330 [RFC2330]. 382 4.3. Xth percentile mean 384 The values for this entry are as follows: 385 o Value: Xth-percentile-mean 386 o Reference: draft-bagnulo-ippm-new-registry 388 The additional input parameter for the metric is 390 o X: the percentile (e.g, if the X input parameter is 99, then the 391 output will be the 99th percentile mean.) 392 The output when using this Output type will be a single value, 393 expressed in the same units as the raw output, that is the mean of 394 the sample only considering the values contained in the Xth 395 percentile interval, as defined in RFC 2330 [RFC2330]. 397 5. Initial assignments for the Environment registry 399 5.1. Undefined 401 The values for this entry are as follows: 402 o Value: Undefined 403 o Reference: draft-bagnulo-ippm-new-registry 405 The undefined environment is the case where no additional environment 406 settings are defined to perform the metric. 408 5.2. No cross traffic 410 The values for this entry are as follows: 411 o Value: No-cross-traffic 412 o Reference: draft-bagnulo-ippm-new-registry 414 It is often important that there is no other traffic than the one 415 generated by the measurement itself while doing the measurement. The 416 reasons for this are two-folded, first, it is sometimes important 417 that the traffic created by the measurement doesn't impact the 418 experience of the users of the measured resource. Second it is 419 sometimes important that no other traffic interferes with the 420 measurement. This can be ensured by checking that the level of user 421 traffic is either zero or low enough to be confident that it won't 422 impact or be impacted by the measurement. 424 The "No cross traffic" condition is satisfied when, during the 5 425 seconds preceding measurement of the metric: 426 o the level of traffic flowing through the interface that will be 427 used to send measurement packets in either direction is less than 428 a threshold value of 1% of the line rate of the aforementioned 429 interface. 431 The "cross traffic" measurement is made at the interface, associated 432 with the measurement agent, that user traffic flows across. For 433 example, if the probe is attached to the home gateway, then the 434 interface is the service demarcation point where the subscriber 435 connects their private equipment or network to the subscribed 436 service. 438 Note that the No-cross traffic condition is defined only for the link 439 directly attached to the measurement agent initiating the 440 measurement. There is nothing mentioned about cross traffic on other 441 parts of the path used by measurement packets. In the case the 442 bottleneck of the path is other link than the one directly attached 443 to the device running the measurement agent, it may affect and be 444 affected by the measurement even if the No cross traffic as defined 445 here holds. 447 DISCUSSION 449 o It is not clear we need a registry for this. If the only thing we 450 are going to define is the No cross traffic condition, we can 451 simply set it as an input parameter in each metric. 452 o clarify whether traffic for each direction is less than threshold, 453 or the sum 454 o current SamKnows probes measure cross-traffic before the 455 measurement of the metric. Another approach would be to measure 456 cross-traffic during the time the metric is measured. Or a hybrid 457 approach. These would either be separate environment entries, or 458 parameterise the existing one. 459 o current SamKnows probes define a fixed threshold. It could be a 460 parameter 461 o could ignore broadcast traffic (think SamKnows includes) 462 o It would be possible to define this a bit more precisely as 463 follows: 464 * The "No cross-traffic" condition is defined for active 465 measurements. The measurement agent runs in a device that has 466 one or more interfaces. In active measurements, the 467 measurement agent sends one or more packets. Lets call if0 the 468 interface through with the packets resulting from the 469 measurement are sent through. The no cross traffic condition 470 is fulfilled when during the 5 seconds prior sending each of 471 the packets of the measurement: 472 + The traffic incoming through if0 that does not belong to the 473 measurement is lower than 1% of the line rate of if0 474 + The traffic coming through the rest of the interfaces 475 towards if0 is less than 1% of the line rate of if0. 477 6. Initial assignments for the Metric registry 479 6.1. Comment 481 Need to work through that we only define T0 and Tf (and not T, dT). 483 6.2. UDP related metrics 485 6.2.1. Parameters for UDP metrics 487 RFC 2681 [RFC2681] defines a Round-trip delay metric and RFC 6673 488 [RFC6673] defines a Round-trip packet loss metric. We build on these 489 two metrics by specifying several of the open parameters to precisely 490 define several metrics for measuring UDP latency and packet loss. 491 All the UDP related metrics defined in this section use the 492 following: 494 Type-P: 495 o IPv4 header values: 496 * DSCP: set to 0 497 * TTL set to 255 498 * Protocol: Set to 17 (UDP) 499 o UDP header values: 500 * Checksum: the checksum must be calculated 501 o Payload 502 * Sequence number: 8-byte integer 503 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 504 as per section 6 of RFC 5905 [RFC5905] 505 * No padding 507 Timeout: 3 seconds waiting time threshold for packet arrival 509 6.2.2. Round-trip UDP latency metric 511 We define the UDP latency metric as follows: 512 o Metric Name: RT_UDP_Latency 513 o Metric Definition: The metric is defined in section 2.4 of RFC 514 2681 [RFC2681] with the Type-P and timeout value being the ones 515 defined in Section 6.2.1 of this document. 516 o Method of Measurement or calculation: The method is defined in 517 section 2.6 of RFC 2681 [RFC2681]. 518 o Units of Measurement: Defined in section 2.3 of RFC 2681 519 [RFC2681]. 520 o Measurement Accuracy: Measurement timing considerations are 521 described in section 2.5 of RFC 2681 [RFC2681] and section 2.7 of 522 RFC 2681 [RFC2681]. 524 The input parameters for this metric are: 526 o Source IP Address 527 o Destination IP Address 528 o Source UDP port 529 o Destination UDP port 530 o Measurement point nomenclature from the reference path defined in 531 [I-D.ietf-ippm-lmap-path] 532 o Time 534 The output of this metric is the couple of values formed by the 535 timestamp of the sent packet and the time when the echo was received. 536 They are expressed in milliseconds and use the date (yyyy-mm-dd) and 537 NTP 64 bit timestamp 539 6.2.3. Round-trip UDP packet-loss metric 541 We define the Round-trip UDP packet-loss metric as follows: 542 o Metric Name: RT_UDP_packet_loss. 543 o Metric Definition: This metric is defined in section 4.3 of RFC 544 6673 [RFC6673] using the Type-P and Timeout defined in 545 Section 6.2.1 of this document. 546 o Method of Measurement or calculation: The method is defined in 547 section 4.4 of RFC 6673 [RFC6673]. 548 o Units of Measurement. The units are defined in section 4.3 of RFC 549 6673 [RFC6673] 550 o Measurement Accuracy: Timing considerations are discussed in 551 section 4.3 of RFC 6673 [RFC6673]. 553 The input parameters for this metric are: 554 o Source IP Address 555 o Destination IP Address 556 o Source UDP port 557 o Destination UDP port 558 o Measurement point nomenclature from the reference path defined in 559 [I-D.ietf-ippm-lmap-path] 560 o Time T 562 The output of this metric is a single value 0 (packet was lost) or 1 563 (packet has arrived before timeout) 565 7. ICMP related metrics 567 7.1. ICMP Parameters 569 RFC 6673 [RFC6673] defines a Round-trip packet loss metric. We build 570 on that metrics by specifying several of the open parameters to 571 precisely define a metric for measuring ICMP packet loss. The ICMP 572 related metric defined in this document use the following: 574 P-Type: 575 o IPv4 header values: 576 * DSCP: set to 0 577 * TTL set to 255 578 * Protocol: Set to 1 (ICMP) 579 o ICMP header values: 580 * Type: 8 (Echo request) 581 * Code: 0 583 Observation: reply packets will contain an ICMP type of 0 Echo reply. 585 Timeout: 3 seconds 587 7.2. ICMP packet-loss metric 589 We define the ICMP packet-loss metric as follows: 590 o Metric Name: ICMP_packet_loss. 591 o Metric Definition: This metric is defined in section 4.3 of RFC 592 6673 [RFC6673] using the Type-P and Timeout defined in Section 7.1 593 of this document. 594 o Method of Measurement or calculation: The method is defined in 595 section 4.4 of RFC 6673 [RFC6673]. 596 o Units of Measurement. The units are defined in section 4.3 of RFC 597 6673 [RFC6673] 598 o Measurement Accuracy: Timing considerations are discussed in 599 section 4.3 of RFC 6673 [RFC6673]. 601 The input parameters for this metric are: 602 o Source IP Address 603 o Destination IP Address 604 o Measurement point nomenclature from the reference path defined in 605 [I-D.ietf-ippm-lmap-path] 606 o Time T 608 The output of this metric is a single value 0 (packet was lost) or 1 609 (packet has arrived before timeout) 611 8. DNS related metrics 613 8.1. DNS parameters 615 RFC 2681 [RFC2681] defines a Round-trip delay metric. We build on 616 that metric by specifying several of the open parameters to precisely 617 define a metric for measuring DNS latency. The metric uses the 618 following parameters: 620 P-Type: 622 o IPv4 header values: 623 * DSCP: set to 0 624 * TTL set to 255 625 * Protocol: Set to 17 (UDP) 626 o UDP header values: 627 * Source port: 53 628 * Destination port: 53 629 * Checksum: the checksum must be calculated 630 o Payload: The payload contains a DNS message as defined in RFC 1035 631 [RFC1035] with the following values: 632 * The DNS header section contains: 633 + QR: set to 0 (Query) 634 + OPCODE: set to 0 (standard query) 635 + AA: not set 636 + TC: not set 637 + RD: set to one (recursion desired) 638 + RA: not set 639 + RCODE: not set 640 + QDCOUNT: set to one (only one entry) 641 + ANCOUNT: not set 642 + NSCOUNT: not set 643 + ARCOUNT: not set 644 * The Question section contains: 645 + QNAME: the FQDN provided as input for the test 646 + QTYPE: the query type provided as input for the test 647 + QCLASS: set to IN 648 * The other sections do not contain any Resource Records. 650 Observation: reply packets will contain a DNS response and may 651 contain RRs. 653 Timeout: 3 seconds 655 8.2. DNS latency metric 657 We define the DNS latency metric as follows: 658 o Value: DNS_Latency 659 o Reference: draft-bagnulo-ippm-new-registry 660 o Metric Name: DNS_Latency 661 o Metric Definition: The metric is defined in section 2.4 of RFC 662 2681 [RFC2681] with the Type-P and timeout value being the ones 663 defined in Section 8.1 of this document. 664 o Method of Measurement or calculation: The method is defined in 665 section 2.6 of RFC 2681 [RFC2681]. 666 o Units of Measurement: Defined in section 2.3 of RFC 2681 667 [RFC2681]. 669 o Measurement Accuracy: Measurement timing considerations are 670 described in section 2.5 of RFC 2681 [RFC2681]. 672 The input parameters for this metric are: 673 o Source IP Address 674 o Destination IP Address (the address of the DNS server to be 675 tested) 676 o Measurement point nomenclature from the reference path defined in 677 [I-D.ietf-ippm-lmap-path] 678 o QTYPE: A RR 679 o FQDN: a valid FQDN that will be queried for. 680 o Time T 682 The output of this metric is the timestamp when the packet was sent 683 and the delay that it took to receive a response. Please note that 684 any DNS response is valid, including no records in the answer. 685 (Should we be more explicit about what is the output when there is no 686 reply packet received?) 688 9. Some examples of measurement plans 690 A measurement plan will be characterized by the following tuple: 691 (Metric, environment, scheduling, output format). We will next 692 present some measurement plans that are currently used. 694 A measurement plan for measuring the 99th percentile interval of the 695 UDP latency without cross traffics, using a Poisson stream with rate 696 l pkts/sec, stating at time T0 and ending at Tf seconds, between 697 source IP address IPs and source port Ps and destination IP address 698 IPd and destination port Pd would be expressed as: 699 (RT_UDP_Latency(IPs,Ps,IPd,Pd), No-cross-traffic, 700 Poisson(T0,Tf,l), Xth-percentile(99)) 702 A measurement plan for measuring the UDP packet loss ration without 703 cross traffics, using a Poisson stream with rate l pkts/sec, stating 704 at time T0 and ending at Tf seconds, between source IP address IPs 705 and source port Ps and destination IP address IPd and destination 706 port Pd would be expressed as: 707 (RT_UDP_Packet_Loss(IPs,Ps,IPd,Pd), No-cross-traffic, 708 Poisson(T0,Tf,l), Xth-percentile-mean(100)) 710 A measurement plan for measuring the ICMP packet loss ratio, using a 711 Periodic stream s second between packets, stating at time T0 and 712 ending at Tf seconds, between source IP address IPs and destination 713 IP address IPd would be expressed as: 715 (ICMP_Packet_Loss(IPs,IPd), Undefined, Periodic(T0,Tf,s), Xth- 716 percentile-mean(100)) 718 A measurement plan for measuring the DNS latency for resolving FQDN 719 foo.com between a resolver in IP address IPs and a server with 720 address IPd at time T would be expressed as: 721 (DNS_Latency(IPs,IPd,foo.com), Undefined, Singleton(T), raw) 723 10. Security considerations 725 TBD 727 11. IANA Considerations 729 TBD 731 12. Acknowledgments 733 We would like to thank Henning Schulzrinne for many constructive 734 comments and input on early versions of this document. 736 13. References 738 13.1. Normative References 740 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 741 "Framework for IP Performance Metrics", RFC 2330, 742 May 1998. 744 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 745 performance measurement with periodic streams", RFC 3432, 746 November 2002. 748 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 749 Delay Metric for IPPM", RFC 2681, September 1999. 751 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 752 August 2012. 754 [RFC1035] Mockapetris, P., "Domain names - implementation and 755 specification", STD 13, RFC 1035, November 1987. 757 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 758 Time Protocol Version 4: Protocol and Algorithms 759 Specification", RFC 5905, June 2010. 761 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 762 Delay Metric for IPPM", RFC 2679, September 1999. 764 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 765 Packet Loss Metric for IPPM", RFC 2680, September 1999. 767 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 768 Metric for IP Performance Metrics (IPPM)", RFC 3393, 769 November 2002. 771 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 772 Applicability Statement", RFC 5481, March 2009. 774 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 775 Performance Metric Development", BCP 170, RFC 6390, 776 October 2011. 778 [I-D.ietf-ippm-lmap-path] 779 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 780 A. Morton, "A Reference Path and Measurement Points for 781 LMAP", draft-ietf-ippm-lmap-path-00 (work in progress), 782 July 2013. 784 13.2. Informative References 786 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 787 Registry", BCP 108, RFC 4148, August 2005. 789 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 790 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 791 April 2011. 793 Authors' Addresses 795 Marcelo Bagnulo 796 Universidad Carlos III de Madrid 797 Av. Universidad 30 798 Leganes, Madrid 28911 799 SPAIN 801 Phone: 34 91 6249500 802 Email: marcelo@it.uc3m.es 803 URI: http://www.it.uc3m.es 804 Trevor Burbridge 805 British Telecom 806 Adastral Park, Martlesham Heath 807 Ipswich 808 ENGLAND 810 Email: trevor.burbridge@bt.com 812 Sam Crawford 813 SamKnows 815 Email: sam@samknows.com 817 Philip Eardley 818 British Telecom 819 Adastral Park, Martlesham Heath 820 Ipswich 821 ENGLAND 823 Email: philip.eardley@bt.com 825 Al Morton 826 AT&T Labs 827 200 Laurel Avenue South 828 Middletown, NJ 829 USA 831 Email: acmorton@att.com