idnits 2.17.1 draft-ietf-ippm-loss-pattern-05.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 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 are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 62 has weird spacing: '...spacing betwe...' == Line 123 has weird spacing: '...= 1 and f(P_(...' == Line 195 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 438, 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: 9 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Performance Metrics (IPPM) WG Rajeev Koodli 2 INTERNET DRAFT Nokia Research Center 3 20 July 2001 R. Ravikanth 4 Axiowave 6 One-way Loss Pattern Sample Metrics 7 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 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., bursty 36 packet loss) that can affect the performance seen by the users as 37 well as the operators. Currently, the focus has been on specifying 38 base metrics such as delay, loss and connectivity under the 39 framework described in [frame-work]. It is useful to capture 40 specific Internet behaviors under the umbrella of IPPM framework, 41 specifying new concepts while reusing existing guidelines as much as 42 possible. This draft proposes the use of "derived metrics" to 43 accomplish this, specifically providing means for capturing the loss 44 pattern on the Internet. 46 1. Introduction 47 In certain real-time applications (such as packet voice and video), 48 the loss pattern or loss distribution is a key parameter 49 that determines the performance observed by the users. For the same 50 loss rate, two different loss distributions could potentially produce 51 widely different perceptions of performance. The impact of loss pattern 52 is also extremely important for non-real-time applications that use 53 an adaptive protocol such as TCP. There is ample evidence in the 54 literature indicating the importance and existence of loss burstiness 55 and its effect on packet voice and video applications 56 [Bolot], [Borella], [Handley], [Yajnik]. 58 In this document, we propose two derived metrics, called "loss distance" 59 and "loss period", with associated statistics, to capture packet loss 60 patterns. The loss period metric captures the frequency and length 61 (burstiness) of loss once it starts, and the loss distance metric 62 captures the spacing between the loss periods. It is important to note 63 that these metrics are derived based on the base metric 64 Type-P-One-Way-packet-Loss. 66 2. The Approach 68 This document closely follows the guidelines specified in [frame-work]. 69 Specifically, the concepts of "singleton, sample, statistic", 70 measurement principles, Type-P packets, as well as standard-formed 71 packets all apply. However, since the draft proposes to capture 72 specific Internet behaviors, modifications to the sampling process 73 may be needed. Indeed, this is mentioned in [AKZ], where it is noted 74 that alternate sampling procedures may be useful depending on specific 75 circumstances. This draft proposes that the specific behaviors be 76 captured as "derived" metrics from the base metrics the behaviors 77 are related to. The reasons for adopting this position are the 78 following 80 - it provides consistent usage of singleton metric definition for 81 different behaviors (e.g., a single definition of packet loss 82 is needed for capturing burst of losses, 'm out of n' losses 83 etc. Otherwise, the metrics would have to be fundamentally 84 different) 85 - it allows re-use of the methodologies specified for the singleton 86 metric with modifications whenever necessary 87 - it clearly separates few base metrics from many Internet behaviors 89 Following the guidelines in [frame-work], this 90 translates to deriving sample metrics from the respective 91 singletons. The process of deriving sample metrics from the singletons 92 is specified in [frame-work], [AKZ], and others. 94 In the following sections, we apply this approach to a particular 95 Internet behavior, namely the packet loss process. 97 3. Basic Definitions: 99 3.1. Bursty loss: 101 The loss involving consecutive packets of a stream. 103 3.2. Loss Distance: 105 The difference in sequence numbers of two successively lost 106 packets which may or may not be separated by successfully 107 received packets. 109 Example. Let packet with sequence number 50 be considered lost 110 immediately after packet with sequence number 20 was 111 considered lost. The loss distance is 30. 113 Note that this definition does not specify exactly how to 114 associate sequence numbers with test packets. In other words, from 115 a timeseries sample of test packets, one may derive the sequence 116 numbers. However, these sequence numbers must be consecutive 117 integers. 119 3.3. Loss period: 121 Let P_i be the i'th packet. 122 Define f(P_i) = 1 if P_i is lost, 0 otherwise. 123 Then, a loss period begins if f(P_i) = 1 and f(P_(i-1)) = 0 125 Example. Consider the following sequence of lost (denoted by x) 126 and received (denoted by r) packets. 128 r r r x r r x x x r x r r x x x 130 Then, with i assigned as follows 131 1 1 1 1 1 1 132 i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 134 f(P_i) is, 136 f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 138 and there are four loss periods in the above sequence 139 beginning at P_3, P_6, P_10, and P_13. 141 4. Definitions for Samples of One-way Loss Distance, 142 and One-way Loss Period. 144 4.1 Metric Name: 146 4.1.1 Type-P-One-Way-Loss-Distance-Stream 147 4.1.2 Type-P-One-Way-Loss-Period-Stream 148 4.2 Metric Parameters 150 + Src, the IP address of a host 151 + Dst, the IP address of a host 152 + T0, a time 153 + Tf, a time 154 + lambda, a rate in reciprocal of seconds 155 + Path, the path from Src to Dst (See [AKZ] for comments) 157 4.3 Metric Units 159 4.3.1 Type-P-One-Way-Loss-Distance-Stream: 161 A sequence of pairs of the form , where loss 162 is derived from the sequence of in [AKZ], and loss 163 distance is either zero or a positive integer. 165 4.3.2 Type-P-One-Way-Loss-Period-Stream 167 A sequence of pairs of the form , where loss is 168 derived from the sequence of in [AKZ], and loss period 169 an integer. 171 4.4. Definitions: 173 4.4.1 Type-P-One-Way-Loss-Distance-Stream 175 When a packet is considered lost (using the definition in [AKZ]), we 176 look at its sequence number and compare it with that of the 177 previously lost packet. The difference is the loss distance between 178 the lost packet and the previously lost packet. The sample would 179 consist of pairs. This definition assumes that 180 sequence numbers of successive test packets increase monotonically by 181 one. The loss distance associated with the very first packet loss is 182 considered to be zero. 184 The sequence number of a test packet can be derived from the timeseries 185 sample collected by performing the loss measurement according to the 186 methodology in [AKZ]. For example, if a loss sample consists of 187 {, , , , }, the sequence numbers of the 188 five test packets sent at T0, T1, T2, T3, and T4 can be 0, 1, 2, 3 and 189 4 respectively, or 100, 101, 102, 103 and 104 respectively, etc. 191 4.4.2 Type-P-One-Way-Loss-Period-Stream 192 We start a counter 'n' at an initial value of zero. This counter is 193 incremented by one each time a lost packet satisfies the Definition 3.3. 194 The metric is defined as where 195 "loss" is derived from the sequence of in 196 Type-P-One-Way-Loss-Stream [AKZ], and 197 loss period is set to zero when "loss" is zero in 198 Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above) 199 when "loss" is one in Type-P-One-Way-Loss-Stream. 201 Essentially, when a packet is lost, the current value of "n" indicates 202 the loss period to which this packet belongs. For a packet that is 203 received successfully, the loss period is defined to be zero. 205 4.4.3 Example: 207 Let the following set of pairs represent a Type-P-One-Way-Loss-Stream. 209 {,,,,,,,,, 210 } 212 where T1, T2,..,T10 are in increasing order. 214 Packets sent at T2, T5, T7, T9, T10 are lost. The two derived metrics 215 can be obtained from this sample as follows. 217 (i) Type-P-One-Way-Loss-Distance-Stream: 219 Since packet 2 is the first lost packet, the associated loss distance 220 is zero. For the next lost packet (packet 5), loss distance is 5-2 or 3. 221 Similarly, for the remaining lost packets (packets 7, 9, and 10) their 222 loss distances are 2, 2, and 1 respectively. Therefore, the 223 Type-P-One-Way-Loss-Distance-Stream is: 225 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>} 227 (ii) The Type-P-One-Way-Loss-Period-Stream: 229 The packet 2 sets the counter 'n' to 1, which is incremented by one 230 for packets 5, 7 and 9 according to Definition 3.3. However, for 231 packet 10, the counter remains at 4 satisfying Definition 3.3 again. 232 Thus, the Type-P-One-Way-Loss-Period-Stream is: 234 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>} 236 4.5. Methodologies: 238 The same methodology outlined in [AKZ] can be used to conduct the 239 sample experiments. 241 4.6 Discussion: 243 The Loss-Distance-Stream metric allows one to study the separation 244 between packet losses. This could be useful in determining a 245 "spread factor" associated with the packet loss rate. For 246 example, for a given packet loss rate, this metric 247 indicates how the losses are spread. On the other hand, 248 the Loss-Period-Stream metric allows the study of loss burstiness 249 for each occurrence of loss. Note that a single loss period of 250 length 'n' can account for a significant portion of the overall 251 loss rate. Note also that it is possible to measure distance between 252 loss bursts seprated by one or more successfully received packets: See 253 Section 5.4, and 5.5 255 4.7 Sampling Considerations: 257 The proposed metrics can be used independent of the 258 particular sampling method used. We note that Poisson sampling 259 may not yield appropriate values for these metrics for 260 certain real-time applications such as voice over IP, as well as to 261 TCP-based applications. For real-time applications, it may be more 262 appropriate to use the ON-OFF [Sriram] model, in which an ON period 263 starts with certain probability 'p', during which certain number of 264 packets are transmitted with mean 'lambda-on' according to geometric 265 distribution and an OFF period starts with probability '1-p' and 266 lasts for a period of time based on exponential distribution with 267 rate 'lambda-off'. 269 For TCP-based applications, one may use the model proposed in 270 [Padhye1]. See [Padhye2] for an application of the model. 272 5. Statistics: 274 5.1 Type-P-One-Way-Loss-Noticeable-Rate 276 Define loss of a packet to be "noticeable" [RK97] if the distance 277 between the lost packet and the previously lost packet is no 278 greater than delta, a positive integer, where delta is the 279 "loss constraint". 281 Example. Let delta = 99. Let us assume that packet 50 is lost 282 followed by a bursty loss of length 3 starting from 283 packet 125. 284 All the *four* losses are noticeable. 286 Given a Type-P-One-Way-Loss-Distance-Stream, this statistic 287 can be computed simply as the number of losses that violate some 288 constraint delta, divided by the number of losses. (Alternately, it 289 can also be defined as the number of "noticeable losses" to the number 290 of successfully received packets). This statistic is useful when the 291 actual distance between successive losses is important. For example, 292 many multimedia codecs can sustain losses by "concealing" the effect 293 of loss by making use of past history information. Their ability to 294 do so degrades with poor history resulting from losses separated by 295 close distances. By chosing delta based on this sensitivity, one can 296 measure how "noticeable" a loss might be for quality purposes. 297 The noticeable loss requires a certain "spread factor" for losses 298 in the timeseries. In the above example where loss constraint is equal 299 to 99, a loss rate of one percent with a spread of 100 between 300 losses (e.g., 100, 200, 300, 400, 500 out of 500 packets) may be more 301 desirable for some applications compared to the same loss rate with a 302 spread that violates the loss constraint 303 (e.g., 100, 175, 275, 290, 400: losses occuring at 175 and 290 304 violate delta = 99). 306 5.2 Type-P-One-Way-Loss-Period-Total 308 This represents the total number of loss periods, and can be derived 309 from the loss period metric Type-P-One-Way-Loss-Period-Stream as 310 follows: 312 Type-P-One-Way-Loss-Period-Total = maximum value of the first entry 313 of the set of pairs, , representing the loss metric 314 Type-P-One-Way-Loss-Period-Stream. 316 Note that this statistic does not describe the duration of each loss 317 period itself. If this statistic is large, it does not mean that the 318 losses are more spread out than they are otherwise; one or more 319 loss periods may include bursty losses. This statistic is generally 320 useful in gathering first order of approximation of loss spread. 322 5.3 Type-P-One-Way-Loss-Period-Lengths 324 This statistic is a sequence of pairs , with the 325 "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total. 326 Thus the total number of pairs in this statistic equals 327 Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is 328 obtained by counting the number of pairs, , in the 329 metric Type-P-One-Way-Loss-Period-Stream which have first entry equal 330 to "loss period." 332 Since this statistic represents the number of packets lost in each 333 loss period, it is an indicator of burstiness of each loss period. In 334 conjunction with loss-period-total statistic, this statistic is generally 335 useful in observing which loss periods are potentially more influential 336 than others from a quality perspective. 338 5.4 Type-P-One-Way-Inter-Loss-Period-Lengths 340 This statistic measures distance between successive loss periods. It 341 takes the form of a set of pairs 342 , with the 343 "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total, 344 and "inter-loss-period-length" is the loss distance between the last 345 packet considered lost in "loss period" 'i-1', and the first packet 346 considered lost in "loss period" 'i', where 'i' ranges from 2 to 347 Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" 348 associated with the first "loss period" is defined to be zero. 350 This statistic allows one to consider, for example, two loss periods each 351 of length greater than one (implying loss burst), but separated by a 352 distance of 2 to belong to the same loss burst if such a consideration 353 is deemed useful. When the Inter-Loss-Period-Length between two bursty 354 loss periods is smaller, it could affect the loss concealing ability of 355 multimedia codecs since there is relatively smaller history. When it is 356 larger, an application may be able to rebuild its history which could 357 dampen the effect of an impending loss (period). 359 5.5 Example 361 We continue with the same example as in Section 4.4.3. The three 362 statistics defined above will have the following values. 364 + Let delta = 2. 365 In Type-P-One-Way-Loss-Distance-Stream 366 {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, there 367 are 3 loss distances that violate the delta of 2. Thus, 369 Type-P-One-Way-Loss-Noticeable-Rate = 3/5 370 ((number of noticeable losses)/(number of total losses)) 372 + In Type-P-One-Way-Loss-Period-Stream 373 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 374 largest of the first entry in the sequence of 375 pairs is 4. Thus, 377 Type-P-One-Way-Loss-Period-Total = 4 379 + In Type-P-One-Way-Loss-Period-Stream 380 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 381 lengths of individual loss periods are 1, 1, 1 and 2 respectively. 382 Thus, 384 Type-P-One-Way-Loss-Period-Lengths = {<1,1>,<2,1>,<3,1>,<4,2>} 386 + In Type-P-One-Way-Loss-Period-Stream 387 {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the 388 loss periods 1 and 2 are separated by 3 (5-2), loss periods 2 and 3 389 are separated by 2 (7-5), and 3 and 4 are separated by 2 (9-7). 390 Thus, 391 Type-P-One-Way-Inter-Loss-Period-Lengths = {<1,0>,<2,3>,<3,2>,<4,2>} 393 6. Security Considerations 395 Since this draft proposes sample metrics based on the base loss metric 396 defined in [AKZ], it inherits the security considerations mentioned in 397 [AKZ]. 399 7. Acknowledgements 401 Many thanks to Matt Zekauskas for the constructive feedback on the draft. 402 Thanks to Guy Almes for encouraging the work, and Vern Paxson for the 403 comments during the IETF meetings. Thanks to Steve Glass for making the 404 presentation at the Oslo meeting. 406 8. References 408 [AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet 409 Loss Metric for IPPM", RFC 2680, September 1999 411 [Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based 412 error control for Packet Audio in the Internet", ACM Multimedia 413 Systems, 1997. 415 [Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, 416 "Internet Packet Loss: Measurement and Implications for End-to-End 417 QoS," Proceedings, International Conference on Parallel Processing, 418 August 1998. 420 [Handley] M. Handley, "An examination of MBONE performance", 421 Technical Report, USC/ISI, ISI/RR-97-450, July 1997 423 [RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of 424 Service in Continuous Media Applications", PhD dissertation, 425 Electrical and Computer Engineering Department, University of 426 Massachusetts, Amherst, MA 01003. 428 [Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling 429 TCP throughput: a simple model and its empirical validation", in 430 Proceedings of SIGCOMM'98, 1998. 432 [Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A 433 TCP-friendly rate adjustment protocol for continuous media flows 434 over best-effort networks", short paper presentation in 435 ACM SIGMETRICS'99. Available as Umass Computer Science tech report 436 from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz 438 [Paxson] V. Paxson, "End-to-end Internet packet dynamics", Computer 439 Communication review, Proceedings of ACM SIGCOMM'97 Conference, 440 Cannes, France, September 1997, 27(4), pages 139-152, October 1997 442 [frame-work] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, 443 "Framework for IP Performance Metrics", RFC 2330, May 1998. 445 [Sriram] K. Sriram and W. Whitt, "Characterizing superposition 446 arrival processes in packet multiplexers for voice and data", IEEE 447 Journal on Selected Areas of Communication, September 1986, pages 448 833-846 450 [Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss 451 correlation in the MBONE multicast network", Proceedings of IEEE 452 Global Internet, London, UK, November 1996. 454 Author's Addresses 456 Rajeev Koodli 457 Nokia Research Center 458 313, Fairchild Drive 459 Mountain View, CA 94043 460 Phone: +1 650-625-2359 461 Email: rajeev.koodli@nokia.com 463 Rayadurgam Ravikanth 464 Axiowave Networks Inc. 465 100 Nickerson Road 466 Marlborough, MA- 01752 467 Email: rravikanth@axiowave.com