idnits 2.17.1 draft-morton-ippm-rt-loss-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 6, 2010) is 4950 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: 'RFC2679' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC5835' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC5474' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'Stats' is defined on line 481, 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) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) ** Downref: Normative reference to an Informational RFC: RFC 5835 Summary: 5 errors (**), 0 flaws (~~), 5 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 October 6, 2010 5 Expires: April 9, 2011 7 Round-trip Loss Metrics 8 draft-morton-ippm-rt-loss-01 10 Abstract 12 Many user applications and the transport protocols that make them 13 possible require two-way communications. To address this need, and 14 also for system simplicity, round-trip loss measurements are 15 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 proposes/adds round-trip loss to the set of IP Performance 21 Metrics (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 April 9, 2011. 46 Copyright Notice 47 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . 8 81 6.1. Type-P-Round-trip-Loss--Ratio . . . . . . . . . . 8 82 7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 8 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 8.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9 85 8.2. User Data Confidentiality . . . . . . . . . . . . . . . . 9 86 8.3. Interference with the metrics . . . . . . . . . . . . . . 9 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 1. Introduction 96 This memo defines a metric for round-trip loss on Internet paths. It 97 builds on the notions and conventions introduced in the IP 98 Performance Metrics (IPPM) framework [RFC2330]. Also, the 99 specifications of the One-way Loss metric [RFC2680] and the Round- 100 trip Delay metric [RFC2681] are frequently referenced and modified to 101 match the round-trip circumstances addressed here. However, this 102 memo assumes that the reader is familiar with the references, and 103 does not repeat material as was done in [RFC2681]. 105 This memo uses the terms "two-way" and "round-trip" synonymously. 107 1.1. Motivation 109 Many user applications and the transport protocols that make them 110 possible require two-way communications. For example, the TCP SYN->, 111 <-SYN-ACK, ACK-> three-way handshake attempted billions of times each 112 day cannot be completed without two-way connectivity in a near- 113 simultaneous time interval. Thus, measurements of Internet round- 114 trip loss performance provide a basis to infer application 115 performance more easily. 117 Measurement system designers have also recognized advantages of 118 system simplicity when one host simply echoes or reflects test 119 packets to the sender. Round-trip loss measurements are frequently 120 conducted and reported in practice. The Two-Way Active Measurement 121 Protocol specified in [RFC5357] establishes a round-trip loss 122 measurement capability for the Internet. However, there is currently 123 no round-trip loss metric specified according to the [RFC2330] 124 framework. 126 [RFC2681] indicates that round-trip measurements may sometimes 127 encounter "asymmetric" paths. When loss is observed using a round- 128 trip measurement, there is often a desire to ascertain which of the 129 two directional paths "lost" the packet. Under some circumstances, 130 it is possible to make this inference. The round-trip measurement 131 method raises a few complications when interpreting the embedded one- 132 way results, and the user should be aware of them. 134 [RFC2681] also points out that loss measurement conducted 135 sequentially in both directions of a path and reported as a round- 136 trip result may be exactly the desired metric. On the other hand, it 137 may be difficult to derive the state of round-trip loss from one-way 138 measurements conducted in each direction unless a method to match the 139 appropriate one-way measurements has pre-arranged. 141 Finally, many measurement systems report statistics on a conditional 142 delay distribution, where the condition is packet arrival at the 143 destination. This condition is encouraged in [RFC3393], [RFC5481], 144 and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets 145 need to be reported separately, according to a standardized metric. 146 This memo defines such a metric. 148 See Section 1.1 of[RFC2680] for additional motivation of the packet 149 loss metric. 151 2. Scope 153 This memo defines a round-trip loss metric using the conventions of 154 the IPPM framework [RFC2330]. 156 The memo defines a singleton metric, a sample metric, and a 157 statistic, as per [RFC2330]. 159 The memo also investigates the topic of one-way loss inference from a 160 two-way measurement, and lists some key considerations. 162 3. Common Specifications for Round-trip Metrics 164 To reduce the redundant information presented in the detailed metrics 165 sections that follow, this section presents the specifications that 166 are common to two or more metrics. The section is organized using 167 the same subsections as the individual metrics, to simplify 168 comparisons. 170 3.1. Name: Type-P-* 172 All metrics use the Type-P convention as described in [RFC2330]. The 173 rest of the name is unique to each metric. 175 3.2. Metric Parameters 177 o Src, the IP address of a host 179 o Dst, the IP address of a host 181 o T, a time (start of test interval) 183 o Tf, a time (end of test interval) 185 o lambda, a rate in reciprocal seconds (for Poisson Streams) 186 o incT, the nominal duration of inter-packet interval, first bit to 187 first bit (for Periodic Streams) 189 o T0, a time that MUST be selected at random from the interval [T, 190 T+dT] to start generating packets and taking measurements (for 191 Periodic Streams) 193 o TstampSrc, the wire time of the packet as measured at MP(Src) as 194 it leaves for Dst. 196 o TstampDst, the wire time of the packet as measured at MP(Dst), 197 assigned to packets that arrive within a "reasonable" time. 199 o Tmax, a maximum waiting time for packets to arrive, set 200 sufficiently long to disambiguate packets with long delays from 201 packets that are discarded (lost). 203 o M, the total number of packets sent between T0 and Tf 205 o N, the total number of packets received at Dst (sent between T0 206 and Tf) 208 o Type-P, as defined in [RFC2330], which includes any field that may 209 affect a packet's treatment as it traverses the network 211 3.3. Metric Definition 213 This section is specific to each metric. 215 3.4. Metric Units 217 The metric units are logical (1 or 0) when describing a single 218 packet's loss performance, where a 0 indicates successful packet 219 transmission and a 1 indicates packet loss. 221 Units of time are as specified in [RFC2330]. 223 Other units used are defined in the associated section. 225 4. A Singleton Round-trip Loss Metric 227 4.1. Name: Type-P-Round-trip-Loss 228 4.2. Metric Parameters 230 See section 3.2. 232 4.3. Definition and Metric Units 234 Type-P-Round-trip-Loss SHALL be represented by the binary logical 235 values (or their equivalents) when the following conditions are met: 237 Type-P-Round-trip-Loss = 0: 239 o Src sent the first bit of a Type-P packet to Dst at wire-time 240 TstampSrc, 242 o that Dst received that packet, 244 o the Dst immediately sent a Type-P packet back to the Src, and 246 o that Src received the last bit of the reflected packet at wire- 247 time TstampSrc + Tmax. 249 Type-P-Round-trip-Loss = 1: 251 o Src sent the first bit of a Type-P packet to Dst at wire-time 252 TstampSrc, 254 o that Src did not receive the last bit of the reflected packet 255 before the waiting time lapsed at TstampSrc + Tmax 257 o (possibly because that Dst did not receive that packet, 259 o the Dst did not immediately sent a Type-P packet back to the Src, 260 or 262 o the Src did not receive a reflected Type-P packet sent from the 263 Dst). 265 Following the precedent of[RFC2681], we make the simplifying 266 assertion: 268 Type-P-Round-trip-Loss(Src->Dst) = Type-P-Round-trip-Loss(Dst->Src) 270 (and agree with the rationale, that the ambiguity introduced is a 271 small price to pay for measurement efficiency). 273 Therefore, each singleton can be represented by pairs of elements as 274 follows: 276 o TstampSrc, the wire time of the packet at the Src (beginning the 277 round-trip journey). 279 o L, either zero or one (or some logical equivalent), where L=1 280 indicates loss and L=0 indicates successful round-trip arrival 281 prior to TstampSrc + Tmax. 283 4.4. Discussion and other details 285 See [RFC2680] and [RFC2681] for extensive discussion, methods of 286 measurement, errors and uncertainties, and other fundamental 287 considerations that need not be repeated here. 289 5. A Sample Round-trip Loss Metric 291 Given the singleton metric Type-P-Round-trip-Loss, we now define one 292 particular sample of such singletons. The idea of the sample is to 293 select a particular binding of the parameters Src, Dst, and Type-P, 294 then define a sample of values of parameter TstampSrc. This can be 295 done in several ways, including: 297 1. Poisson: a pseudo-random Poisson process of rate lambda, whose 298 values fall between T and Tf. The time interval between 299 successive values of TstampSrc will then average 1/lambda, as per 300 [RFC2330]. 302 2. Periodic: a periodic stream process with pseudo-random start time 303 T0 between T and dT, and nominal inter-packet interval incT, as 304 per [RFC3432]. 306 In the metric name, the variable should be replaced with the 307 process used to define the sample, using one of the above processes 308 (or other process, the details of which MUST be specified if used). 310 5.1. Name: Type-P-Round-trip-Loss--Stream 312 5.2. Metric Parameters 314 See section 3.2. 316 5.3. Definition and Metric Units 318 Given one of the methods for defining the test interval, the sample 319 of times (TstampSrc) and other metric parameters, we obtain a 320 sequence of Type-P-Round-trip-Loss singletons as defined in section 321 4.3. 323 Type-P-Round-trip-Loss--Stream SHALL be a sequence of pairs 324 with elements as follows: 326 o TstampSrc, as above 328 o L, either zero or one (or some logical equivalent), where L=1 329 indicates loss and L=0 indicates successful round-trip arrival 330 prior to TstampSrc + Tmax. 332 where SHALL be replaced with "Poisson", "Periodic", or an 333 appropriate term to designate another sample method meeting the 334 criteria of [RFC2330]. 336 5.4. Discussion and other details 338 See [RFC2680] and [RFC2681] for extensive discussion, methods of 339 measurement, errors and uncertainties, and other fundamental 340 considerations that need not be repeated here. 342 6. Round-trip Loss Statistic 344 This section gives the primary and overall statistic for loss 345 performance. Additional statistics and metrics originally prepared 346 for One-way loss MAY also be applicable. 348 6.1. Type-P-Round-trip-Loss--Ratio 350 Given a Type-P-Round-trip-Loss--Stream, the average of all 351 the logical values, L, in the Stream is the Type-P-Round-trip-Loss- 352 -Ratio. This ratio is in units of lost packets per round- 353 trip transmissions attempted. 355 In addition, the Type-P-Round-trip-Loss--Ratio is undefined 356 if the sample is empty. 358 7. Round-trip Testing and One-way Reporting 360 This section raises considerations for results collected using a 361 round-trip measurement architecture, such as in TWAMP [RFC5357]. 363 The sampling process for the return path (Dst->Src) is a conditional 364 process that depends on successful packet arrival at the Dst and 365 correct operation at the Dst to generate the reflected packet. 366 Therefore, the sampling process for the return path will be 367 significantly affected when appreciable loss occurs on the Src->Dst 368 path, making an attempt to assess the return path performance invalid 369 (for loss or possibly any metric). 371 Further, the sampling times for the return path (Dst->Src) are a 372 random process that depends on the original sample times (TstampSrc), 373 the one-way-delay for successful packet arrival at the Dst, and time 374 taken at the Dst to generate the reflected packet. Therefore, the 375 sampling process for the return path will be significantly affected 376 when appreciable delay variation occurs on the Src->Dst path, making 377 an attempt to assess the return path performance invalid (for loss or 378 possibly any metric). 380 8. Security Considerations 382 8.1. Denial of Service Attacks 384 This metric requires a stream of packets sent from one host (source) 385 to another host (destination) through intervening networks, and back. 386 This method could be abused for denial of service attacks directed at 387 the destination and/or the intervening network(s). 389 Administrators of source, destination, and the intervening network(s) 390 should establish bilateral or multi-lateral agreements regarding the 391 timing, size, and frequency of collection of sample metrics. Use of 392 this method in excess of the terms agreed between the participants 393 may be cause for immediate rejection or discard of packets or other 394 escalation procedures defined between the affected parties. 396 8.2. User Data Confidentiality 398 Active use of this method generates packets for a sample, rather than 399 taking samples based on user data, and does not threaten user data 400 confidentiality. Passive measurement must restrict attention to the 401 headers of interest. Since user payloads may be temporarily stored 402 for length analysis, suitable precautions MUST be taken to keep this 403 information safe and confidential. In most cases, a hashing function 404 will produce a value suitable for payload comparisons. 406 8.3. Interference with the metrics 408 It may be possible to identify that a certain packet or stream of 409 packets is part of a sample. With that knowledge at the destination 410 and/or the intervening networks, it is possible to change the 411 processing of the packets (e.g. increasing or decreasing delay) that 412 may distort the measured performance. It may also be possible to 413 generate additional packets that appear to be part of the sample 414 metric. These additional packets are likely to perturb the results 415 of the sample measurement. 417 To discourage the kind of interference mentioned above, packet 418 interference checks, such as cryptographic hash, may be used. 420 9. IANA Considerations 422 Metrics defined in IETF are typically registered in the IANA IPPM 423 METRICS REGISTRY as described in initial version of the registry 424 [RFC4148]. However, areas for improvement of this registry have been 425 identified, and the registry structure has to be revisited when there 426 is consensus to do so. 428 Therefore, the metrics in this draft may be considered for 429 registration in the future, and no IANA Action is requested at this 430 time. 432 10. Acknowledgements 434 11. References 436 11.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 442 "Framework for IP Performance Metrics", RFC 2330, 443 May 1998. 445 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 446 Delay Metric for IPPM", RFC 2679, September 1999. 448 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 449 Packet Loss Metric for IPPM", RFC 2680, September 1999. 451 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 452 Delay Metric for IPPM", RFC 2681, September 1999. 454 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 455 Metric for IP Performance Metrics (IPPM)", RFC 3393, 456 November 2002. 458 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 459 performance measurement with periodic streams", RFC 3432, 460 November 2002. 462 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 463 Registry", BCP 108, RFC 4148, August 2005. 465 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 466 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 467 RFC 5357, October 2008. 469 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 470 Composition", RFC 5835, April 2010. 472 11.2. Informative References 474 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 475 Grossglauser, M., and J. Rexford, "A Framework for Packet 476 Selection and Reporting", RFC 5474, March 2009. 478 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 479 Applicability Statement", RFC 5481, March 2009. 481 [Stats] McGraw-Hill NY NY, "Introduction to the Theory of 482 Statistics, 3rd Edition,", 1974. 484 Author's Address 486 Al Morton 487 AT&T Labs 488 200 Laurel Avenue South 489 Middletown,, NJ 07748 490 USA 492 Phone: +1 732 420 1571 493 Fax: +1 732 368 1192 494 Email: acmorton@att.com 495 URI: http://home.comcast.net/~acmacm/