idnits 2.17.00 (12 Aug 2021) /tmp/idnits43128/draft-bagnulo-ippm-new-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 336: '...odic sampling, T0 MUST NOT be strictly...' RFC 2119 keyword, line 339: '...Also, the duration of the test MUST be...' RFC 2119 keyword, line 972: '... sequence number MAY be included. For...' RFC 2119 keyword, line 974: '... packet SHOULD be indicated as "not ...' RFC 2119 keyword, line 1026: '... sequence number MAY be included. For...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3226 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) ** 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 -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 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 15, 2014 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 July 14, 2013 14 A registry for commonly used metrics 15 draft-bagnulo-ippm-new-registry-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 a single registry with multiple sub-registries. A 23 companion document draft-bagnulo-ippm-new-registry-independent 24 explores an alternative structure with independent registries for 25 each of the fields involved. . 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 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. The commonly used metrics registry . . . . . . . . . . . . . 4 63 2.1. The metrics registry . . . . . . . . . . . . . . . . . . 5 64 2.2. The Scheduling registry . . . . . . . . . . . . . . . . . 5 65 2.3. The Environment registry . . . . . . . . . . . . . . . . 6 66 2.4. The Output type registry . . . . . . . . . . . . . . . . 6 67 3. Initial assignment for the Scheduling registry . . . . . . . 6 68 3.1. Common parameter definitions . . . . . . . . . . . . . . 6 69 3.2. Poisson scheduling . . . . . . . . . . . . . . . . . . . 7 70 3.3. Periodic scheduling . . . . . . . . . . . . . . . . . . . 7 71 3.4. Singleton scheduling . . . . . . . . . . . . . . . . . . 8 72 4. Initial assignments for the Output Type registry . . . . . . 8 73 4.1. Raw . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.2. Xth percentile interval . . . . . . . . . . . . . . . . . 9 75 4.3. Xth percentile mean . . . . . . . . . . . . . . . . . . . 9 76 5. Initial assignments for the Environment registry . . . . . . 9 77 5.1. Undefined . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.2. No cross traffic . . . . . . . . . . . . . . . . . . . . 10 79 6. Initial assignments for the Metric registry . . . . . . . . . 11 80 6.1. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.2. UDP related metrics . . . . . . . . . . . . . . . . . . . 11 82 6.2.1. No cross traffic, raw, Poisson, UDP latency metric . 12 83 6.2.2. No cross traffic, 99th percentile mean, Poisson, UDP 84 latency metric . . . . . . . . . . . . . . . . . . . 13 85 6.2.3. No cross traffic, 99th percentile interval, Poisson, 86 UDP latency metric . . . . . . . . . . . . . . . . . 14 87 6.2.4. No cross traffic, Poisson UDP packet-loss ratio 88 metric . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.3. ICMP related metrics . . . . . . . . . . . . . . . . . . 16 90 6.3.1. No cross traffic, Periodic, ICMP packet-loss ratio 91 metric . . . . . . . . . . . . . . . . . . . . . . . 16 93 6.4. DNS related metrics . . . . . . . . . . . . . . . . . . . 17 94 6.4.1. DNS latency metric . . . . . . . . . . . . . . . . . 18 95 6.5. VoIP related metrics . . . . . . . . . . . . . . . . . . 19 96 6.5.1. No cross traffic, raw, Periodic, UDP latency metric . 20 97 6.5.2. No cross traffic, raw, Periodic, UDP loss metric . . 21 98 6.5.3. No cross traffic, raw, Periodic, UDP, PDV metric . . 22 99 6.5.4. No cross traffic, Periodic, UDP PDV:99.9 metric . . . 24 100 6.5.5. No cross traffic, Periodic UDP packet-loss ratio 101 metric . . . . . . . . . . . . . . . . . . . . . . . 25 102 7. Security considerations . . . . . . . . . . . . . . . . . . . 26 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 107 10.2. Informative References . . . . . . . . . . . . . . . . . 27 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Introduction 112 This document creates a registry for commonly used metrics. In order 113 to do that, it creates a number of namespaces whose values will be 114 recorded by the registry and will uniquely and precisely identify 115 metrics. 117 The motivation for having such registry is to allow a controller to 118 request a measurement agent to execute a measurement using a specific 119 metric. Such request can be performed using any control protocol 120 that refers to the value assigned to the specific metric in the 121 registry. Similarly, the measurement agent can report the results of 122 the measurement and by referring to the metric value it can 123 unequivocally identify the metric that the results correspond to. 125 There was a previous attempt to define a metric registry RFC 4148 126 [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because 127 it was "found to be insufficiently detailed to uniquely identify IPPM 128 metrics... [there was too much] variability possible when 129 characterizing a metric exactly" which led to the RFC4148 registry 130 having "very few users, if any". 132 Our approach learns from this, by tightly defining each entry in the 133 registry with only a few parameters open for each. The idea is that 134 the entries in the registry represent different measurement tests, 135 whilst the parameters set things like source and destination 136 addresses that don't change the fundamental nature of the test. The 137 downside of this approach is that it could result in an explosion in 138 the number of entries in the registry. We believe that less is more 139 in this context - it is better to have a reduced set of useful 140 metrics rather than a large set of metrics with questionable 141 usefulness. Therefore this document defines that the registry only 142 includes commonly used metrics that are well defined; hence we 143 require both specification required AND expert review policies for 144 the assignment of values in the registry. 146 There are a couple of side benefits of having such registry. First 147 the registry could serve as an inventory of useful and used metrics, 148 that are normally supported by different implementations of 149 measurement agents. Second, the results of the metrics would be 150 comparable even if they are performed by different implementations 151 and in different networks, as the metric is properly defined. 153 The registry forms part of a Measurement Plan {do you prefer the term 154 'Characterization Plan', 'control framework' or 'test schedule'?}. It 155 describes various factors that need to be set by the party 156 controlling the measurements, for example: specific values for the 157 parameters associated with the selected registry entry (for instance, 158 source and destination addresses); and how often the measurement is 159 made. The Measurement Plan might look something like: "Dear 160 measurement agent: Please start test DNS(example.com) and 161 RTT(server.com,150) every day at 2000 GMT. Run the DNS test 5 times 162 and the RTT test 50 times. Do that when the network is idle. 163 Generate both raw results and 99th percentile mean. Send measurement 164 results to collector.com in IPFIX format". The Measurement Plan 165 depends on the requirements of the controlling party. For instance 166 the broadband consumer might want a one-off measurement made 167 immediately to one specific server; a regulator might want the same 168 measurement made once a day until further notice to the 'top 10' 169 servers; whilst an operator might want a varying series of tests 170 (some of which will be beyond those defined in the registry) as 171 determined from time to time by their operational support system. 172 While the registries defined in this document help to define the 173 Measurement Plan its full specification falls outside the scope of 174 this document. 176 2. The commonly used metrics registry 178 In this section we define the registry for commonly used metrics. It 179 is composed by the following sub-registries: 181 o Scheduling registry 183 o Environment registry 185 o Output-type registry 187 o Metric registry 188 The rationale for the registry structure is to allow flexibility but 189 yet precise definition of metrics. The metric registry is the 190 fundamental registry and the other are auxiliary registries that 191 define values for different fields in the metric registry. 193 2.1. The metrics registry 195 Each entry for the metrics registry contain the following 196 information: 198 o Identifier: A text string that uniquely identifies the metric 200 o Name: The name of the metric 202 o Environment: A value from the Environment registry 204 o Output-type: A value from the Output-type registry 206 o Scheduling: A value form the Scheduling registry 208 o Reference: The specification where the metric is defined 210 The policy for the assignments in the metric registry is both 211 specification required AND expert review. This means that in order 212 to create an entry for the metric value a specification defining the 213 metric is required and when that happens, the request for allocation 214 will be reviewed by an expert. 216 The specification must define the input parameters for the metric as 217 well as the output of the metric. The metric must be well defined, 218 in the sense that two independent implementations must produce 219 uniform and comparable results. 221 The expert review must make sure that the proposed metric is 222 operationally useful. This means that the metric has proven to be 223 useful in operational/real scenarios. 225 2.2. The Scheduling registry 227 Each entry for the scheduling registry contain the following 228 information: 230 o Value: The name of the scheduling 232 o Reference: the specification where the scheduling is defined 234 The scheduling defines the scheduling strategy for the metric. 235 Simplest is Singleton scheduling, where an atomic measurement is 236 made. Other strategies make a series of atomic measurements in a 237 "sample" or "stream", with the schedule defining the timing between 238 each distinct measurement. Each atomic measurement could consist of 239 sending a single packet (such as a DNS request) or sending several 240 packets (for example a webpage). A scheduling strategy requires 241 input parameter(s). Assignment in this registry follows the 242 specification required policy. 244 2.3. The Environment registry 246 Each entry for the environment registry contain the following 247 information: 249 o Value: The name of the environment 251 o Reference: the specification where the environment is defined 253 The environment defines the conditions where the metric is expected 254 to be used. It does not define the metric itself, but the context 255 where the metric is executed. Assignment in this registry follows 256 the specification required policy. 258 2.4. The Output type registry 260 Each entry for the output type registry contain the following 261 information: 263 o Value: The name of the output type 265 o Reference: the specification where the output type is defined 267 The output type define the type of output that the metric produces. 268 It can be the raw results or it can be some form of statistic. 269 Assignment in this registry follows the specification required 270 policy. The specification of the output type must define the format 271 of the output. Note that if two types of statistic are required from 272 the same test (for example, both "Xth percentile mean" and "Raw") 273 then a new output type must be defined ("Xth percentile mean AND 274 Raw"). 276 3. Initial assignment for the Scheduling registry 278 3.1. Common parameter definitions 280 Although each IPPM RFC defines individual parameters and uses them 281 consistently, the parameter names are not completely consistent 282 across the RFC set. For example, the variable "dT" is used in 283 several different ways. This memo uses one set of parameter names, 284 and the reader is cautioned to map the names according to their 285 definitions. 287 We define some parameters that are used by several types of 288 scheduling: 290 o T0: time to begin a test 292 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) 304 o Total duration of the test: Tf - T0 + Waiting Time 306 3.2. Poisson scheduling 308 The values for this entry are as follows: 310 o Value: Poisson 312 o Reference: draft-bagnulo-ippm-new-registry 314 The Poisson scheduling is defined in section 11.1.1 of RFC 2330 315 [RFC2330] and needs input parameters: 317 o T0 and Tf: defined above 319 o lambda: the parameter defining the Poisson distribution. Lambda 320 is the mean number of distinct measurements per second in the 321 sample. 323 3.3. Periodic scheduling 325 The values for this entry are as follows: 327 o Value: Periodic 329 o Reference: draft-bagnulo-ippm-new-registry 330 The Periodic sampling is defined in RFC 3432 [RFC3432]. The 331 additional input parameters for the metric required by Periodic 332 scheduling are: 334 o T0 and Tf: defined above 336 * Note that with Periodic sampling, T0 MUST NOT be strictly 337 periodic with other tests of the same type. RFC 3432 [RFC3432] 338 requires randomized start times and describes one way to 339 accomplish this. Also, the duration of the test MUST be 340 limited. 342 o incT: the time in seconds between one distinct event and the next, 343 where events typically result in repeating singleton measurements 344 of various types (illustrated below). 346 * for a periodic stream this is the time between packets in the 347 sample, first bit to first bit 349 * for measurements on a process this is the time between the 350 first packets of the process, for example first bit to first 351 bit of the SYN in a TCP 3-way handshake 353 3.4. Singleton scheduling 355 The values for this entry are as follows: 357 o Value: singleton 359 o Reference: draft-bagnulo-ippm-new-registry 361 The singleton scheduling covers the case when an atomic metric is 362 performed as per RFC 2330 [RFC2330]. The additional input parameter 363 for the metric required by Singleton scheduling is: 365 o T0: defined above 367 4. Initial assignments for the Output Type registry 369 4.1. Raw 371 The values for this entry are as follows: 373 o Value: Raw 375 o Reference: draft-bagnulo-ippm-new-registry 376 The results of the metric are delivered in the exact way they are 377 produced by the measurements without any further processing or 378 filtering. 380 4.2. Xth percentile interval 382 The values for this entry are as follows: 384 o Value: Xth percentile interval 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 interval.) 393 The output when using this Output type will be a a couple of values, 394 expressed in the same units as the raw output, that is the Xth 395 percentile interval, as defined in section 1.3 of RFC 2330 [RFC2330]. 397 4.3. Xth percentile mean 399 The values for this entry are as follows: 401 o Value: Xth percentile mean 403 o Reference: draft-bagnulo-ippm-new-registry 405 The additional input parameter for the metric is 407 o X: the percentile (e.g, if the X input parameter is 99, then the 408 output will be the 99th percentile mean.) 410 The output when using this Output type will be a single value, 411 expressed in the same units as the raw output, that is the mean of 412 the sample only considering the values contained in the Xth 413 percentile interval, as defined in RFC 2330 [RFC2330]. 415 5. Initial assignments for the Environment registry 417 5.1. Undefined 419 The values for this entry are as follows: 421 o Value: Undefined 423 o Reference: draft-bagnulo-ippm-new-registry 424 The undefined environment is the case where no additional environment 425 settings are defined to perform the metric. 427 5.2. No cross traffic 429 The values for this entry are as follows: 431 o Value: No cross-traffic 433 o Reference: draft-bagnulo-ippm-new-registry 435 It is often important that there is no other traffic than the one 436 generated by the measurement itself while doing the measurement. The 437 reasons for this are two-folded, first, it is sometimes important 438 that the traffic created by the measurement doesn't impact the 439 experience of the users of the measured resource. Second it is 440 sometimes important that no other traffic interferes with the 441 measurement. This can be ensured by checking that the level of user 442 traffic is either zero or low enough to be confident that it won't 443 impact or be impacted by the measurement. 445 The "No cross traffic" condition is satisfied when, during the 5 446 seconds preceding measurement of the metric: 448 o the level of traffic flowing through the interface that will be 449 used to send measurement packets in either direction is less than 450 a threshold value of 1% of the line rate of the aforementioned 451 interface. 453 The "cross traffic" measurement is made at the interface, associated 454 with the measurement agent, that user traffic flows across. For 455 example, if the probe is attached to the home gateway, then the 456 interface is the service demarcation point where the subscriber 457 connects their private equipment or network to the subscribed 458 service. 460 Note that the No-cross traffic condition is defined only for the link 461 directly attached to the measurement agent initiating the 462 measurement. There is nothing mentioned about cross traffic on other 463 parts of the path used by measurement packets. In the case the 464 bottleneck of the path is other link than the one directly attached 465 to the device running the measurement agent, it may affect and be 466 affected by the measurement even if the No cross traffic as defined 467 here holds. 469 DISCUSSION 470 o clarify whether traffic for each direction is less than threshold, 471 or the sum 473 o current SamKnows probes measure cross-traffic before the 474 measurement of the metric. Another approach would be to measure 475 cross-traffic during the time the metric is measured. Or a hybrid 476 approach. These would either be separate environment entries, or 477 parameterise the existing one. 479 o current SamKnows probes define a fixed threshold. it could be a 480 parameter 482 o could ignore broadcast traffic (think SamKnows includes) 484 o It would be possible to define this a bit more precisely as 485 follows: 487 The "No cross-traffic" condition is defined for active 488 measurements. The measurement agent runs in a device that has 489 one or more interfaces. In active measurements, the 490 measurement agent sends one or more packets. Lets call if0 the 491 interface through with the packets resulting from the 492 measurement are sent through. The no cross traffic condition 493 is fulfilled when during the 5 seconds prior sending each of 494 the packets of the measurement: 496 + The traffic incoming through if0 that does not belong to the 497 measurement is lower than 1% of the line rate of if0 499 + The traffic coming through the rest of the interfaces 500 towards if0 is less than 1% of the line rate of if0. 502 6. Initial assignments for the Metric registry 504 6.1. Comment 506 Need to work through that we only define T0 and Tf (and not T, dT). 508 6.2. UDP related metrics 510 RFC 2681 [RFC2681] defines a Round-trip delay metric and RFC 6673 511 [RFC6673] defines a Round-trip packet loss metric. We build on these 512 two metrics by specifying several of the open parameters to precisely 513 define several metrics for measuring UDP latency and packet loss. 514 All the UDP related metrics defined in this section use the 515 following: 517 P-Type: 519 o IPv4 header values: 521 * DSCP: set to 0 523 * TTL set to 255 525 * Protocol: Set to 17 (UDP) 527 o UDP header values: 529 * Checksum: the checksum must be calculated 531 o Payload 533 * Sequence number: 8-byte integer 535 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 536 as per section 6 of RFC 5905 [RFC5905] 538 * No padding 540 Timeout: 3 seconds 542 6.2.1. No cross traffic, raw, Poisson, UDP latency metric 544 We define the No cross traffic, raw, Poisson, UDP latency metric as 545 follows: 547 o Identifier: TBD1 549 o Name: No cross-traffic, raw, Poisson, UDP latency 551 o Environment: No cross-traffic, access measurement 553 o Output type: raw 555 o Scheduling: Poisson 557 o Reference: draft-bagnulo-ippm-new-registry 559 The methodology for this metric is defined as Type-P-Round-trip- 560 Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and 561 Timeout defined above. 563 The input parameters for this metric are: 565 o Source IP Address 566 o Destination IP Address 568 o Source UDP port 570 o Destination UDP port 572 o Initial time T 574 o Duration dT 576 o Rate lambda 578 The output of this metric is a list of elements. Each element 579 corresponds to one packet sent. Each element contains the timestamp 580 of the sent packet and the time when the echo was received. 582 6.2.2. No cross traffic, 99th percentile mean, Poisson, UDP latency 583 metric 585 The methodology for this metric is defined as Type-P-Round-trip- 586 Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and 587 Timeout defined above. However, the output of the metric is not the 588 raw output, but the 99th percentile mean statistic. 590 The input parameters for this metric are: 592 o Identifier: TBD2 594 o Name: No cross-traffic, 99th percentile mean, Poisson, UDP latency 596 o Environment: No cross-traffic, access measurement 598 o Output type: Xth percentile mean 600 o Scheduling: Poisson 602 o Reference: draft-bagnulo-ippm-new-registry 604 The methodology for this metric is defined in RFC 2681 [RFC2681] 605 using the P-Type and Timeout defined above. 607 The input parameters for this metric are: 609 o Source IP Address 611 o Destination IP Address 613 o Source UDP port 614 o Destination UDP port 616 o Initial time T 618 o Duration dT 620 o Rate lambda 622 o Xth percentile: 99 624 The output of this metric is a single value that corresponds to the 625 99th percentile mean of the results. 627 6.2.3. No cross traffic, 99th percentile interval, Poisson, UDP latency 628 metric 630 The methodology for this metric is defined as Type-P-Round-trip- 631 Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and 632 Timeout defined above. However, the output of the metric is not the 633 raw output, but the 99th percentile interval statistic. 635 The input parameters for this metric are: 637 o Identifier: TBD3 639 o Name: No cross-traffic, 99th percentile interval, Poisson, UDP 640 latency 642 o Environment: No cross-traffic, access measurement 644 o Output type: Xth percentile interval 646 o Scheduling: Poisson 648 o Reference: draft-bagnulo-ippm-new-registry 650 The methodology for this metric is defined in RFC 2681 [RFC2681] 651 using the P-Type and Timeout defined above. 653 The input parameters for this metric are: 655 o Source IP Address 657 o Destination IP Address 659 o Source UDP port 661 o Destination UDP port 662 o Initial time T 664 o Duration dT 666 o Rate lambda 668 o Xth percentile: 99 670 The output of this metric is a single value that corresponds to the 671 99th percentile interval of the results. 673 6.2.4. No cross traffic, Poisson UDP packet-loss ratio metric 675 We define the No cross traffic, Poisson, UDP packet-loss ratio metric 676 as follows: 678 o Identifier: TBD4 680 o Name: No cross-traffic, Poisson, UDP packet-loss ratio 682 o Environment: No cross-traffic, access measurement 684 o Output type: Xth percentile mean 686 o Scheduling: Poisson 688 o Reference: draft-bagnulo-ippm-new-registry 690 This metric is defined as Type-P-Round-trip-Loss-Poisson-Ratio in RFC 691 6673 [RFC6673] using the P-Type and Timeout defined above. 693 The input parameters for this metric are: 695 o Source IP Address 697 o Destination IP Address 699 o Source UDP port 701 o Destination UDP port 703 o Initial time T 705 o Duration dT 707 o Rate lambda 709 o X percentile: 100 710 The output of this metric is a single value that corresponds to the 711 ratio of loss packets divided by the total number of packets sent. 713 6.3. ICMP related metrics 715 RFC 6673 [RFC6673] defines a Round-trip packet loss metric. We build 716 on that metrics by specifying several of the open parameters to 717 precisely define a metric for measuring ICMP packet loss. The ICMP 718 related metric defined in this document use the following: 720 P-Type: 722 o IPv4 header values: 724 * DSCP: set to 0 726 * TTL set to 255 728 * Protocol: Set to 1 (ICMP) 730 o ICMP header values: 732 * Type: 8 (Echo request) 734 * Code: 0 736 Observation: reply packets will contain an ICMP type of 0 Echo reply. 738 Timeout: 3 seconds 740 6.3.1. No cross traffic, Periodic, ICMP packet-loss ratio metric 742 We define the No cross traffic, Periodic, ICMP packet-loss ratio 743 metric as follows: 745 o Identifier: TBD6 747 o Name: No cross-traffic, Periodic, ICMP packet-loss ratio 749 o Environment: No cross-traffic, access measurement 751 o Output type: Xth percentile mean 753 o Scheduling: Periodic 755 o Reference: draft-bagnulo-ippm-new-registry 756 This metric is defined as Type-P-Round-trip-Loss-Periodic-Ratio in 757 RFC 6673 [RFC6673] using the P-Type and Timeout defined above. 759 The input parameters for this metric are: 761 o Source IP Address 763 o Destination IP Address 765 o Initial time T 767 o End Time Tf 769 o dt (the interval allowed for sample start times) 771 o Inter-packet time: incT 773 o X percentile: 100 775 The output of this metric is a single value that corresponds to the 776 ratio of loss packets divided by the total number of packets sent. 778 6.4. DNS related metrics 780 RFC 2681 [RFC2681] defines a Round-trip delay metric. We build on 781 that metric by specifying several of the open parameters to precisely 782 define a metric for measuring DNS latency. The metric uses the 783 following parameters: 785 P-Type: 787 o IPv4 header values: 789 * DSCP: set to 0 791 * TTL set to 255 793 * Protocol: Set to 17 (UDP) 795 o UDP header values: 797 * Source port: 53 799 * Destination port: 53 801 * Checksum: the checksum must be calculated 803 o Payload: The payload contains a DNS message as defined in RFC 1035 804 [RFC1035] with the following values: 806 * The DNS header section contains: 808 + QR: set to 0 (Query) 810 + OPCODE: set to 0 (standard query) 812 + AA: not set 814 + TC: not set 816 + RD: set to one (recursion desired) 818 + RA: not set 820 + RCODE: not set 822 + QDCOUNT: set to one (only one entry) 824 + ANCOUNT: not set 826 + NSCOUNT: not set 828 + ARCOUNT: not set 830 * The Question section contains: 832 + QNAME: the FQDN provided as input for the test 834 + QTYPE: the query type provided as input for the test 836 + QCLASS: set to IN 838 * The other sections do not contain any Resource Records. 840 Observation: reply packets will contain a DNS response and may 841 contain RRs. 843 Timeout: 3 seconds 845 6.4.1. DNS latency metric 847 We define the DNS latency metric as follows: 849 o Identifier: TBD7 850 o Name: DNS latency 852 o Environment: Undefined 854 o Output type: raw 856 o Scheduling: Singleton 858 o Reference: draft-bagnulo-ippm-new-registry 860 The methodology for this metric is defined as Type-P-Round-trip-Delay 861 in RFC 2681 [RFC2681] using the P-Type and Timeout defined above. 863 The input parameters for this metric are: 865 o Source IP Address 867 o Destination IP Address (the address of the DNS server to be 868 tested) 870 o QTYPE: A RR 872 o FQDN: a valid FQDN that will be queried for. 874 o Time T 876 The output of this metric is the timestamp when the packet was sent 877 and the delay that it took to receive a response. Please note that 878 any DNS response is valid, including no records in the answer. 879 (Should we be more explicit about what is the output when there is no 880 reply packet received?) 882 6.5. VoIP related metrics 884 [RFC2679] defines a one-way delay metric and [RFC2680] defines a one- 885 way packet loss metric. IPPM has derived a general packet delay 886 variation metric in [RFC3393], which we apply as recommended in 887 section 4.2 of [RFC5481]. We build on these specifications by 888 specifying several of the open parameters to precisely define several 889 metrics for measuring Voice over IP (VoIP) delay, delay variation, 890 and packet loss. All the VoIP related metrics defined in this 891 section use the following: 893 Type-P: 895 o IPv4 header values: 897 * DSCP: set to 0 (I think we move this to the sub-sections) 898 * TTL set to 255 900 * Protocol: Set to 17 (UDP) 902 o UDP header values: 904 * Checksum: the checksum must be calculated 906 o Payload - suffcient octets to emulate a VoIP audio payload, 907 including the an RTP header if desired, the actual test protocol 908 will populate the payload with a measurement header containing 909 fields such as: 911 * Sequence number: 913 * Timestamp: 915 * Random bit pattern: 917 Waiting Time to declare a packet lost: 5 seconds 919 Periodic Stream Description: 921 o Nominal inter-packet interval incT=20ms (first bit to first bit) 923 6.5.1. No cross traffic, raw, Periodic, UDP latency metric 925 We define the No cross traffic, raw, Periodic, UDP latency metric as 926 follows: 928 o Identifier: TBD641 930 o Name: No cross-traffic, raw, Periodic, UDP latency 932 o Environment: No cross-traffic, access measurement 934 o Output type: raw 936 o Scheduling: Periodic 938 o Reference: draft-bagnulo-ippm-new-registry 940 The methodology for this metric is defined as Type-P-One-way-Delay- 941 Periodic-Stream in section 4 of [RFC3432], including parameters from 942 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 943 above in section 6.4. 945 The input parameters for this metric are: 947 o Source IP Address 949 o Destination IP Address 951 o Source UDP port 953 o Destination UDP port 955 o Beginning of testing interval, T 957 o Initial time T0 (including a random offset from the beginning of 958 T) 960 o Ending time Tf 962 Variable aspects of Type-P are: 964 o DSCP value 966 o UDP Payload length 968 The output of this metric is a list of elements. Each element 969 corresponds to one packet sent. Each element contains the timestamp 970 of the sent packet and the time when the packet was received at the 971 destination (from which the one-way delay can be calculated). The 972 methodology's sequence number MAY be included. For packets which do 973 not arrive prior to the Waiting Time, the received timestamp for that 974 packet SHOULD be indicated as "not available", or post-processing may 975 be applied to enforce the constant Waiting Time to exclude long- 976 delayed packets and lost packets from further analysis. 978 6.5.2. No cross traffic, raw, Periodic, UDP loss metric 980 We define the No cross traffic, raw, Periodic, UDP loss metric as 981 follows: 983 o Identifier: TBD642 985 o Name: No cross-traffic, raw, Periodic, UDP latency 987 o Environment: No cross-traffic, access measurement 989 o Output type: raw 991 o Scheduling: Periodic 993 o Reference: draft-bagnulo-ippm-new-registry 994 The methodology for this metric is identical to Type-P-One-way-Delay- 995 Periodic-Stream in section 4 of [RFC3432], including parameters from 996 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 997 above in section 6.4. 999 The input parameters for this metric are: 1001 o Source IP Address 1003 o Destination IP Address 1005 o Source UDP port 1007 o Destination UDP port 1009 o Beginning of testing interval, T 1011 o Initial time T0 (including a random offset from the beginning of 1012 T) 1014 o Ending time Tf 1016 Variable aspects of Type-P are: 1018 o DSCP value 1020 o UDP Payload length 1022 The output of this metric is a list of elements. Each element 1023 corresponds to one packet sent. Each element contains the timestamp 1024 of the sent packet and the time when the packet was received at the 1025 destination (from which the one-way delay can be calculated). The 1026 methodology's sequence number MAY be included. For packets which do 1027 not arrive prior to the Waiting Time, the received timestamp for that 1028 packet SHOULD be indicated as "not available", or post-processing may 1029 be applied to enforce the constant Waiting Time to exclude long- 1030 delayed packets and lost packets from further analysis. 1032 Note that the same raw output format MAY serve both loss and delay 1033 metrics. 1035 6.5.3. No cross traffic, raw, Periodic, UDP, PDV metric 1037 We define the No cross traffic, Periodic, UDP Packet Delay Variation 1038 metric as follows: 1040 o Identifier: TBD643 1041 o Name: No cross-traffic, Periodic, UDP PDV 1043 o Environment: No cross-traffic, access measurement 1045 o Output type: raw 1047 o Scheduling: Periodic 1049 o Reference: draft-bagnulo-ippm-new-registry 1051 The methodology for the delay singletons from which this metric is 1052 derived take the first steps defined as Type-P-One-way-Delay- 1053 Periodic-Stream in section 4 of [RFC3432], including parameters from 1054 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 1055 above in section 6.4. This collects the one-way delay singletons. 1057 The next step in the methodology follows from sections 2 and 3 of 1058 [RFC3393] (which describes how to use a selection function to 1059 determine pairs of packets to derive PDV) and section 4.2 of 1060 [RFC5481], where the packet with the minimum delay is specified as a 1061 fixed member of the pair. 1063 The input parameters for this metric are: 1065 o Source IP Address 1067 o Destination IP Address 1069 o Source UDP port 1071 o Destination UDP port 1073 o Beginning of testing interval, T 1075 o Initial time T0 (including a random offset from the beginning of 1076 T) 1078 o Ending time Tf 1080 Variable aspects of Type-P are: 1082 o DSCP value 1084 o UDP Payload length 1086 The output of this metric is a list of triples (3 elements). Each 1087 element corresponds to one packet in the sample. Each element 1088 contains the one way delay of the first packet in the pair, the one 1089 way delay of the second packet in the pair (having minimum delay), 1090 and the variation in transmission time calculated for packet with 1091 sequence number i as PDV(i) = D(i)-D(min). The methodology's 1092 sequence number MAY be included. For packets which do not arrive 1093 prior to the Waiting Time, the delay for that packet and its PDV 1094 SHOULD be indicated as "not available" (following section 4.1 of 1095 [RFC3393]). 1097 6.5.4. No cross traffic, Periodic, UDP PDV:99.9 metric 1099 We define the No cross traffic, Periodic, UDP Packet Delay Variation 1100 (99.9 percentile) metric as follows: 1102 o Identifier: TBD644 1104 o Name: No cross-traffic, Periodic, UDP PDV:99.9 1106 o Environment: No cross-traffic, access measurement 1108 o Output type: 99.9 percentile 1110 o Scheduling: Periodic 1112 o Reference: draft-bagnulo-ippm-new-registry 1114 The methodology for the delay singletons from which this metric is 1115 derived take the first steps defined as Type-P-One-way-Delay- 1116 Periodic-Stream in section 4 of [RFC3432], including parameters from 1117 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 1118 above in section 6.4. This collects the one-way delay singletons. 1120 The next step in the methodology follows from sections 2 and 3 of 1121 [RFC3393] (which describes how to use a selection function to 1122 determine pairs of packets to derive PDV) and section 4.2 of 1123 [RFC5481], where the packet with the minimum delay is specified as a 1124 fixed member of the pair. 1126 The input parameters for this metric are: 1128 o Source IP Address 1130 o Destination IP Address 1132 o Source UDP port 1134 o Destination UDP port 1136 o Beginning of testing interval, T 1137 o Initial time T0 (including a random offset from the beginning of 1138 T) 1140 o Ending time Tf 1142 Variable aspects of Type-P are: 1144 o DSCP value 1146 o UDP Payload length 1148 The output of this metric is a single value corresponding to the 1149 99.9th percentile of PDV. For packets which do not arrive prior to 1150 the Waiting Time, the delay for that packet and its PDV SHOULD be 1151 indicated as "not available" (following section 4.1 of [RFC3393]). 1152 If the 99.9th percentile of singletons corresponds to packet whose 1153 delay and PDV are "not available", then the output of this metric is 1154 "not available". 1156 6.5.5. No cross traffic, Periodic UDP packet-loss ratio metric 1158 We define the No cross traffic, Periodic, UDP packet-loss ratio 1159 metric as follows: 1161 o Identifier: TBD645 1163 o Name: No cross-traffic, Periodic, UDP packet-loss ratio 1165 o Environment: No cross-traffic, access measurement 1167 o Output type: X percentile mean 1169 o Scheduling: Periodic 1171 o Reference: draft-bagnulo-ippm-new-registry 1173 This metric is defined as Type-P-One-way-Loss-Average in Section 4.1 1174 of[RFC2680] using the Type-P and Waiting Time defined in section 6.4 1175 above. 1177 The input parameters for this metric are: 1179 o Source IP Address 1181 o Destination IP Address 1183 o Source UDP port 1184 o Destination UDP port 1186 o Beginning of testing interval, T 1188 o Initial time T0 (including a random offset from the beginning of 1189 T) 1191 o Ending time Tf 1193 o X percentile mean: 100 1195 Variable aspects of Type-P are: 1197 o DSCP value 1199 o UDP Payload length 1201 The output of this metric is one value that corresponds to the ratio 1202 of lost packets divided by the total number of packets sent. This 1203 can be calculated from the singleton elements of section 6.4.2 above, 1204 assigning the logical value "0" to packets with a valid one-way delay 1205 and the value "1" to all packets whose one-way delay is recorded as 1206 "not available". As section 4.1 of [RFC2680] indicates, the average 1207 of all the logical values is the ratio of lost to total packets. 1209 7. Security considerations 1211 TBD 1213 8. IANA Considerations 1215 TBD 1217 9. Acknowledgments 1219 We would like to thank Henning Schulzrinne for many constructive 1220 comments and input on early versions of this document. 1222 10. References 1224 10.1. Normative References 1226 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1227 "Framework for IP Performance Metrics", RFC 2330, May 1228 1998. 1230 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1231 performance measurement with periodic streams", RFC 3432, 1232 November 2002. 1234 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1235 Delay Metric for IPPM", RFC 2681, September 1999. 1237 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 1238 August 2012. 1240 [RFC1035] Mockapetris, P., "Domain names - implementation and 1241 specification", STD 13, RFC 1035, November 1987. 1243 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1244 Time Protocol Version 4: Protocol and Algorithms 1245 Specification", RFC 5905, June 2010. 1247 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1248 Delay Metric for IPPM", RFC 2679, September 1999. 1250 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1251 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1253 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1254 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1255 November 2002. 1257 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1258 Applicability Statement", RFC 5481, March 2009. 1260 10.2. Informative References 1262 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1263 Registry", BCP 108, RFC 4148, August 2005. 1265 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 1266 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 1267 2011. 1269 Authors' Addresses 1270 Marcelo Bagnulo 1271 Universidad Carlos III de Madrid 1272 Av. Universidad 30 1273 Leganes, Madrid 28911 1274 SPAIN 1276 Phone: 34 91 6249500 1277 Email: marcelo@it.uc3m.es 1278 URI: http://www.it.uc3m.es 1280 Trevor Burbridge 1281 British Telecom 1282 Adastral Park, Martlesham Heath 1283 Ipswich 1284 ENGLAND 1286 Email: trevor.burbridge@bt.com 1288 Sam Crawford 1289 SamKnows 1291 Email: sam@samknows.com 1293 Philip Eardley 1294 British Telecom 1295 Adastral Park, Martlesham Heath 1296 Ipswich 1297 ENGLAND 1299 Email: philip.eardley@bt.com 1301 Al Morton 1302 AT&T Labs 1303 200 Laurel Avenue South 1304 Middletown, NJ 1305 USA 1307 Email: acmorton@att.com