idnits 2.17.1 draft-ietf-ippm-rt-loss-05.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 (May 8, 2012) is 4369 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 May 8, 2012 5 Expires: November 9, 2012 7 Round-trip Packet Loss Metrics 8 draft-ietf-ippm-rt-loss-05 10 Abstract 12 Many user applications (and the transport protocols that make them 13 possible) require two-way communications. To assess this capability, 14 and to achieve test system simplicity, round-trip loss measurements 15 are frequently conducted in practice. The Two-Way Active Measurement 16 Protocol specified in RFC 5357 establishes a round-trip loss 17 measurement capability for the Internet. However, there is currently 18 no metric specified according to the RFC 2330 framework. 20 This memo adds round-trip loss to the set of IP Performance Metrics 21 (IPPM). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 9, 2012. 46 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Common Specifications for Round-trip Metrics . . . . . . . . . 4 66 3.1. Name: Type-P-* . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 5 69 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 6 71 4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 6 72 4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 73 4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6 74 4.4. Discussion and other details . . . . . . . . . . . . . . . 7 75 5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7 76 5.1. Name: Type-P-Round-trip-Loss--Stream . . . . . . . 8 77 5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8 78 5.3. Definition and Metric Units . . . . . . . . . . . . . . . 8 79 5.4. Discussion and other details . . . . . . . . . . . . . . . 8 80 6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 9 81 6.1. Type-P-Round-trip-Loss--Ratio . . . . . . . . . . 9 82 7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9 83 8. Measurement Considerations and Calibration . . . . . . . . . . 10 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 11 86 9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 11 87 9.3. Interference with the metrics . . . . . . . . . . . . . . 11 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 This memo defines a metric to quantify an IP network's ability to 98 transfer packets in both directions from one host to another host. 99 Two-way communication is almost always needed, thus failure to 100 transfer a packet in either direction constitutes a round-trip packet 101 loss. 103 This memo defines a metric for round-trip packet loss on Internet 104 paths. It builds on the notions and conventions introduced in the IP 105 Performance Metrics (IPPM) framework [RFC2330]. Also, the 106 specifications of the One-way Packet Loss Metric for IPPM [RFC2680] 107 and the Round-trip Delay Metric for IPPM [RFC2681] are frequently 108 referenced and modified to match the round-trip circumstances 109 addressed here. However, this memo assumes that the reader is 110 familiar with the references, and does not repeat material as was 111 done in [RFC2681]. 113 This memo uses the terms "two-way" and "round-trip" synonymously. 115 1.1. Motivation 117 Many user applications and the transport protocols that make them 118 possible require two-way communications. For example, the TCP SYN->, 119 <-SYN-ACK, ACK-> three-way handshake attempted billions of times each 120 day cannot be completed without two-way connectivity in a near- 121 simultaneous time interval. Thus, measurements of Internet round- 122 trip packet loss performance provide a basis to infer application 123 performance more easily. 125 Measurement system designers have also recognized advantages of 126 system simplicity when one host simply echoes or reflects test 127 packets to the sender. Round-trip packet loss measurements are 128 frequently conducted and reported in practice. The ubiquitous "ping" 129 tools allow the measurement of round-trip packet loss and delay, but 130 usually require ICMP Echo-Request/Reply support, and ICMP packets may 131 encounter exceptional treatment on the measurement path (see Section 132 2.6 of [RFC2681]). The Two-Way Active Measurement Protocol (TWAMP) 133 specified in [RFC5357] establishes a round-trip packet loss 134 measurement capability for the Internet. However, there is currently 135 no round-trip packet loss metric specified according to the [RFC2330] 136 framework. 138 [RFC2681] indicates that round-trip measurements may sometimes 139 encounter "asymmetric" paths. When loss is observed using a round- 140 trip measurement, there is often a desire to ascertain which of the 141 two directional paths "lost" the packet. Under some circumstances, 142 it is possible to make this inference. The round-trip measurement 143 method raises a few complications when interpreting the embedded one- 144 way results, and the user should be aware of them. 146 [RFC2681] also points out that loss measurement conducted 147 sequentially in both directions of a path and reported as a round- 148 trip result may be exactly the desired metric. On the other hand, it 149 may be difficult to derive the state of round-trip packet loss from 150 one-way measurements conducted in each direction unless a method to 151 match the appropriate one-way measurements has been pre-arranged. 153 Finally, many measurement systems report statistics on a conditional 154 delay distribution, where the condition is packet arrival at the 155 destination. This condition is encouraged in [RFC3393], [RFC5481], 156 and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets 157 need to be reported separately, according to a standardized metric. 158 This memo defines such a metric. 160 See Section 1.1 of[RFC2680] for additional motivation of the packet 161 loss metric. 163 2. Scope 165 This memo defines a round-trip packet loss metric using the 166 conventions of the IPPM framework [RFC2330]. 168 The memo defines a singleton metric, a sample metric, and a 169 statistic, as per [RFC2330]. The [RFC2330] framework is for active 170 measurement methods. Although this metric MAY be applicable in 171 passive measurement as well, discussion of additional considerations 172 for the passive scenario are beyond the normative scope of this memo. 174 The memo also investigates the topic of one-way loss inference from a 175 two-way measurement, and lists some key considerations. 177 3. Common Specifications for Round-trip Metrics 179 To reduce the redundant information presented in the detailed metrics 180 sections that follow, this section presents the specifications that 181 are common to two or more metrics. The section is organized using 182 the same subsections as the individual metrics, to simplify 183 comparisons. 185 3.1. Name: Type-P-* 187 All metrics use the Type-P convention as described in [RFC2330]. The 188 rest of the name is unique to each metric. 190 3.2. Metric Parameters 192 o Src, the IP address of a host 194 o Dst, the IP address of a host 196 o T, a time (start of test interval) 198 o Tf, a time (end of test interval) 200 o lambda, a rate in reciprocal seconds (for Poisson Streams) 202 o incT, the nominal duration of inter-packet interval, first bit to 203 first bit (for Periodic Streams) 205 o T0, a time that MUST be selected at random from the interval [T, 206 T+dT] to start generating packets and taking measurements (for 207 Periodic Streams) 209 o TstampSrc, the wire time of the packet as measured at MP(Src) as 210 it leaves for Dst. 212 o TstampDst, the wire time of the packet as measured at MP(Dst), 213 assigned to packets that arrive within a "reasonable" time (less 214 than Tmax). 216 o Tmax, a maximum waiting time for packets to arrive at Src, set 217 sufficiently long to disambiguate packets with long delays from 218 packets that are discarded (lost). 220 o M, the total number of packets sent between T0 and Tf 222 o N, the total number of packets received at Dst (sent between T0 223 and Tf) 225 o Type-P, as defined in [RFC2330], which includes any field that may 226 affect a packet's treatment as it traverses the network 228 3.3. Metric Definition 230 This section is specific to each metric. 232 3.4. Metric Units 234 The metric units are logical (1 or 0) when describing a single 235 packet's loss performance, where a 0 indicates successful packet 236 transmission and a 1 indicates packet loss. 238 Units of time are as specified in [RFC2330]. 240 Other units used are defined in the associated section. 242 4. A Singleton Round-trip Loss Metric 244 4.1. Name: Type-P-Round-trip-Loss 246 4.2. Metric Parameters 248 See section 3.2. 250 4.3. Definition and Metric Units 252 Type-P-Round-trip-Loss SHALL be represented by the binary logical 253 values (or their equivalents) when the following conditions are met: 255 Type-P-Round-trip-Loss = 0: 257 o Src sent the first bit of a Type-P packet to Dst at wire-time 258 TstampSrc, 260 o that Dst received that packet, 262 o the Dst sent a Type-P packet back to the Src as quickly as 263 possible (certainly less than Tmax, and fast enough for the 264 intended purpose), and 266 o that Src received the last bit of the reflected packet prior to 267 wire-time TstampSrc + Tmax. 269 Type-P-Round-trip-Loss = 1: 271 o Src sent the first bit of a Type-P packet to Dst at wire-time 272 TstampSrc, 274 o that Src did not receive the last bit of the reflected packet 275 before the waiting time lapsed at TstampSrc + Tmax. 277 Possible causes for the Loss = 1 outcome are: 279 o the Dst did not receive that packet, 281 o the Dst did not send a Type-P packet back to the Src, or 283 o the Src did not receive a reflected Type-P packet sent from the 284 Dst. 286 Following the precedent of Section 2.4 of[RFC2681], we make the 287 simplifying assertion, that Round-trip loss measured between two 288 hosts is equal regardless of the host that originates the test: 290 Type-P-Round-trip-Loss(Src->Dst->Src) = Type-P-Round-trip- 291 Loss(Dst->Src->Dst) 293 (and agree with the rationale presented there, that the ambiguity 294 introduced is a small price to pay for measurement efficiency). 296 Therefore, each singleton can be represented by pairs of elements as 297 follows: 299 o TstampSrc, the wire time of the packet at the Src (beginning the 300 round-trip journey). 302 o L, either zero or one (or some logical equivalent), where L=1 303 indicates loss and L=0 indicates successful round-trip arrival 304 prior to TstampSrc + Tmax. 306 4.4. Discussion and other details 308 See [RFC2680] and [RFC2681] for extensive discussion, methods of 309 measurement, errors and uncertainties, and other fundamental 310 considerations that need not be repeated here. 312 We add the following guidance regarding the responder process to 313 "send a Type-P packet back to the Src as quickly as possible". 315 A response that was not generated within Tmax is inadequate for any 316 realistic test, and the Src will discard such responses. A responder 317 that serves typical round-trip packet loss testing (which is relevant 318 to higher-layer application performance) SHOULD produce a response in 319 1 second or less. A responder that is unable to satisfy this 320 requirement SHOULD log the fact so that an operator can adjust the 321 load and priorities as necessary. Analysis of responder time-stamps 322 [RFC5357] that finds responses are not generated in a timely fashion 323 SHOULD result in operator notification, and the operator SHOULD 324 suspend tests to the responder since it may be overloaded. 325 Additional measurement considerations are described in Section 8, 326 below. 328 5. A Sample Round-trip Loss Metric 330 Given the singleton metric Type-P-Round-trip-Loss, we now define one 331 particular sample of such singletons. The idea of the sample is to 332 select a particular binding of the parameters Src, Dst, and Type-P, 333 then define a sample of values of parameter TstampSrc. This can be 334 done in several ways, including: 336 1. Poisson: a pseudo-random Poisson process of rate lambda, whose 337 values fall between T and Tf. The time interval between 338 successive values of TstampSrc will then average 1/lambda, as per 339 Section 11.1 of [RFC2330]. 341 2. Periodic: a periodic stream process with pseudo-random start time 342 T0 between T and dT, and nominal inter-packet interval incT, as 343 per [RFC3432]. 345 In the metric name, the variable SHALL be replaced with the 346 process used to define the sample, using one of the above processes 347 (or another sample process meeting the criteria in Section 11.1 of 348 [RFC2330], the details of which MUST be reported with the results if 349 used). 351 5.1. Name: Type-P-Round-trip-Loss--Stream 353 5.2. Metric Parameters 355 See section 3.2. 357 5.3. Definition and Metric Units 359 Given one of the methods for defining the test interval, the sample 360 of times (TstampSrc) and other metric parameters, we obtain a 361 sequence of Type-P-Round-trip-Loss singletons as defined in section 362 4.3. 364 Type-P-Round-trip-Loss--Stream SHALL be a sequence of pairs 365 with elements as follows: 367 o TstampSrc, as above 369 o L, either zero or one (or some logical equivalent), where L=1 370 indicates loss and L=0 indicates successful round-trip arrival 371 prior to TstampSrc + Tmax. 373 and where SHALL be replaced with "Poisson", "Periodic", or 374 an appropriate term to designate another sample method as described 375 in Section 5 above. 377 5.4. Discussion and other details 379 See [RFC2680] and [RFC2681] for extensive discussion, methods of 380 measurement, errors and uncertainties, and other fundamental 381 considerations that need not be repeated here. However, when these 382 references were approved, the packet reordering metrics in [RFC4737] 383 had not yet been defined, nor had reordering been addressed in IPPM 384 methodologies. 386 [RFC4737] defines packets that arrive "late" with respect to their 387 sending order as reordered. For example, when packets arrive with 388 sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and 389 they are obviously not lost because they have arrived within some 390 reasonable waiting time threshold. The presence of reordering on a 391 round-trip path has several likely effects on the measurement. 393 1. Methods of measurement should continue to wait the specified time 394 for packets, and avoid prematurely declaring round-trip packet 395 loss when a sequence gap or error is observed. 397 2. The time distribution of the singletons in the sample has been 398 significantly changed. 400 3. Either the original packet stream or the reflected packet stream 401 experienced path instability, and the original conditions may no 402 longer be present. 404 Measurement implementations MUST address the possibility for packet 405 reordering and avoid related errors in their processes. 407 6. Round-trip Loss Statistic 409 This section gives the primary and overall statistic for loss 410 performance. Additional statistics and metrics originally prepared 411 for One-way loss MAY also be applicable. 413 6.1. Type-P-Round-trip-Loss--Ratio 415 Given a Type-P-Round-trip-Loss--Stream, the average of all 416 the logical values, L, in the Stream is the Type-P-Round-trip-Loss- 417 -Ratio. This ratio is in units of lost packets per round- 418 trip transmissions actually attempted. 420 In addition, the Type-P-Round-trip-Loss--Ratio is undefined 421 if the sample is empty. 423 7. Round-trip Testing and One-way Reporting 425 This section raises considerations for results collected using a 426 round-trip measurement architecture, such as in TWAMP [RFC5357]. 428 The sampling process for the reverse path (Dst->Src) is a conditional 429 process that depends on successful packet arrival at the Dst and 430 correct operation at the Dst to generate the reflected packet. 431 Therefore, the sampling process for the reverse path will be 432 significantly affected when appreciable loss occurs on the Src->Dst 433 path, making an attempt to assess the reverse path performance 434 invalid (for loss or possibly any metric). 436 Further, the sampling times for the reverse path (Dst->Src) are a 437 random process that depends on the original sample times (TstampSrc), 438 the one-way-delay for successful packet arrival at the Dst, and time 439 taken at the Dst to generate the reflected packet. Therefore, the 440 sampling process for the reverse path will be significantly affected 441 when appreciable delay variation occurs on the Src->Dst path, making 442 an attempt to assess the reverse path performance invalid (for loss 443 or possibly any metric). 445 As discussed above in Section 5.4, packet reordering is always a 446 possibility. In addition to the severe delay variation that usually 447 accompanies it, reordering on the Src->Dst path will cause a mis- 448 alignment of sequence numbers applied at the Dst when compared to the 449 sender numbers. Measurement implementations MUST address this 450 possible outcome. 452 8. Measurement Considerations and Calibration 454 Prior to conducting this measurement, the participating hosts MUST be 455 configured to send and receive test packets of the chosen Type-P. 456 Standard measurement protocols are capable of this task [RFC5357], 457 but any reliable method is sufficient (e.g., if the issues with ICMP 458 discussed in Section 2.6 of[RFC2681] can be alleviated, and the 459 requirements of Section 4.3 and Section 4.4 above are met, then ICMP 460 could be used). 462 Two key features of the host that receives test packets and returns 463 them to the originating host are described in section 4.2 of 464 [RFC5357] . Every received test packet MUST result in a responding 465 packet, and the response MUST be generated as quickly as possible. 466 This implies that interface buffers will be serviced promptly, and 467 that buffer discards will be extremely rare. These features of the 468 measurement equipment MUST be calibrated according to Section 3.7.3 469 of [RFC2679], when operating under a representative measurement load 470 (as defined by the user). Both unexpected test packet discards, and 471 the systematic and random errors and uncertainties, MUST be recorded. 473 We note that Section 4.2.1 of [RFC5357] specifies a method to collect 474 all four significant time-stamps needed to describe a packet's round- 475 trip delay [RFC2681] and remove the processing time incurred at the 476 responding host. This information supports the measurement of the 477 corresponding One-way Delays encountered on the round-trip path, 478 which can identify path asymmetry or unexpected processing time at 479 the responding host. 481 9. Security Considerations 483 9.1. Denial of Service Attacks 485 This metric requires a stream of packets sent from one host (source) 486 to another host (destination) through intervening networks, and back. 487 This method could be abused for denial of service attacks directed at 488 the destination and/or the intervening network(s). 490 Administrators of source, destination, and the intervening network(s) 491 should establish bilateral or multi-lateral agreements regarding the 492 timing, size, and frequency of collection of sample metrics. Use of 493 this method in excess of the terms agreed between the participants 494 may be cause for immediate rejection or discard of packets or other 495 escalation procedures defined between the affected parties. 497 9.2. User Data Confidentiality 499 Active use of this method generates packets for a sample, rather than 500 taking samples based on user data, and does not threaten user data 501 confidentiality. Passive measurement must restrict attention to the 502 headers of interest. Since user payloads may be temporarily stored 503 for length analysis, suitable precautions MUST be taken to keep this 504 information safe and confidential. In most cases, a hashing function 505 will produce a value suitable for payload comparisons. 507 9.3. Interference with the metrics 509 It may be possible to identify that a certain packet or stream of 510 packets is part of a sample. With that knowledge at the destination 511 and/or the intervening networks, it is possible to change the 512 processing of the packets (e.g. increasing or decreasing delay) in a 513 way that may distort the measured performance. It may also be 514 possible to generate additional packets that appear to be part of the 515 sample metric. These additional packets are likely to perturb the 516 results of the sample measurement. 518 Authentication or encryption techniques, such as digital signatures, 519 MAY be used where appropriate to guard against injected traffic 520 attacks. [RFC5357] includes both authentication and encryption 521 features. 523 10. IANA Considerations 525 Metrics previously defined in IETF were registered in the IANA IPPM 526 METRICS REGISTRY, however this process was discontinued when the 527 registry structure was found to be inadequate, and the registry was 528 declared Obsolete [RFC6248]. 530 Although the metrics in this draft may be considered for some form of 531 registration in the future, no IANA Action is requested at this time. 533 11. Acknowledgements 535 The author thanks Tiziano Ionta for his careful review of this memo, 536 primarily resulting in the development of measurement considerations 537 using TWAMP [RFC5357] as an example method. The reviews of Adrian 538 Farrel and Benoit Claise also contributed to the clarity of the memo. 540 12. References 542 12.1. Normative References 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 548 "Framework for IP Performance Metrics", RFC 2330, 549 May 1998. 551 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 552 Delay Metric for IPPM", RFC 2679, September 1999. 554 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 555 Packet Loss Metric for IPPM", RFC 2680, September 1999. 557 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 558 Delay Metric for IPPM", RFC 2681, September 1999. 560 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 561 Metric for IP Performance Metrics (IPPM)", RFC 3393, 562 November 2002. 564 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 565 performance measurement with periodic streams", RFC 3432, 566 November 2002. 568 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 569 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 570 November 2006. 572 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 573 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 574 RFC 5357, October 2008. 576 12.2. Informative References 578 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 579 Applicability Statement", RFC 5481, March 2009. 581 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 582 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 583 April 2011. 585 Author's Address 587 Al Morton 588 AT&T Labs 589 200 Laurel Avenue South 590 Middletown,, NJ 07748 591 USA 593 Phone: +1 732 420 1571 594 Fax: +1 732 368 1192 595 Email: acmorton@att.com 596 URI: http://home.comcast.net/~acmacm/