idnits 2.17.1 draft-ietf-ippm-loss-pattern-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 8 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 are 2 instances 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 390, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AKZ' -- 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 (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft 2 Expiration Date: December, 1999 R. Koodli 3 R. Ravikanth 4 Nokia Research Center 5 June, 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 1 0 0 0 1 0 1 1 0 0 0 139 and there are four loss periods in the above sequence 140 begining 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 4 190 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. 259 4.7 Sampling Considerations: 261 The proposed metrics can be used independent of the 262 particular sampling method used. We note that Poisson sampling 263 may not yield appropriate values for these metrics for 264 certain real-time applications such as voice over IP, as well as to 265 TCP-based applications. For real-time applications, it may be more 266 appropriate to use the ON-OFF [Sriram] model, in which an ON period 267 starts with certain probability 'p', during which certain number of 268 packets are transmitted with mean 'lambda-on' according to geometric 269 distribution and an OFF period starts with probability '1-p' and 270 lasts for a period of time based on exponential distribution with 271 rate 'lambda-off'. 272 For TCP-based applications, one may use the model proposed in 273 [Padhye1]. See [Padhye2] for an application of the model. 275 5. Statistics: 277 5.1 Type-P-One-Way-Loss-Noticeable-Rate 279 Define loss of a packet to be "noticeable" [RK97] if the distance 280 between the lost packet and the previously lost packet is no 281 greater than delta, a positive integer, where delta is the 282 "loss constraint". 284 Example. Let delta = 100. Let us assume that packet 50 is lost 285 followed by a bursty loss of length 3 starting from 286 packet 125. 287 All the *four* losses are noticeable. 289 Given a Type-P-One-Way-Loss-Distance-Stream, this statistic 290 can be computed simply as the number of losses that violate some 291 constraint delta, divided by the number of losses. (Alternately, it 292 can also be defined as the number of "noticeable losses" to the number 293 of successfully received packets). 295 5.2 Type-P-One-Way-Loss-Period-Total 296 This represents the total number of loss periods, and can be derived 297 from the loss period metric Type-P-One-Way-Loss-Period-Stream as 298 follows: 300 Type-P-One-Way-Loss-Period-Total = maximum value of the first entry 301 of the set of pairs, , representing the loss metric 302 Type-P-One-Way-Loss-Period-Stream. 304 5.3 Type-P-One-Way-Loss-Period-Lengths 306 This statistic is a sequence of pairs , with the 307 "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total. 308 Thus the total number of pairs in this statistic equals 309 Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is 310 obtained by counting the number of pairs, , in the 311 metric Type-P-One-Way-Loss-Period-Stream which have first entry equal 312 to "loss period." 314 {Note: This statistic represents the number of packets lost in each 315 loss period.} 317 5.4 Example 319 We continue with the same example as in Section 4.4.3. The three 320 statistics defined above will have the following values. 322 + Let delta = 2. 323 In Type-P-One-Way-Loss-Distance-Stream 324 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, there 325 are 3 loss distances that violate the delta of 2. Thus, 327 Type-P-One-Way-Loss-Noticeable-Rate = 3/5 328 ((number of noticeable losses)/(number of total losses)) 330 + In Type-P-One-Way-Loss-Period-Stream 331 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 332 largest of the first entry in the sequence of 333 pairs is 4. Thus, 335 Type-P-One-Way-Loss-Period-Total = 4 337 + In Type-P-One-Way-Loss-Period-Stream 338 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 339 lengths of individual loss periods are 1, 1, 1 and 2 respectively. 340 Thus, 342 Type-P-One-Way-Loss-Period-Lengths = {<1,1>,<2,1>,<3,1>,<4,2>} 344 6. Security Considerations 346 Since this draft proposes sample metrics based on the base loss metric 347 defined in [AKZ], it inherits the security considerations mentioned in 348 [AKZ]. 350 7. Acknowledgements 352 Many thanks to Matt Zekauskas for the constructive feedback on the draft. 353 Thanks to Guy Almes for encouraging the work, and Vern Paxson for all the 354 comments during the IETF meetings. 356 8. References 358 [AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet 359 Loss Metric for IPPM", Internet Draft , 360 May 1999 362 [Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based 363 error control for Packet Audio in the Internet", ACM Multimedia 364 Systems, 1997. 366 [Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, 367 "Internet Packet Loss: Measurement and Implications for End-to-End 368 QoS," Proceedings, International Conference on Parallel Processing, 369 August 1998. 371 [Handley] M. Handley, "An examination of MBONE performance", 372 Technical Report, USC/ISI, ISI/RR-97-450, January 1997 374 [RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of 375 Service in Continuous Media Applications", PhD dissertation, 376 Electrical and Computer Engineering Department, University of 377 Massachusetts, Amherst, MA 01003. 378 ftp://aurelius.ecs.umass.edu/pub/koodli/thesis.ps.Z 380 [Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling 381 TCP throughput: a simple model and its empirical validation", in 382 Proceedings of SIGCOMM'98, 1998. 384 [Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A 385 TCP-friendly rate adjustment protocol for continuous media flows 386 over best-effort networks", short paper presentation in 387 ACM SIGMETRICS'99. Available as Umass Computer Science tech report 388 from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz 390 [Paxson] V. Paxson, "End-to-end Internet packet dynamics", Computer 391 Communication review, Proceedings of ACM SIGCOMM'97 Conference, 392 Cannes, France, September 1997, 27(4), pages 139-152, October 1997 394 [frame-work] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, 395 "Framework for IP Performance Metrics", RFC 2330. 397 [Sriram] K. Sriram and W. Whitt, "Characterizing superposition 398 arrival processes in packet multiplexers for voice and data", IEEE 399 Journal on Selected Areas of Communication, September 1986, pages 400 833-846 402 [Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss 403 correlation in the MBONE multicast network", Proceedings of IEEE 404 Global Internet, London, UK, November 1996. 406 Author's Addresses 408 Rajeev Koodli 409 Nokia Research Center 410 3, Burlington Woods Drive, #250 411 Burlington, MA 01803 412 Phone: +1 781-359-5136 413 Email: rajeev.koodli@nokia.com 415 Rayadurgam Ravikanth 416 Nokia Research Center 417 3, Burlington Woods Drive, #250 418 Burlington, MA 01803 419 Phone: +1 781-238-4905 420 Email: rayadurgam.ravikanth@nokia.com