idnits 2.17.1 draft-ietf-ippm-loss-pattern-00.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 60 has weird spacing: '...tistics which...' == Line 118 has weird spacing: '...= 1 and f(P(i...' == Line 183 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) -- 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 (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft 2 Expiration Date: September, 1999 R. Koodli 3 R. Ravikanth 4 Nokia Research Center 5 March, 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 Engineerin 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 would be 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], [Paxson], [Yajnik]. 59 In this document, we propose two "derived metrics" -- loss distance 60 and loss periods -- and associated statistics which 61 capture the loss pattern and help derive statistics reflecting the same. 62 The loss period metric captures the frequency and length (burstiness) of 63 loss once it starts, and the loss distance captures the spacing between 64 the loss periods. It is important to note that these metrics are 65 derived based on the base metric Type-P-One-Way-packet-Loss. 67 2. The Approach 69 This draft closely follows the guidelines specified in [frame-work]. 70 Specifically, the concepts of a "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 additions whenever necessary 88 - it clearly separates few base metrics from many Internet behaviors 89 and provides a suitable place-holder. 91 Following the guidelines in [frame-work], this 92 translates to deriving *sample* metrics from the respective 93 singletons. The process of deriving sample metrics from the singletons 94 is specified in [frame-work], [AKZ], and others. 96 In the following sections, we apply this approach to a particular 97 Internet behavior, namely the packet loss process. 99 3. Basic Definitions: 101 3.1. Bursty loss: 103 The loss involving consecutive packets of a stream. 105 3.2. Loss Distance: 107 The difference in sequence numbers of two successively lost 108 packets which may or may not be separated by successfully 109 received packets. 111 Example. Let packet with sequence number 50 be considered lost 112 immediately after packet with sequence number 20 was 113 considered lost. The loss distance is 30. 115 3.3. Loss period: 117 Define f(Pi) = 1 if a packet 'i' is lost, 0 otherwise. 118 Then, a loss period begins if f(Pi) = 1 and f(P(i-1)) = 0 120 Example. Consider the following sequence of lost (denoted by x) 121 and received (denoted by r) packets. 123 r r r x r r x x x r x r r x x x 125 There are four loss periods in the above sequence. 127 4. Definitions for Samples of One-way Loss Distance, 128 and One-way Loss Period. 130 4.1 Metric Name: 132 4.1.1 Type-P-One-Way-Loss-Distance-Stream 133 4.1.2 Type-P-One-Way-Loss-Period-Stream 135 4.2 Metric Parameters 137 + Src, the IP address of a host 138 + Dst, the IP address of a host 139 + T0, a time 140 + Tf, a time 141 + lambda, a rate in reciprocal of seconds 142 + Path, the path from Src to Dst (See [AKZ] for comments) 143 + Seq, the sequence number (an integer) of test packet 145 4.3 Metric Units 147 4.3.1 Type-P-One-Way-Loss-Distance-Stream: 149 A sequence of pairs of the form , where loss 150 is derived from the sequence of in [AKZ], and loss 151 distance is either zero or a positive integer. 153 4.3.2 Type-P-One-Way-Loss-Period-Stream 155 A sequence of pairs of the form , where loss is 156 derived from the sequence of in [AKZ], and loss period 157 an integer. 159 4.4. Definitions: 161 4.4.1 Type-P-One-Way-Loss-Distance-Stream 163 When a packet is considered lost (using the definition in [AKZ]), we 164 look at its sequence number and compare it with that of the 165 previously lost packet. The difference is the loss distance between 166 the lost packet and the previously lost packet. The sample would 167 consist of pairs. This definition assumes that 168 sequence numbers of successive test packets increase monotonically by 169 one. 170 The loss distance associated with the very first packet loss is 171 considered to be zero. 173 {Packet loss may also be considered as a result of exceeding some delay 174 threshold. This is particularly applicable to delay-sensitive audio 175 (or video) applications. 176 } 178 4.4.2 Type-P-One-Way-Loss-Period-Stream 180 We start a counter 'n' at an initial value of zero. This counter is 181 incremented by one each time a lost packet satisfies the Definition 3.3. 182 The metric is defined as where 183 "loss" is derived from the sequence of in [AKZ], and 184 loss period is set to zero when "loss"=0, and is set to "n" 185 when "loss"=1. 187 {Note: When a packet is lost, the current value of "n" indicates the 188 loss period to which this packet belongs. For a packet that is 189 received successfully, the loss period is defined to be zero.} 191 4.4.3 Example: 193 Let the following set of pairs represent a Type-P-One-Way-Loss-Stream. 195 {,,,,,,,,, 196 } 198 where T1, T2,..,T10 are in increasing order. 200 Packets sent at T2, T5, T7, T9, T10 are lost. The two derived metrics 201 can be obtained from this sample as follows. 203 (i) Type-P-One-Way-Loss-Distance-Stream: 205 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>} 207 (ii) The Type-P-One-Way-Loss-Period-Stream: 209 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>} 211 4.5. Methodologies: 213 The same methodology outlined in [AKZ] can be used to conduct the 214 sample experiments. 216 4.6 Discussion: 218 The Loss-Distance-Stream metric allows one to study the separation 219 between packet losses. This could be useful in determining a 220 "spread factor" associated with the packet loss rate. For 221 example, for a given packet loss rate, the proposed metric 222 indicates how the losses are spread. On the other hand, 223 the Loss-Period-Stream metric allows the study of loss burstiness 224 for each occurrence of loss. Note that a single loss period of 225 length 'n' can account for a significant portion of the overall 226 loss rate. 228 4.7 Sampling Considerations: 230 The proposed metrics can be used independent of the 231 particular sampling method used. We note that Poisson sampling 232 may not yield appropriate values for these metrics for 233 certain real-time applications such as voice over IP, as well as to 234 TCP-based applications. For real-time applications, it may be more 235 appropriate to use the ON-OFF [Sriram] model, in which an ON period 236 starts with certain probability 'p', during which certain number of 237 packets are transmitted with mean 'lambda-on' according to geometric 238 distribution and an OFF period starts with probability '1-p' and 239 lasts for a period of time based on exponential distribution with 240 rate 'lambda-off'. 241 For TCP-based applications, one may use the model proposed in 242 [Padhye1]. See [Padhye2] for an application of the model. 244 4.8 Errors and Uncertainities: 246 Care must be taken (if)when the sequence numbers wrap around, 247 since the computation of loss distance depends on correct sequence 248 numbers. 250 5. Statistics: 252 5.1 Type-P-One-Way-Noticeable-Loss-Rate 254 Define loss of a packet to be "noticeable" [RK97] if the distance 255 between the lost packet and the previously lost packet is no 256 greater than delta, a positive integer, where delta is the 257 "loss constraint". 259 Example. Let delta = 100. Let us assume that packet 50 is lost 260 followed by a bursty loss of length 3 starting from 261 packet 125. 262 All the *four* losses are noticeable. 264 Given a Type-P-One-Way-Loss-Distance-Stream, this statistic 265 can be computed simply as the number of losses that violate some 266 constraint delta, divided by the number of losses. (Alternately, it 267 can also be defined as the number of "noticeable losses" to the number 268 of successfully received packets). 270 5.2 Type-P-One-Way-Loss-Period-Total 272 This represents the total number of loss periods, and can be derived 273 from the loss period metric Type-P-One-Way-Loss-Period-Stream as 274 follows: 276 Type-P-One-Way-Loss-Period-Total = maximum value of the first entry 277 of the set of pairs, , representing the loss metric 278 Type-P-One-Way-Loss-Period-Stream. 280 5.3 Type-P-One-Way-Loss-Period-Lengths 282 This statistic is a sequence of pairs , with the 283 "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total. 284 Thus the total number of pairs in this statistic equals 285 Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is 286 obtained by counting the number of pairs, , in the 287 metric Type-P-One-Way-Loss-Period-Stream which have first entry equal 288 to "loss period." 290 {Note: This statistic represents the number of packets lost in each 291 loss period.} 293 5.4 Example 295 We continue with the same example as in Section 3.4.2. The three 296 statistics defined above will have the following values. 298 Type-P-One-Way-Noticeable-Loss-Rate: 3/5 299 (( number of noticeable losses)/(number of total losses)) 301 Type-P-One-Way-Loss-Period-Total: 4 302 (largest of the first entry in the sequence of 303 pairs). 305 Type-P-One-Way-Loss-Period-Lengths: The sequence 306 {<1,1>,<2,1>,<3,1>,<4,2>} 308 6. References 310 [AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet 311 Loss Metric for IPPM", Internet Draft , 312 November 1998 314 [Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based 315 error control for Packet Audio in the Internet", ACM Multimedia 316 Systems, 1997. 318 [Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, 319 "Internet Packet Loss: Measurement and Implications for End-to-End 320 QoS," Proceedings, International Conference on Parallel Processing, 321 August 1998. 323 [Handley] M. Handley, "An examination of MBONE performance", 324 Technical Report, USC/ISI, ISI/RR-97-450, January 1997 326 [RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of 327 Service in Continuous Media Applications", PhD dissertation, 328 Electrical and Computer Engineering Department, University of 329 Massachusetts, Amherst, MA 01003. 330 ftp://aurelius.ecs.umass.edu/pub/koodli/thesis.ps.Z 332 [Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling 333 TCP throughput: a simple model and its empirical validation", in 334 Proceedings of SIGCOMM'98, 1998. 336 [Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A 337 TCP-friendly rate adjustment protocol for continuous media flows 338 over best-effort networks", short paper presentation in 339 ACM SIGMETRICS'99. Available as Umass Computer Science tech report 340 from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz 342 [Paxson] V. Paxson, "End-to-end Internet packet dynamics", Computer 343 Communication review, Proceedings of ACM SIGCOMM'97 Conference, 344 Cannes, France, September 1997, 27(4), pages 139-152, October 1997 346 [frame-work] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, 347 "Framework for IP Performance Metrics", RFC 2330. 349 [Sriram] K. Sriram and W. Whitt, "Characterizing superposition 350 arrival processes in packet multiplexers for voice and data", IEEE 351 Journal on Selected Areas of Communication, September 1986, pages 352 833-846 354 [Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss 355 correlation in the MBONE multicast network", Proceedings of IEEE 356 Global Internet, London, UK, November 1996. 358 Author's Addresses 360 Rajeev Koodli 361 Nokia Research Center 362 3, Burlington Woods Drive, #250 363 Burlington, MA 01803 364 Phone: +1 781-359-5136 365 Email: rajeev.koodli@research.nokia.com 367 Rayadurgam Ravikanth 368 Nokia Research Center 369 3, Burlington Woods Drive, #250 370 Burlington, MA 01803 371 Phone: +1 781-238-4905 372 Email: rayadurgam.ravikanth@research.nokia.com