idnits 2.17.1 draft-ietf-ippm-ipdv-07.txt: ** The Abstract section seems to be numbered 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 the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '... of the metric MUST include all the ...' RFC 2119 keyword, line 192: '...pdv metric is taken MUST all be of the...' RFC 2119 keyword, line 466: '... metric is taken MUST all be of the sa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 376 has weird spacing: '...f these error...' == Line 399 has weird spacing: '... to the subtr...' -- 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: '3' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 753, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 757, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. '1') ** Obsolete normative reference: RFC 2679 (ref. '2') (Obsoleted by RFC 7679) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2598 (ref. '7') (Obsoleted by RFC 3246) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Demichelis 3 INTERNET-DRAFT CSELT 4 Expiration Date: August 2001 P. Chimento 5 Ericsson IPI 6 February 2001 8 IP Packet Delay Variation Metric for IPPM 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft shadow directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. Distribution of 34 this memo is unlimited. 36 2. Abstract 38 This memo refers to a metric for variation in delay of packets across 39 Internet paths. The metric is based on the difference in the One-Way- 40 Delay of selected packets. This difference in delay is called "IP 41 Packet Delay variation." 43 The metric is valid for measurements between two hosts both in the 44 case that they have synchronized clocks and in the case that they are 45 not synchronized. We discuss both in this draft. 47 3. Introduction 49 This memo is based on "A One-Way-Delay metric for IPPM", RFC 2679 50 [2]. 52 Part of the text in this memo is taken directly from that document. 54 This memo defines a metric for variation in delay of packets that 55 flow from one host to another one through an IP path. This quantity 56 is sometimes called "jitter". This term, however, causes confusion 57 because it is used in different ways by different groups of people. 59 "Jitter" commonly has two meanings: The first meaning is the 60 variation of a signal with respect to some clock signal, where the 61 arrival time of the signal is expected to coincide with the arrival 62 of the clock signal. The second meaning has to do with the variation 63 of a metric (e.g. delay) with respect to some reference metric (e.g. 64 average delay or minimum delay). 66 The first meaning is used with reference to synchronous signals and 67 might be used to measure the quality of circuit emulation, for 68 example. There is also a metric called "wander" used in this context. 69 The second meaning is frequently used by computer scientists and 70 frequently (but not always) refers to variation in delay. 72 In this document we will avoid the term "jitter" whenever possible 73 and stick to delay variation which is more precise. 75 3.1. Definition 77 A definition of the IP Packet Delay Variation (ipdv) can be given for 78 packets inside a stream of packets. 80 The IP Packet Delay Variation (ipdv) of a pair of packets within a 81 stream of packets is defined for a selected pair of packets in the 82 stream going from measurement point MP1 to measurement point MP2 is 83 the difference between the one-way-delay of the first of the selected 84 packets and the one-way-delay of the second of the selected packets. 86 3.2. Motivation 88 One important use of delay variation is the sizing of playout buffers 89 for applications requiring the regular delivery of packets (for 90 example, voice or video playout). What is normally important in this 91 case is the maximum delay variation, which is used to size playout 92 buffers for such applications [6]. Other uses of a delay variation 93 metric are, for example, to determine the dynamics of queues within a 94 network (or router) where the changes in delay variation can be 95 linked to changes in the queue length process at a given link or a 96 combination of links. 98 In addition, this type of metric is particularly robust with respect 99 differences and variations of the clocks of the two hosts. This 100 allows the use of the metric even if the two hosts that support the 101 measurement points are not synchronized. In the latter case 102 indications of reciprocal skew of the clocks can be derived from the 103 measurement and corrections are possible. The related precision is 104 often comparable with the one that can be achieved with synchronized 105 clocks, being of the same order of magnitude of synchronization 106 errors. This will be discussed below. 108 The scope of this document is to provide a way to measure the ipdv 109 delivered on a path. Our goal is to provide a metric which can be 110 parameterized so that it can be used for various purposes. Any report 111 of the metric MUST include all the parameters associated with it so 112 that the conditions and meaning of the metric can be determined 113 exactly. We specifically do not specify particular values of the 114 metrics that IP networks must meet. 116 The flexibility of the metric can be viewed as a disadvantage but 117 there are some arguments for making it flexible. First, though there 118 are some uses of ipdv mentioned above, to some degree the uses of 119 ipdv are still a research topic and some room should be left for 120 experimentation. Secondly, there are different views in the community 121 of what precisely the definition should be (e.g. [7],[8],[9]). The 122 idea here is to parameterize the definition, rather than write a 123 different draft for each proposed definition. As long as all the 124 parameters are reported, it will be clear what is meant by a 125 particular use of ipdv. All the remarks in the draft hold, no matter 126 which parameters are chosen. 128 3.3. General Issues Regarding Time 130 Everything contained in the Section 2.2. of [2] applies also in this 131 case. 133 To summarize: As in [1] we define "skew" as the first derivative of 134 the offset of a clock with respect to "true time" and define "drift" 135 as the second derivative of the offset of a clock with respect to 136 "true time". 138 From there, we can construct "relative skew" and "relative drift" for 139 two clocks C1 and C2 with respect to one another. These are natural 140 extensions of the basic framework definitions of these quantities: 142 + Relative offset = difference in clock times 144 + Relative skew = first derivative of the difference in clock times 146 + Relative drift = second derivative of the difference in clock 147 times 149 NOTE: The drift of a clock, as it is above defined over a long period 150 must have an average value that tends to zero while the period 151 becomes large since the frequency of the clock has a finite (and 152 small) range. In order to underline the order of magnitude of this 153 effect,it is considered that the maximum range of drift for 154 commercial crystals is about 50 part per million (ppm). Since it is 155 mainly connected with variations in operating temperature (from 0 to 156 70 degrees Celsius), it is expected that a host will have a nearly 157 constant temperature during its operation period, and variations in 158 temperature, even if quick, could be less than one Celsius per 159 second, and range in the order of few degrees. The total range of the 160 drift is usually related to variations from 0 to 70 Celsius. These 161 are important points for evaluation of precision of ipdv 162 measurements, as will be seen below. 164 4. A singleton definition of a One-way ipdv metric 166 The purpose of the singleton metric is to define what a single 167 instance of an ipdv measurement is. Note that it can only be 168 statistically significant in combination with other instances. It is 169 not intended to be meaningful as a singleton, in the sense of being 170 able to draw inferences from it. 172 This definition makes use of the corresponding definition of type-P- 173 One-Way-Delay metric [2]. This section makes use of those parts of 174 the One-Way-Delay Draft that directly apply to the One-Way-ipdv 175 metric, or makes direct references to that Draft. 177 4.1. Metric name 179 Type-P-One-way-ipdv 181 4.2. Metric parameters 183 + Src, the IP address of a host 185 + Dst, the IP address of a host 187 + T1, a time 189 + T2, a time 191 + L, a packet length in bits. The packets of a Type P packet stream 192 from which the singleton ipdv metric is taken MUST all be of the 193 same length. 195 + F, a selection function defining unambiguously the two packets 196 from the stream selected for the metric. 198 + I1,I2, times which mark that beginning and ending of the interval 199 in which the packet stream from which the singleton measurement is 200 taken occurs. 202 + P, the specification of the packet type, over and above the source 203 and destination addresses 205 4.3. Metric unit 207 The value of a Type-P-One-way-ipdv is either a real number of seconds 208 (positive, zero or negative) or an undefined number of seconds. 210 4.4. Definition 212 We are given a Type P packet stream and I1 and I2 such that the first 213 Type P packet to pass measurement point MP2 after I1 is given index 0 214 and the last Type P packet to pass measurement point MP2 before I2 is 215 given the highest index number. 217 Type-P-One-way-ipdv is defined for two packets from Src to Dst 218 selected by the selection function F, as the difference between the 219 value of the type-P-One-way- delay from Src to Dst at T2 and the 220 value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the 221 wire-time at which Scr sent the first bit of the first packet, and T2 222 is the wire-time at which Src sent the first bit of the second 223 packet. This metric is derived from the One-Way-Delay metric. 225 T2 denote the wire times of the packets sent from Src to Dst. 227 Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to 228 Dst at T1, T2 is ddT" means that Src sent two packets, the first at 229 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 230 and the packets were received by Dst at wire-time dT1+T1 (last bit of 231 the first packet), and at wire-time dT2+T2 (last bit of the second 232 packet), and that dT2-dT1=ddT. 234 "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means 235 that Src sent the first bit of a packet at T1 and the first bit of a 236 second packet at T2 and that Dst did not receive one or both packets. 238 4.5. Discussion 240 This metric definition depends on a stream of Type-P-One-Way-Delay 241 packets that have been measured. In general this can be a stream of 242 two or more packets, delimited by the interval endpoints I1 and I2. 243 There must be a stream of at least two packets in order for a 244 singleton ipdv measurement to take place. The purpose of the 245 selection function is to specify exactly which two packets from the 246 stream are to be used for the singleton measurement. Note that the 247 selection function may involve observing the one-way-delay of all the 248 Type P packets of the stream in the specified interval. Examples of a 249 selection function are: 251 + Consecutive Type-P packets within the specified interval 253 + Type-P packets with specified indices within the specified 254 interval 256 + Type-P packets with the min and max one-way-delays within the 257 specified interval 259 + Type-P packets with specified indices from the set of all defined 260 (i.e. non-infinite) one-way-delays Type-P packets within the 261 specified interval. 263 The following practical issues have to be considered: 265 + Being a differential measurement, this metric is less sensitive to 266 clock synchronization problems. This issue will be more carefully 267 examined in section 7 of this memo. It is pointed out that, if the 268 relative clock conditions change in time, the accuracy of the 269 measurement will depend on the time interval I2-I1 and the 270 magnitude of possible errors will be discussed below. 272 + A given methodology will have to include a way to determine 273 whether a delay value is infinite or whether it is merely very 274 large (and the packet is yet to arrive at Dst). As noted by 275 Mahdavi and Paxson, simple upper bounds (such as the 255 seconds 276 theoretical upper bound on the lifetimes of IP packets [Postel: 277 RFC 791]) could be used, but good engineering, including an 278 understanding of packet lifetimes, will be needed in practice. 279 Comment: Note that, for many applications of these metrics, the 280 harm in treating a large delay as infinite might be zero or very 281 small. A TCP data packet, for example, that arrives only after 282 several multiples of the RTT may as well have been lost. 284 + As with other 'type-P' metrics, the value of the metric may depend 285 on such properties of the packet as protocol,(UDP or TCP) port 286 number, size, and arrangement for special treatment (as with IP 287 precedence or with RSVP). 289 + If the packet is duplicated along the path (or paths!) so that 290 multiple non-corrupt copies arrive at the destination, then the 291 packet is counted as received, and the first copy to arrive 292 determines the packet's One-Way-Delay. 294 + If the packet is fragmented and if, for whatever reason, 295 reassembly does not occur, then the packet will be deemed lost. 297 It is assumed that the Type-P packet stream is generated according to 298 the Poisson sampling methodology described in [1]. 300 4.6. Methodologies 302 As with other Type-P-* metrics, the detailed methodology will depend 303 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 304 precedence). 306 The measurement methodology described in this section asssumes the 307 measurement and determination of ipdv in real-time as part of an 308 active measurement. Note that this can equally well be done a 309 posteriori, i.e. after the one-way-delay measurement is completed. 311 Generally, for a given Type-P, the methodology would proceed as 312 follows: 314 + The need of synchronized clocks for Src and Dst will be discussed 315 later. Here a methodology is supposed that is based on 316 synchronized clocks. 318 + After time I1, start. At the Src host, select Src and Dst IP 319 addresses, and form test packets of Type-P with these addresses 320 according to a given technique (e.g. the Poisson sampling 321 technique). Any 'padding' portion of the packet needed only to 322 make the test packet a given size should be filled with randomized 323 bits to avoid a situation in which the measured delay is lower 324 than it would otherwise be due to compression techniques along the 325 path. 327 + At the Dst host, arrange to receive the packets. 329 + At the Src host, place a timestamp in the Type-P packet, and send 330 it towards Dst. 332 + If the packet arrives within a reasonable period of time, take a 333 timestamp as soon as possible upon the receipt of the packet. By 334 subtracting the two timestamps, an estimate of One-Way-Delay can 335 be computed. 337 + If the packet meets the selection function criterion for the first 338 packet, record this first delay value. Otherwise, continue 339 generating the Type-P packet stream as above until the criterion 340 is met or I2, whichever comes first. 342 + At the Src host, packets continue to be generated according to the 343 given methodology. The Src host places a timestamp in the Type-P 344 packet, and send it towards Dst. 346 + If the packet arrives within a reasonable period of time, take a 347 timestamp as soon as possible upon the receipt of the packet. By 348 subtracting the two timestamps, an estimate of One-Way-Delay can 349 be computed. 351 + If the packet meets the criterion for the second packet for the 352 second packet, then by subtracting the second value of One-Way- 353 Delay from the first value the ipdv value of the pair of packets 354 is obtained. Otherwise, packets continue to be generated until 355 the criterion for the second packet is fulfilled or I2, whichever 356 comes first. 358 + If one or both packets fail to arrive within a reasonable period 359 of time, the ipdv is taken to be undefined. 361 4.7. Errors and Uncertainties 363 In the singleton metric of ipdv, factors that affect the measurement 364 are the same as those affecting the One-Way-Delay measurement, even 365 if, in this case, the influence is different. 367 The Framework document [1] provides general guidance on this point, 368 but we note here the following specifics related to delay metrics: 370 + Errors/uncertainties due to uncertainties in the clocks of the Src 371 and Dst hosts. 373 + Errors/uncertainties due to the difference between 'wire time' and 374 'host time'. 376 Each of these errors is discussed in more detail in the following 377 paragraphs. 379 4.7.1. Errors/Uncertainties related to Clocks 381 If, as a first approximation, the error that affects the first 382 measurement of One-Way-Delay were the same as the one affecting the 383 second measurement, they will cancel each other when calculating 384 ipdv. The residual error related to clocks is the difference of the 385 errors that are supposed to change from time T1, at which the first 386 measurement is performed, to time T2 at which the second measurement 387 is performed. Synchronization, skew, accuracy and resolution are 388 here considered with the following notes: 390 + Errors in synchronization between source and destination clocks 391 contribute to errors in both of the delay measurements required 392 for calculating ipdv. 394 + The effect of drift and skew errors on ipdv measurements can be 395 quantified as follows: Suppose that the skew and drift functions 396 are known. Assume first that the skew function is linear in time. 397 Clock offset if then also a function of time and the error evolves 398 as e(t) = K*t + O, where K is a constant and O is the offset at 399 time 0. In this case, the error added to the subtraction two 400 different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which 401 will be added to the time difference (t2 - t1). If the drift 402 cannot be ignored, but we assume that the drift is a linear 403 function of time, then the skew is given by s(t) = M*(t**2) + N*t 404 + S0, where M and N are constants and S0 is the skew at time 0. 405 The error added by the variable skew/drift process in this case 406 becomes e(t) = O + s(t) and the error added to the difference in 407 time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. 409 It is the claim here (see remarks in section 3.3) that the effects 410 of skew are rather small over the time scales that we are 411 discussing here, since temperature variations in a system tend to 412 be slow relative to packet inter-transmission times and the range 413 of drift is so small. 415 + As far as accuracy and resolution are concerned, what is noted in 416 the one-way-delay document [2] in section 3.7.1, applies also in 417 this case, with the further consideration, about resolution, that 418 in this case the uncertainty introduced is two times the one of a 419 single delay measurement. Errors introduced by these effects are 420 often larger than the ones introduced by the drift. 422 4.7.2. Errors/uncertainties related to Wire-time vs Host-time 424 The content of sec. 3.7.2 of [2] applies also in this case, with the 425 following further consideration: The difference between Host-time and 426 Wire-time can be in general decomposed into two components, of which 427 one is constant and the other is variable. Only the variable 428 components will produce measurement errors, while the constant one 429 will be canceled while calculating ipdv. 431 However, in most cases, the fixed and variable components are not 432 known exactly. 434 5. Definitions for Samples of One-way ipdv 436 The goal of the sample definition is to make it possible to compute 437 the statistics of sequences of ipdv measurements. The singleton 438 definition is applied to a stream of test packets generated according 439 to a pseudo-random Poisson process with average arrival rate lambda. 440 If necessary, the interval in which the stream is generated can be 441 divided into sub-intervals on which the singleton definition of ipdv 442 can be applied. The result of this is a sequence of ipdv measurements 443 that can be analyzed by various statistical procedures. 445 Starting from the definition of the singleton metric of one-way ipdv, 446 we define a sample of such singletons. In the following, the two 447 packets needed for a singleton measurement will be called a "pair". 449 5.1. Metric name 451 Type-P-One-way-ipdv-Poisson-stream 453 5.2. Parameters 455 + Src, the IP address of a host 457 + Dst, the IP address of a host 459 + T0, a time 461 + Tf, a time 463 + lambda, a rate in reciprocal seconds 465 + L, a packet length in bits. The packets of a Type P packet stream 466 from which the sample ipdv metric is taken MUST all be of the same 467 length. 469 + F, a selection function defining unambiguously the packets from 470 the stream selected for the metric. 472 + I(i),I(i+1), i >=0, pairs of times which mark the beginning and 473 ending of the intervals in which the packet stream from which the 474 measurement is taken occurs. I(0) >= T0 and assuming that n is the 475 largest index, I(n) <= Tf. 477 + P, the specification of the packet type, over and above the source 478 and destination addresses 480 5.3. Metric Units: 482 A sequence of triples whose elements are: 484 + T1, T2,times 486 + dT a real number or an undefined number of seconds 488 5.4. Definition 490 A pseudo-random Poisson process is defined such that it begins at or 491 before T0, with average arrival rate lambda, and ends at or after Tf. 492 Those time values T(i) greater than or equal to T0 and less than or 493 equal to Tf are then selected for packet generation times. 495 Each packet falling within one of the sub-intervals I(i), I(i+1) is 496 tested to determine whether it meets the criteria of the selection 497 function F as the first or second of a packet pair needed to compute 498 ipdv. The sub-intervals can be defined such that a sufficient number 499 of singleton samples for valid statistical estimates can be obtained. 501 The triples defined above consist of the transmission times of the 502 first and second packets of each singleton included in the sample, 503 and the ipdv in seconds. 505 5.5. Discussion 507 Note first that, since a pseudo-random number sequence is employed, 508 the sequence of times, and hence the value of the sample, is not 509 fully specified. Pseudo-random number generators of good quality will 510 be needed to achieve the desired qualities. 512 The sample is defined in terms of a Poisson process both to avoid the 513 effects of self-synchronization and also capture a sample that is 514 statistically as unbiased as possible. There is, of course, no claim 515 that real Internet traffic arrives according to a Poisson arrival 516 process. 518 The sample metric can best be explained with a couple of examples: 519 For the first example, assume that the selection function specifies 520 the "non-infinite" max and min one-way-delays over each sub-interval. 521 We can define contiguous sub-intervals of fixed specifiec length and 522 produce a sequence each of whose elements is the triple which is collected for each sub-interval. A 525 second example is the selection function that specifies packets whose 526 indices (sequence numbers) are just the integers below a certain 527 bound. In this case, the sub-intervals are defined by the 528 transmission times of the generated packets and the sequence produced 529 is just where D(i) denotes the one-way 530 delay of the ith packet of a stream. 532 This definition of the sample metric encompasses both the definition 533 proposed in [8] and the one proposed in [9]. 535 5.6. Methodology 537 Since packets can be lost or duplicated or can arrive in a different 538 order than the order sent, in order to recognize the pairs of test 539 packets, they should be marked with a sequence number. For duplicated 540 packets only the first received copy should be considered. 542 Otherwise, the methodology is the same as for the singleton 543 measurement, with the exception that the singleton measurement is 544 repeated a number of times. 546 5.7. Errors and uncertainties 548 The same considerations apply that have been made about the singleton 549 metric. Additional error can be introduced by the pseudo-random 550 Poisson process as discussed in [2]. Further considerations will be 551 given in section 7. 553 6. Statistics for One-way-ipdv 555 Some statistics are suggested which can provide useful information in 556 analyzing the behavior of the packets flowing from Src to Dst. The 557 statistics are assumed to be computed from an ipdv sample of 558 reasonable size. 560 The purpose is not to define every possible statistic for ipdv, but 561 ones which have been proposed or used. 563 6.1. Lost Packets and ipdv statistics 565 The treatment of lost packets as having "infinite" or "undefined" 566 delay complicates the derivation of statistics for ipdv. 567 Specifically, when packets in the measurement sequence are lost, 568 simple statistics such as sample mean cannot be computed. One 569 possible approach to handling this problem is to reduce the event 570 space by conditioning. That is, we consider conditional statistics; 571 namely we estimate the mean ipdv (or other derivative statistic) 572 conditioned on the event that selected packet pairs arrive at the 573 destination (within the given timeout). While this itself is not 574 without problems (what happens, for example, when every other packet 575 is lost), it offers a way to make some (valid) statements about ipdv, 576 at the same time avoiding events with undefined outcomes. 578 In practical terms, what this means is throwing out the samples where 579 one or both of the selected packets has an undefined delay. The 580 sample space is reduced (conditioned) and we can compute the usual 581 statistics, understanding that formally they are conditional. 583 6.2. Distribution of One-way-ipdv values 585 The one-way-ipdv values are limited by virtue of the fact that there 586 are upper and lower bounds on the one-way-delay values. Specifically, 587 one-way-delay is upper bounded by the value chosen as the maximum 588 beyond which a packet is counted as lost. It is lower bounded by 589 propagation, transmission and nodal transit delays assuming that 590 there are no queues or variable nodal delays in the path. Denote the 591 upper bound of one-way-delay by U and the lower bound by L and we see 592 that one-way-ipdv can only take on values in the (open) interval (L- 593 U, U-L). 595 In any finite interval, the one-way-delay can vary monotonically 596 (non-increasing or non-decreasing) or of course it can vary in both 597 directions in the interval, within the limits of the half-open 598 interval [L,U). Accordingly, within that interval, the one-way-ipdv 599 values can be positive, negative, or a mixture (including 0). 601 Since the range of values is limited, the one-way-ipdv cannot 602 increase or decrease indefinitely. Suppose, for example, that the 603 ipdv has a positive 'run' (i.e. a long sequence of positive values). 604 At some point in this 'run', the positive values must approach 0 (or 605 become negative) if the one-way-delay remains finite. Otherwise, the 606 one-way-delay bounds would be violated. If such a run were to 607 continue infinitely long, the sample mean (assuming no packets are 608 lost) would approach 0 (because the one-way-ipdv values must approach 609 0). Note, however, that this says nothing about the shape of the 610 distribution, or whether it is symmetric. Note further that over 611 significant intervals, depending on the width of the interval [L,U), 612 that the sample mean one-way-ipdv could be positive, negative or 0. 614 There are basically two ways to represent the distribution of values 615 of an ipdv sample: an empirical pdf and an empirical cdf. The 616 empirical pdf is most often represented as a histogram where the 617 range of values of an ipdv sample is divided into bins of a given 618 length and each bin contains the proportion of values falling between 619 the two limits of the bin. (Sometimes instead the number of values 620 falling between the two limits is used). The empirical cdf is simply 621 the proportion of ipdv sample values less than a given value, for a 622 sequence of values selected from the range of ipdv values. 624 6.3. Type-P-One-way-ipdv-percentile 626 Given a Type-P One-Way-ipdv sample and a percent X between 0% and 627 100%, the Xth percentile of all ipdv values in the sample. The 50th 628 percentile is the median. 630 6.4. Type-P-One-way-ipdv-inverse-percentile 632 Given a Type-P-One-way-ipdv sample and a given value Y, the percent 633 of ipdv sample values less than or equal to Y. 635 6.5. Type-P-One-way-ipdv-jitter 637 Although the use of the term "jitter" is deprecated, we use it here 638 following the authors in [7]. In that document, the selection 639 function specifies that consecutive packets of the Type-P stream are 640 to be selected for the packet pairs used in ipdv computation. They 641 then take the absolute value of the ipdv values in the sample. The 642 authors in [7] use the resulting sample to compare the behavior of 643 two different scheduling algorithms. 645 6.6. Type-P-One-way-peak-to-peak-ipdv 647 In this case, the selection function used in collecting the Type-P- 648 One-Way-ipdv sample specifies that the first packet of each pair to 649 be the packet with the maximum Type-P-One-Way-Delay in each sub- 650 interval and the second packet of each pair to be the packet with the 651 minimum Type-P-One-Way-Delay in each sub-interval. The resulting 652 sequence of values is the peak-to-peak delay variation in each sub- 653 interval of the measurement interval. 655 7. Discussion of clock synchronization 657 This section gives some considerations about the need of having 658 synchronized clocks at the source and destination. These 659 considerations are given as a basis for discussion and they require 660 further investigation. 662 7.1. Effects of synchronization errors 664 Clock errors can be generated by two processes: the relative drift 665 and the relative skew of two given clocks. We should note that drift 666 is physically limited and so the total relative skew of two clocks 667 can vary between an upper and a lower bound. 669 Suppose then that we have a measurement between two systems such that 670 the clocks in the source and destination systems have at time 0 a 671 relative skew of s(0) and after a measurement interval T have skew 672 s(T). We assume that the two clocks have an initial offset of O (that 673 is letter O). 675 Now suppose that the packets travel from source to destination in 676 constant time, in which case the ipdv is zero and the difference in 677 the timestamps of the two clocks is actually just the relative offset 678 of the clocks. Suppose further that at the beginning of the 679 measurement interval the ipdv value is calculated from a packet pair 680 and at the end of the measurement interval another ipdv value is 681 calculated from another packet pair. Assume that the time interval 682 covered by the first measurement is t1 and that covered by the second 683 measurement is t2. Then 685 ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T 687 ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T 689 assuming that the change is skew is linear in time. In most practical 690 cases, it is claimed that the drift will be close to zero in which 691 case the second (correction) term in the above equations disappears. 693 Note that in the above discussion, other errors, including the 694 differences between host time and wire time, and externally-caused 695 clock discontinuities (e.g. clock corrections) were ignored. Under 696 these assumptions the maximum clock errors will be due to the maximum 697 relative skew acting on the largest interval between packets. 699 7.2. Estimating the skew of unsynchronized clocks 701 If the skew is linear (that is, if s(t) = S * t for constant S), the 702 error in ipdv values will depend on the time between the packets used 703 in calculating the value. If ti is the time between the packet pair, 704 then let Ti denote the sample mean time between packets and the 705 average skew is s(Ti) = S * Ti. In the event that the delays are 706 constant, the skew parameter S can be estimated from the estimate Ti 707 of the time between packets and the sample mean ipdv value. Under 708 these assumptions, the ipdv values can be corrected by subtracting 709 the estimated S * ti. 711 We observe that the displacement due to the skew does not change the 712 shape of the distribution, and, for example the Standard Deviation 713 remains the same. What introduces a distortion is the effect of the 714 drift, also when the mean value of this effect is zero at the end of 715 the measurement. The value of this distortion is limited to the 716 effect of the total skew variation on the emission interval. 718 8. Security Considerations 720 The one-way-ipdv metric has the same security properties as the one- 721 way-delay metric [2]. The packets contain no user information, and so 722 privacy of user data is not a concern. It is still possible that 723 there could be an attempt at a denial of service attack by sending 724 many measurement packets into the network; there could also be 725 attempts to disrupt measurements by diverting packets or corrupting 726 them. 728 In general, legitimate measurements must have their parameters 729 selected carefully in order to avoid interfering with normal traffic 730 in the network. Such measurements should also be authorized and 731 authenticated in some way so that attacks can be identified and 732 intercepted. 734 9. Acknowledgements 736 This major revision of the draft resulted from e-mail discussions 737 with and suggestions from Mike Pierce, Ruediger Geib, Glenn 738 Grotefeld, and Al Morton. For previous revisions of this document, 739 discussions with Ruediger Geib, Matt Zekauskas and Andy Scherer were 740 very helpful. 742 10. References 743 [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP 744 Performance Metrics", RFC 2330 Feb. 1998 746 [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 747 2679, September 1999 749 [3] ITU-T Recommendation Y.1540 (formerly numbered I.380) 750 "Internet Protocol Data Communication Service - IP Packet 751 Transfer and Availability Performance Parameters", February 1999 753 [4] Demichelis, Carlo - "Packet Delay Variation Comparison between 754 ITU-T and IETF Draft Definitions" November 2000 (in the IPPM 755 mail archives) 757 [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer 758 Performance" 760 [6] S. Keshav - "An Engineering Approach to Computer Networking", 761 Addison-Wesley 1997, ISBN 0-201-63442-2 763 [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding 764 PHB", RFC 2598, June 1999 766 [8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol 767 Communication Service - IP Performance and Availability 768 Objectives and Allocations", April 2000 770 [9] Demichelis, Carlo - "Improvement of the Instantaneous Packet 771 Delay Variation (IPDV) Concept and Applications", World 772 Telecommunications Congress 2000, 7-12 May 2000 774 11. Authors' Addresses 776 Carlo Demichelis 777 CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A 778 Via G. Reiss Romoli 274 779 10148 - TORINO 780 Italy 781 Phone +39 11 228 5057 782 Fax. +39 11 228 5069 783 Philip Chimento 784 Ericsson IPI 785 7301 Calhoun Place 786 Rockville, Maryland 787 20855 788 USA 789 Phone +1-240-314-3597 791 Expiration date: August 2001