idnits 2.17.1 draft-ietf-ippm-rt-loss-03.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 (March 1, 2012) is 4432 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 March 1, 2012 5 Expires: September 2, 2012 7 Round-trip Loss Metrics 8 draft-ietf-ippm-rt-loss-03 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 September 2, 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 . . . . . . . . . . . . . . . . . . . . 4 68 3.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 5 69 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 5 71 4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 5 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 . . . . . . . 7 77 5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 78 5.3. Definition and Metric Units . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 85 9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 10 86 9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 10 87 9.3. Interference with the metrics . . . . . . . . . . . . . . 11 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 1. Introduction 97 This memo defines a metric for round-trip loss on Internet paths. It 98 builds on the notions and conventions introduced in the IP 99 Performance Metrics (IPPM) framework [RFC2330]. Also, the 100 specifications of the One-way Loss metric [RFC2680] and the Round- 101 trip Delay metric [RFC2681] are frequently referenced and modified to 102 match the round-trip circumstances addressed here. However, this 103 memo assumes that the reader is familiar with the references, and 104 does not repeat material as was done in [RFC2681]. 106 This memo uses the terms "two-way" and "round-trip" synonymously. 108 1.1. Motivation 110 Many user applications and the transport protocols that make them 111 possible require two-way communications. For example, the TCP SYN->, 112 <-SYN-ACK, ACK-> three-way handshake attempted billions of times each 113 day cannot be completed without two-way connectivity in a near- 114 simultaneous time interval. Thus, measurements of Internet round- 115 trip loss performance provide a basis to infer application 116 performance more easily. 118 Measurement system designers have also recognized advantages of 119 system simplicity when one host simply echoes or reflects test 120 packets to the sender. Round-trip loss measurements are frequently 121 conducted and reported in practice. The Two-Way Active Measurement 122 Protocol (TWAMP) specified in [RFC5357] establishes a round-trip loss 123 measurement capability for the Internet. However, there is currently 124 no round-trip loss metric specified according to the [RFC2330] 125 framework. 127 [RFC2681] indicates that round-trip measurements may sometimes 128 encounter "asymmetric" paths. When loss is observed using a round- 129 trip measurement, there is often a desire to ascertain which of the 130 two directional paths "lost" the packet. Under some circumstances, 131 it is possible to make this inference. The round-trip measurement 132 method raises a few complications when interpreting the embedded one- 133 way results, and the user should be aware of them. 135 [RFC2681] also points out that loss measurement conducted 136 sequentially in both directions of a path and reported as a round- 137 trip result may be exactly the desired metric. On the other hand, it 138 may be difficult to derive the state of round-trip loss from one-way 139 measurements conducted in each direction unless a method to match the 140 appropriate one-way measurements has been pre-arranged. 142 Finally, many measurement systems report statistics on a conditional 143 delay distribution, where the condition is packet arrival at the 144 destination. This condition is encouraged in [RFC3393], [RFC5481], 145 and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets 146 need to be reported separately, according to a standardized metric. 147 This memo defines such a metric. 149 See Section 1.1 of[RFC2680] for additional motivation of the packet 150 loss metric. 152 2. Scope 154 This memo defines a round-trip loss metric using the conventions of 155 the IPPM framework [RFC2330]. 157 The memo defines a singleton metric, a sample metric, and a 158 statistic, as per [RFC2330]. 160 The memo also investigates the topic of one-way loss inference from a 161 two-way measurement, and lists some key considerations. 163 3. Common Specifications for Round-trip Metrics 165 To reduce the redundant information presented in the detailed metrics 166 sections that follow, this section presents the specifications that 167 are common to two or more metrics. The section is organized using 168 the same subsections as the individual metrics, to simplify 169 comparisons. 171 3.1. Name: Type-P-* 173 All metrics use the Type-P convention as described in [RFC2330]. The 174 rest of the name is unique to each metric. 176 3.2. Metric Parameters 178 o Src, the IP address of a host 180 o Dst, the IP address of a host 182 o T, a time (start of test interval) 184 o Tf, a time (end of test interval) 186 o lambda, a rate in reciprocal seconds (for Poisson Streams) 187 o incT, the nominal duration of inter-packet interval, first bit to 188 first bit (for Periodic Streams) 190 o T0, a time that MUST be selected at random from the interval [T, 191 T+dT] to start generating packets and taking measurements (for 192 Periodic Streams) 194 o TstampSrc, the wire time of the packet as measured at MP(Src) as 195 it leaves for Dst. 197 o TstampDst, the wire time of the packet as measured at MP(Dst), 198 assigned to packets that arrive within a "reasonable" time. 200 o Tmax, a maximum waiting time for packets to arrive, set 201 sufficiently long to disambiguate packets with long delays from 202 packets that are discarded (lost). 204 o M, the total number of packets sent between T0 and Tf 206 o N, the total number of packets received at Dst (sent between T0 207 and Tf) 209 o Type-P, as defined in [RFC2330], which includes any field that may 210 affect a packet's treatment as it traverses the network 212 3.3. Metric Definition 214 This section is specific to each metric. 216 3.4. Metric Units 218 The metric units are logical (1 or 0) when describing a single 219 packet's loss performance, where a 0 indicates successful packet 220 transmission and a 1 indicates packet loss. 222 Units of time are as specified in [RFC2330]. 224 Other units used are defined in the associated section. 226 4. A Singleton Round-trip Loss Metric 228 4.1. Name: Type-P-Round-trip-Loss 229 4.2. Metric Parameters 231 See section 3.2. 233 4.3. Definition and Metric Units 235 Type-P-Round-trip-Loss SHALL be represented by the binary logical 236 values (or their equivalents) when the following conditions are met: 238 Type-P-Round-trip-Loss = 0: 240 o Src sent the first bit of a Type-P packet to Dst at wire-time 241 TstampSrc, 243 o that Dst received that packet, 245 o the Dst sent a Type-P packet back to the Src as immediately as 246 possible, and 248 o that Src received the last bit of the reflected packet prior to 249 wire-time TstampSrc + Tmax. 251 Type-P-Round-trip-Loss = 1: 253 o Src sent the first bit of a Type-P packet to Dst at wire-time 254 TstampSrc, 256 o that Src did not receive the last bit of the reflected packet 257 before the waiting time lapsed at TstampSrc + Tmax. 259 Possible causes for the Loss = 1 outcome are: 261 o the Dst did not receive that packet, 263 o the Dst did not send a Type-P packet back to the Src, or 265 o the Src did not receive a reflected Type-P packet sent from the 266 Dst. 268 Following the precedent of[RFC2681], we make the simplifying 269 assertion: 271 Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src) 273 (and agree with the rationale presented there, that the ambiguity 274 introduced is a small price to pay for measurement efficiency). 276 Therefore, each singleton can be represented by pairs of elements as 277 follows: 279 o TstampSrc, the wire time of the packet at the Src (beginning the 280 round-trip journey). 282 o L, either zero or one (or some logical equivalent), where L=1 283 indicates loss and L=0 indicates successful round-trip arrival 284 prior to TstampSrc + Tmax. 286 4.4. Discussion and other details 288 See [RFC2680] and [RFC2681] for extensive discussion, methods of 289 measurement, errors and uncertainties, and other fundamental 290 considerations that need not be repeated here. 292 5. A Sample Round-trip Loss Metric 294 Given the singleton metric Type-P-Round-trip-Loss, we now define one 295 particular sample of such singletons. The idea of the sample is to 296 select a particular binding of the parameters Src, Dst, and Type-P, 297 then define a sample of values of parameter TstampSrc. This can be 298 done in several ways, including: 300 1. Poisson: a pseudo-random Poisson process of rate lambda, whose 301 values fall between T and Tf. The time interval between 302 successive values of TstampSrc will then average 1/lambda, as per 303 [RFC2330]. 305 2. Periodic: a periodic stream process with pseudo-random start time 306 T0 between T and dT, and nominal inter-packet interval incT, as 307 per [RFC3432]. 309 In the metric name, the variable SHALL be replaced with the 310 process used to define the sample, using one of the above processes 311 (or other process, the details of which MUST be specified if used). 313 5.1. Name: Type-P-Round-trip-Loss--Stream 315 5.2. Metric Parameters 317 See section 3.2. 319 5.3. Definition and Metric Units 321 Given one of the methods for defining the test interval, the sample 322 of times (TstampSrc) and other metric parameters, we obtain a 323 sequence of Type-P-Round-trip-Loss singletons as defined in section 324 4.3. 326 Type-P-Round-trip-Loss--Stream SHALL be a sequence of pairs 327 with elements as follows: 329 o TstampSrc, as above 331 o L, either zero or one (or some logical equivalent), where L=1 332 indicates loss and L=0 indicates successful round-trip arrival 333 prior to TstampSrc + Tmax. 335 where SHALL be replaced with "Poisson", "Periodic", or an 336 appropriate term to designate another sample method meeting the 337 criteria of [RFC2330]. 339 5.4. Discussion and other details 341 See [RFC2680] and [RFC2681] for extensive discussion, methods of 342 measurement, errors and uncertainties, and other fundamental 343 considerations that need not be repeated here. However, when these 344 references were approved, the packet reordering metrics in [RFC4737] 345 had not yet been defined, nor had reordering been addressed in IPPM 346 methodologies. 348 [RFC4737] defines packets that arrive "late" with respect to their 349 sending order as reordered. For example, when packets arrive with 350 sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and 351 they are obviously not lost because they have arrived within some 352 reasonable waiting time threshold. The presence of reordering on a 353 round-trip path has several likely affects on the measurement. 355 1. Methods of measurement should continue to wait the specified time 356 for packets, and avoid prematurely declaring round-trip loss when 357 a sequence gap or error is observed. 359 2. The time distribution of the singletons in the sample has been 360 significantly changed. 362 3. Either the original packet stream or the reflected packet stream 363 experienced path instability, and the original conditions may no 364 longer be present. 366 Measurement implementations MUST address the possibility for packet 367 reordering and avoid related errors in their processes. 369 6. Round-trip Loss Statistic 371 This section gives the primary and overall statistic for loss 372 performance. Additional statistics and metrics originally prepared 373 for One-way loss MAY also be applicable. 375 6.1. Type-P-Round-trip-Loss--Ratio 377 Given a Type-P-Round-trip-Loss--Stream, the average of all 378 the logical values, L, in the Stream is the Type-P-Round-trip-Loss- 379 -Ratio. This ratio is in units of lost packets per round- 380 trip transmissions actually attempted. 382 In addition, the Type-P-Round-trip-Loss--Ratio is undefined 383 if the sample is empty. 385 7. Round-trip Testing and One-way Reporting 387 This section raises considerations for results collected using a 388 round-trip measurement architecture, such as in TWAMP [RFC5357]. 390 The sampling process for the reverse path (Dst->Src) is a conditional 391 process that depends on successful packet arrival at the Dst and 392 correct operation at the Dst to generate the reflected packet. 393 Therefore, the sampling process for the reverse path will be 394 significantly affected when appreciable loss occurs on the Src->Dst 395 path, making an attempt to assess the reverse path performance 396 invalid (for loss or possibly any metric). 398 Further, the sampling times for the reverse path (Dst->Src) are a 399 random process that depends on the original sample times (TstampSrc), 400 the one-way-delay for successful packet arrival at the Dst, and time 401 taken at the Dst to generate the reflected packet. Therefore, the 402 sampling process for the reverse path will be significantly affected 403 when appreciable delay variation occurs on the Src->Dst path, making 404 an attempt to assess the reverse path performance invalid (for loss 405 or possibly any metric). 407 As discussed above, packet reordering is always a possibility. In 408 addition to the severe delay variation that usually accompanies it, 409 reordering on the Src->Dst path will cause a mis-alignment of 410 sequence numbers applied at the reflector when compared to the sender 411 numbers. Measurement implementations SHOULD address this possible 412 outcome. 414 8. Measurement Considerations and Calibration 416 Prior to conducting this measurement, the participating hosts MUST be 417 configured to send and receive test packets of the chosen Type-P. 418 Standard measurement protocols are capable of this task [RFC5357], 419 but any reliable method is sufficient. 421 Two key features of the host that receives test packets and returns 422 them to the originating host is described in section 4.2 of [RFC5357] 423 . Every received test packet MUST result in a responding packet, and 424 the response MUST be generated as immediately as possible. This 425 implies that interface buffers will be serviced promptly, and that 426 buffer discards will be extremely rare. These features of the 427 measurement equipment MUST be calibrated according to Section 3.7.3 428 of [RFC2679], when operating under a representative measurement load 429 (as defined by the user). Both unexpected test packet discards and 430 the systematic and random errors and uncertainties MUST be recorded. 432 We note that Section 4.2.1 of [RFC5357] specifies a method to collect 433 all four significant time-stamps needed to describe a packet's round- 434 trip delay [RFC2681] and remove the processing time incurred at the 435 responding host. This information supports the measurement of the 436 corresponding One-way Delays encountered on the round-trip path, 437 which can identify path asymmetry or unexpected processing time at 438 the responding host. 440 9. Security Considerations 442 9.1. Denial of Service Attacks 444 This metric requires a stream of packets sent from one host (source) 445 to another host (destination) through intervening networks, and back. 446 This method could be abused for denial of service attacks directed at 447 the destination and/or the intervening network(s). 449 Administrators of source, destination, and the intervening network(s) 450 should establish bilateral or multi-lateral agreements regarding the 451 timing, size, and frequency of collection of sample metrics. Use of 452 this method in excess of the terms agreed between the participants 453 may be cause for immediate rejection or discard of packets or other 454 escalation procedures defined between the affected parties. 456 9.2. User Data Confidentiality 458 Active use of this method generates packets for a sample, rather than 459 taking samples based on user data, and does not threaten user data 460 confidentiality. Passive measurement must restrict attention to the 461 headers of interest. Since user payloads may be temporarily stored 462 for length analysis, suitable precautions MUST be taken to keep this 463 information safe and confidential. In most cases, a hashing function 464 will produce a value suitable for payload comparisons. 466 9.3. Interference with the metrics 468 It may be possible to identify that a certain packet or stream of 469 packets is part of a sample. With that knowledge at the destination 470 and/or the intervening networks, it is possible to change the 471 processing of the packets (e.g. increasing or decreasing delay) that 472 may distort the measured performance. It may also be possible to 473 generate additional packets that appear to be part of the sample 474 metric. These additional packets are likely to perturb the results 475 of the sample measurement. 477 To discourage the kind of interference mentioned above, packet 478 interference checks, such as cryptographic hash, may be used. 480 10. IANA Considerations 482 Metrics previously defined in IETF were registered in the IANA IPPM 483 METRICS REGISTRY, however this process was discontinued when the 484 registry structure was found to be inadequate, and the registry was 485 declared Obsolete [RFC6248]. 487 Although the metrics in this draft may be considered for some form of 488 registration in the future, no IANA Action is requested at this time. 490 11. Acknowledgements 492 The author thanks Tiziano Ionta for his careful review of this memo, 493 primarily resulting in the development of measurement considerations 494 using TWAMP [RFC5357] as an example method. 496 12. References 498 12.1. Normative References 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, March 1997. 503 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 504 "Framework for IP Performance Metrics", RFC 2330, 505 May 1998. 507 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 508 Delay Metric for IPPM", RFC 2679, September 1999. 510 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 511 Packet Loss Metric for IPPM", RFC 2680, September 1999. 513 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 514 Delay Metric for IPPM", RFC 2681, September 1999. 516 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 517 Metric for IP Performance Metrics (IPPM)", RFC 3393, 518 November 2002. 520 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 521 performance measurement with periodic streams", RFC 3432, 522 November 2002. 524 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 525 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 526 November 2006. 528 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 529 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 530 RFC 5357, October 2008. 532 12.2. Informative References 534 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 535 Applicability Statement", RFC 5481, March 2009. 537 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 538 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 539 April 2011. 541 Author's Address 543 Al Morton 544 AT&T Labs 545 200 Laurel Avenue South 546 Middletown,, NJ 07748 547 USA 549 Phone: +1 732 420 1571 550 Fax: +1 732 368 1192 551 Email: acmorton@att.com 552 URI: http://home.comcast.net/~acmacm/