idnits 2.17.1 draft-ietf-ippm-loss-pattern-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '9' is defined on line 580, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2680 (ref. '1') (Obsoleted by RFC 7680) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPPM Working Group Rajeev Koodli 2 INTERNET DRAFT Nokia Research Center 3 5 December 2001 R. Ravikanth 4 Axiowave 6 One-way Loss Pattern Sample Metrics 7 draft-ietf-ippm-loss-pattern-06.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html. 29 This memo provides information for the Internet community. This memo 30 does not specify an Internet standard of any kind. Distribution of 31 this memo is unlimited. 33 Abstract 35 The Internet exhibits certain specific types of behavior (e.g., 36 bursty packet loss) that can affect the performance seen by the users 37 as well as the operators. Previously, the focus of the IPPM had 38 been on specifying base metrics such as delay, loss and connectivity 39 under the framework described in [10]. However, specific Internet 40 behaviors can also be captured under the umbrella of IPPM framework, 41 specifying new concepts while reusing existing guidelines as much as 42 possible. This document defines metrics derived from the previously 43 specified base metrics to capture loss patterns experienced by 44 streams of packets on the Internet. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 2 54 2. Terminology 2 56 3. The Approach 2 58 4. Basic Definitions 3 60 5. Definitions for Samples of One-way Loss Distance, and One-way 61 Loss Period 4 62 5.1. Metric Names . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 4 64 5.1.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 4 65 5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 4 66 5.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 4 67 5.3.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 4 68 5.3.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 4 69 5.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.4.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 5 71 5.4.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 5 72 5.4.3. Examples . . . . . . . . . . . . . . . . . . . . 5 73 5.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 6 74 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.7. Sampling Considerations . . . . . . . . . . . . . . . . . 7 76 5.8. Errors and Uncertainties . . . . . . . . . . . . . . . . 7 78 6. Statistics 8 79 6.1. Type-P-One-Way-Loss-Noticeable-Rate . . . . . . . . . . . 8 80 6.2. Type-P-One-Way-Loss-Period-Total . . . . . . . . . . . . 8 81 6.3. Type-P-One-Way-Loss-Period-Lengths . . . . . . . . . . . 9 82 6.4. Type-P-One-Way-Inter-Loss-Period-Lengths . . . . . . . . 9 83 6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 85 7. Security Considerations: 10 87 8. IANA Considerations 11 89 9. Acknowledgements 11 91 Addresses 13 92 1. Introduction 94 In certain real-time applications (such as packet voice and 95 video), the loss pattern or loss distribution is a key parameter 96 that determines the performance observed by the users. For the 97 same loss rate, two different loss distributions could potentially 98 produce widely different perceptions of performance. The impact 99 of loss pattern is also extremely important for non-real-time 100 applications that use an adaptive protocol such as TCP. Refer 101 to [2], [3], [5], [12] for evidence as to the importance and 102 existence of loss burstiness and its effect on packet voice and video 103 applications. 105 In this document, we propose two derived metrics, called "loss 106 distance" and "loss period", with associated statistics, to capture 107 packet loss patterns. The loss period metric captures the frequency 108 and length (burstiness) of loss once it starts, and the loss 109 distance metric captures the spacing between the loss periods. It is 110 important to note that these metrics are derived based on the base 111 metric Type-P-One-Way-packet-Loss. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 116 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 117 "silently ignore" in this document are to be interpreted as described 118 in RFC 2119 [4]. 120 3. The Approach 122 This document closely follows the guidelines specified in [10]. 123 Specifically, the concepts of singleton, sample, statistic, 124 measurement principles, Type-P packets, as well as standard-formed 125 packets all apply. However, since the draft proposes to capture 126 specific Internet behaviors, modifications to the sampling process 127 MAY be needed. Indeed, this is mentioned in [1], where it is 128 noted that alternate sampling procedures may be useful depending 129 on specific circumstances. This draft proposes that the specific 130 behaviors be captured as "derived" metrics from the base metrics the 131 behaviors are related to. The reasons for adopting this position are 132 the following: 134 - it provides consistent usage of singleton metric definition for 135 different behaviors (e.g., a single definition of packet loss is 136 needed for capturing burst of losses, 'm out of n' losses etc.) 138 - it allows re-use of the methodologies specified for the singleton 139 metric with modifications whenever necessary 141 - it clearly separates few base metrics from many Internet 142 behaviors 144 Following the guidelines in [10], this translates to deriving 145 sample metrics from the respective singletons. The process 146 of deriving sample metrics from the singletons is specified 147 in [10], [1], and others. 149 In the following sections, we apply this approach to a particular 150 Internet behavior, namely the packet loss process. 152 4. Basic Definitions 154 Sequence number: Consecutive packets in a time series sample 155 are given sequence numbers that are consecutive 156 integers. This document does not specify exactly 157 how to associate sequence numbers with packets. The 158 sequence numbers could be contained within test 159 packets themselves, or they could be derived through 160 post-processing of the sample. 162 Bursty loss: The loss involving consecutive packets of a stream. 164 Loss Distance: The difference in sequence numbers of two 165 successively lost packets which may or may not be 166 separated by successfully received packets. 168 Example: In a packet stream, the packet with sequence number 20 169 is considered lost, followed by the packet with 170 sequence number 50. The loss distance is 30. 172 Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i 173 is lost, 0 otherwise. Then, a loss period begins if 174 f(P_i) = 1 and f(P_(i-1)) = 0 176 Example: Consider the following sequence of lost (denoted by x) 177 and received (denoted by r) packets. 179 r r r x r r x x x r x r r x x x 181 Then, with `i' assigned as follows, 182 1 1 1 1 1 1 183 i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 184 f(P_i) is, 186 f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 188 and there are four loss periods in the above sequence 189 beginning at P_3, P_6, P_10, and P_13. 191 5. Definitions for Samples of One-way Loss Distance, and One-way 192 Loss Period 194 5.1. Metric Names 196 5.1.1. Type-P-One-Way-Loss-Distance-Stream 198 5.1.2. Type-P-One-Way-Loss-Period-Stream 200 5.2. Metric Parameters 202 Src, the IP address of a host 204 Dst, the IP address of a host 206 T0, a time 208 Tf, a time 210 lambda, a rate of any sampling method chosen in reciprocal of 211 seconds 213 5.3. Metric Units 215 5.3.1. Type-P-One-Way-Loss-Distance-Stream 217 A sequence of pairs of the form , where 218 loss is derived from the sequence of in [1], and loss 219 distance is either zero or a positive integer. 221 5.3.2. Type-P-One-Way-Loss-Period-Stream 223 A sequence of pairs of the form , where loss is 224 derived from the sequence of in [1], and loss period is 225 an integer. 227 5.4. Definitions 229 5.4.1. Type-P-One-Way-Loss-Distance-Stream 231 When a packet is considered lost (using the definition in [1]), 232 we look at its sequence number and compare it with that of the 233 previously lost packet. The difference is the loss distance between 234 the lost packet and the previously lost packet. The sample would 235 consist of pairs. This definition assumes that 236 sequence numbers of successive test packets increase monotonically by 237 one. The loss distance associated with the very first packet loss is 238 considered to be zero. 240 The sequence number of a test packet can be derived from the 241 timeseries sample collected by performing the loss measurement 242 according to the methodology in [1]. For example, if a loss sample 243 consists of , , , , , the sequence 244 numbers of the five test packets sent at T0, T1, T2, T3, and T4 can 245 be 0, 1, 2, 3 and 4 respectively, or 100, 101, 102, 103 and 104 246 respectively, etc. 248 5.4.2. Type-P-One-Way-Loss-Period-Stream 250 We start a counter 'n' at an initial value of zero. This 251 counter is incremented by one each time a lost packet satisfies the 252 definition outlined in 4. The metric is defined as where "loss" is derived from the sequence of in 254 Type-P-One-Way-Loss-Stream [1], and loss period is set to zero when 255 "loss" is zero in Type-P-One-Way-Loss-Stream, and loss period is set 256 to 'n' (above) when "loss" is one in Type-P-One-Way-Loss-Stream. 258 Essentially, when a packet is lost, the current value of "n" 259 indicates the loss period to which this packet belongs. For a packet 260 that is received successfully, the loss period is defined to be zero. 262 5.4.3. Examples 264 Let the following set of pairs represent a Type-P-One-Way-Loss-Stream. 266 {,,,,,,,,,} 268 where T1, T2,..,T10 are in increasing order. 270 Packets sent at T2, T5, T7, T9, T10 are lost. The two derived 271 metrics can be obtained from this sample as follows. 273 (i) Type-P-One-Way-Loss-Distance-Stream: 275 Since packet 2 is the first lost packet, the associated loss 276 distance is zero. For the next lost packet (packet 5), loss distance 277 is 5-2 or 3. Similarly, for the remaining lost packets (packets 278 7, 9, and 10) their loss distances are 2, 2, and 1 respectively. 279 Therefore, the Type-P-One-Way-Loss-Distance-Stream is: 281 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>} 283 (ii) The Type-P-One-Way-Loss-Period-Stream: 285 The packet 2 sets the counter 'n' to 1, which is incremented 286 by one for packets 5, 7 and 9 according to the definition in 4. 287 However, for packet 10, the counter remains at 4, again satisfying 288 the definition in 4. Thus, the Type-P-One-Way-Loss-Period-Stream is: 290 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>} 292 5.5. Methodologies 294 The same methodology outlined in [1] can be used to conduct the 295 sample experiments. A synopsis is listed below. 297 Generally, for a given Type-P, one possible methodology would 298 proceed as follows: 300 - Arrange that Src and Dst have clocks that are synchronized with 301 each other. The degree of synchronization is a parameter of the 302 methodology, and depends on the threshold used to determine loss 303 (see below). 305 - At the Src host, select Src and Dst IP addresses, and form a test 306 packet of Type-P with these addresses. 308 - At the Dst host, arrange to receive the packet. 310 - At the Src host, place a timestamp in the prepared Type-P packet, 311 and send it towards Dst. 313 - If the packet arrives within a reasonable period of time, the 314 one-way packet-loss is taken to be zero. 316 - If the packet fails to arrive within a reasonable period of 317 time, the one-way packet-loss is taken to be one. Note that the 318 threshold of "reasonable" here is a parameter of the methodology. 320 5.6. Discussion 322 The Loss-Distance-Stream metric allows one to study the separation 323 between packet losses. This could be useful in determining a "spread 324 factor" associated with the packet loss rate. In conjunction, the 325 Loss-Period-Stream metric allows the study of loss burstiness for 326 each occurrence of loss. A single loss period of length 'n' can 327 account for a significant portion of the overall loss rate. Note 328 that it is possible to measure distance between loss bursts separated 329 by one or more successfully received packets. (Refer to Sections 6.4 330 and 6.5). 332 5.7. Sampling Considerations 334 The proposed metrics can be used independent of the particular 335 sampling method used. We note that Poisson sampling may not 336 yield appropriate values for these metrics for certain real-time 337 applications such as voice over IP, as well as to TCP-based 338 applications. For real-time applications, it may be more appropriate 339 to use the ON-OFF [11] model, in which an ON period starts with 340 certain probability 'p', during which certain number of packets 341 are transmitted with mean 'lambda-on' according to geometric 342 distribution and an OFF period starts with probability '1-p' and 343 lasts for a period of time based on exponential distribution with 344 rate 'lambda-off'. 346 For TCP-based applications, one may use the model proposed in [7]. 347 See [8] for an application of the model. 349 5.8. Errors and Uncertainties 351 The measurement aspects, including the packet size, loss 352 threshold, type of the test machine chosen etc, invariably influence 353 the packet loss metric itself and hence the derived metrics described 354 in this document. Thus, when making assessment of the results 355 pertaining to the metrics outlined in this document, attention must 356 be paid to these matters. See [1] for a detailed consideration of 357 errors and uncertainties regarding the measurement of base packet 358 loss metric. 360 6. Statistics 362 6.1. Type-P-One-Way-Loss-Noticeable-Rate 364 Define loss of a packet to be "noticeable" [6] if the distance 365 between the lost packet and the previously lost packet is no greater 366 than delta, a positive integer, where delta is the "loss constraint". 368 Example: Let delta = 99. Let us assume that packet 50 is lost 369 followed by a bursty loss of length 3 starting from packet 125. All 370 the three losses starting from packet 125 are noticeable. 372 Given a Type-P-One-Way-Loss-Distance-Stream, this statistic can be 373 computed simply as the number of losses that violate some constraint 374 delta, divided by the number of losses. (Alternatively, it can also 375 be defined as the number of "noticeable losses" to the number of 376 successfully received packets). This statistic is useful when the 377 actual distance between successive losses is important. For example, 378 many multimedia codecs can sustain losses by "concealing" the effect 379 of loss by making use of past history information. Their ability to 380 do so degrades with poor history resulting from losses separated by 381 close distances. By choosing delta based on this sensitivity, one 382 can measure how "noticeable" a loss might be for quality purposes. 383 The noticeable loss requires a certain "spread factor" for losses 384 in the timeseries. In the above example where loss constraint is 385 equal to 99, a loss rate of one percent with a spread of 100 between 386 losses (e.g., 100, 200, 300, 400, 500 out of 500 packets) may be more 387 desirable for some applications compared to the same loss rate with a 388 spread that violates the loss constraint (e.g., 100, 175, 275, 290, 389 400: losses occurring at 175 and 290 violate delta = 99). 391 6.2. Type-P-One-Way-Loss-Period-Total 393 This represents the total number of loss periods, and can be 394 derived from the loss period metric Type-P-One-Way-Loss-Period-Stream 395 as follows: 397 Type-P-One-Way-Loss-Period-Total = maximum value of the first 398 entry of the set of pairs, , representing the loss 399 metric Type-P-One-Way-Loss-Period-Stream. 401 Note that this statistic does not describe the duration of each 402 loss period itself. If this statistic is large, it does not mean 403 that the losses are more spread out than they are otherwise; one 404 or more loss periods may include bursty losses. This statistic is 405 generally useful in gathering first order of approximation of loss 406 spread. 408 6.3. Type-P-One-Way-Loss-Period-Lengths 410 This statistic is a sequence of pairs , with the "loss period" entry ranging from 1 - 412 Type-P-One-Way-Loss-Period-Total. Thus the total number of 413 pairs in this statistic equals Type-P-One-Way-Loss-Period-Total. In 414 each pair, the "length" is obtained by counting the number of pairs, 415 , in the metric Type-P-One-Way-Loss-Period-Stream 416 which have first entry equal to "loss period." 418 Since this statistic represents the number of packets lost in each 419 loss period, it is an indicator of burstiness of each loss period. 420 In conjunction with loss-period-total statistic, this statistic is 421 generally useful in observing which loss periods are potentially more 422 influential than others from a quality perspective. 424 6.4. Type-P-One-Way-Inter-Loss-Period-Lengths 426 This statistic measures distance between successive loss 427 periods. It takes the form of a set of pairs , with the "loss period" entry ranging from 429 1 - Type-P-One-Way-Loss-Period-Total, and "inter-loss-period-length" 430 is the loss distance between the last packet considered lost in "loss 431 period" 'i-1', and the first packet considered lost in "loss period" 432 'i', where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. 433 The "inter-loss-period-length" associated with the first "loss 434 period" is defined to be zero. 436 This statistic allows one to consider, for example, two loss 437 periods each of length greater than one (implying loss burst), but 438 separated by a distance of 2 to belong to the same loss burst if such 439 a consideration is deemed useful. When the Inter-Loss-Period-Length 440 between two bursty loss periods is smaller, it could affect the loss 441 concealing ability of multimedia codecs since there is relatively 442 smaller history. When it is larger, an application may be able to 443 rebuild its history which could dampen the effect of an impending 444 loss (period). 446 6.5. Examples 448 We continue with the same example as in Section 5.4.3. The three 449 statistics defined above will have the following values. 451 - Let delta = 2. In Type-P-One-Way-Loss-Distance-Stream 453 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, 455 there are 3 loss distances that violate the delta of 2. Thus, 457 Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable 458 losses)/(number of total losses)) 460 - In Type-P-One-Way-Loss-Period-Stream 462 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, 464 the largest of the first entry in the sequence of pairs is 4. Thus, 467 Type-P-One-Way-Loss-Period-Total = 4 469 - In Type-P-One-Way-Loss-Period-Stream 471 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, 473 the lengths of individual loss periods are 1, 1, 1 and 2 474 respectively. Thus, 476 Type-P-One-Way-Loss-Period-Lengths = 478 {<1,1>,<2,1>,<3,1>,<4,2>} 480 - In Type-P-One-Way-Loss-Period-Stream 482 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, 484 the loss periods 1 and 2 are separated by 3 (5-2), loss periods 485 2 and 3 are separated by 2 (7-5), and 3 and 4 are separated by 2 486 (9-7). Thus, 487 Type-P-One-Way-Inter-Loss-Period-Lengths = 489 {<1,0>,<2,3>,<3,2>,<4,2>} 491 7. Security Considerations: 493 Since this draft proposes sample metrics based on the base loss 494 metric defined in [1], it inherits the security considerations 495 mentioned in [1]. 497 Conducting Internet measurements raises both security and privacy 498 concerns. This document does not specify a particular implementation 499 of metrics, so it does not directly affect the security of the 500 Internet nor of applications which run on the Internet. However, 501 implementations of these metrics must be mindful of security and 502 privacy concerns. 504 The derived sample metrics in this document are based on the loss 505 metric defined in RFC-2680 [1], and thus they inherit the security 506 considerations of that document. The reader should consult [1] for a 507 more detailed treatment of security considerations. 509 Nevertheless, there are a few things to highlight. First, 510 the lambda specified in the Type-P-Loss-Distance-Stream and 511 Type-P-Loss-Period-Stream controls the rate at which test packets 512 are sent, and therefore if it is set inappropriately large could 513 perturb the network under test, cause congestion, or at worst be a 514 denial-of-service attack to the network under test. 516 Second, privacy of user data is not a concern, since the 517 underlying metric is intended to be implemented using test packets 518 that contain no user information. Even if packets contained user 519 information, the derived metrics do not release data sent by the 520 user. Third, the results could be perturbed by attempting to corrupt 521 or disrupt the underlying stream, for example adding extra packets 522 that look just like test packets. 524 In general, legitimate measurements must have their parameters 525 selected carefully in order to avoid interfering with normal traffic 526 in the network. Such measurements should also be authorized and 527 authenticated in some way so that attacks can be identified and 528 intercepted. 530 8. IANA Considerations 532 Since this document does not define a specific protocol, nor does 533 it define any well-known values, there are no IANA considerations for 534 this document. 536 9. Acknowledgements 538 Matt Zekauskas provided insightful feedback and the text for the 539 Security Considerations section. We sincerely thank him for his 540 painstaking review and for supporting this work along with Merike 541 Kaeo. Thanks to Guy Almes for encouraging the work, and Vern Paxson 542 for the comments during the IETF meetings. Thanks to Steve Glass for 543 making the presentation at the Oslo meeting. 545 References 547 [1] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet 548 Loss Metric for IPPM", RFC 2680, September 1999. 550 [2] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error 551 control for Packet Audio in the Internet", ACM Multimedia 552 Systems, 1997. 554 [3] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, 555 "Internet Packet Loss: Measurement and Implications for 556 End-to-End QoS," Proceedings, International Conference on 557 Parallel Processing, August 1998. 559 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 560 Levels," RFC 2119, Internet Engineering Task Force, March 1997. 562 [5] M. Handley, "An examination of MBONE performance", Technical 563 Report, USC/ISI, ISI/RR-97-450, July 1997 565 [6] R. Koodli, "Scheduling Support for Multi-tier Quality of 566 Service in Continuous Media Applications", PhD dissertation, 567 Electrical and Computer Engineering Department, University of 568 Massachusetts, Amherst, MA 01003, September 1997. 570 [7] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP 571 throughput: a simple model and its empirical validation", in 572 Proceedings of SIGCOMM'98, 1998. 574 [8] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly 575 rate adjustment protocol for continuous media flows over 576 best-effort networks", short paper presentation in ACM 577 SIGMETRICS'99. Available as Umass Computer Science tech report 578 from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz 580 [9] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM 581 Transactions on Networking, 7(3), pages 277-292, June 1999. 583 [10] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for 584 IP Performance Metrics", RFC 2330, May 1998. 586 [11] K. Sriram and W. Whitt, "Characterizing superposition arrival 587 processes in packet multiplexers for voice and data", IEEE 588 Journal on Selected Areas of Communication, pages 833-846, 589 September 1986, 591 [12] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation 592 in the MBONE multicast network", Proceedings of IEEE Global 593 Internet, London, UK, November 1996. 595 Addresses 597 Questions about this memo can be directed to the authors: 599 Rajeev Koodli Rayadurgam Ravikanth 600 Communications Systems Lab Axiowave Networks Inc. 601 Nokia Research Center 100 Nickerson Road 602 313 Fairchild Drive Marlborough, MA- 01752 603 Mountain View, California 94043 USA 604 USA Email: rravikanth@axiowave.com 605 Phone: +1-650 625-2359 606 EMail: rajeev.koodli@nokia.com 607 Fax: +1 650 625-2502