idnits 2.17.1 draft-ietf-ippm-ipdv-09.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 108 has weird spacing: '...he ipdv is th...' == Line 433 has weird spacing: '...f these error...' == Line 456 has weird spacing: '... to the subtr...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 827, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 831, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 835, 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' ** Obsolete normative reference: RFC 1889 (ref. '11') (Obsoleted by RFC 3550) Summary: 10 errors (**), 0 flaws (~~), 8 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: October 2002 P. Chimento 5 Ericsson IPI 6 April 2002 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 RFC 2026. 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 defines a metric for the variation in delay of packets that 50 flow from one host to another through an IP path. It is based on "A 51 One-Way-Delay metric for IPPM", RFC 2679 [2] and part of the text in 52 this memo is taken directly from that document; the reader is assumed 53 to be familiar with that document. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [10]. 58 Although RFC 2119 was written with protocols in mind, the key words 59 are used in this document for similar reasons. They are used to 60 ensure the results of measurements from two different implementations 61 are comparable and to note instances where an implementation could 62 perturb the network. 64 The structure of the memo is as follows: 66 + A 'singleton' analytic metric, called Type-P-One-way-ipdv, will be 67 introduced to define a single instance of an ipdv measurement. 69 + Using this singleton metric, as 'sample', called Type-P-one-way- 70 ipdv-Poisson-stream, will be introduced to make it possible to 71 compute the statistics of sequences of ipdv measurements. 73 + Using this sample, several 'statistics' of the sample will be 74 defined and discussed. 76 3.1. Terminology 78 The variation in packet delay is sometimes called "jitter". This 79 term, however, causes confusion because it is used in different ways 80 by different groups of people. 82 "Jitter" commonly has two meanings: The first meaning is the 83 variation of a signal with respect to some clock signal, where the 84 arrival time of the signal is expected to coincide with the arrival 85 of the clock signal. This meaning is used with reference to 86 synchronous signals and might be used to measure the quality of 87 circuit emulation, for example. There is also a metric called 88 "wander" used in this context. 90 The second meaning has to do with the variation of a metric (e.g. 91 delay) with respect to some reference metric (e.g. average delay or 92 minimum delay). This meaning is frequently used by computer 93 scientists and frequently (but not always) refers to variation in 94 delay. 96 In this document we will avoid the term "jitter" whenever possible 97 and stick to delay variation which is more precise. 99 3.2. Definition 101 A definition of the IP Packet Delay Variation (ipdv) can be given for 102 packets inside a stream of packets. 104 The IP Packet Delay Variation (ipdv) of a pair of packets within a 105 stream of packets is defined for a selected pair of packets in the 106 stream going from measurement point MP1 to measurement point MP2. 108 The ipdv is the difference between the one-way-delay of the selected 109 packets. 111 3.3. Motivation 113 One important use of delay variation is the sizing of play-out 114 buffers for applications requiring the regular delivery of packets 115 (for example, voice or video play-out). What is normally important in 116 this case is the maximum delay variation, which is used to size play- 117 out buffers for such applications [6]. Other uses of a delay 118 variation metric are, for example, to determine the dynamics of 119 queues within a network (or router) where the changes in delay 120 variation can be linked to changes in the queue length process at a 121 given link or a combination of links. 123 In addition, this type of metric is particularly robust with respect 124 to differences and variations of the clocks of the two hosts. This 125 allows the use of the metric even if the two hosts that support the 126 measurement points are not synchronized. In the latter case 127 indications of reciprocal skew of the clocks can be derived from the 128 measurement and corrections are possible. The related precision is 129 often comparable with the one that can be achieved with synchronized 130 clocks, being of the same order of magnitude of synchronization 131 errors. This will be discussed below. 133 The scope of this document is to provide a way to measure the ipdv 134 delivered on a path. Our goal is to provide a metric which can be 135 parameterized so that it can be used for various purposes. Any report 136 of the metric MUST include all the parameters associated with it so 137 that the conditions and meaning of the metric can be determined 138 exactly. Since the metric does not represent a value judgment (i.e. 139 define "good" and "bad"), we specifically do not specify particular 140 values of the metrics that IP networks must meet. 142 The flexibility of the metric can be viewed as a disadvantage but 143 there are some arguments for making it flexible. First, though there 144 are some uses of ipdv mentioned above, to some degree the uses of 145 ipdv are still a research topic and some room should be left for 146 experimentation. Secondly, there are different views in the community 147 of what precisely the definition should be (e.g. [7],[8],[9]). The 148 idea here is to parameterize the definition, rather than write a 149 different draft for each proposed definition. As long as all the 150 parameters are reported, it will be clear what is meant by a 151 particular use of ipdv. All the remarks in the draft hold, no matter 152 which parameters are chosen. 154 3.4. General Issues Regarding Time 156 Everything contained in Section 2.2. of [2] applies also in this 157 case. 159 To summarize: As in [1] we define "skew" as the first derivative of 160 the offset of a clock with respect to "true time" and define "drift" 161 as the second derivative of the offset of a clock with respect to 162 "true time". 164 From there, we can construct "relative skew" and "relative drift" for 165 two clocks C1 and C2 with respect to one another. These are natural 166 extensions of the basic framework definitions of these quantities: 168 + Relative offset = difference in clock times 170 + Relative skew = first derivative of the difference in clock times 172 + Relative drift = second derivative of the difference in clock 173 times 175 NOTE: The drift of a clock, as it is above defined over a long period 176 must have an average value that tends to zero while the period 177 becomes large since the frequency of the clock has a finite (and 178 small) range. In order to underline the order of magnitude of this 179 effect,it is considered that the maximum range of drift for 180 commercial crystals is about 50 part per million (ppm). Since it is 181 mainly connected with variations in operating temperature (from 0 to 182 70 degrees Celsius), it is expected that a host will have a nearly 183 constant temperature during its operation period, and variations in 184 temperature, even if quick, could be less than one Celsius per 185 second, and range in the order of few degrees. The total range of the 186 drift is usually related to variations from 0 to 70 Celsius. These 187 are important points for evaluation of precision of ipdv 188 measurements, as will be seen below. 190 4. A singleton definition of a One-way ipdv metric 192 The purpose of the singleton metric is to define what a single 193 instance of an ipdv measurement is. Note that it can only be 194 statistically significant in combination with other instances. It is 195 not intended to be meaningful as a singleton, in the sense of being 196 able to draw inferences from it. 198 This definition makes use of the corresponding definition of type-P- 199 One-Way-Delay metric [2]. This section makes use of those parts of 200 the One-Way-Delay Draft that directly apply to the One-Way-ipdv 201 metric, or makes direct references to that Draft. 203 4.1. Metric name 205 Type-P-One-way-ipdv 207 4.2. Metric parameters 209 + Src, the IP address of a host 211 + Dst, the IP address of a host 213 + T1, a time 215 + T2, a time 217 + L, a packet length in bits. The packets of a Type P packet stream 218 from which the singleton ipdv metric is taken MUST all be of the 219 same length. 221 + F, a selection function defining unambiguously the two packets 222 from the stream selected for the metric. 224 + I1,I2, times which mark that beginning and ending of the interval 225 in which the packet stream from which the singleton measurement is 226 taken occurs. 228 + P, the specification of the packet type, over and above the source 229 and destination addresses 231 4.3. Metric unit 233 The value of a Type-P-One-way-ipdv is either a real number of seconds 234 (positive, zero or negative) or an undefined number of seconds. 236 4.4. Definition 238 We are given a Type P packet stream and I1 and I2 such that the first 239 Type P packet to pass measurement point MP1 after I1 is given index 0 240 and the last Type P packet to pass measurement point MP1 before I2 is 241 given the highest index number. 243 Type-P-One-way-ipdv is defined for two packets from Src to Dst 244 selected by the selection function F, as the difference between the 245 value of the type-P-One-way- delay from Src to Dst at T2 and the 246 value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the 247 wire-time at which Scr sent the first bit of the first packet, and T2 248 is the wire-time at which Src sent the first bit of the second 249 packet. This metric is derived from the One-Way-Delay metric. 251 Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to 252 Dst at T1, T2 is ddT" means that Src sent two packets, the first at 253 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 254 and the packets were received by Dst at wire-time dT1+T1 (last bit of 255 the first packet), and at wire-time dT2+T2 (last bit of the second 256 packet), and that dT2-dT1=ddT. 258 "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means 259 that Src sent the first bit of a packet at T1 and the first bit of a 260 second packet at T2 and that Dst did not receive one or both packets. 262 Figure 1 illustrates this definition. Suppose that packets P(i) and 263 P(k) are selected. 265 I1 P(i) P(j) P(k) I2 267 MP1 268 |----------------------------------------------------------------| 269 |\ |\ |\ 270 | \ | \ | \ 271 | \ | \ | \ 272 | \ | \ | \ 273 |dTi \ |dTj \ |dTk \ 274 |<--->v |<--->v |<--->v 276 MP2 277 |----------------------------------------------------------------| 279 I1 P(i) P(j) P(k) I2 281 Figure 1: Illustration of the definition 283 Then ddT = dTk - dTi as defined above. 285 4.5. Discussion 287 This metric definition depends on a stream of Type-P-One-Way-Delay 288 packets that have been measured. In general this can be a stream of 289 two or more packets, delimited by the interval endpoints I1 and I2. 290 There must be a stream of at least two packets in order for a 291 singleton ipdv measurement to take place. The purpose of the 292 selection function is to specify exactly which two packets from the 293 stream are to be used for the singleton measurement. Note that the 294 selection function may involve observing the one-way-delay of all the 295 Type P packets of the stream in the specified interval. Examples of a 296 selection function are: 298 + Consecutive Type-P packets within the specified interval 300 + Type-P packets with specified indices within the specified 301 interval 303 + Type-P packets with the min and max one-way-delays within the 304 specified interval 306 + Type-P packets with specified indices from the set of all defined 307 (i.e. non-infinite) one-way-delays Type-P packets within the 308 specified interval. 310 The following practical issues have to be considered: 312 + Being a differential measurement, this metric is less sensitive to 313 clock synchronization problems. This issue will be more carefully 314 examined in section 7 of this memo. It is pointed out that, if the 315 relative clock conditions change in time, the accuracy of the 316 measurement will depend on the time interval I2-I1 and the 317 magnitude of possible errors will be discussed below. 319 + A given methodology will have to include a way to determine 320 whether a delay value is infinite or whether it is merely very 321 large (and the packet is yet to arrive at Dst). As noted by 322 Mahdavi and Paxson, simple upper bounds (such as the 255 seconds 323 theoretical upper bound on the lifetimes of IP packets [Postel: 324 RFC 791]) could be used, but good engineering, including an 325 understanding of packet lifetimes, will be needed in practice. 326 Comment: Note that, for many applications of these metrics, the 327 harm in treating a large delay as infinite might be zero or very 328 small. A TCP data packet, for example, that arrives only after 329 several multiples of the RTT may as well have been lost. 331 + As with other 'type-P' metrics, the value of the metric may depend 332 on such properties of the packet as protocol,(UDP or TCP) port 333 number, size, and arrangement for special treatment (as with IP 334 precedence or with RSVP). 336 + ddT is derived from the start of the first bit out from a packet 337 sent out by Src to the reception of the last bit received by Dst. 338 Delay is correlated to the size of the packet. For this reason, 339 the packet size is a parameter of the measurement and must be 340 reported along with the measurement. 342 + If the packet is duplicated along the path (or paths!) so that 343 multiple non-corrupt copies arrive at the destination, then the 344 packet is counted as received, and the first copy to arrive 345 determines the packet's One-Way-Delay. 347 + If the packet is fragmented and if, for whatever reason, 348 reassembly does not occur, then the packet will be deemed lost. 350 In this draft it is assumed that the Type-P packet stream is 351 generated according to the Poisson sampling methodology described in 352 [1]. The reason for Poisson sampling is that it ensures an unbiased 353 and uniformly distributed sampling of times between I1 and I2. 354 However, alternate sampling methodologies are possible. For example, 355 continuous sampling of a constant bit rate stream (i.e. periodic 356 packet transmission) is a possibility. However, in this case, one 357 must be sure to avoid any "aliasing" effects that may occur with 358 periodic samples. 360 4.6. Methodologies 362 As with other Type-P-* metrics, the detailed methodology will depend 363 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 364 precedence). 366 The measurement methodology described in this section assumes the 367 measurement and determination of ipdv in real-time as part of an 368 active measurement. Note that this can equally well be done a 369 posteriori, i.e. after the one-way-delay measurement is completed. 371 Generally, for a given Type-P, the methodology would proceed as 372 follows: Note that this methodology is based on synchronized clocks. 373 The need for synchronized clocks for Src and Dst will be discussed 374 later. 376 + Start after time I1. At the Src host, select Src and Dst IP 377 addresses, and form test packets of Type-P with these addresses 378 according to a given technique (e.g. the Poisson sampling 379 technique). Any 'padding' portion of the packet needed only to 380 make the test packet a given size should be filled with randomized 381 bits to avoid a situation in which the measured delay is lower 382 than it would otherwise be due to compression techniques along the 383 path. 385 + At the Dst host, arrange to receive the packets. 387 + At the Src host, place a time stamp in the Type-P packet, and send 388 it towards Dst. 390 + If the packet arrives within a reasonable period of time, take a 391 time stamp as soon as possible upon the receipt of the packet. By 392 subtracting the two time stamps, an estimate of One-Way-Delay can 393 be computed. 395 + If the packet meets the selection function criterion for the first 396 packet, record this first delay value. Otherwise, continue 397 generating the Type-P packet stream as above until the criterion 398 is met or I2, whichever comes first. 400 + At the Src host, packets continue to be generated according to the 401 given methodology. The Src host places a time stamp in the Type-P 402 packet, and send it towards Dst. 404 + If the packet arrives within a reasonable period of time, take a 405 time stamp as soon as possible upon the receipt of the packet. By 406 subtracting the two time stamps, an estimate of One-Way-Delay can 407 be computed. 409 + If the packet meets the criterion for the second packet, then by 410 subtracting the first value of One-Way-Delay from the second value 411 the ipdv value of the pair of packets is obtained. Otherwise, 412 packets continue to be generated until the criterion for the 413 second packet is fulfilled or I2, whichever comes first. 415 + If one or both packets fail to arrive within a reasonable period 416 of time, the ipdv is taken to be undefined. 418 4.7. Errors and Uncertainties 420 In the singleton metric of ipdv, factors that affect the measurement 421 are the same as those affecting the One-Way-Delay measurement, even 422 if, in this case, the influence is different. 424 The Framework document [1] provides general guidance on this point, 425 but we note here the following specifics related to delay metrics: 427 + Errors/uncertainties due to uncertainties in the clocks of the Src 428 and Dst hosts. 430 + Errors/uncertainties due to the difference between 'wire time' and 431 'host time'. 433 Each of these errors is discussed in more detail in the following 434 paragraphs. 436 4.7.1. Errors/Uncertainties related to Clocks 438 If, as a first approximation, the error that affects the first 439 measurement of One-Way-Delay were the same as the one affecting the 440 second measurement, they will cancel each other when calculating 441 ipdv. The residual error related to clocks is the difference of the 442 errors that are supposed to change from time T1, at which the first 443 measurement is performed, to time T2 at which the second measurement 444 is performed. Synchronization, skew, accuracy and resolution are 445 here considered with the following notes: 447 + Errors in synchronization between source and destination clocks 448 contribute to errors in both of the delay measurements required 449 for calculating ipdv. 451 + The effect of drift and skew errors on ipdv measurements can be 452 quantified as follows: Suppose that the skew and drift functions 453 are known. Assume first that the skew function is linear in time. 454 Clock offset if then also a function of time and the error evolves 455 as e(t) = K*t + O, where K is a constant and O is the offset at 456 time 0. In this case, the error added to the subtraction two 457 different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which 458 will be added to the time difference (t2 - t1). If the drift 459 cannot be ignored, but we assume that the drift is a linear 460 function of time, then the skew is given by s(t) = M*(t**2) + N*t 461 + S0, where M and N are constants and S0 is the skew at time 0. 462 The error added by the variable skew/drift process in this case 463 becomes e(t) = O + s(t) and the error added to the difference in 464 time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. 466 It is the claim here (see remarks in section 3.3) that the effects 467 of skew are rather small over the time scales that we are 468 discussing here, since temperature variations in a system tend to 469 be slow relative to packet inter-transmission times and the range 470 of drift is so small. 472 + As far as accuracy and resolution are concerned, what is noted in 473 the one-way-delay document [2] in section 3.7.1, applies also in 474 this case, with the further consideration, about resolution, that 475 in this case the uncertainty introduced is two times the one of a 476 single delay measurement. Errors introduced by these effects are 477 often larger than the ones introduced by the drift. 479 4.7.2. Errors/uncertainties related to Wire-time vs Host-time 481 The content of sec. 3.7.2 of [2] applies also in this case, with the 482 following further consideration: The difference between Host-time and 483 Wire-time can be in general decomposed into two components, of which 484 one is constant and the other is variable. Only the variable 485 components will produce measurement errors, while the constant one 486 will be canceled while calculating ipdv. 488 However, in most cases, the fixed and variable components are not 489 known exactly. 491 5. Definitions for Samples of One-way ipdv 493 The goal of the sample definition is to make it possible to compute 494 the statistics of sequences of ipdv measurements. The singleton 495 definition is applied to a stream of test packets generated according 496 to a pseudo-random Poisson process with average arrival rate lambda. 497 If necessary, the interval in which the stream is generated can be 498 divided into sub-intervals on which the singleton definition of ipdv 499 can be applied. The result of this is a sequence of ipdv measurements 500 that can be analyzed by various statistical procedures. 502 Starting from the definition of the singleton metric of one-way ipdv, 503 we define a sample of such singletons. In the following, the two 504 packets needed for a singleton measurement will be called a "pair". 506 5.1. Metric name 508 Type-P-One-way-ipdv-Poisson-stream 510 5.2. Parameters 512 + Src, the IP address of a host 514 + Dst, the IP address of a host 516 + T0, a time 518 + Tf, a time 520 + lambda, a rate in reciprocal seconds 521 + L, a packet length in bits. The packets of a Type P packet stream 522 from which the sample ipdv metric is taken MUST all be of the same 523 length. 525 + F, a selection function defining unambiguously the packets from 526 the stream selected for the metric. 528 + I(i),I(i+1), i >=0, pairs of times which mark the beginning and 529 ending of the intervals in which the packet stream from which the 530 measurement is taken occurs. I(0) >= T0 and assuming that n is the 531 largest index, I(n) <= Tf. 533 + P, the specification of the packet type, over and above the source 534 and destination addresses 536 5.3. Metric Units: 538 A sequence of triples whose elements are: 540 + T1, T2,times 542 + dT a real number or an undefined number of seconds 544 5.4. Definition 546 A pseudo-random Poisson process is defined such that it begins at or 547 before T0, with average arrival rate lambda, and ends at or after Tf. 548 Those time values T(i) greater than or equal to T0 and less than or 549 equal to Tf are then selected for packet generation times. 551 Each packet falling within one of the sub-intervals I(i), I(i+1) is 552 tested to determine whether it meets the criteria of the selection 553 function F as the first or second of a packet pair needed to compute 554 ipdv. The sub-intervals can be defined such that a sufficient number 555 of singleton samples for valid statistical estimates can be obtained. 557 The triples defined above consist of the transmission times of the 558 first and second packets of each singleton included in the sample, 559 and the ipdv in seconds. 561 5.5. Discussion 563 Note first that, since a pseudo-random number sequence is employed, 564 the sequence of times, and hence the value of the sample, is not 565 fully specified. Pseudo-random number generators of good quality will 566 be needed to achieve the desired qualities. 568 The sample is defined in terms of a Poisson process both to avoid the 569 effects of self-synchronization and also capture a sample that is 570 statistically as unbiased as possible. There is, of course, no claim 571 that real Internet traffic arrives according to a Poisson arrival 572 process. 574 The sample metric can best be explained with a couple of examples: 575 For the first example, assume that the selection function specifies 576 the "non-infinite" max and min one-way-delays over each sub-interval. 577 We can define contiguous sub-intervals of fixed specified length and 578 produce a sequence each of whose elements is the triple which is collected for each sub-interval. A 581 second example is the selection function that specifies packets whose 582 indices (sequence numbers) are just the integers below a certain 583 bound. In this case, the sub-intervals are defined by the 584 transmission times of the generated packets and the sequence produced 585 is just where D(i) denotes the one-way 586 delay of the ith packet of a stream. 588 This definition of the sample metric encompasses both the definition 589 proposed in [8] and the one proposed in [9]. 591 5.6. Methodology 593 Since packets can be lost or duplicated or can arrive in a different 594 order than the order sent, in order to recognize the pairs of test 595 packets, they should be marked with a sequence number. For duplicated 596 packets only the first received copy should be considered. 598 Otherwise, the methodology is the same as for the singleton 599 measurement, with the exception that the singleton measurement is 600 repeated a number of times. 602 5.7. Errors and uncertainties 604 The same considerations apply that have been made about the singleton 605 metric. Additional error can be introduced by the pseudo-random 606 Poisson process as discussed in [2]. Further considerations will be 607 given in section 7. 609 6. Statistics for One-way-ipdv 611 Some statistics are suggested which can provide useful information in 612 analyzing the behavior of the packets flowing from Src to Dst. The 613 statistics are assumed to be computed from an ipdv sample of 614 reasonable size. 616 The purpose is not to define every possible statistic for ipdv, but 617 ones which have been proposed or used. 619 6.1. Lost Packets and ipdv statistics 621 The treatment of lost packets as having "infinite" or "undefined" 622 delay complicates the derivation of statistics for ipdv. 623 Specifically, when packets in the measurement sequence are lost, 624 simple statistics such as sample mean cannot be computed. One 625 possible approach to handling this problem is to reduce the event 626 space by conditioning. That is, we consider conditional statistics; 627 namely we estimate the mean ipdv (or other derivative statistic) 628 conditioned on the event that selected packet pairs arrive at the 629 destination (within the given timeout). While this itself is not 630 without problems (what happens, for example, when every other packet 631 is lost), it offers a way to make some (valid) statements about ipdv, 632 at the same time avoiding events with undefined outcomes. 634 In practical terms, what this means is throwing out the samples where 635 one or both of the selected packets has an undefined delay. The 636 sample space is reduced (conditioned) and we can compute the usual 637 statistics, understanding that formally they are conditional. 639 6.2. Distribution of One-way-ipdv values 641 The one-way-ipdv values are limited by virtue of the fact that there 642 are upper and lower bounds on the one-way-delay values. Specifically, 643 one-way-delay is upper bounded by the value chosen as the maximum 644 beyond which a packet is counted as lost. It is lower bounded by 645 propagation, transmission and nodal transit delays assuming that 646 there are no queues or variable nodal delays in the path. Denote the 647 upper bound of one-way-delay by U and the lower bound by L and we see 648 that one-way-ipdv can only take on values in the (open) interval (L- 649 U, U-L). 651 In any finite interval, the one-way-delay can vary monotonically 652 (non-increasing or non-decreasing) or of course it can vary in both 653 directions in the interval, within the limits of the half-open 654 interval [L,U). Accordingly, within that interval, the one-way-ipdv 655 values can be positive, negative, or a mixture (including 0). 657 Since the range of values is limited, the one-way-ipdv cannot 658 increase or decrease indefinitely. Suppose, for example, that the 659 ipdv has a positive 'run' (i.e. a long sequence of positive values). 660 At some point in this 'run', the positive values must approach 0 (or 661 become negative) if the one-way-delay remains finite. Otherwise, the 662 one-way-delay bounds would be violated. If such a run were to 663 continue infinitely long, the sample mean (assuming no packets are 664 lost) would approach 0 (because the one-way-ipdv values must approach 665 0). Note, however, that this says nothing about the shape of the 666 distribution, or whether it is symmetric. Note further that over 667 significant intervals, depending on the width of the interval [L,U), 668 that the sample mean one-way-ipdv could be positive, negative or 0. 670 There are basically two ways to represent the distribution of values 671 of an ipdv sample: an empirical pdf and an empirical cdf. The 672 empirical pdf is most often represented as a histogram where the 673 range of values of an ipdv sample is divided into bins of a given 674 length and each bin contains the proportion of values falling between 675 the two limits of the bin. (Sometimes instead the number of values 676 falling between the two limits is used). The empirical cdf is simply 677 the proportion of ipdv sample values less than a given value, for a 678 sequence of values selected from the range of ipdv values. 680 6.3. Type-P-One-way-ipdv-percentile 682 Given a Type-P One-Way-ipdv sample and a percent X between 0% and 683 100%, the Xth percentile of all ipdv values in the sample. The 50th 684 percentile is the median. 686 6.4. Type-P-One-way-ipdv-inverse-percentile 688 Given a Type-P-One-way-ipdv sample and a given value Y, the percent 689 of ipdv sample values less than or equal to Y. 691 6.5. Type-P-One-way-ipdv-jitter 693 Although the use of the term "jitter" is deprecated, we use it here 694 following the authors in [7]. In that document, the selection 695 function specifies that consecutive packets of the Type-P stream are 696 to be selected for the packet pairs used in ipdv computation. They 697 then take the absolute value of the ipdv values in the sample. The 698 authors in [7] use the resulting sample to compare the behavior of 699 two different scheduling algorithms. 701 An alternate, but related, way of computing an estimate of jitter is 702 given in RFC 1889 [11]. The selection function there is implicitly 703 consecutive packet pairs, and the "jitter estimate" is computed by 704 taking the absolute values of the ipdv sequence (as defined in this 705 draft) and applying an exponential filter with parameter 1/16 to 706 generate the estimate (i.e. j_new = 15/16* j_old + 1/16*j_new). 708 6.6. Type-P-One-way-peak-to-peak-ipdv 710 In this case, the selection function used in collecting the Type-P- 711 One-Way-ipdv sample specifies that the first packet of each pair to 712 be the packet with the maximum Type-P-One-Way-Delay in each sub- 713 interval and the second packet of each pair to be the packet with the 714 minimum Type-P-One-Way-Delay in each sub-interval. The resulting 715 sequence of values is the peak-to-peak delay variation in each sub- 716 interval of the measurement interval. 718 7. Discussion of clock synchronization 720 This section gives some considerations about the need for having 721 synchronized clocks at the source and destination, although in the 722 case of unsynchronized clocks, data from the measurements themselves 723 can be used to correct error. These considerations are given as a 724 basis for discussion and they require further investigation. 726 7.1. Effects of synchronization errors 728 Clock errors can be generated by two processes: the relative drift 729 and the relative skew of two given clocks. We should note that drift 730 is physically limited and so the total relative skew of two clocks 731 can vary between an upper and a lower bound. 733 Suppose then that we have a measurement between two systems such that 734 the clocks in the source and destination systems have at time 0 a 735 relative skew of s(0) and after a measurement interval T have skew 736 s(T). We assume that the two clocks have an initial offset of O (that 737 is letter O). 739 Now suppose that the packets travel from source to destination in 740 constant time, in which case the ipdv is zero and the difference in 741 the time stamps of the two clocks is actually just the relative 742 offset of the clocks. Suppose further that at the beginning of the 743 measurement interval the ipdv value is calculated from a packet pair 744 and at the end of the measurement interval another ipdv value is 745 calculated from another packet pair. Assume that the time interval 746 covered by the first measurement is t1 and that covered by the second 747 measurement is t2. Then 749 ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T 751 ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T 753 assuming that the change is skew is linear in time. In most practical 754 cases, it is claimed that the drift will be close to zero in which 755 case the second (correction) term in the above equations disappears. 757 Note that in the above discussion, other errors, including the 758 differences between host time and wire time, and externally-caused 759 clock discontinuities (e.g. clock corrections) were ignored. Under 760 these assumptions the maximum clock errors will be due to the maximum 761 relative skew acting on the largest interval between packets. 763 7.2. Estimating the skew of unsynchronized clocks 765 If the skew is linear (that is, if s(t) = S * t for constant S), the 766 error in ipdv values will depend on the time between the packets used 767 in calculating the value. If ti is the time between the packet pair, 768 then let Ti denote the sample mean time between packets and the 769 average skew is s(Ti) = S * Ti. In the event that the delays are 770 constant, the skew parameter S can be estimated from the estimate Ti 771 of the time between packets and the sample mean ipdv value. Under 772 these assumptions, the ipdv values can be corrected by subtracting 773 the estimated S * ti. 775 We observe that the displacement due to the skew does not change the 776 shape of the distribution, and, for example the Standard Deviation 777 remains the same. What introduces a distortion is the effect of the 778 drift, also when the mean value of this effect is zero at the end of 779 the measurement. The value of this distortion is limited to the 780 effect of the total skew variation on the emission interval. 782 8. Security Considerations 784 The one-way-ipdv metric has the same security properties as the one- 785 way-delay metric [2], and thus they inherit the security 786 considerations of that document. The reader should consult [2] for a 787 more detailed treatment of security considerations. Nevertheless, 788 there are a few things to highlight. 790 8.1. Denial of service 792 It is still possible that there could be an attempt at a denial of 793 service attack by sending many measurement packets into the network. 794 In general, legitimate measurements must have their parameters 795 carefully selected in order to avoid interfering with normal traffic. 797 8.2. Privacy/Confidentiality 799 The packets contain no user information, and so privacy of user data 800 is not a concern. 802 8.3. Integrity 804 There could also be attempts to disrupt measurements by diverting 805 packets or corrupting them. To ensure that test packets are valid and 806 have not be altered during transit, packet authentication and 807 integrity checks may be used. 809 9. Acknowledgments 811 Thanks to Merike Kaeo, Al Morton and Henk Uiterwaal for catching 812 mistakes and for clarifying re-wordings for this final draft. 814 A previous major revision of the draft resulted from e-mail 815 discussions with and suggestions from Mike Pierce, Ruediger Geib, 816 Glenn Grotefeld, and Al Morton. For previous revisions of this 817 document, discussions with Ruediger Geib, Matt Zekauskas and Andy 818 Scherer were very helpful. 820 10. References 821 [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP 822 Performance Metrics", RFC 2330 Feb. 1998 (Normative) 824 [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 825 2679, September 1999 (Normative) 827 [3] ITU-T Recommendation Y.1540 (formerly numbered I.380) 828 "Internet Protocol Data Communication Service - IP Packet 829 Transfer and Availability Performance Parameters", February 1999 831 [4] Demichelis, Carlo - "Packet Delay Variation Comparison between 832 ITU-T and IETF Draft Definitions" November 2000 (in the IPPM 833 mail archives) 835 [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer 836 Performance" 838 [6] S. Keshav - "An Engineering Approach to Computer Networking", 839 Addison-Wesley 1997, ISBN 0-201-63442-2 841 [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding 842 PHB", RFC 2598, June 1999 844 [8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol 845 Communication Service - IP Performance and Availability 846 Objectives and Allocations", April 2000 848 [9] Demichelis, Carlo - "Improvement of the Instantaneous Packet 849 Delay Variation (IPDV) Concept and Applications", World 850 Telecommunications Congress 2000, 7-12 May 2000 852 [10] Bradner, Scott - "Key words for use in RFCs to indicate 853 requirement levels", RFC 2119, March 1997 855 [11] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson - "RTP: A 856 transport protocol for real-time applications", RFC 1889, 857 January 1996 859 11. Authors' Addresses 861 Carlo Demichelis 862 CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A 863 Via G. Reiss Romoli 274 864 10148 - TORINO 865 Italy 866 Phone +39 11 228 5057 867 Fax. +39 11 228 5069 868 Philip Chimento 869 Ericsson IPI 870 7301 Calhoun Place 871 Rockville, Maryland 872 20855 873 USA 874 Phone +1-240-314-3597 876 Expiration date: October 2002