idnits 2.17.00 (12 Aug 2021) /tmp/idnits5875/draft-morton-ippm-registry-pdv-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2013) is 3183 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: 'RFC2680' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 602, 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) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Standards Track August 26, 2013 5 Expires: February 27, 2014 7 A Registry Investigation for IPPM Packet Delay Variation Metrics 8 draft-morton-ippm-registry-pdv-00 10 Abstract 12 This memo investigates a scheme to organize registry entries, 13 primarily those defined in RFCs prepared in the IP Performance 14 Metrics (IPPM) Working Group of the IETF. Three aspects make IPPM 15 metric registration difficult: (1) Use of the Type-P notion to allow 16 users to specify their own packet types. (2) Use of Flexible input 17 variables, called Parameters in IPPM definitions, some which 18 determine the quantity measured and others which should not be 19 specified until execution of the measurement. (3) Allowing 20 flexibility in choice of statistics to summarize the results on a 21 stream of measurement packets. Specifically, this memo investigates 22 registry entries that would follow from RFC 3393, the specification 23 IP Packet Delay Variation that allows for many different forms of 24 unique metrics, as a difficult and important test of the registry 25 structure. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 27, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. List of Registry Columns . . . . . . . . . . . . . . . . . . . 5 69 3.1. Element ID . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Run-time Parameters . . . . . . . . . . . . . . . . . . . 6 72 3.4. Fixed Parameters . . . . . . . . . . . . . . . . . . . . . 6 73 3.5. Metric Definition . . . . . . . . . . . . . . . . . . . . 6 74 3.6. Metric Units (and Data Format?) . . . . . . . . . . . . . 6 75 3.7. Stream Type and Stream Parameters . . . . . . . . . . . . 6 76 3.8. Method of Measurement . . . . . . . . . . . . . . . . . . 7 77 3.9. Output Statistic . . . . . . . . . . . . . . . . . . . . . 7 78 3.10. Discussion/Remarks . . . . . . . . . . . . . . . . . . . . 7 79 4. Registry Column Entries for PDV . . . . . . . . . . . . . . . 7 80 4.1. Element ID . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.3. Run-time Parameters . . . . . . . . . . . . . . . . . . . 7 83 4.4. Fixed Parameters . . . . . . . . . . . . . . . . . . . . . 8 84 4.5. Metric Definition . . . . . . . . . . . . . . . . . . . . 8 85 4.6. Metric Units (and Data Format?) . . . . . . . . . . . . . 8 86 4.7. Stream Type and Stream Parameters . . . . . . . . . . . . 9 87 4.8. Method of Measurement . . . . . . . . . . . . . . . . . . 9 88 4.9. Output Statistic . . . . . . . . . . . . . . . . . . . . . 9 89 4.10. Discussion/Remarks . . . . . . . . . . . . . . . . . . . . 9 90 5. Registry Column Entries for IPDV . . . . . . . . . . . . . . . 10 91 5.1. Element ID . . . . . . . . . . . . . . . . . . . . . . . . 10 92 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10 93 5.3. Run-time Parameters . . . . . . . . . . . . . . . . . . . 10 94 5.4. Fixed Parameters . . . . . . . . . . . . . . . . . . . . . 11 95 5.5. Metric Definition . . . . . . . . . . . . . . . . . . . . 11 96 5.6. Metric Units (and Data Format?) . . . . . . . . . . . . . 11 97 5.7. Stream Type and Stream Parameters . . . . . . . . . . . . 11 98 5.8. Method of Measurement . . . . . . . . . . . . . . . . . . 12 99 5.9. Output Statistic . . . . . . . . . . . . . . . . . . . . . 12 100 5.10. Discussion/Remarks . . . . . . . . . . . . . . . . . . . . 12 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 102 6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 12 103 6.2. User Data Confidentiality . . . . . . . . . . . . . . . . 13 104 6.3. Interference with the metrics . . . . . . . . . . . . . . 13 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 108 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 109 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 1. Introduction 114 This memo investigates a scheme to organize registry entries, 115 primarily those defined in RFCs prepared in the IP Performance 116 Metrics (IPPM) Working Group of the IETF, according to their 117 framework [RFC2330]. Three aspects make IPPM metric registration 118 difficult: (1) Use of the Type-P notion to allow users to specify 119 their own packet types. (2) Use of Flexible input variables, called 120 Parameters in IPPM definitions, some which determine the quantity 121 measured and others which should not be specified until execution of 122 the measurement. (3) Allowing flexibility in choice of statistics to 123 summarize the results on a stream of measurement packets. 124 Specifically, this memo investigates registry entries that would 125 follow from [RFC3393], the specification IP Packet Delay Variation 126 that allows for many different forms of unique metrics, as a 127 difficult and important test of the registry structure. 129 Although there are several standard templates for organizing 130 specifications of performance metrics (see [RFC2679] for an example 131 of the traditional IPPM template, based to large extent on the 132 Benchmarking Methodology Working Group's traditional template in 133 [RFC1242], and [RFC6390] for a similar template), none of these 134 templates were intended to become the basis for the columns of an 135 IETF-wide registry of metrics. As we examine the aspects of metric 136 specifications which need to appear in the registry, we will see that 137 none of the existing metric templates fully satisfies the needs of a 138 registry. 140 The authors of [draft-bagnulo-ippm-new-registry] and 141 [draft-bagnulo-ippm-new-registry-independent] made important 142 contributions to this memo in the registry column structure, and the 143 problem of registry development in general. We also acknowledge 144 input from the authors of [draft-claise-ippm-perf-metric-registry], 145 especially the value of an Element ID and the need for naming 146 conventions. 148 2. Scope 150 This memo investigates the registry structure that best describes 151 IPPM delay variation metrics based on [RFC3393] using the conventions 152 of the IPPM framework [RFC2330]. 154 We find that the flexibility allowed in [RFC3393] requires further 155 specificity to have a metric worthy of registration, and we refer to 156 [RFC5481] for the needed definition details. 158 In this memo, we attempt a combinatoric registry, where all factors 159 that can be reasonably specified ARE specified, and changing even one 160 factor would require a new registry entry (row). It is believed that 161 this exercise can also be instructive for a registry based on 162 independent factors, [draft-bagnulo-ippm-new-registry-independent] 163 but that topic is beyond the scope of this effort. 165 3. List of Registry Columns 167 This section briefly describes the columns used by this draft, as 168 this is likely to be a topic for discussion and revision. Taken as a 169 whole, the entries in the columns give a registered instance of a 170 metric with sufficient specificity to promote comparable results 171 across independent implementations. In other words, a complete 172 Metric Description. 174 3.1. Element ID 176 An integer having enough digits to uniquely identify each entry in 177 the Registry. 179 3.2. Metric Name 181 A metric naming convention is TBD. 183 The current guidance from Section 13 of [RFC2330], where Type-P is a 184 feature of all IPPM metric names, is: 186 "... we introduce the generic notion of a "packet of type P", where 187 in some contexts P will be explicitly defined (i.e., exactly what 188 type of packet we mean), partially defined (e.g., "with a payload of 189 B octets"), or left generic. Thus we may talk about generic IP-type- 190 P-connectivity or more specific IP-port-HTTP-connectivity. Some 191 metrics and methodologies may be fruitfully defined using generic 192 type P definitions which are then made specific when performing 193 actual measurements. Whenever a metric's value depends on the type 194 of the packets involved in the metric, the metric's name will include 195 either a specific type or a phrase such as "type-P". ..." 197 Registry entries are a context where Type-P must be defined. 199 IPPM Metric names have also included the typically included the 200 stream type, to distinguish between singleton and sample metrics (see 201 [RFC2330] for the definition of these terms). 203 3.3. Run-time Parameters 205 Run-Time Parameters are input factors that must be determined, 206 configured into the measurement system, and reported with the results 207 for the context to be complete. However, the values of these 208 parameters is not specified in the Registry, rather these parameters 209 are listed as an aid to the measurement system implementor or user 210 (they must be left as variables, and supplied on execution). 212 Where metrics supply a list of Parameters as part of their 213 descriptive template, a sub-set of the Parameters will be designated 214 as Run-Time Parameters. 216 3.4. Fixed Parameters 218 Fixed Parameters are input factors that must be determined and 219 embedded in the measurement system for use when needed. The values 220 of these parameters is specified in the Registry. 222 Where metrics supply a list of Parameters as part of their 223 descriptive template, a sub-set of the Parameters will be designated 224 as Fixed Parameters. 226 A Parameter which is Fixed for one Registry element may be designated 227 as a Run-time Parameter for another Registry element. 229 3.5. Metric Definition 231 This entry provides references to relevant sections of the RFC(s) 232 defining the metric, as well as any supplemental information needed 233 to ensure an unambiguous definition for implementations. 235 3.6. Metric Units (and Data Format?) 237 The results of a metric must be expressed using some standard 238 dimension or units of measure. This column provides the units (and 239 if possible, the data format, whose specification will simplify both 240 measurement implementation and collection/storage tasks). 242 When a sample of singletons is collected, this entry will include the 243 data format and units of measure for each measured value. 245 3.7. Stream Type and Stream Parameters 247 Principally, two different streams are used in IPPM metrics, Poisson 248 distributed as described in [RFC2330] and Periodic as described in 249 [RFC3432]. Both Poisson and Periodic have their own unique 250 parameters, and the relevant set is specified in as Fixed Parameters 251 in this column. 253 3.8. Method of Measurement 255 This entry provides references to relevant sections of the RFC(s) 256 describing the method of measurement, as well as any supplemental 257 information needed to ensure an unambiguous methods for 258 implementations. 260 3.9. Output Statistic 262 For entries which involve a stream and many singleton measurements, a 263 statistic may be specified in this column to summarize the results to 264 a single value. 266 3.10. Discussion/Remarks 268 Besides providing additional details which do not appear in other 269 columns, the Discussion/Remarks column allows for unforeseen issues 270 to be addressed by simply updating this Informational column. 272 4. Registry Column Entries for PDV 274 This is a complete Metric Description for one Packet Delay Variation 275 (PDV) metric. 277 4.1. Element ID 279 An integer with enough digits to uniquely identify the entry. 281 4.2. Metric Name 283 A metric naming convention is TBD. 285 One possibility based on IPPM's framework is: 287 IP-UDP-One-way-pdv-95th-percentile-Poisson 289 4.3. Run-time Parameters 291 Where metrics supply a list of Parameters as part of their 292 descriptive template, a sub-set of the Parameters will be designated 293 as Run-Time Parameters. 295 o Src, the IP address of a host 296 o Dst, the IP address of a host 298 o T, a time (start of test interval) 300 o Tf, a time (end of test interval) 302 o T1, the wire time of the first packet in a pair, measured at 303 MP(Src) as it leaves for Dst. 305 o T2, the wire time of the second packet in a pair, measured at 306 MP(Src) as it leaves for Dst. 308 o I(i),I(i+1), i >=0, pairs of times which mark the beginning and 309 ending of the intervals in which the packet stream from which the 310 measurement is taken occurs. Here, I(0) = T0 and assuming that n 311 is the largest index, I(n) = Tf. 313 4.4. Fixed Parameters 315 Where metrics supply a list of Parameters as part of their 316 descriptive template, a sub-set of the Parameters will be designated 317 as Fixed Parameters. 319 o F, a selection function defining unambiguously the packets from 320 the stream selected for the metric. See section 4.2 of [RFC5481] 321 for the PDV form. 323 o L, a packet length in bits. L = 200 bits. 325 o Tmax, a maximum waiting time for packets to arrive at Dst, set 326 sufficiently long to disambiguate packets with long delays from 327 packets that are discarded (lost). Tmax = 3 seconds. 329 o Type-P, as defined in [RFC2330], which includes any field that may 330 affect a packet's treatment as it traverses the network. The 331 packets are IP/UDP, with DSCP = 0 (BE). 333 4.5. Metric Definition 335 See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences 336 measured are referred to by the variable name "ddT". 338 4.6. Metric Units (and Data Format?) 340 See section 3.3 of [RFC3393] for singleton elements. 342 [RFC2330] recommends that when a time is given, it will be expressed 343 in UTC. 345 The timestamp format (for T, Tf, etc.) is the same as in [RFC5905] 346 (64 bits) and is as follows: the first 32 bits represent the unsigned 347 integer number of seconds elapsed since 0h on 1 January 1900; the 348 next 32 bits represent the fractional part of a second that has 349 elapsed since then. 351 The result format for ddT is *similar to* the short format in 352 [RFC5905] (32 bits) and is as follows: the first 16 bits represent 353 the *signed* integer number of seconds; the next 16 bits represent 354 the fractional part of a second. 356 4.7. Stream Type and Stream Parameters 358 Poisson distributed as described in [RFC2330], with the following 359 Parameters. 361 o lambda, a rate in reciprocal seconds (for Poisson Streams). lambda 362 = 1 packet per second 364 o Upper limit on Poisson distribution (values above this limit will 365 be clipped and set to the limit value). Upper limit = 30 seconds. 367 4.8. Method of Measurement 369 See section 2.6 and 3.6 of [RFC3393] for singleton elements. 371 4.9. Output Statistic 373 See section 4.3 of [RFC3393] for details on the percentile statistic. 374 The percentile = 95. 376 Individual results (singletons) should be represented by the 377 following triple 379 o T1 and T2, times as described above 381 o ddT as defined in section 2.4 of [RFC3393] 383 if needed. 385 4.10. Discussion/Remarks 387 Lost packets represent a challenge for delay variation metrics. See 388 section 4.1 of [RFC3393] and the delay variation applicability 389 statement[RFC5481] for extensive analysis and comparison of PDV and 390 IPDV. 392 5. Registry Column Entries for IPDV 394 This is a complete Metric Description for one Inter-Packet Delay 395 Variation (IPDV) metric. 397 5.1. Element ID 399 An integer with enough digits to uniquely identify the entry. 401 5.2. Metric Name 403 A metric naming convention is TBD. 405 One possibility based on IPPM's framework is: 407 IP-UDP-One-way-ipdv-range-Periodic 409 5.3. Run-time Parameters 411 Where metrics supply a list of Parameters as part of their 412 descriptive template, a sub-set of the Parameters will be designated 413 as Run-Time Parameters. 415 o Src, the IP address of a host 417 o Dst, the IP address of a host 419 o T, the beginning of a time interval where a periodic sample is 420 desired. 422 o T0, a time that MUST be selected at random from the interval [T, 423 T+PdT] to start generating packets and taking measurements (start 424 of test interval) 426 o Tf, a time, greater than T0, for stopping generation of packets 427 for a sample (Tf may be relative to T0 if desired). 429 o T1, the wire time of the first packet in a pair, measured at 430 MP(Src) as it leaves for Dst. 432 o T2, the wire time of the second packet in a pair, measured at 433 MP(Src) as it leaves for Dst. 435 o I(i),I(i+1), i >=0, pairs of times which mark the beginning and 436 ending of the intervals in which the packet stream from which the 437 measurement is taken occurs. Here, I(0) = T0 and assuming that n 438 is the largest index, I(n) = Tf. 440 5.4. Fixed Parameters 442 Where metrics supply a list of Parameters as part of their 443 descriptive template, a sub-set of the Parameters will be designated 444 as Fixed Parameters. 446 o F, a selection function defining unambiguously the packets from 447 the stream selected for the metric. See section 4.1 of [RFC5481] 448 for the IPDV form. 450 o L, a packet length in bits. L = 200 bits. 452 o Tmax, a maximum waiting time for packets to arrive at Dst, set 453 sufficiently long to disambiguate packets with long delays from 454 packets that are discarded (lost). Tmax = 3 seconds. 456 o Type-P, as defined in [RFC2330], which includes any field that may 457 affect a packet's treatment as it traverses the network. The 458 packets are IP/UDP, with DSCP = 0 (BE). 460 5.5. Metric Definition 462 See section 3.4 of [RFC3393]. 464 5.6. Metric Units (and Data Format?) 466 See section 3.3 of [RFC3393] for singleton elements. 468 [RFC2330] recommends that when a time is given, it will be expressed 469 in UTC. 471 The timestamp format (for T, Tf, etc.) is the same as in [RFC5905] 472 (64 bits) and is as follows: the first 32 bits represent the unsigned 473 integer number of seconds elapsed since 0h on 1 January 1900; the 474 next 32 bits represent the fractional part of a second that has 475 elapsed since then. 477 The result format for ddT is *similar to* the short format in 478 [RFC5905] (32 bits) and is as follows: the first 16 bits represent 479 the *signed* integer number of seconds; the next 16 bits represent 480 the fractional part of a second (resolving 15 microseconds). 482 5.7. Stream Type and Stream Parameters 484 Periodic distributed as described in [RFC3432], with the following 485 Parameters. 487 o incT, the nominal duration of inter-packet interval, first bit to 488 first bit (for Periodic Streams). incT = 1 second (per packet) 490 o PdT, the duration of the interval for allowed sample start times. 491 T0 may be drawn from a uniform distribution, such as T0 = T + 492 Unif(0,PdT), or other distribution for PdT. 494 5.8. Method of Measurement 496 See section 2.6 and 3.6 of [RFC3393] for singleton elements. 498 5.9. Output Statistic 500 See sections 5.2 and 6.5 of [RFC5481] for details on the range 501 statistic, or max(ddT) - min(ddT). Note that min(ddT) will almost 502 always be a negative value. 504 Individual results (singletons) should be represented by the 505 following triple 507 o T1 and T2, times as described above 509 o ddT as defined in section 2.4 of [RFC3393] 511 if needed. 513 5.10. Discussion/Remarks 515 Lost packets represent a challenge for delay variation metrics. See 516 section 4.1 of [RFC3393] and the delay variation applicability 517 statement[RFC5481] for extensive analysis and comparison of PDV and 518 IPDV. 520 6. Security Considerations 522 6.1. Denial of Service Attacks 524 The metrics in this memo require a stream of packets sent from one 525 host (source) to another host (destination) through intervening 526 networks, and back. This method could be abused for denial of 527 service attacks directed at the destination and/or the intervening 528 network(s). 530 Administrators of source, destination, and the intervening network(s) 531 should establish bilateral or multi-lateral agreements regarding the 532 timing, size, and frequency of collection of sample metrics. Use of 533 this method in excess of the terms agreed between the participants 534 may be cause for immediate rejection or discard of packets or other 535 escalation procedures defined between the affected parties. 537 6.2. User Data Confidentiality 539 Active use of this method generates packets for a sample, rather than 540 taking samples based on user data, and does not threaten user data 541 confidentiality. 543 6.3. Interference with the metrics 545 It may be possible to identify that a certain packet or stream of 546 packets is part of a sample. With that knowledge at the destination 547 and/or the intervening networks, it is possible to change the 548 processing of the packets (e.g. increasing or decreasing delay) in a 549 way that may distort the measured performance. It may also be 550 possible to generate additional packets that appear to be part of the 551 sample metric. These additional packets are likely to perturb the 552 results of the sample measurement. 554 Authentication or encryption techniques, such as digital signatures, 555 MAY be used where appropriate to guard against injected traffic 556 attacks. [RFC5357] includes both authentication and encryption 557 features. 559 7. IANA Considerations 561 Metrics previously defined in IETF were registered in the IANA IPPM 562 METRICS REGISTRY, however this process was discontinued when the 563 registry structure was found to be inadequate, and the registry was 564 declared Obsolete [RFC6248]. 566 Although the metrics in this draft may be considered for some form of 567 registration in the future, no IANA Action is requested at this time. 569 8. Acknowledgements 571 The author thanks Brian Trammell for suggesting the term "Run-time 572 Parameters", which led to the distinction between run-time and fixed 573 parameters implemented in this memo. 575 9. References 576 9.1. Normative References 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 582 "Framework for IP Performance Metrics", RFC 2330, 583 May 1998. 585 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 586 Delay Metric for IPPM", RFC 2679, September 1999. 588 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 589 Packet Loss Metric for IPPM", RFC 2680, September 1999. 591 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 592 Delay Metric for IPPM", RFC 2681, September 1999. 594 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 595 Metric for IP Performance Metrics (IPPM)", RFC 3393, 596 November 2002. 598 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 599 performance measurement with periodic streams", RFC 3432, 600 November 2002. 602 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 603 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 604 November 2006. 606 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 607 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 608 RFC 5357, October 2008. 610 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 611 Time Protocol Version 4: Protocol and Algorithms 612 Specification", RFC 5905, June 2010. 614 9.2. Informative References 616 [RFC1242] Bradner, S., "Benchmarking terminology for network 617 interconnection devices", RFC 1242, July 1991. 619 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 620 Applicability Statement", RFC 5481, March 2009. 622 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 623 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 624 April 2011. 626 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 627 Performance Metric Development", BCP 170, RFC 6390, 628 October 2011. 630 Author's Address 632 Al Morton 633 AT&T Labs 634 200 Laurel Avenue South 635 Middletown,, NJ 07748 636 USA 638 Phone: +1 732 420 1571 639 Fax: +1 732 368 1192 640 Email: acmorton@att.com 641 URI: http://home.comcast.net/~acmacm/