idnits 2.17.1 draft-ietf-ippm-loss-pattern-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 63 has weird spacing: '...spacing betwe...' == Line 124 has weird spacing: '...= 1 and f(P_(...' == Line 201 has weird spacing: '...ed from the s...' -- 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: 'Paxson' is defined on line 415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2680 (ref. 'AKZ') (Obsoleted by RFC 7680) -- Possible downref: Non-RFC (?) normative reference: ref. 'Bolot' -- Possible downref: Non-RFC (?) normative reference: ref. 'Borella' -- Possible downref: Non-RFC (?) normative reference: ref. 'Handley' -- Possible downref: Non-RFC (?) normative reference: ref. 'RK97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Padhye1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Padhye2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Paxson' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sriram' -- Possible downref: Non-RFC (?) normative reference: ref. 'Yajnik' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft 2 Expiration Date: April, 2000 R. Koodli 3 R. Ravikanth 4 Nokia Research Center 5 October, 1999 7 One-way Loss Pattern Sample Metrics 8 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 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 27 The list of Internet-Draft shadow directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This memo provides information for the Internet community. This memo 31 does not specify an Internet standard of any kind. Distribution of 32 this memo is unlimited. 34 Abstract 36 The Internet exhibits certain specific types of behavior (e.g., bursty 37 packet loss) that can affect the performance seen by the users as 38 well as the operators. Currently, the focus has been on specifying 39 base metrics such as delay, loss and connectivity under the 40 framework described in [frame-work]. It is useful to capture 41 specific Internet behaviors under the umbrella of IPPM framework, 42 specifying new concepts while reusing existing guidelines as much as 43 possible. This draft proposes the use of "derived metrics" to 44 accomplish this, specifically providing means for capturing the loss 45 pattern on the Internet. 47 1. Introduction 48 In certain real-time applications (such as packet voice and video), 49 the loss pattern or loss distribution is a key parameter 50 that determines the performance observed by the users. For the same 51 loss rate, two different loss distributions could potentially produce 52 widely different perceptions of performance. The impact of loss pattern 53 is also extremely important for non-real-time applications that use 54 an adaptive protocol such as TCP. There is ample evidence in the 55 literature indicating the importance and existence of loss burstiness 56 and its effect on packet voice and video applications 57 [Bolot], [Borella], [Handley], [Yajnik]. 59 In this document, we propose two derived metrics, called "loss distance" 60 and "loss period", with associated statistics, to capture packet loss 61 patterns. The loss period metric captures the frequency and length 62 (burstiness) of loss once it starts, and the loss distance metric 63 captures the spacing between the loss periods. It is important to note 64 that these metrics are derived based on the base metric 65 Type-P-One-Way-packet-Loss. 67 2. The Approach 69 This document closely follows the guidelines specified in [frame-work]. 70 Specifically, the concepts of "singleton, sample, statistic", 71 measurement principles, Type-P packets, as well as standard-formed 72 packets all apply. However, since the draft proposes to capture 73 specific Internet behaviors, modifications to the sampling process 74 may be needed. Indeed, this is mentioned in [AKZ], where it is noted 75 that alternate sampling procedures may be useful depending on specific 76 circumstances. This draft proposes that the specific behaviors be 77 captured as "derived" metrics from the base metrics the behaviors 78 are related to. The reasons for adopting this position are the 79 following 81 - it provides consistent usage of singleton metric definition for 82 different behaviors (e.g., a single definition of packet loss 83 is needed for capturing burst of losses, 'm out of n' losses 84 etc. Otherwise, the metrics would have to be fundamentally 85 different) 86 - it allows re-use of the methodologies specified for the singleton 87 metric with modifications whenever necessary 88 - it clearly separates few base metrics from many Internet behaviors 90 Following the guidelines in [frame-work], this 91 translates to deriving *sample* metrics from the respective 92 singletons. The process of deriving sample metrics from the singletons 93 is specified in [frame-work], [AKZ], and others. 95 In the following sections, we apply this approach to a particular 96 Internet behavior, namely the packet loss process. 98 3. Basic Definitions: 100 3.1. Bursty loss: 102 The loss involving consecutive packets of a stream. 104 3.2. Loss Distance: 106 The difference in sequence numbers of two successively lost 107 packets which may or may not be separated by successfully 108 received packets. 110 Example. Let packet with sequence number 50 be considered lost 111 immediately after packet with sequence number 20 was 112 considered lost. The loss distance is 30. 114 {Comment: note that this definition does not specify exactly how to 115 associate sequence numbers with test packets. In other words, from 116 a timeseries sample of test packets, one may derive the sequence 117 numbers. For example, assign consecutive integers to each packet in 118 the time series.} 120 3.3. Loss period: 122 Let P_i be the i'th packet. 123 Define f(P_i) = 1 if P_i is lost, 0 otherwise. 124 Then, a loss period begins if f(P_i) = 1 and f(P_(i-1)) = 0 126 Example. Consider the following sequence of lost (denoted by x) 127 and received (denoted by r) packets. 129 r r r x r r x x x r x r r x x x 131 Then, with i assigned as follows 132 1 1 1 1 1 1 133 i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 135 f(P_i) is, 137 f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 139 and there are four loss periods in the above sequence 140 beginning at P_3, P_6, P_10, and P_13. 142 4. Definitions for Samples of One-way Loss Distance, 143 and One-way Loss Period. 145 4.1 Metric Name: 147 4.1.1 Type-P-One-Way-Loss-Distance-Stream 148 4.1.2 Type-P-One-Way-Loss-Period-Stream 149 4.2 Metric Parameters 151 + Src, the IP address of a host 152 + Dst, the IP address of a host 153 + T0, a time 154 + Tf, a time 155 + lambda, a rate in reciprocal of seconds 156 + Path, the path from Src to Dst (See [AKZ] for comments) 158 4.3 Metric Units 160 4.3.1 Type-P-One-Way-Loss-Distance-Stream: 162 A sequence of pairs of the form , where loss 163 is derived from the sequence of in [AKZ], and loss 164 distance is either zero or a positive integer. 166 4.3.2 Type-P-One-Way-Loss-Period-Stream 168 A sequence of pairs of the form , where loss is 169 derived from the sequence of in [AKZ], and loss period 170 an integer. 172 4.4. Definitions: 174 4.4.1 Type-P-One-Way-Loss-Distance-Stream 176 When a packet is considered lost (using the definition in [AKZ]), we 177 look at its sequence number and compare it with that of the 178 previously lost packet. The difference is the loss distance between 179 the lost packet and the previously lost packet. The sample would 180 consist of pairs. This definition assumes that 181 sequence numbers of successive test packets increase monotonically by 182 one. The loss distance associated with the very first packet loss is 183 considered to be zero. 185 The sequence number of a test packet can be derived from the timeseries 186 sample collected by performing the loss measurement according to the 187 methodology in [AKZ]. For example, if a loss sample consists of 188 {, , , , }, the sequence numbers of the 189 five test packets sent at T0, T1, T2, T3, and T4 can be 0, 1, 2, 3 and 190 4 respectively, or 100, 101, 102, 103 and 104 respectively, etc. 192 {Packet loss may also be considered as a result of exceeding some delay 193 threshold. This is particularly applicable to delay-sensitive audio 194 (or video) applications. 195 } 197 4.4.2 Type-P-One-Way-Loss-Period-Stream 198 We start a counter 'n' at an initial value of zero. This counter is 199 incremented by one each time a lost packet satisfies the Definition 3.3. 200 The metric is defined as where 201 "loss" is derived from the sequence of in 202 Type-P-One-Way-Loss-Stream [AKZ], and 203 loss period is set to zero when "loss" is zero in 204 Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above) 205 when "loss" is one in Type-P-One-Way-Loss-Stream. 207 {Note: When a packet is lost, the current value of "n" indicates the 208 loss period to which this packet belongs. For a packet that is 209 received successfully, the loss period is defined to be zero.} 211 4.4.3 Example: 213 Let the following set of pairs represent a Type-P-One-Way-Loss-Stream. 215 {,,,,,,,,, 216 } 218 where T1, T2,..,T10 are in increasing order. 220 Packets sent at T2, T5, T7, T9, T10 are lost. The two derived metrics 221 can be obtained from this sample as follows. 223 (i) Type-P-One-Way-Loss-Distance-Stream: 225 Since packet 2 is the first lost packet, the associated loss distance 226 is zero. For the next lost packet (packet 5), loss distance is 5-2 or 3. 227 Similarly, for the remaining lost packets (packets 7, 9, and 10) their 228 loss distances are 2, 2, and 1 respectively. Therefore, the 229 Type-P-One-Way-Loss-Distance-Stream is: 231 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>} 233 (ii) The Type-P-One-Way-Loss-Period-Stream: 235 The packet 2 sets the counter 'n' to 1, which is incremented by one 236 for packets 5, 7 and 9 according to Definition 3.3. However, for 237 packet 10, the counter remains at 4 satisfying Definition 3.3 again. 238 Thus, the Type-P-One-Way-Loss-Period-Stream is: 240 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>} 242 4.5. Methodologies: 244 The same methodology outlined in [AKZ] can be used to conduct the 245 sample experiments. 247 4.6 Discussion: 249 The Loss-Distance-Stream metric allows one to study the separation 250 between packet losses. This could be useful in determining a 251 "spread factor" associated with the packet loss rate. For 252 example, for a given packet loss rate, the proposed metric 253 indicates how the losses are spread. On the other hand, 254 the Loss-Period-Stream metric allows the study of loss burstiness 255 for each occurrence of loss. Note that a single loss period of 256 length 'n' can account for a significant portion of the overall 257 loss rate. Note also that it is possible to measure distance between 258 loss bursts seprated by one or more successfully received packets: See 259 Section 5.4, and 5.5 261 4.7 Sampling Considerations: 263 The proposed metrics can be used independent of the 264 particular sampling method used. We note that Poisson sampling 265 may not yield appropriate values for these metrics for 266 certain real-time applications such as voice over IP, as well as to 267 TCP-based applications. For real-time applications, it may be more 268 appropriate to use the ON-OFF [Sriram] model, in which an ON period 269 starts with certain probability 'p', during which certain number of 270 packets are transmitted with mean 'lambda-on' according to geometric 271 distribution and an OFF period starts with probability '1-p' and 272 lasts for a period of time based on exponential distribution with 273 rate 'lambda-off'. 274 For TCP-based applications, one may use the model proposed in 275 [Padhye1]. See [Padhye2] for an application of the model. 277 5. Statistics: 279 5.1 Type-P-One-Way-Loss-Noticeable-Rate 281 Define loss of a packet to be "noticeable" [RK97] if the distance 282 between the lost packet and the previously lost packet is no 283 greater than delta, a positive integer, where delta is the 284 "loss constraint". 286 Example. Let delta = 100. Let us assume that packet 50 is lost 287 followed by a bursty loss of length 3 starting from 288 packet 125. 289 All the *four* losses are noticeable. 291 Given a Type-P-One-Way-Loss-Distance-Stream, this statistic 292 can be computed simply as the number of losses that violate some 293 constraint delta, divided by the number of losses. (Alternately, it 294 can also be defined as the number of "noticeable losses" to the number 295 of successfully received packets). 297 5.2 Type-P-One-Way-Loss-Period-Total 298 This represents the total number of loss periods, and can be derived 299 from the loss period metric Type-P-One-Way-Loss-Period-Stream as 300 follows: 302 Type-P-One-Way-Loss-Period-Total = maximum value of the first entry 303 of the set of pairs, , representing the loss metric 304 Type-P-One-Way-Loss-Period-Stream. 306 5.3 Type-P-One-Way-Loss-Period-Lengths 308 This statistic is a sequence of pairs , with the 309 "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total. 310 Thus the total number of pairs in this statistic equals 311 Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is 312 obtained by counting the number of pairs, , in the 313 metric Type-P-One-Way-Loss-Period-Stream which have first entry equal 314 to "loss period." 316 {Note: This statistic represents the number of packets lost in each 317 loss period.} 319 5.4 Type-P-One-Way-Inter-Loss-Period-Lengths 321 This statistic measures distance between successive loss periods. It 322 takes the form of a set of pairs 323 , with the 324 "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total, 325 and "inter-loss-period-length" is the loss distance between the last 326 packet considered lost in "loss period" 'i-1', and the first packet 327 considered lost in "loss period" 'i', where 'i' ranges from 2 to 328 Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" 329 associated with the first "loss period" is defined to be zero. This 330 statistic allows one to consider, for example, two loss periods each 331 of length greater than one (implying loss burst), but separated by a 332 distance of 2 to belong to the same loss burst if such a consideration 333 is deemed useful. 335 5.5 Example 337 We continue with the same example as in Section 4.4.3. The three 338 statistics defined above will have the following values. 340 + Let delta = 2. 341 In Type-P-One-Way-Loss-Distance-Stream 342 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, there 343 are 3 loss distances that violate the delta of 2. Thus, 345 Type-P-One-Way-Loss-Noticeable-Rate = 3/5 346 ((number of noticeable losses)/(number of total losses)) 348 + In Type-P-One-Way-Loss-Period-Stream 349 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 350 largest of the first entry in the sequence of 351 pairs is 4. Thus, 353 Type-P-One-Way-Loss-Period-Total = 4 355 + In Type-P-One-Way-Loss-Period-Stream 356 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 357 lengths of individual loss periods are 1, 1, 1 and 2 respectively. 358 Thus, 360 Type-P-One-Way-Loss-Period-Lengths = {<1,1>,<2,1>,<3,1>,<4,2>} 362 + In Type-P-One-Way-Loss-Period-Stream 363 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 364 loss periods 1 and 2 are separated by 3 (5-2), loss periods 2 and 3 365 are separated by 2 (7-5), and 3 and 4 are separated by 2 (9-7). 366 Thus, 367 Type-P-One-Way-Inter-Loss-Period-Lengths = {<1,0>,<2,3>,<3,2>,<4,2>} 369 6. Security Considerations 371 Since this draft proposes sample metrics based on the base loss metric 372 defined in [AKZ], it inherits the security considerations mentioned in 373 [AKZ]. 375 7. Acknowledgements 377 Many thanks to Matt Zekauskas for the constructive feedback on the draft. 378 Thanks to Guy Almes for encouraging the work, and Vern Paxson for the 379 comments during the IETF meetings. Thanks to Steve Glass for making the 380 presentation at the Oslo meeting. 382 8. References 384 [AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet 385 Loss Metric for IPPM", RFC 2680, September 1999 387 [Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based 388 error control for Packet Audio in the Internet", ACM Multimedia 389 Systems, 1997. 391 [Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, 392 "Internet Packet Loss: Measurement and Implications for End-to-End 393 QoS," Proceedings, International Conference on Parallel Processing, 394 August 1998. 396 [Handley] M. Handley, "An examination of MBONE performance", 397 Technical Report, USC/ISI, ISI/RR-97-450, January 1997 399 [RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of 400 Service in Continuous Media Applications", PhD dissertation, 401 Electrical and Computer Engineering Department, University of 402 Massachusetts, Amherst, MA 01003. 403 ftp://aurelius.ecs.umass.edu/pub/koodli/thesis.ps.Z 405 [Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling 406 TCP throughput: a simple model and its empirical validation", in 407 Proceedings of SIGCOMM'98, 1998. 409 [Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A 410 TCP-friendly rate adjustment protocol for continuous media flows 411 over best-effort networks", short paper presentation in 412 ACM SIGMETRICS'99. Available as Umass Computer Science tech report 413 from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz 415 [Paxson] V. Paxson, "End-to-end Internet packet dynamics", Computer 416 Communication review, Proceedings of ACM SIGCOMM'97 Conference, 417 Cannes, France, September 1997, 27(4), pages 139-152, October 1997 419 [frame-work] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, 420 "Framework for IP Performance Metrics", RFC 2330, May 1998. 422 [Sriram] K. Sriram and W. Whitt, "Characterizing superposition 423 arrival processes in packet multiplexers for voice and data", IEEE 424 Journal on Selected Areas of Communication, September 1986, pages 425 833-846 427 [Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss 428 correlation in the MBONE multicast network", Proceedings of IEEE 429 Global Internet, London, UK, November 1996. 431 Author's Addresses 433 Rajeev Koodli 434 Nokia Research Center 435 3, Burlington Woods Drive, #250 436 Burlington, MA 01803 437 Phone: +1 781-359-5136 438 Email: rajeev.koodli@nokia.com 440 Rayadurgam Ravikanth 441 Nokia Research Center 442 3, Burlington Woods Drive, #250 443 Burlington, MA 01803 444 Phone: +1 781-238-4905 445 Email: rayadurgam.ravikanth@nokia.com