idnits 2.17.1 draft-ietf-ippm-ipdv-01.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (16 January 1999) is 9226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C.Demichelis CSELT 3 Internet Draft July 1998 4 expires 16 January 1999 6 Instantaneous Packet Delay Variation Metric for IPPM 7 9 1. Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow 23 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 2. Abstract 33 This memo refers to a metric for variation in delay of packets across 34 Internet paths. The metric is based on statistics of the difference 35 in One-way Delay of consecutive packets. This particular definition 36 of variation is called "Instantaneous Packet Delay Variation (ipdv)". 38 The metric is valid for measurements between two hosts both in the 39 case that they have synchronized clocks and in the case that they are 40 not synchronized. In the second case it allows an evaluation of the 41 relative skew. Measurements performed on both directions (Two-ways 42 measurements) allow a better estimation of clock differences. The 43 precision that can be obtained is evaluated. 45 This memo is intended to have, as much as possible, the structure of 46 the ippm draft on one-way delay metric. 48 I-D Ipdv Metric July 1998 50 3. Introduction 52 This memo refers to the Draft-ietf "One-way-delay metric for IPPM" that 53 supposes as known. Part of the text in this memo is directly taken from 54 that Draft. 56 This memo defines a metric for variation in delay of packets that flow 57 from one host to another one through an IP path. Since the metric is 58 related to a variation, different definitions are possible according 59 to what the variation is measured against. 61 3.1. Definition 63 The Instantaneous Packet Delay Variation of an IP packet, inside a 64 stream of packets, going from the measurement point MP1 to the measu- 65 rement point MP2, is the difference of the One-Way Delay of that packet 66 and the One-Way Delay of preceding packet in the stream. 68 3.2. Motivation 70 A number of services that can be supported by IP are sensitive to the 71 regular delivery of packets and can be disturbed by instantaneous va- 72 riations in delay, while they are not disturbed by slow variations, 73 that can last a relatively long time. A specific metric for quick va- 74 riations is therefore desirable. Metrics that can be derived from the 75 analysis of statistics of ipdv can also be used for buffer 76 dimensioning, but this memo is not intended in that sense. The scope 77 is to provide a way for measurement of the quality delivered by a 78 path. 80 In addition, this type of metric is particularly robust with respect 81 differences and variations of the clocks of the two hosts. This allow 82 the use of the metric even if the two hosts that support the measure- 83 ment points are not synchronized. The related precision is comparable 84 with the one that can be achieved with synchronized clocks. This will 85 be discussed below. 87 3.3. General Issues Regarding Time 89 All what is contained in the paragraph 2.2. of the Draft ippm on one- 90 way delay metric (2.2. General Issues Regarding Time) applies also in 91 this case. 93 In addition, it is here considered that the relative skew of the two 94 clocks can be decomposed into two parts: 95 * A fixed one, called in this context "skew", given, for example, by 96 tolerances in physical dimension of crystals. 98 I-D Ipdv Metric July 1998 100 * A variable one, called in this context "drift", given, for example, 101 by changes in temperature or other conditions of operation. 102 Both of this components are part of the term "skew" as defined in the 103 referenced Draft and in the Framework document. 105 4. Structure of this memo 107 The metric will be defined as applicable to a stream of packets that 108 flow from a source host to a destination host (one-way ipdv). The ini 109 -tial assumption is that source and destination hosts have synchronized 110 clocks. 111 The definition of a singleton of one-way ipdv metric is first consi- 112 dered, and then a definition of samples for ipdv will be given. 114 Then the case of application to not synchronized hosts will be dis- 115 cussed, and the precision will be compared with the one of the previous 116 case. 118 A bidirectional ipdv metric will be defined, and the methodology for 119 error corrections. This will not be a two-ways metric, but a "paired" 120 one-way in opposite directions. Some statistics describing the IP 121 path's behavior will be proposed. 123 5. A singleton definition of a One-way ipdv metric 125 This definition makes use of the corresponding definition of type-P- 126 One-way-delay, that is supposed to be known. This section makes use 127 of those parts of the One-way-delay Draft that directly apply to the 128 One-way-ipdv metric, or makes direct references to that Draft. 130 5.1. Metric name 132 Type-P-One-way-ipdv 134 5.2. Metric parameters 136 + Scr, the IP address of a host 137 + Dst, the IP address of a host 138 + T1, a time 139 + T2, a time. It is explicitly noted that also the difference T2-T1 140 is a parameter of the measurement though this is already implicit, 141 since the times T1 and T2 exactly define the time conditions in which 142 the measurement takes place. 143 + Path, the path from Src to Dst; in cases where there is only one 145 I-D Ipdv Metric July 1998 147 path from Src to Dst, this optional parameter can be omitted. 148 {Comment: the presence of path is motivated by cases such as with 149 Merit's NetNow setup, in which a Src on one NAP can reach a Dst on 150 another NAP by either of several different backbone networks. Gener- 151 ally, this optional parameter is useful only when several different 152 routes are possible from Src to Dst. Using the loose source route IP 153 option is avoided since it would often artificially worsen the per- 154 formance observed, and since it might not be supported along some 155 paths.} 157 5.2. Metric unit 159 The value of a Type-P-One-way-ipdv is either a real number of seconds 160 (positive, zero or negative) or an undefined number of seconds. 162 5.3. Definition 164 Type-P-One-way-ipdv is defined for two (consecutive) packets from Src 165 to Dst, as the difference between the value of the type-P-One-way- 166 delay from Src to Dst at T2 [via path] and the value of the type-P- 167 One-way-delay from Src to Dst at T1 [via path]. T1 is the wire-time 168 at which Scr sent the first bit of the first packet, and T2 is the 169 wire-time at which Src sent the first bit of the second packet. This 170 metric is therefore ideally derived from the One-Way-Delay metric. 172 NOTE: The requirement of "consecutive" packets is not essential. The 173 measured value is anyway the difference in one-way-delay at the times 174 T1 and T2, which is meaningful by itself, as long as the times T1 and 175 T2 are such to describe the investigated characteristics. These times 176 will be better defined later. 178 Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to 179 Dst at T1, T2 [via path] is ddT" means that Src sent two consecutive 180 packets whose the first at wire-time T1 (first bit), and the second 181 wire-time T2 (first bit) and the packets were received by Dst at wire 182 -time dT1+T1 (last bit of the first packet), and, respectively, at 183 wire-time dT2+T2 (last bit of the second packet), and that dT2-dT1=ddT. 185 "The type-P-one-way-ipdv from Src to Dst at T1,T2 [via path] is unde- 186 fined" means that Src sent the first bit of a packet at T1 and the 187 first bit of a second packet at T2 and that Dst did not receive one 188 or both packets. 190 5.4. Discussion 192 Type-P-One-way-ipdv is a metric that makes use of the same measurement 193 methods provided for delay metrics. 195 I-D Ipdv Metric July 1998 197 The following practical issues have to be considered: 198 + Being a differential measurement, this metric is less sensitive 199 to clock synchronization problems. This issue will be more care- 200 fully examined in section 6. of this memo. It is pointed out 201 that, if the reciprocal clock conditions change in time, the ac- 202 curacy of the measurement will depend on the time interval T2-T1 203 and the amount of possible errors will be discussed below. 204 + A given methodology will have to include a way to deter- 205 mine whether a delay value is infinite or whether it is mere- 206 ly very large (and the packet is yet to arrive at Dst). 207 As noted by Mahdavi and Paxson, simple upper bounds (such as the 208 255 seconds theoretical upper bound on the lifetimes of IP 209 packets [Postel: RFC 791]) could be used, but good engineering, 210 including an understanding of packet lifetimes, will be nee- 211 ded in practice. {Comment: Note that, for many applications of 212 these metrics, the harm in treating a large delay as infinite 213 might be zero or very small. A TCP data packet, for example, 214 that arrives only after several multiples of the RTT may as well 215 have been lost.} 216 + Usually a path is such that if the first packet is largely delayed, 217 it can "stop" the second packet of the pair and vary its delay. 218 This is not a problem for the definition since is, in any case, 219 part of the description of the path's behavior. 220 + As with other 'type-P' metrics, the value of the metric may de- 221 pend on such properties of the packet as protocol,(UDP or TCP) 222 port number, size, and arrangement for special treatment (as 223 with IP precedence or with RSVP). 224 + If the packet is duplicated along the path (or paths!) so that 225 multiple non-corrupt copies arrive at the destination, then the 226 packet is counted as received, and the first copy to arrive 227 determines the packet's one-way delay. 228 + If the packet is fragmented and if, for whatever reason, reas- 229 sembly does not occur, then the packet will be deemed lost. 231 5.5. Methodologies 233 As with other Type-P-* metrics, the detailed methodology will depend 234 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 235 precedence). 237 Generally, for a given Type-P, the methodology would proceed as fol- 238 lows: 240 + The need of synchronized clocks for Src and Dst will be discus- 241 sed later. Here a methodology is supposed that is based on 242 synchronized clocks. 244 I-D Ipdv Metric July 1998 246 + At the Src host, select Src and Dst IP addresses, and form two 247 test packets of Type-P with these addresses. Any 'padding' por- 248 tion of the packet needed only to make the test packet a given 249 size should be filled with randomized bits to avoid a situation 250 in which the measured delay is lower than it would otherwise 251 be due to compression techniques along the path. 252 + Optionally, select a specific path and arrange for Src to send 253 the packets to that path. {Comment: This could be done, for 254 example, by installing a temporary host-route for Dst in Src's 255 routing table.} 256 + At the Dst host, arrange to receive the packets. 257 + At the Src host, place a timestamp in the prepared first 258 Type-P packet, and send it towards Dst [via path]. 259 + If the packet arrives within a reasonable period of time, take a 260 timestamp as soon as possible upon the receipt of the packet. By 261 subtracting the two timestamps, an estimate of one-way delay can 262 be computed. 263 + Record this first delay value. 264 + At the Src host, place a timestamp in the prepared second 265 Type-P packet, and send it towards Dst [via path]. 266 + If the packet arrives within a reasonable period of time, take a 267 timestamp as soon as possible upon the receipt of the packet. By 268 subtracting the two timestamps, an estimate of one-way delay can 269 be computed. 270 + By subtracting the second value of one-way-delay from the first value 271 the ipdv value of the pair of packets is obtained. 272 + If one or both packets fail to arrive within a reasonable period 273 of time, the ipdv is taken to be undefined. 275 5.6. Errors and Uncertainties 277 In the singleton metric of ipdv, factors that affect the measurement 278 are the same that can affect the one-way delay measurement, even if, 279 in this case, the influence is different. 281 The Framework document provides general guidance on this point, but 282 we note here the following specifics related to delay metrics: 283 + Errors/uncertainties due to uncertainties in the clocks of the 284 Src and Dst hosts. 285 + Errors/uncertainties due to the difference between 'wire time' 286 and 'host time'. 287 Each of these are discussed in more detail below. 289 5.6.1. Errors/Uncertainties related to Clocks 291 If, as a first approximation, the error that affects the first measu- 292 rement of one-way delay were the same of the one affecting the second 294 I-D Ipdv Metric July 1998 296 measurement, they will cancel each other when calculating ipdv. The 297 residual error related to clocks is the difference of the said errors 298 that are supposed to change from the time T1, at which the first 299 measurement is performed, to the time T2 at which the second measure- 300 ment is performed. Synchronization, skew, accuracy and resolution are 301 here considered with the following notes: 302 + Errors in synchronization between source and destination clocks 303 contribute to errors in both of the delay measurements required 304 for calculating ipdv. 305 + If the synchronization error is Tsync, and it is a linear func- 306 tion of time, through the skew value, at time T1 the error will 307 be Tsync1 and at time T2 the error will be Tsync2. The ipdv mea- 308 surement will be affected by the error Tsync2-Tsync1, depending 309 from skew and T2-T1. To minimize this error it is possible to 310 reduce the time interval T2-T1, but this could limit the genera- 311 lity of the metric. Methods for evaluating the synchronization 312 error will be discussed below, since they come from a statistic 313 over a significant sample. 314 + As far as accuracy and resolution are concerned, what is noted 315 in the above referenced Draft on one-way delay at section 3.7.1, 316 applies also in this case, with the further consideration, about 317 resolution, that in this case the uncertainty introduced is two 318 times the one of a single delay measurement. 320 5.6.2. Errors/uncertainties related to Wire-time vs Host-time 322 The content of sec. 3.7.2 of the above referenced Draft applies also 323 in this case, with the following further consideration: 324 The difference between Host-time and Wire-time can be in general de- 325 composed into two components, whose one is constant and the other is 326 variable around zero. Only the variable components will produce measu- 327 rement errors, while the constant one will be canceled while calcu- 328 lating ipdv. 330 6. Definitions for Samples of One-way ipdv 332 Starting from the definition of the singleton metric of one-way ipdv, 333 some ways of building a sample of such singletons are here described 334 that have to be further analyzed in order to find the best way of con- 335 sidering all the related problems. In the following, the two packets 336 needed for a singleton measurement will be called a "pair". 338 I-D Ipdv Metric July 1998 340 6.1. A "discontinuous" definition 342 A general definition can be the following: 343 Given particular binding of the parameters Src, Dst, path, and 344 Type-P, a sample of values of parameters T1 and T2 is defined. 345 The means for defining the values of T1 is to select a beginning 346 time T0, a final time Tf, and an average rate lambda, then 347 define a pseudo-random Poisson arrival process of rate lambda, 348 whose values fall between T0 and Tf. The time interval between 349 successive values of T1 will then average 1/lambda. Another si- 350 milar, but independent, pseudo-random Poisson arrival process 351 based on T0', Tf' and lambda', will produce a series of t' 352 values. The time interval between successive t' values will then 353 average 1/lambda'. For each T1 value that has been obtained 354 by the first process, it is then possible to calculate the 355 successive T2 values as the successive T1 values plus the 356 successive intervals of t'. 358 The result is shown in figure 1. 360 |<- average interval 1/lambda ->| 361 | | 362 |<- av.int. | |<- av.int. | 363 |1/lambda'->| | 1/lambda'->| 364 _____|___________|___________________|_____________|________ 365 pair i pair i+1 366 Figure 1 368 This general definition is likely go give problems, if no limits are 369 considered for the obtained values. For example, the emission 370 time of the first packet of a pair, could fall before the emission 371 time of the second packet of the preceding pair. Probably this could 372 be acceptable (provided that there are means to recognize pairs -e.g. 373 use of sequence numbers-), but the concept itself of ipdv would be,at 374 least, slightly changed. A way for avoiding this type of philosophical 375 problems can be to give some rules on the values T0, Tf, lambda, 376 T0', Tf', lambda', without changing the meaning of the metric. 378 6.2. A "continuous" definition 380 A way to naturally avoid the previous problem is to adopt the following 381 definition. 382 A continuous stream of test packets can be supposed, where the second 383 packet of a pair is, at the same time, the first packet of the next 384 pair. Therefore the preceding definition becomes: 386 + Given particular binding of the parameters Src, Dst, path, and 387 Type-P, a sample of values of parameter T1 is defined. 388 The means for defining the values of T1 is to select a beginning 389 time T0, a final time Tf, and an average rate lambda, then 390 define a pseudo-random Poisson arrival process of rate lambda, 391 whose values fall between T0 and Tf. The time interval between 392 successive values of T1 will then average 1/lambda. From the 393 second value on, T1 value of the pair n coincides with T2 of the 394 pair n-1, and the first packet of pair n coincides with the se- 395 cond packet of the pair n-1. 396 For the moment, in the following, this second definition will be con- 397 sidered. Further refinement is required and is for further discussion. 399 6.3. Metric name 401 Type-P-One-way-ipdv-stream 403 6.4. Parameters 404 + Src, the IP address of a host 405 + Dst, the IP address of a host 406 + Path, the path* from Src to Dst; in cases where there is only 407 one path from Src to Dst, this optional parameter can be omitted 408 + T0, a time 409 + Tf, a time 410 + lambda, a rate in reciprocal seconds 412 6.5. Metric Units: 414 A sequence of triads whose elements are: 415 + T, a time 416 + Ti, a time interval. 417 + dT a real number or an undefined number of seconds 419 6.6. Definition 421 A pseudo-random Poisson process is defined such that it begins at or 422 before T0, with average arrival rate lambda, and ends at or after Tf. 423 Those time values Ti greater than or equal to T0 and less than or 424 equal to Tf are then selected. Starting from time T, at each pair of 425 times T(i), T(i+1)of this process a value of Type-P-One-way-ipdv is 426 obtained. The value of the sample is the sequence made up of the 427 resulting triad, where the time interval 428 is given by T(i+1)-T(i). Each obtained time T(i), excluding the first 429 and the last, is therefore at the same time the the second time of 430 pair i and the first time of pair i+1. The result is shown in figure 2 432 |T(i-2) |T(i-1) |T(i) |T(i+1) 433 _____|__________|___________________|__________|________ 434 pair i-1 pair i pair i+1 435 Figure 2 437 I-D Ipdv Metric July 1998 439 6.7. Discussion 441 Note first that, since a pseudo-random number sequence is employed, 442 the sequence of times, and hence the value of the sample, is not 443 fully specified. Pseudo-random number generators of good quality 444 will be needed to achieve the desired qualities. 446 The sample is defined in terms of a Poisson process both to avoid the 447 effects of self-synchronization and also capture a sample that is 448 statistically as unbiased as possible. {Comment: there is, of 449 course, no claim that real Internet traffic arrives according to a 450 Poisson arrival process.} 452 6.8. Methodology 454 Since packets can be lost or duplicated or can arrive in a different 455 order with respect the one of emission, in order to recognize the 456 pairs of test packets, they should be marked with a Sequence Number 457 or make use of any other tool suitable to the scope. For duplicated 458 packets only the first received copy should be considered. If a pac- 459 ket is lost, two values of ipdv will be undefined, since each packet, 460 in the supposed "continuous" definition, is common to two pairs. 462 Steps for measurement can be the following: 463 + Starting from a given time T, Src generates a test packet as for 464 a singleton metrics, inserts in the packet a Sequence Number 465 and the transmission Time Stamp Tx,then sorts the time Ti at 466 which the next packet has to be sent. 467 + At time Ti, Src repeats the previous step, unless T(i) > Tf. 468 + On reception of the first packet, or the first packet after a SN 469 error, Dst records SN and Tx timestamp that are contained in 470 the packet and the reception time Rx as "old values". 471 + On reception of the other packets Dst verifies the SN and if it is 472 correct, by using the "old values" and the newly received ones, 473 a value of ipdv is computed. Then Dst records the new SN, Tx 474 and Rx timestamps as "old values". 476 6.9. Errors and uncertainties 478 The same considerations apply that have been made about the single- 479 ton metric. An additional error can be introduced by the pseudo-ran- 480 dom Poisson process as focused in the above referenced Draft. 481 Further considerations will be made in section 7. 483 I-D Ipdv Metric July 1998 485 6.10 Some statistics for One-way-ipdv 487 Some statistics are here considered, that can provide useful informa- 488 tion in analyzing the behavior of the packets flowing from Src to Dst 489 These statistics are given having in mind a practical use of them. The 490 focus is on the instantaneous behavior of the connection, while buffer 491 dimensioning is not in the scope of this document. 492 Other statistics can be defined if needed. 494 6.10.1. Type-P-One-way-ipdv-inverse-percentile 496 Given a Type-P-One-way-ipdv-Stream and a time threshold, that can be 497 either positive or negative, the fraction of all the ipdv values in 498 the Stream less than or equal to the threshold, if the threshold is 499 positive, or greater or equal to the threshold if the threshold is ne- 500 gative. 502 For many real-time services that require a regular delivery of the 503 packets, this statistics can give the amount of packets received 504 beyond acceptable limits. 506 6.10.2 Type-P-One-way-ipdv-standard-deviation 508 Given a Type-P-One-way-ipdv-Stream, the distribution of ipdv values 509 is considered and the Standard Deviation can be calculated as an 510 indication of regularity of delivery. For practical purposes it can 511 useful to define a total standard deviation, computed over the com- 512 plete set of value, and a standard deviation computed over the sub- 513 set of those values that do not exceed given positive and negative 514 thresholds. This allows a more accurate description of the performan- 515 ce experienced by packets. 517 6.10.3 Type-P-One-way-ipdv-average 519 This statistic should tend to a value of ZERO for a number of ipdv 520 values that tend to infinite. The behavior of Type-P-One-way-ipdv- 521 average, and its meaning, are issues for the next section 7. 523 7. Discussion on clock synchronization 525 This section gives some considerations about the need of having syn- 526 chronized clocks at Src and Dst. These considerations are given as a 527 basis for discussion, they require further investigation. We start 528 from the analysis of the mean value of the ipdv distribution related 529 to a "continuous" sample. 531 I-D Ipdv Metric July 1998 533 7.1. Mean value of ipdv distribution. 535 If D(i) is the delay of packet "i", and ipdv(i) is the i-th value of 536 ipdv in the distribution of a sample of "n" values, collected with 537 the described methodology, we can write: 539 ipdv(1) = D1 - D0 540 .......... 541 ipdv(i) = D(i) - D(i-1) 542 .......... 543 ipdv(n) = D(n) - D(n-1) 545 The mean value of ipdv distribution will result in 547 E(ipdv) = (D(n) - D(0))/n 549 If an actual measurement is performed, that lasts a period of time 550 long enough to contain a number "n" sufficiently large and, supposing 551 synchronized clocks, such that the network conditions (traffic) allow 552 to find a D(n) not too different from D(0), e.g. a time of 553 n x 24 hours, E(ipdv) will tend to zero, since the difference 554 D(n) - D(0) will remain finite. 556 7.2. Effects of a varying traffic 558 If the mean values of delay D are changing inside a given period of 559 time, for example they are increasing due to an increment of traffic, 560 we can consider, as a first approximation, the ipdv values as decom- 561 posed into two components, one being instantaneous and another one 562 as having a constant rate dD and corresponding to the increment "per 563 interval" of the mean value of D. The mean value of the distribution 564 will be shifted of the value dD corresponding to the mean value of 565 the interval between test packets. When the conditions will come back 566 to the initial ones, the distribution will resume a mean value around 567 zero. At any time the distribution will correctly describe the 568 effects of the path on the packet flow. 570 7.3. Effects of synchronization errors 572 We refer here to the two components that can generate this type of 573 errors that are the relative "skew" and "drift" of the Src and Dst 574 clocks. It is first of all noted that the variable component "drift" 575 is physically limited and its effects can be interpreted by saying 576 that the total skew of the two clocks can vary, ranging from a min 577 to a max value in the time. This type of variation takes place very 578 slowly being mostly connected to variations in temperature. 580 I-D Ipdv Metric July 1998 582 We suppose to perform a measurement between a Src and a Dst that have 583 a reciprocal, initial skew of "ts1" and a reciprocal drift such that, 584 after the time T the total skew is "ts2". It is not here a limitation 585 to consider that at the beginning of time T the two clocks indicate 586 the same time T0. In order to analyze the effects produced by this 587 situation we suppose that packets are transferred, from Src to Dst, 588 with a constant delay D. In this conditions the measured ipdv should 589 always be zero, and what is actually measured is the error. 591 An ipdv value is measured at the beginning of time T with two packets 592 having an interval of Ti(1).Another ipdv value is measured at the end 593 of T with two packets having a time interval Ti(2). 595 On our purposes other errors (like wire-time vs host-time) are not 596 considered since they are not relevant in this analysis. 598 It is then possible to calculate the values of the Tx and Rx time- 599 stamps as they are seen by the two clocks, and the related values of 600 the two ipdv values. 602 The first ipdv value will be: ipdv1 = ts1*Ti(1) + ((ts2-ts1)/T)*Ti(1) 603 The second ipdv value will be: ipdv2 = ts2*Ti(2) +((ts2-ts1)/T)*Ti(2) 605 The error is given by the amount of variation during the time inter- 606 val Ti(i) between the two packets of the pair, and a second order 607 term due to the variation of that variation in the same interval. 609 If, as in practical cases, the drift can be considered zero, then 610 ts1 = ts2, and the error is not depending on the time at which the 611 measurement is done. 613 7.4. Related precision 615 This means that: 616 1) + If the skew is constant and is = ts all the ipdv(i) values are 617 increased by the quantity Ti(i)*ts with respect the actual value. 618 2) + Considering the total skew as subdivided into a fixed part and a 619 variable part (skew and drift),respectively, ts and + or - td, and 620 a minimum time T in which the drift can go from -td to +td or vice 621 -versa, each ipdv(i) value will be increased of the fixed quantity 622 Ti(i)*ts plus or minus, as a maximum, the quantity 2*td*Ti(i)/T 624 3) + If the duration of the measurement is such that it is possible 625 to consider that the effect of the items at points 7.1 and 7.2, 626 and the effect of the drift are negligible (related average ten- 627 ding to zero), the mean value of the ipdv distribution will have 628 the value of the skew multiplied by the mean value of the emission 629 interval. 630 4) + We observe that the displacement due to the skew does not change 631 the shape of the distribution, and, for example the Standard Devi- 632 ation remains the same. What introduces a distortion is the effect 633 of the drift, even if the mean value of this effect is zero at the 634 end of the measurement. The value of this distortion is limited to 635 the effect of the total skew variation on the emission interval. 637 8. Definition for a bidirectional ipdv metric 639 We now consider that the action of the skew on one direction is the 640 same, with opposite sign, of the action on the other direction. The 641 idea of performing at the same time two independent measurements in 642 the two directions is suggested by this fact. 644 If, after a long measurement, the variable conditions of the system 645 under test have reached the situation of a contribution close to zero 646 to the mean value of the ipdv distribution, it is expected that only 647 the fixed action of the skew has modified the measured mean value. It 648 is therefore expected that on one direction that value is equal and 649 opposite to the one measured in the other direction. 651 This fact offers the possibility of defining a theoretical reference 652 measurement duration in the following way: 654 The reference duration of a bidirectional ipdv measurement between 655 an host E and an host W is reached at time Tf such that for each time 656 T > Tf the expression ABS(E(ipdv E-W) - E(ipdv W-E))< epsilon, where 657 epsilon is what we can consider as zero, is always verified. 659 A bidirectional measurement can be defined not only as twin one-way 660 independent metrics that take place (nearly) at the same time, but 661 also as a two-ways metric making use of packets looped back at one 662 end. This metric, that can be object of further study/Draft, would be 663 able to measure also the Round Trip Delay and its variations. 665 I-D Ipdv Metric July 1998 667 9. References 669 V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP Performance 670 Metrics", Internet Draft Feb. 1998 672 G.Almes, S.Kalidindi - "A One-way Delay Metric for IPPM", Internet 673 Draft Nov. 1997 675 10. Author's Address 677 Carlo Demichelis 678 CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A 679 Via G. Reiss Romoli 274 680 10148 - TORINO 681 Italy 682 Phone +39 11 228 5057 683 Fax. +39 11 228 5069 685