idnits 2.17.1 draft-ietf-ippm-ipdv-08.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. ** There are 73 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 107 has weird spacing: '...he ipdv is th...' == Line 424 has weird spacing: '...f these error...' == Line 447 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 804, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 808, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 812, 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: 11 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: May 2002 P. Chimento 5 Ericsson IPI 6 November 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 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' anlaytic 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. | 107 The ipdv is the difference between the one-way-delay of the selected | 108 packets. 110 3.3. Motivation 112 One important use of delay variation is the sizing of playout buffers 113 for applications requiring the regular delivery of packets (for 114 example, voice or video playout). What is normally important in this 115 case is the maximum delay variation, which is used to size playout 116 buffers for such applications [6]. Other uses of a delay variation 117 metric are, for example, to determine the dynamics of queues within a 118 network (or router) where the changes in delay variation can be 119 linked to changes in the queue length process at a given link or a 120 combination of links. 122 In addition, this type of metric is particularly robust with respect 123 to differences and variations of the clocks of the two hosts. This 124 allows the use of the metric even if the two hosts that support the 125 measurement points are not synchronized. In the latter case 126 indications of reciprocal skew of the clocks can be derived from the 127 measurement and corrections are possible. The related precision is 128 often comparable with the one that can be achieved with synchronized 129 clocks, being of the same order of magnitude of synchronization 130 errors. This will be discussed below. 132 The scope of this document is to provide a way to measure the ipdv 133 delivered on a path. Our goal is to provide a metric which can be 134 parameterized so that it can be used for various purposes. Any report 135 of the metric MUST include all the parameters associated with it so 136 that the conditions and meaning of the metric can be determined 137 exactly. Since the metric does not represent a value judgement (i.e. 138 define "good" and "bad"), ee specifically do not specify particular 139 values of the metrics that IP networks must meet. 141 The flexibility of the metric can be viewed as a disadvantage but 142 there are some arguments for making it flexible. First, though there 143 are some uses of ipdv mentioned above, to some degree the uses of 144 ipdv are still a research topic and some room should be left for 145 experimentation. Secondly, there are different views in the community 146 of what precisely the definition should be (e.g. [7],[8],[9]). The 147 idea here is to parameterize the definition, rather than write a 148 different draft for each proposed definition. As long as all the 149 parameters are reported, it will be clear what is meant by a 150 particular use of ipdv. All the remarks in the draft hold, no matter 151 which parameters are chosen. 153 3.4. General Issues Regarding Time 155 Everything contained in Section 2.2. of [2] applies also in this 156 case. 158 To summarize: As in [1] we define "skew" as the first derivative of 159 the offset of a clock with respect to "true time" and define "drift" 160 as the second derivative of the offset of a clock with respect to 161 "true time". 163 From there, we can construct "relative skew" and "relative drift" for 164 two clocks C1 and C2 with respect to one another. These are natural 165 extensions of the basic framework definitions of these quantities: 167 + Relative offset = difference in clock times 168 + Relative skew = first derivative of the difference in clock times 170 + Relative drift = second derivative of the difference in clock 171 times 173 NOTE: The drift of a clock, as it is above defined over a long period 174 must have an average value that tends to zero while the period 175 becomes large since the frequency of the clock has a finite (and 176 small) range. In order to underline the order of magnitude of this 177 effect,it is considered that the maximum range of drift for 178 commercial crystals is about 50 part per million (ppm). Since it is 179 mainly connected with variations in operating temperature (from 0 to 180 70 degrees Celsius), it is expected that a host will have a nearly 181 constant temperature during its operation period, and variations in 182 temperature, even if quick, could be less than one Celsius per 183 second, and range in the order of few degrees. The total range of the 184 drift is usually related to variations from 0 to 70 Celsius. These 185 are important points for evaluation of precision of ipdv 186 measurements, as will be seen below. 188 4. A singleton definition of a One-way ipdv metric 190 The purpose of the singleton metric is to define what a single 191 instance of an ipdv measurement is. Note that it can only be 192 statistically significant in combination with other instances. It is 193 not intended to be meaningful as a singleton, in the sense of being 194 able to draw inferences from it. 196 This definition makes use of the corresponding definition of type-P- 197 One-Way-Delay metric [2]. This section makes use of those parts of 198 the One-Way-Delay Draft that directly apply to the One-Way-ipdv 199 metric, or makes direct references to that Draft. 201 4.1. Metric name 203 Type-P-One-way-ipdv 205 4.2. Metric parameters 207 + Src, the IP address of a host 209 + Dst, the IP address of a host 210 + T1, a time 212 + T2, a time 214 + L, a packet length in bits. The packets of a Type P packet stream 215 from which the singleton ipdv metric is taken MUST all be of the 216 same length. 218 + F, a selection function defining unambiguously the two packets 219 from the stream selected for the metric. 221 + I1,I2, times which mark that beginning and ending of the interval 222 in which the packet stream from which the singleton measurement is 223 taken occurs. 225 + P, the specification of the packet type, over and above the source 226 and destination addresses 228 4.3. Metric unit 230 The value of a Type-P-One-way-ipdv is either a real number of seconds 231 (positive, zero or negative) or an undefined number of seconds. 233 4.4. Definition 235 We are given a Type P packet stream and I1 and I2 such that the first | 236 Type P packet to pass measurement point MP1 after I1 is given index 0 | 237 and the last Type P packet to pass measurement point MP1 before I2 is 238 given the highest index number. 240 Type-P-One-way-ipdv is defined for two packets from Src to Dst 241 selected by the selection function F, as the difference between the 242 value of the type-P-One-way- delay from Src to Dst at T2 and the 243 value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the 244 wire-time at which Scr sent the first bit of the first packet, and T2 245 is the wire-time at which Src sent the first bit of the second 246 packet. This metric is derived from the One-Way-Delay metric. | 248 Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to 249 Dst at T1, T2 is ddT" means that Src sent two packets, the first at 250 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 251 and the packets were received by Dst at wire-time dT1+T1 (last bit of 252 the first packet), and at wire-time dT2+T2 (last bit of the second 253 packet), and that dT2-dT1=ddT. 255 "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means 256 that Src sent the first bit of a packet at T1 and the first bit of a 257 second packet at T2 and that Dst did not receive one or both packets. 259 Figure 1 illustrates this definition. Suppose that packets P(i) and | 260 P(k) are selected. | 262 I1 P(i) P(j) P(k) I2 | 264 MP1 | 265 |----------------------------------------------------------------| | 266 |\ |\ |\ | 267 | \ | \ | \ | 268 | \ | \ | \ | 269 | \ | \ | \ | 270 |dTi \ |dTj \ |dTk \ | 271 |<--->v |<--->v |<--->v | 273 MP2 | 274 |----------------------------------------------------------------| | 276 I1 P(i) P(j) P(k) I2 | 278 Figure 1: Illustration of the definition | 280 Then ddT = dTk - dTi as defined above. 282 4.5. Discussion 284 This metric definition depends on a stream of Type-P-One-Way-Delay 285 packets that have been measured. In general this can be a stream of 286 two or more packets, delimited by the interval endpoints I1 and I2. 287 There must be a stream of at least two packets in order for a 288 singleton ipdv measurement to take place. The purpose of the 289 selection function is to specify exactly which two packets from the 290 stream are to be used for the singleton measurement. Note that the 291 selection function may involve observing the one-way-delay of all the 292 Type P packets of the stream in the specified interval. Examples of a 293 selection function are: 295 + Consecutive Type-P packets within the specified interval 297 + Type-P packets with specified indices within the specified 298 interval 300 + Type-P packets with the min and max one-way-delays within the 301 specified interval 303 + Type-P packets with specified indices from the set of all defined 304 (i.e. non-infinite) one-way-delays Type-P packets within the 305 specified interval. 307 The following practical issues have to be considered: 309 + Being a differential measurement, this metric is less sensitive to 310 clock synchronization problems. This issue will be more carefully 311 examined in section 7 of this memo. It is pointed out that, if the 312 relative clock conditions change in time, the accuracy of the 313 measurement will depend on the time interval I2-I1 and the 314 magnitude of possible errors will be discussed below. 316 + A given methodology will have to include a way to determine 317 whether a delay value is infinite or whether it is merely very 318 large (and the packet is yet to arrive at Dst). As noted by 319 Mahdavi and Paxson, simple upper bounds (such as the 255 seconds 320 theoretical upper bound on the lifetimes of IP packets [Postel: 321 RFC 791]) could be used, but good engineering, including an 322 understanding of packet lifetimes, will be needed in practice. 323 Comment: Note that, for many applications of these metrics, the 324 harm in treating a large delay as infinite might be zero or very 325 small. A TCP data packet, for example, that arrives only after 326 several multiples of the RTT may as well have been lost. 328 + As with other 'type-P' metrics, the value of the metric may depend 329 on such properties of the packet as protocol,(UDP or TCP) port 330 number, size, and arrangement for special treatment (as with IP 331 precedence or with RSVP). 333 + If the packet is duplicated along the path (or paths!) so that 334 multiple non-corrupt copies arrive at the destination, then the 335 packet is counted as received, and the first copy to arrive 336 determines the packet's One-Way-Delay. 338 + If the packet is fragmented and if, for whatever reason, 339 reassembly does not occur, then the packet will be deemed lost. 341 In this draft it is assumed that the Type-P packet stream is | 342 generated according to the Poisson sampling methodology described in | 343 [1]. The reason for Poisson sampling is that it ensures an unbiased | 344 and uniformly distributed sampling of times between I1 and I2. | 345 However, alternate sampling methodologies are possible. For example, | 346 continuous sampling of a constant bit rate stream (i.e. periodic | 347 packet transmission) is a possibility. However, in this case, one | 348 must be sure to avoid any "aliasing" effects that may occur with | 349 periodic samples. 351 4.6. Methodologies 353 As with other Type-P-* metrics, the detailed methodology will depend 354 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 355 precedence). 357 The measurement methodology described in this section asssumes the 358 measurement and determination of ipdv in real-time as part of an 359 active measurement. Note that this can equally well be done a 360 posteriori, i.e. after the one-way-delay measurement is completed. 362 Generally, for a given Type-P, the methodology would proceed as 363 follows: Note that this methodology is based on synchronized clocks. 364 The need for synchronized clocks for Src and Dst will be discussed 365 later. 367 + Start after time I1. At the Src host, select Src and Dst IP 368 addresses, and form test packets of Type-P with these addresses 369 according to a given technique (e.g. the Poisson sampling 370 technique). Any 'padding' portion of the packet needed only to 371 make the test packet a given size should be filled with randomized 372 bits to avoid a situation in which the measured delay is lower 373 than it would otherwise be due to compression techniques along the 374 path. 376 + At the Dst host, arrange to receive the packets. 378 + At the Src host, place a timestamp in the Type-P packet, and send 379 it towards Dst. 381 + If the packet arrives within a reasonable period of time, take a 382 timestamp as soon as possible upon the receipt of the packet. By 383 subtracting the two timestamps, an estimate of One-Way-Delay can 384 be computed. 386 + If the packet meets the selection function criterion for the first 387 packet, record this first delay value. Otherwise, continue 388 generating the Type-P packet stream as above until the criterion 389 is met or I2, whichever comes first. 391 + At the Src host, packets continue to be generated according to the 392 given methodology. The Src host places a timestamp in the Type-P 393 packet, and send it towards Dst. 395 + If the packet arrives within a reasonable period of time, take a 396 timestamp as soon as possible upon the receipt of the packet. By 397 subtracting the two timestamps, an estimate of One-Way-Delay can 398 be computed. 400 + If the packet meets the criterion for the second packet, then by | 401 subtracting the first value of One-Way-Delay from the second value | 402 the ipdv value of the pair of packets is obtained. Otherwise, 403 packets continue to be generated until the criterion for the 404 second packet is fulfilled or I2, whichever comes first. 406 + If one or both packets fail to arrive within a reasonable period 407 of time, the ipdv is taken to be undefined. 409 4.7. Errors and Uncertainties 411 In the singleton metric of ipdv, factors that affect the measurement 412 are the same as those affecting the One-Way-Delay measurement, even 413 if, in this case, the influence is different. 415 The Framework document [1] provides general guidance on this point, 416 but we note here the following specifics related to delay metrics: 418 + Errors/uncertainties due to uncertainties in the clocks of the Src 419 and Dst hosts. 421 + Errors/uncertainties due to the difference between 'wire time' and 422 'host time'. 424 Each of these errors is discussed in more detail in the following 425 paragraphs. 427 4.7.1. Errors/Uncertainties related to Clocks 429 If, as a first approximation, the error that affects the first 430 measurement of One-Way-Delay were the same as the one affecting the 431 second measurement, they will cancel each other when calculating 432 ipdv. The residual error related to clocks is the difference of the 433 errors that are supposed to change from time T1, at which the first 434 measurement is performed, to time T2 at which the second measurement 435 is performed. Synchronization, skew, accuracy and resolution are 436 here considered with the following notes: 438 + Errors in synchronization between source and destination clocks 439 contribute to errors in both of the delay measurements required 440 for calculating ipdv. 442 + The effect of drift and skew errors on ipdv measurements can be 443 quantified as follows: Suppose that the skew and drift functions 444 are known. Assume first that the skew function is linear in time. 445 Clock offset if then also a function of time and the error evolves 446 as e(t) = K*t + O, where K is a constant and O is the offset at 447 time 0. In this case, the error added to the subtraction two 448 different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which 449 will be added to the time difference (t2 - t1). If the drift 450 cannot be ignored, but we assume that the drift is a linear 451 function of time, then the skew is given by s(t) = M*(t**2) + N*t 452 + S0, where M and N are constants and S0 is the skew at time 0. 453 The error added by the variable skew/drift process in this case 454 becomes e(t) = O + s(t) and the error added to the difference in 455 time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. 457 It is the claim here (see remarks in section 3.3) that the effects 458 of skew are rather small over the time scales that we are 459 discussing here, since temperature variations in a system tend to 460 be slow relative to packet inter-transmission times and the range 461 of drift is so small. 463 + As far as accuracy and resolution are concerned, what is noted in 464 the one-way-delay document [2] in section 3.7.1, applies also in 465 this case, with the further consideration, about resolution, that 466 in this case the uncertainty introduced is two times the one of a 467 single delay measurement. Errors introduced by these effects are 468 often larger than the ones introduced by the drift. 470 4.7.2. Errors/uncertainties related to Wire-time vs Host-time 472 The content of sec. 3.7.2 of [2] applies also in this case, with the 473 following further consideration: The difference between Host-time and 474 Wire-time can be in general decomposed into two components, of which 475 one is constant and the other is variable. Only the variable 476 components will produce measurement errors, while the constant one 477 will be canceled while calculating ipdv. 479 However, in most cases, the fixed and variable components are not 480 known exactly. 482 5. Definitions for Samples of One-way ipdv 484 The goal of the sample definition is to make it possible to compute 485 the statistics of sequences of ipdv measurements. The singleton 486 definition is applied to a stream of test packets generated according 487 to a pseudo-random Poisson process with average arrival rate lambda. 488 If necessary, the interval in which the stream is generated can be 489 divided into sub-intervals on which the singleton definition of ipdv 490 can be applied. The result of this is a sequence of ipdv measurements 491 that can be analyzed by various statistical procedures. 493 Starting from the definition of the singleton metric of one-way ipdv, 494 we define a sample of such singletons. In the following, the two 495 packets needed for a singleton measurement will be called a "pair". 497 5.1. Metric name 499 Type-P-One-way-ipdv-Poisson-stream 501 5.2. Parameters 503 + Src, the IP address of a host 505 + Dst, the IP address of a host 507 + T0, a time 509 + Tf, a time 511 + lambda, a rate in reciprocal seconds 513 + L, a packet length in bits. The packets of a Type P packet stream 514 from which the sample ipdv metric is taken MUST all be of the same 515 length. 517 + F, a selection function defining unambiguously the packets from 518 the stream selected for the metric. 520 + I(i),I(i+1), i >=0, pairs of times which mark the beginning and 521 ending of the intervals in which the packet stream from which the 522 measurement is taken occurs. I(0) >= T0 and assuming that n is the 523 largest index, I(n) <= Tf. 525 + P, the specification of the packet type, over and above the source 526 and destination addresses 528 5.3. Metric Units: 530 A sequence of triples whose elements are: 532 + T1, T2,times 534 + dT a real number or an undefined number of seconds 536 5.4. Definition 538 A pseudo-random Poisson process is defined such that it begins at or 539 before T0, with average arrival rate lambda, and ends at or after Tf. 540 Those time values T(i) greater than or equal to T0 and less than or 541 equal to Tf are then selected for packet generation times. 543 Each packet falling within one of the sub-intervals I(i), I(i+1) is 544 tested to determine whether it meets the criteria of the selection 545 function F as the first or second of a packet pair needed to compute 546 ipdv. The sub-intervals can be defined such that a sufficient number 547 of singleton samples for valid statistical estimates can be obtained. 549 The triples defined above consist of the transmission times of the 550 first and second packets of each singleton included in the sample, 551 and the ipdv in seconds. 553 5.5. Discussion 555 Note first that, since a pseudo-random number sequence is employed, 556 the sequence of times, and hence the value of the sample, is not 557 fully specified. Pseudo-random number generators of good quality will 558 be needed to achieve the desired qualities. 560 The sample is defined in terms of a Poisson process both to avoid the 561 effects of self-synchronization and also capture a sample that is 562 statistically as unbiased as possible. There is, of course, no claim 563 that real Internet traffic arrives according to a Poisson arrival 564 process. 566 The sample metric can best be explained with a couple of examples: 567 For the first example, assume that the selection function specifies 568 the "non-infinite" max and min one-way-delays over each sub-interval. 569 We can define contiguous sub-intervals of fixed specifiec length and 570 produce a sequence each of whose elements is the triple which is collected for each sub-interval. A 573 second example is the selection function that specifies packets whose 574 indices (sequence numbers) are just the integers below a certain 575 bound. In this case, the sub-intervals are defined by the 576 transmission times of the generated packets and the sequence produced 577 is just where D(i) denotes the one-way | 578 delay of the ith packet of a stream. 580 This definition of the sample metric encompasses both the definition 581 proposed in [8] and the one proposed in [9]. 583 5.6. Methodology 585 Since packets can be lost or duplicated or can arrive in a different 586 order than the order sent, in order to recognize the pairs of test 587 packets, they should be marked with a sequence number. For duplicated 588 packets only the first received copy should be considered. 590 Otherwise, the methodology is the same as for the singleton 591 measurement, with the exception that the singleton measurement is 592 repeated a number of times. 594 5.7. Errors and uncertainties 596 The same considerations apply that have been made about the singleton 597 metric. Additional error can be introduced by the pseudo-random 598 Poisson process as discussed in [2]. Further considerations will be 599 given in section 7. 601 6. Statistics for One-way-ipdv 603 Some statistics are suggested which can provide useful information in 604 analyzing the behavior of the packets flowing from Src to Dst. The 605 statistics are assumed to be computed from an ipdv sample of 606 reasonable size. 608 The purpose is not to define every possible statistic for ipdv, but 609 ones which have been proposed or used. 611 6.1. Lost Packets and ipdv statistics 613 The treatment of lost packets as having "infinite" or "undefined" 614 delay complicates the derivation of statistics for ipdv. 615 Specifically, when packets in the measurement sequence are lost, 616 simple statistics such as sample mean cannot be computed. One 617 possible approach to handling this problem is to reduce the event 618 space by conditioning. That is, we consider conditional statistics; 619 namely we estimate the mean ipdv (or other derivative statistic) 620 conditioned on the event that selected packet pairs arrive at the 621 destination (within the given timeout). While this itself is not 622 without problems (what happens, for example, when every other packet 623 is lost), it offers a way to make some (valid) statements about ipdv, 624 at the same time avoiding events with undefined outcomes. 626 In practical terms, what this means is throwing out the samples where 627 one or both of the selected packets has an undefined delay. The 628 sample space is reduced (conditioned) and we can compute the usual 629 statistics, understanding that formally they are conditional. 631 6.2. Distribution of One-way-ipdv values 633 The one-way-ipdv values are limited by virtue of the fact that there 634 are upper and lower bounds on the one-way-delay values. Specifically, 635 one-way-delay is upper bounded by the value chosen as the maximum 636 beyond which a packet is counted as lost. It is lower bounded by 637 propagation, transmission and nodal transit delays assuming that 638 there are no queues or variable nodal delays in the path. Denote the 639 upper bound of one-way-delay by U and the lower bound by L and we see 640 that one-way-ipdv can only take on values in the (open) interval (L- 641 U, U-L). 643 In any finite interval, the one-way-delay can vary monotonically 644 (non-increasing or non-decreasing) or of course it can vary in both 645 directions in the interval, within the limits of the half-open 646 interval [L,U). Accordingly, within that interval, the one-way-ipdv 647 values can be positive, negative, or a mixture (including 0). 649 Since the range of values is limited, the one-way-ipdv cannot 650 increase or decrease indefinitely. Suppose, for example, that the 651 ipdv has a positive 'run' (i.e. a long sequence of positive values). 652 At some point in this 'run', the positive values must approach 0 (or 653 become negative) if the one-way-delay remains finite. Otherwise, the 654 one-way-delay bounds would be violated. If such a run were to 655 continue infinitely long, the sample mean (assuming no packets are 656 lost) would approach 0 (because the one-way-ipdv values must approach 657 0). Note, however, that this says nothing about the shape of the 658 distribution, or whether it is symmetric. Note further that over 659 significant intervals, depending on the width of the interval [L,U), 660 that the sample mean one-way-ipdv could be positive, negative or 0. 662 There are basically two ways to represent the distribution of values 663 of an ipdv sample: an empirical pdf and an empirical cdf. The 664 empirical pdf is most often represented as a histogram where the 665 range of values of an ipdv sample is divided into bins of a given 666 length and each bin contains the proportion of values falling between 667 the two limits of the bin. (Sometimes instead the number of values 668 falling between the two limits is used). The empirical cdf is simply 669 the proportion of ipdv sample values less than a given value, for a 670 sequence of values selected from the range of ipdv values. 672 6.3. Type-P-One-way-ipdv-percentile 674 Given a Type-P One-Way-ipdv sample and a percent X between 0% and 675 100%, the Xth percentile of all ipdv values in the sample. The 50th 676 percentile is the median. 678 6.4. Type-P-One-way-ipdv-inverse-percentile 680 Given a Type-P-One-way-ipdv sample and a given value Y, the percent 681 of ipdv sample values less than or equal to Y. 683 6.5. Type-P-One-way-ipdv-jitter 685 Although the use of the term "jitter" is deprecated, we use it here 686 following the authors in [7]. In that document, the selection 687 function specifies that consecutive packets of the Type-P stream are 688 to be selected for the packet pairs used in ipdv computation. They 689 then take the absolute value of the ipdv values in the sample. The 690 authors in [7] use the resulting sample to compare the behavior of 691 two different scheduling algorithms. 693 An alternate, but related, way of computing an estimate of jitter is | 694 given in RFC 1889 [11]. The selection function there is implicitly | 695 consecutive packet pairs, and the "jitter estimate" is computed by | 696 taking the absolute values of the ipdv sequence (as defined in this | 697 draft) and applying an exponential filter with parameter 1/16 to | 698 generate the estimate (i.e. j_new = 15/16* j_old + 1/16*j_new). 700 6.6. Type-P-One-way-peak-to-peak-ipdv 702 In this case, the selection function used in collecting the Type-P- 703 One-Way-ipdv sample specifies that the first packet of each pair to 704 be the packet with the maximum Type-P-One-Way-Delay in each sub- 705 interval and the second packet of each pair to be the packet with the 706 minimum Type-P-One-Way-Delay in each sub-interval. The resulting 707 sequence of values is the peak-to-peak delay variation in each sub- 708 interval of the measurement interval. 710 7. Discussion of clock synchronization 712 This section gives some considerations about the need of having 713 synchronized clocks at the source and destination. These 714 considerations are given as a basis for discussion and they require 715 further investigation. 717 7.1. Effects of synchronization errors 719 Clock errors can be generated by two processes: the relative drift 720 and the relative skew of two given clocks. We should note that drift 721 is physically limited and so the total relative skew of two clocks 722 can vary between an upper and a lower bound. 724 Suppose then that we have a measurement between two systems such that 725 the clocks in the source and destination systems have at time 0 a 726 relative skew of s(0) and after a measurement interval T have skew 727 s(T). We assume that the two clocks have an initial offset of O (that 728 is letter O). 730 Now suppose that the packets travel from source to destination in 731 constant time, in which case the ipdv is zero and the difference in 732 the timestamps of the two clocks is actually just the relative offset 733 of the clocks. Suppose further that at the beginning of the 734 measurement interval the ipdv value is calculated from a packet pair 735 and at the end of the measurement interval another ipdv value is 736 calculated from another packet pair. Assume that the time interval 737 covered by the first measurement is t1 and that covered by the second 738 measurement is t2. Then 740 ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T 742 ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T 744 assuming that the change is skew is linear in time. In most practical 745 cases, it is claimed that the drift will be close to zero in which 746 case the second (correction) term in the above equations disappears. 748 Note that in the above discussion, other errors, including the 749 differences between host time and wire time, and externally-caused 750 clock discontinuities (e.g. clock corrections) were ignored. Under 751 these assumptions the maximum clock errors will be due to the maximum 752 relative skew acting on the largest interval between packets. 754 7.2. Estimating the skew of unsynchronized clocks 756 If the skew is linear (that is, if s(t) = S * t for constant S), the 757 error in ipdv values will depend on the time between the packets used 758 in calculating the value. If ti is the time between the packet pair, 759 then let Ti denote the sample mean time between packets and the 760 average skew is s(Ti) = S * Ti. In the event that the delays are 761 constant, the skew parameter S can be estimated from the estimate Ti 762 of the time between packets and the sample mean ipdv value. Under 763 these assumptions, the ipdv values can be corrected by subtracting 764 the estimated S * ti. 766 We observe that the displacement due to the skew does not change the 767 shape of the distribution, and, for example the Standard Deviation 768 remains the same. What introduces a distortion is the effect of the 769 drift, also when the mean value of this effect is zero at the end of 770 the measurement. The value of this distortion is limited to the 771 effect of the total skew variation on the emission interval. 773 8. Security Considerations 775 The one-way-ipdv metric has the same security properties as the one- 776 way-delay metric [2]. The packets contain no user information, and so 777 privacy of user data is not a concern. It is still possible that 778 there could be an attempt at a denial of service attack by sending 779 many measurement packets into the network; there could also be 780 attempts to disrupt measurements by diverting packets or corrupting 781 them. 783 In general, legitimate measurements must have their parameters 784 selected carefully in order to avoid interfering with normal traffic 785 in the network. Such measurements should also be authorized and 786 authenticated in some way so that attacks can be identified and 787 intercepted. 789 9. Acknowledgements 791 This major revision of the draft resulted from e-mail discussions 792 with and suggestions from Mike Pierce, Ruediger Geib, Glenn 793 Grotefeld, and Al Morton. For previous revisions of this document, 794 discussions with Ruediger Geib, Matt Zekauskas and Andy Scherer were 795 very helpful. 797 10. References 798 [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP 799 Performance Metrics", RFC 2330 Feb. 1998 801 [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 802 2679, September 1999 804 [3] ITU-T Recommendation Y.1540 (formerly numbered I.380) 805 "Internet Protocol Data Communication Service - IP Packet 806 Transfer and Availability Performance Parameters", February 1999 808 [4] Demichelis, Carlo - "Packet Delay Variation Comparison between 809 ITU-T and IETF Draft Definitions" November 2000 (in the IPPM 810 mail archives) 812 [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer 813 Performance" 815 [6] S. Keshav - "An Engineering Approach to Computer Networking", 816 Addison-Wesley 1997, ISBN 0-201-63442-2 818 [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding 819 PHB", RFC 2598, June 1999 821 [8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol 822 Communication Service - IP Performance and Availability 823 Objectives and Allocations", April 2000 825 [9] Demichelis, Carlo - "Improvement of the Instantaneous Packet 826 Delay Variation (IPDV) Concept and Applications", World 827 Telecommunications Congress 2000, 7-12 May 2000 829 [10] Bradner, Scott - "Key words for use in RFCs to indicate | 830 requirement levels", RFC 2119, March 1997 | 832 [11] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson - "RTP: A | 833 transport protocol for real-time applications", RFC 1889, | 834 January 1996 | 836 11. Authors' Addresses 838 Carlo Demichelis 839 CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A 840 Via G. Reiss Romoli 274 841 10148 - TORINO 842 Italy 843 Phone +39 11 228 5057 844 Fax. +39 11 228 5069 846 Philip Chimento 847 Ericsson IPI 848 7301 Calhoun Place 849 Rockville, Maryland 850 20855 851 USA 852 Phone +1-240-314-3597 854 Expiration date: May 2002