idnits 2.17.1 draft-bagnulo-ippm-new-registry-00.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 313: '...odic sampling, T0 MUST NOT be strictly...' RFC 2119 keyword, line 316: '...Also, the duration of the test MUST be...' RFC 2119 keyword, line 790: '... sequence number MAY be included. For...' RFC 2119 keyword, line 792: '... packet SHOULD be indicated as "not ...' RFC 2119 keyword, line 831: '... 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 (January 15, 2013) is 4119 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: July 19, 2013 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 January 15, 2013 14 A registry for commonly used metrics 15 draft-bagnulo-ippm-new-registry-00 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 July 19, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. The commonly used metrics registry . . . . . . . . . . . . . . 6 63 2.1. The metrics registry . . . . . . . . . . . . . . . . . . . 6 64 2.2. The Scheduling registry . . . . . . . . . . . . . . . . . 7 65 2.3. The Environment registry . . . . . . . . . . . . . . . . . 7 66 2.4. The Output type registry . . . . . . . . . . . . . . . . . 7 67 3. Initial assignment for the Scheduling registry . . . . . . . . 8 68 3.1. Common parameter definitions . . . . . . . . . . . . . . . 8 69 3.2. Poisson scheduling . . . . . . . . . . . . . . . . . . . . 8 70 3.3. Periodic scheduling . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 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. No cross traffic, raw, Poisson, UDP latency metric . . 13 83 6.2.2. No cross traffic, 99th percentile mean, Poisson, 84 UDP latency metric . . . . . . . . . . . . . . . . . . 13 85 6.2.3. No cross traffic, 99th percentile interval, 86 Poisson, 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 . . . . . . . . . . . . . . . . . . . 15 90 6.3.1. No cross traffic, Periodic, ICMP packet-loss ratio 91 metric . . . . . . . . . . . . . . . . . . . . . . . . 16 92 6.4. DNS related metrics . . . . . . . . . . . . . . . . . . . 16 93 6.4.1. DNS latency metric . . . . . . . . . . . . . . . . . . 17 94 6.5. VoIP related metrics . . . . . . . . . . . . . . . . . . . 18 95 6.5.1. No cross traffic, raw, Periodic, UDP latency metric . 18 96 6.5.2. No cross traffic, raw, Periodic, UDP loss metric . . . 19 97 6.5.3. No cross traffic, raw, Periodic, UDP, PDV metric . . . 20 98 6.5.4. No cross traffic, Periodic, UDP PDV:99.9 metric . . . 21 99 6.5.5. No cross traffic, Periodic UDP packet-loss ratio 100 metric . . . . . . . . . . . . . . . . . . . . . . . . 22 101 7. Security considerations . . . . . . . . . . . . . . . . . . . 23 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 106 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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'?}. 155 It 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: 180 o Scheduling registry 181 o Environment registry 182 o Output-type registry 183 o Metric registry 185 The rationale for the registry structure is to allow flexibility but 186 yet precise definition of metrics. The metric registry is the 187 fundamental registry and the other are auxiliary registries that 188 define values for different fields in the metric registry. 190 2.1. The metrics registry 192 Each entry for the metrics registry contain the following 193 information: 194 o Identifier: A text string that uniquely identifies the metric 195 o Name: The name of the metric 196 o Environment: A value from the Environment registry 197 o Output-type: A value from the Output-type registry 198 o Scheduling: A value form the Scheduling registry 199 o Reference: The specification where the metric is defined 201 The policy for the assignments in the metric registry is both 202 specification required AND expert review. This means that in order 203 to create an entry for the metric value a specification defining the 204 metric is required and when that happens, the request for allocation 205 will be reviewed by an expert. 207 The specification must define the input parameters for the metric as 208 well as the output of the metric. The metric must be well defined, 209 in the sense that two independent implementations must produce 210 uniform and comparable results. 212 The expert review must make sure that the proposed metric is 213 operationally useful. This means that the metric has proven to be 214 useful in operational/real scenarios. 216 2.2. The Scheduling registry 218 Each entry for the scheduling registry contain the following 219 information: 220 o Value: The name of the scheduling 221 o Reference: the specification where the scheduling is defined 223 The scheduling defines the scheduling strategy for the metric. 224 Simplest is Singleton scheduling, where an atomic measurement is 225 made. Other strategies make a series of atomic measurements in a 226 "sample" or "stream", with the schedule defining the timing between 227 each distinct measurement. Each atomic measurement could consist of 228 sending a single packet (such as a DNS request) or sending several 229 packets (for example a webpage). A scheduling strategy requires 230 input parameter(s). Assignment in this registry follows the 231 specification required policy. 233 2.3. The Environment registry 235 Each entry for the environment registry contain the following 236 information: 237 o Value: The name of the environment 238 o Reference: the specification where the environment is defined 240 The environment defines the conditions where the metric is expected 241 to be used. It does not define the metric itself, but the context 242 where the metric is executed. Assignment in this registry follows 243 the specification required policy. 245 2.4. The Output type registry 247 Each entry for the output type registry contain the following 248 information: 249 o Value: The name of the output type 250 o Reference: the specification where the output type is defined 252 The output type define the type of output that the metric produces. 254 It can be the raw results or it can be some form of statistic. 255 Assignment in this registry follows the specification required 256 policy. The specification of the output type must define the format 257 of the output. Note that if two types of statistic are required from 258 the same test (for example, both "Xth percentile mean" and "Raw") 259 then a new output type must be defined ("Xth percentile mean AND 260 Raw"). 262 3. Initial assignment for the Scheduling registry 264 3.1. Common parameter definitions 266 Although each IPPM RFC defines individual parameters and uses them 267 consistently, the parameter names are not completely consistent 268 across the RFC set. For example, the variable "dT" is used in 269 several different ways. This memo uses one set of parameter names, 270 and the reader is cautioned to map the names according to their 271 definitions. 273 We define some parameters that are used by several types of 274 scheduling: 276 o T0: time to begin a test 277 o Tf: time to end a test 278 T0 and Tf are both in seconds and use the date (yyyy-mm-dd) and NTP 279 64 bit timestamp. T0 includes any control handshaking before the 280 test stream or singleton. Tf is the time the last test data is sent. 282 As a result, we have: 284 o Time when test devices may close the test socket: Tf + Waiting 285 Time (the time to wait before declaring a packet lost is fixed for 286 each metric) 287 o Total duration of the test: Tf - T0 + Waiting Time 289 3.2. Poisson scheduling 291 The values for this entry are as follows: 292 o Value: Poisson 293 o Reference: draft-bagnulo-ippm-new-registry 295 The Poisson scheduling is defined in section 11.1.1 of RFC 2330 296 [RFC2330] and needs input parameters: 298 o T0 and Tf: defined above 299 o lambda: the parameter defining the Poisson distribution. Lambda 300 is the mean number of distinct measurements per second in the 301 sample. 303 3.3. Periodic scheduling 305 The values for this entry are as follows: 306 o Value: Periodic 307 o Reference: draft-bagnulo-ippm-new-registry 309 The Periodic sampling is defined in RFC 3432 [RFC3432]. The 310 additional input parameters for the metric required by Periodic 311 scheduling are: 312 o T0 and Tf: defined above 313 * Note that with Periodic sampling, T0 MUST NOT be strictly 314 periodic with other tests of the same type. RFC 3432 [RFC3432] 315 requires randomized start times and describes one way to 316 accomplish this. Also, the duration of the test MUST be 317 limited. 318 o incT: the time in seconds between one distinct event and the next, 319 where events typically result in repeating singleton measurements 320 of various types (illustrated below). 321 * for a periodic stream this is the time between packets in the 322 sample, first bit to first bit 323 * for measurements on a process this is the time between the 324 first packets of the process, for example first bit to first 325 bit of the SYN in a TCP 3-way handshake 327 3.4. Singleton scheduling 329 The values for this entry are as follows: 330 o Value: singleton 331 o Reference: draft-bagnulo-ippm-new-registry 333 The singleton scheduling covers the case when an atomic metric is 334 performed as per RFC 2330 [RFC2330]. The additional input parameter 335 for the metric required by Singleton scheduling is: 337 o T0: defined above 339 4. Initial assignments for the Output Type registry 341 4.1. Raw 343 The values for this entry are as follows: 345 o Value: Raw 346 o Reference: draft-bagnulo-ippm-new-registry 348 The results of the metric are delivered in the exact way they are 349 produced by the measurements without any further processing or 350 filtering. 352 4.2. Xth percentile interval 354 The values for this entry are as follows: 355 o Value: Xth percentile interval 356 o Reference: draft-bagnulo-ippm-new-registry 358 The additional input parameter for the metric is: 360 o X: the percentile (e.g, if the X input parameter is 99, then the 361 output will be the 99th percentile interval.) 362 The output when using this Output type will be a a couple of values, 363 expressed in the same units as the raw output, that is the Xth 364 percentile interval, as defined in section 1.3 of RFC 2330 [RFC2330]. 366 4.3. Xth percentile mean 368 The values for this entry are as follows: 369 o Value: Xth percentile mean 370 o Reference: draft-bagnulo-ippm-new-registry 372 The additional input parameter for the metric is 374 o X: the percentile (e.g, if the X input parameter is 99, then the 375 output will be the 99th percentile mean.) 376 The output when using this Output type will be a single value, 377 expressed in the same units as the raw output, that is the mean of 378 the sample only considering the values contained in the Xth 379 percentile interval, as defined in RFC 2330 [RFC2330]. 381 5. Initial assignments for the Environment registry 383 5.1. Undefined 385 The values for this entry are as follows: 386 o Value: Undefined 387 o Reference: draft-bagnulo-ippm-new-registry 389 The undefined environment is the case where no additional environment 390 settings are defined to perform the metric. 392 5.2. No cross traffic 394 The values for this entry are as follows: 395 o Value: No cross-traffic 396 o Reference: draft-bagnulo-ippm-new-registry 398 It is often important that there is no other traffic than the one 399 generated by the measurement itself while doing the measurement. The 400 reasons for this are two-folded, first, it is sometimes important 401 that the traffic created by the measurement doesn't impact the 402 experience of the users of the measured resource. Second it is 403 sometimes important that no other traffic interferes with the 404 measurement. This can be ensured by checking that the level of user 405 traffic is either zero or low enough to be confident that it won't 406 impact or be impacted by the measurement. 408 The "No cross traffic" condition is satisfied when, during the 5 409 seconds preceding measurement of the metric: 410 o the level of traffic flowing through the interface that will be 411 used to send measurement packets in either direction is less than 412 a threshold value of 1% of the line rate of the aforementioned 413 interface. 415 The "cross traffic" measurement is made at the interface, associated 416 with the measurement agent, that user traffic flows across. For 417 example, if the probe is attached to the home gateway, then the 418 interface is the service demarcation point where the subscriber 419 connects their private equipment or network to the subscribed 420 service. 422 Note that the No-cross traffic condition is defined only for the link 423 directly attached to the measurement agent initiating the 424 measurement. There is nothing mentioned about cross traffic on other 425 parts of the path used by measurement packets. In the case the 426 bottleneck of the path is other link than the one directly attached 427 to the device running the measurement agent, it may affect and be 428 affected by the measurement even if the No cross traffic as defined 429 here holds. 431 DISCUSSION 433 o clarify whether traffic for each direction is less than threshold, 434 or the sum 435 o current SamKnows probes measure cross-traffic before the 436 measurement of the metric. Another approach would be to measure 437 cross-traffic during the time the metric is measured. Or a hybrid 438 approach. These would either be separate environment entries, or 439 parameterise the existing one. 441 o current SamKnows probes define a fixed threshold. it could be a 442 parameter 443 o could ignore broadcast traffic (think SamKnows includes) 444 o It would be possible to define this a bit more precisely as 445 follows: 446 * The "No cross-traffic" condition is defined for active 447 measurements. The measurement agent runs in a device that has 448 one or more interfaces. In active measurements, the 449 measurement agent sends one or more packets. Lets call if0 the 450 interface through with the packets resulting from the 451 measurement are sent through. The no cross traffic condition 452 is fulfilled when during the 5 seconds prior sending each of 453 the packets of the measurement: 454 + The traffic incoming through if0 that does not belong to the 455 measurement is lower than 1% of the line rate of if0 456 + The traffic coming through the rest of the interfaces 457 towards if0 is less than 1% of the line rate of if0. 459 6. Initial assignments for the Metric registry 461 6.1. Comment 463 Need to work through that we only define T0 and Tf (and not T, dT). 465 6.2. UDP related metrics 467 RFC 2681 [RFC2681] defines a Round-trip delay metric and RFC 6673 468 [RFC6673] defines a Round-trip packet loss metric. We build on these 469 two metrics by specifying several of the open parameters to precisely 470 define several metrics for measuring UDP latency and packet loss. 471 All the UDP related metrics defined in this section use the 472 following: 474 P-Type: 475 o IPv4 header values: 476 * DSCP: set to 0 477 * TTL set to 255 478 * Protocol: Set to 17 (UDP) 479 o UDP header values: 480 * Checksum: the checksum must be calculated 481 o Payload 482 * Sequence number: 8-byte integer 483 * Timestamp: 8 byte integer. Expressed as 64-bit NTP timestamp 484 as per section 6 of RFC 5905 [RFC5905] 485 * No padding 487 Timeout: 3 seconds 489 6.2.1. No cross traffic, raw, Poisson, UDP latency metric 491 We define the No cross traffic, raw, Poisson, UDP latency metric as 492 follows: 493 o Identifier: TBD1 494 o Name: No cross-traffic, raw, Poisson, UDP latency 495 o Environment: No cross-traffic, access measurement 496 o Output type: raw 497 o Scheduling: Poisson 498 o Reference: draft-bagnulo-ippm-new-registry 500 The methodology for this metric is defined as Type-P-Round-trip- 501 Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and 502 Timeout defined above. 504 The input parameters for this metric are: 505 o Source IP Address 506 o Destination IP Address 507 o Source UDP port 508 o Destination UDP port 509 o Initial time T 510 o Duration dT 511 o Rate lambda 513 The output of this metric is a list of elements. Each element 514 corresponds to one packet sent. Each element contains the timestamp 515 of the sent packet and the time when the echo was received. 517 6.2.2. No cross traffic, 99th percentile mean, Poisson, UDP latency 518 metric 520 The methodology for this metric is defined as Type-P-Round-trip- 521 Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and 522 Timeout defined above. However, the output of the metric is not the 523 raw output, but the 99th percentile mean statistic. 525 The input parameters for this metric are: 526 o Identifier: TBD2 527 o Name: No cross-traffic, 99th percentile mean, Poisson, UDP latency 528 o Environment: No cross-traffic, access measurement 529 o Output type: Xth percentile mean 530 o Scheduling: Poisson 531 o Reference: draft-bagnulo-ippm-new-registry 533 The methodology for this metric is defined in RFC 2681 [RFC2681] 534 using the P-Type and Timeout defined above. 536 The input parameters for this metric are: 538 o Source IP Address 539 o Destination IP Address 540 o Source UDP port 541 o Destination UDP port 542 o Initial time T 543 o Duration dT 544 o Rate lambda 545 o Xth percentile: 99 547 The output of this metric is a single value that corresponds to the 548 99th percentile mean of the results. 550 6.2.3. No cross traffic, 99th percentile interval, Poisson, UDP latency 551 metric 553 The methodology for this metric is defined as Type-P-Round-trip- 554 Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and 555 Timeout defined above. However, the output of the metric is not the 556 raw output, but the 99th percentile interval statistic. 558 The input parameters for this metric are: 559 o Identifier: TBD3 560 o Name: No cross-traffic, 99th percentile interval, Poisson, UDP 561 latency 562 o Environment: No cross-traffic, access measurement 563 o Output type: Xth percentile interval 564 o Scheduling: Poisson 565 o Reference: draft-bagnulo-ippm-new-registry 567 The methodology for this metric is defined in RFC 2681 [RFC2681] 568 using the P-Type and Timeout defined above. 570 The input parameters for this metric are: 571 o Source IP Address 572 o Destination IP Address 573 o Source UDP port 574 o Destination UDP port 575 o Initial time T 576 o Duration dT 577 o Rate lambda 578 o Xth percentile: 99 580 The output of this metric is a single value that corresponds to the 581 99th percentile interval of the results. 583 6.2.4. No cross traffic, Poisson UDP packet-loss ratio metric 585 We define the No cross traffic, Poisson, UDP packet-loss ratio metric 586 as follows: 587 o Identifier: TBD4 588 o Name: No cross-traffic, Poisson, UDP packet-loss ratio 589 o Environment: No cross-traffic, access measurement 590 o Output type: Xth percentile mean 591 o Scheduling: Poisson 592 o Reference: draft-bagnulo-ippm-new-registry 594 This metric is defined as Type-P-Round-trip-Loss-Poisson-Ratio in RFC 595 6673 [RFC6673] using the P-Type and Timeout defined above. 597 The input parameters for this metric are: 598 o Source IP Address 599 o Destination IP Address 600 o Source UDP port 601 o Destination UDP port 602 o Initial time T 603 o Duration dT 604 o Rate lambda 605 o X percentile: 100 607 The output of this metric is a single value that corresponds to the 608 ratio of loss packets divided by the total number of packets sent. 610 6.3. ICMP related metrics 612 RFC 6673 [RFC6673] defines a Round-trip packet loss metric. We build 613 on that metrics by specifying several of the open parameters to 614 precisely define a metric for measuring ICMP packet loss. The ICMP 615 related metric defined in this document use the following: 617 P-Type: 618 o IPv4 header values: 619 * DSCP: set to 0 620 * TTL set to 255 621 * Protocol: Set to 1 (ICMP) 622 o ICMP header values: 623 * Type: 8 (Echo request) 624 * Code: 0 626 Observation: reply packets will contain an ICMP type of 0 Echo reply. 628 Timeout: 3 seconds 630 6.3.1. No cross traffic, Periodic, ICMP packet-loss ratio metric 632 We define the No cross traffic, Periodic, ICMP packet-loss ratio 633 metric as follows: 634 o Identifier: TBD6 635 o Name: No cross-traffic, Periodic, ICMP packet-loss ratio 636 o Environment: No cross-traffic, access measurement 637 o Output type: Xth percentile mean 638 o Scheduling: Periodic 639 o Reference: draft-bagnulo-ippm-new-registry 641 This metric is defined as Type-P-Round-trip-Loss-Periodic-Ratio in 642 RFC 6673 [RFC6673] using the P-Type and Timeout defined above. 644 The input parameters for this metric are: 645 o Source IP Address 646 o Destination IP Address 647 o Initial time T 648 o End Time Tf 649 o dt (the interval allowed for sample start times) 650 o Inter-packet time: incT 651 o X percentile: 100 653 The output of this metric is a single value that corresponds to the 654 ratio of loss packets divided by the total number of packets sent. 656 6.4. DNS related metrics 658 RFC 2681 [RFC2681] defines a Round-trip delay metric. We build on 659 that metric by specifying several of the open parameters to precisely 660 define a metric for measuring DNS latency. The metric uses the 661 following parameters: 663 P-Type: 664 o IPv4 header values: 665 * DSCP: set to 0 666 * TTL set to 255 667 * Protocol: Set to 17 (UDP) 668 o UDP header values: 669 * Source port: 53 670 * Destination port: 53 671 * Checksum: the checksum must be calculated 672 o Payload: The payload contains a DNS message as defined in RFC 1035 673 [RFC1035] with the following values: 674 * The DNS header section contains: 675 + QR: set to 0 (Query) 676 + OPCODE: set to 0 (standard query) 677 + AA: not set 678 + TC: not set 679 + RD: set to one (recursion desired) 680 + RA: not set 681 + RCODE: not set 682 + QDCOUNT: set to one (only one entry) 683 + ANCOUNT: not set 684 + NSCOUNT: not set 685 + ARCOUNT: not set 686 * The Question section contains: 687 + QNAME: the FQDN provided as input for the test 688 + QTYPE: the query type provided as input for the test 689 + QCLASS: set to IN 690 * The other sections do not contain any Resource Records. 692 Observation: reply packets will contain a DNS response and may 693 contain RRs. 695 Timeout: 3 seconds 697 6.4.1. DNS latency metric 699 We define the DNS latency metric as follows: 700 o Identifier: TBD7 701 o Name: DNS latency 702 o Environment: Undefined 703 o Output type: raw 704 o Scheduling: Singleton 705 o Reference: draft-bagnulo-ippm-new-registry 707 The methodology for this metric is defined as Type-P-Round-trip-Delay 708 in RFC 2681 [RFC2681] using the P-Type and Timeout defined above. 710 The input parameters for this metric are: 711 o Source IP Address 712 o Destination IP Address (the address of the DNS server to be 713 tested) 714 o QTYPE: A RR 715 o FQDN: a valid FQDN that will be queried for. 716 o Time T 718 The output of this metric is the timestamp when the packet was sent 719 and the delay that it took to receive a response. Please note that 720 any DNS response is valid, including no records in the answer. 721 (Should we be more explicit about what is the output when there is no 722 reply packet received?) 724 6.5. VoIP related metrics 726 [RFC2679] defines a one-way delay metric and [RFC2680] defines a one- 727 way packet loss metric. IPPM has derived a general packet delay 728 variation metric in [RFC3393], which we apply as recommended in 729 section 4.2 of [RFC5481]. We build on these specifications by 730 specifying several of the open parameters to precisely define several 731 metrics for measuring Voice over IP (VoIP) delay, delay variation, 732 and packet loss. All the VoIP related metrics defined in this 733 section use the following: 735 Type-P: 736 o IPv4 header values: 737 * DSCP: set to 0 (I think we move this to the sub-sections) 738 * TTL set to 255 739 * Protocol: Set to 17 (UDP) 740 o UDP header values: 741 * Checksum: the checksum must be calculated 742 o Payload - suffcient octets to emulate a VoIP audio payload, 743 including the an RTP header if desired, the actual test protocol 744 will populate the payload with a measurement header containing 745 fields such as: 746 * Sequence number: 747 * Timestamp: 748 * Random bit pattern: 750 Waiting Time to declare a packet lost: 5 seconds 752 Periodic Stream Description: 753 o Nominal inter-packet interval incT=20ms (first bit to first bit) 755 6.5.1. No cross traffic, raw, Periodic, UDP latency metric 757 We define the No cross traffic, raw, Periodic, UDP latency metric as 758 follows: 759 o Identifier: TBD641 760 o Name: No cross-traffic, raw, Periodic, UDP latency 761 o Environment: No cross-traffic, access measurement 762 o Output type: raw 763 o Scheduling: Periodic 764 o Reference: draft-bagnulo-ippm-new-registry 766 The methodology for this metric is defined as Type-P-One-way-Delay- 767 Periodic-Stream in section 4 of [RFC3432], including parameters from 768 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 769 above in section 6.4. 771 The input parameters for this metric are: 773 o Source IP Address 774 o Destination IP Address 775 o Source UDP port 776 o Destination UDP port 777 o Beginning of testing interval, T 778 o Initial time T0 (including a random offset from the beginning of 779 T) 780 o Ending time Tf 782 Variable aspects of Type-P are: 783 o DSCP value 784 o UDP Payload length 786 The output of this metric is a list of elements. Each element 787 corresponds to one packet sent. Each element contains the timestamp 788 of the sent packet and the time when the packet was received at the 789 destination (from which the one-way delay can be calculated). The 790 methodology's sequence number MAY be included. For packets which do 791 not arrive prior to the Waiting Time, the received timestamp for that 792 packet SHOULD be indicated as "not available", or post-processing may 793 be applied to enforce the constant Waiting Time to exclude long- 794 delayed packets and lost packets from further analysis. 796 6.5.2. No cross traffic, raw, Periodic, UDP loss metric 798 We define the No cross traffic, raw, Periodic, UDP loss metric as 799 follows: 800 o Identifier: TBD642 801 o Name: No cross-traffic, raw, Periodic, UDP latency 802 o Environment: No cross-traffic, access measurement 803 o Output type: raw 804 o Scheduling: Periodic 805 o Reference: draft-bagnulo-ippm-new-registry 807 The methodology for this metric is identical to Type-P-One-way-Delay- 808 Periodic-Stream in section 4 of [RFC3432], including parameters from 809 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 810 above in section 6.4. 812 The input parameters for this metric are: 813 o Source IP Address 814 o Destination IP Address 815 o Source UDP port 816 o Destination UDP port 817 o Beginning of testing interval, T 818 o Initial time T0 (including a random offset from the beginning of 819 T) 821 o Ending time Tf 823 Variable aspects of Type-P are: 824 o DSCP value 825 o UDP Payload length 827 The output of this metric is a list of elements. Each element 828 corresponds to one packet sent. Each element contains the timestamp 829 of the sent packet and the time when the packet was received at the 830 destination (from which the one-way delay can be calculated). The 831 methodology's sequence number MAY be included. For packets which do 832 not arrive prior to the Waiting Time, the received timestamp for that 833 packet SHOULD be indicated as "not available", or post-processing may 834 be applied to enforce the constant Waiting Time to exclude long- 835 delayed packets and lost packets from further analysis. 837 Note that the same raw output format MAY serve both loss and delay 838 metrics. 840 6.5.3. No cross traffic, raw, Periodic, UDP, PDV metric 842 We define the No cross traffic, Periodic, UDP Packet Delay Variation 843 metric as follows: 844 o Identifier: TBD643 845 o Name: No cross-traffic, Periodic, UDP PDV 846 o Environment: No cross-traffic, access measurement 847 o Output type: raw 848 o Scheduling: Periodic 849 o Reference: draft-bagnulo-ippm-new-registry 851 The methodology for the delay singletons from which this metric is 852 derived take the first steps defined as Type-P-One-way-Delay- 853 Periodic-Stream in section 4 of [RFC3432], including parameters from 854 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 855 above in section 6.4. This collects the one-way delay singletons. 857 The next step in the methodology follows from sections 2 and 3 of 858 [RFC3393] (which describes how to use a selection function to 859 determine pairs of packets to derive PDV) and section 4.2 of 860 [RFC5481], where the packet with the minimum delay is specified as a 861 fixed member of the pair. 863 The input parameters for this metric are: 864 o Source IP Address 865 o Destination IP Address 866 o Source UDP port 867 o Destination UDP port 868 o Beginning of testing interval, T 869 o Initial time T0 (including a random offset from the beginning of 870 T) 871 o Ending time Tf 873 Variable aspects of Type-P are: 874 o DSCP value 875 o UDP Payload length 877 The output of this metric is a list of triples (3 elements). Each 878 element corresponds to one packet in the sample. Each element 879 contains the one way delay of the first packet in the pair, the one 880 way delay of the second packet in the pair (having minimum delay), 881 and the variation in transmission time calculated for packet with 882 sequence number i as PDV(i) = D(i)-D(min). The methodology's 883 sequence number MAY be included. For packets which do not arrive 884 prior to the Waiting Time, the delay for that packet and its PDV 885 SHOULD be indicated as "not available" (following section 4.1 of 886 [RFC3393]). 888 6.5.4. No cross traffic, Periodic, UDP PDV:99.9 metric 890 We define the No cross traffic, Periodic, UDP Packet Delay Variation 891 (99.9 percentile) metric as follows: 892 o Identifier: TBD644 893 o Name: No cross-traffic, Periodic, UDP PDV:99.9 894 o Environment: No cross-traffic, access measurement 895 o Output type: 99.9 percentile 896 o Scheduling: Periodic 897 o Reference: draft-bagnulo-ippm-new-registry 899 The methodology for the delay singletons from which this metric is 900 derived take the first steps defined as Type-P-One-way-Delay- 901 Periodic-Stream in section 4 of [RFC3432], including parameters from 902 section 3 of [RFC3432] and using the Type-P and Waiting Time defined 903 above in section 6.4. This collects the one-way delay singletons. 905 The next step in the methodology follows from sections 2 and 3 of 906 [RFC3393] (which describes how to use a selection function to 907 determine pairs of packets to derive PDV) and section 4.2 of 908 [RFC5481], where the packet with the minimum delay is specified as a 909 fixed member of the pair. 911 The input parameters for this metric are: 912 o Source IP Address 913 o Destination IP Address 914 o Source UDP port 915 o Destination UDP port 916 o Beginning of testing interval, T 917 o Initial time T0 (including a random offset from the beginning of 918 T) 919 o Ending time Tf 921 Variable aspects of Type-P are: 922 o DSCP value 923 o UDP Payload length 925 The output of this metric is a single value corresponding to the 926 99.9th percentile of PDV. For packets which do not arrive prior to 927 the Waiting Time, the delay for that packet and its PDV SHOULD be 928 indicated as "not available" (following section 4.1 of [RFC3393]). 929 If the 99.9th percentile of singletons corresponds to packet whose 930 delay and PDV are "not available", then the output of this metric is 931 "not available". 933 6.5.5. No cross traffic, Periodic UDP packet-loss ratio metric 935 We define the No cross traffic, Periodic, UDP packet-loss ratio 936 metric as follows: 937 o Identifier: TBD645 938 o Name: No cross-traffic, Periodic, UDP packet-loss ratio 939 o Environment: No cross-traffic, access measurement 940 o Output type: X percentile mean 941 o Scheduling: Periodic 942 o Reference: draft-bagnulo-ippm-new-registry 944 This metric is defined as Type-P-One-way-Loss-Average in Section 4.1 945 of[RFC2680] using the Type-P and Waiting Time defined in section 6.4 946 above. 948 The input parameters for this metric are: 949 o Source IP Address 950 o Destination IP Address 951 o Source UDP port 952 o Destination UDP port 953 o Beginning of testing interval, T 954 o Initial time T0 (including a random offset from the beginning of 955 T) 956 o Ending time Tf 957 o X percentile mean: 100 959 Variable aspects of Type-P are: 961 o DSCP value 962 o UDP Payload length 963 The output of this metric is one value that corresponds to the ratio 964 of lost packets divided by the total number of packets sent. This 965 can be calculated from the singleton elements of section 6.4.2 above, 966 assigning the logical value "0" to packets with a valid one-way delay 967 and the value "1" to all packets whose one-way delay is recorded as 968 "not available". As section 4.1 of [RFC2680] indicates, the average 969 of all the logical values is the ratio of lost to total packets. 971 7. Security considerations 973 TBD 975 8. IANA Considerations 977 TBD 979 9. Acknowledgments 981 We would like to thank Henning Schulzrinne for many constructive 982 comments and input on early versions of this document. 984 10. References 986 10.1. Normative References 988 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 989 "Framework for IP Performance Metrics", RFC 2330, 990 May 1998. 992 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 993 performance measurement with periodic streams", RFC 3432, 994 November 2002. 996 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 997 Delay Metric for IPPM", RFC 2681, September 1999. 999 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 1000 August 2012. 1002 [RFC1035] Mockapetris, P., "Domain names - implementation and 1003 specification", STD 13, RFC 1035, November 1987. 1005 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1006 Time Protocol Version 4: Protocol and Algorithms 1007 Specification", RFC 5905, June 2010. 1009 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1010 Delay Metric for IPPM", RFC 2679, September 1999. 1012 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1013 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1015 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1016 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1017 November 2002. 1019 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 1020 Applicability Statement", RFC 5481, March 2009. 1022 10.2. Informative References 1024 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1025 Registry", BCP 108, RFC 4148, August 2005. 1027 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 1028 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 1029 April 2011. 1031 Authors' Addresses 1033 Marcelo Bagnulo 1034 Universidad Carlos III de Madrid 1035 Av. Universidad 30 1036 Leganes, Madrid 28911 1037 SPAIN 1039 Phone: 34 91 6249500 1040 Email: marcelo@it.uc3m.es 1041 URI: http://www.it.uc3m.es 1043 Trevor Burbridge 1044 British Telecom 1045 Adastral Park, Martlesham Heath 1046 Ipswich 1047 ENGLAND 1049 Email: trevor.burbridge@bt.com 1050 Sam Crawford 1051 SamKnows 1053 Email: sam@samknows.com 1055 Philip Eardley 1056 British Telecom 1057 Adastral Park, Martlesham Heath 1058 Ipswich 1059 ENGLAND 1061 Email: philip.eardley@bt.com 1063 Al Morton 1064 AT&T Labs 1065 200 Laurel Avenue South 1066 Middletown, NJ 1067 USA 1069 Email: acmorton@att.com