idnits 2.17.1 draft-ietf-ippm-loss-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 (May 1999) is 9103 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) == Unused Reference: '7' is defined on line 634, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2498 (ref. '3') (Obsoleted by RFC 2678) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Almes 2 INTERNET-DRAFT S. Kalidindi 3 Expiration Date: November 1999 M. Zekauskas 4 Advanced Network & Services 5 May 1999 7 A One-way Packet Loss Metric for IPPM 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft shadow directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This memo provides information for the Internet community. This memo 32 does not specify an Internet standard of any kind. Distribution of 33 this memo is unlimited. 35 2. Introduction 37 This memo defines a metric for one-way packet loss across Internet 38 paths. It builds on notions introduced and discussed in the IPPM 39 Framework document, RFC 2330 [1]; the reader is assumed to be 40 familiar with that document. 42 This memo is intended to be parallel in structure to a companion 43 document for One-way Delay (currently "A One-way Delay Metric for 44 IPPM" ) [2]; the reader is assumed to 45 be familiar with that document. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [5]. 50 Although RFC 2119 was written with protocols in mind, the key words 51 are used in this document for similar reasons. They are used to 52 ensure the results of measurements from two different implementations 53 are comparable, and to note instances when an implementation could 54 perturb the network. 56 The structure of the memo is as follows: 58 + A 'singleton' analytic metric, called Type-P-One-way-Loss, is 59 introduced to measure a single observation of packet transmission 60 or loss. 62 + Using this singleton metric, a 'sample', called Type-P-One-way- 63 Loss-Poisson-Stream, is introduced to measure a sequence of 64 singleton transmissions and/or losses measured at times taken from 65 a Poisson process. 67 + Using this sample, several 'statistics' of the sample are defined 68 and discussed. 70 This progression from singleton to sample to statistics, with clear 71 separation among them, is important. 73 Whenever a technical term from the IPPM Framework document is first 74 used in this memo, it will be tagged with a trailing asterisk. For 75 example, "term*" indicates that "term" is defined in the Framework. 77 2.1. Motivation: 79 Understanding one-way packet loss of Type-P* packets from a source 80 host* to a destination host is useful for several reasons: 82 + Some applications do not perform well (or at all) if end-to-end 83 loss between hosts is large relative to some threshold value. 85 + Excessive packet loss may make it difficult to support certain 86 real-time applications (where the precise threshold of "excessive" 87 depends on the application). 89 + The larger the value of packet loss, the more difficult it is for 90 transport-layer protocols to sustain high bandwidths. 92 + The sensitivity of real-time applications and of transport-layer 93 protocols to loss become especially important when very large 94 delay-bandwidth products must be supported. 96 The measurement of one-way loss instead of round-trip loss is 97 motivated by the following factors: 99 + In today's Internet, the path from a source to a destination may 100 be different than the path from the destination back to the source 101 ("asymmetric paths"), such that different sequences of routers are 102 used for the forward and reverse paths. Therefore round-trip 103 measurements actually measure the performance of two distinct 104 paths together. Measuring each path independently highlights the 105 performance difference between the two paths which may traverse 106 different Internet service providers, and even radically different 107 types of networks (for example, research versus commodity 108 networks, or ATM versus packet-over-SONET). 110 + Even when the two paths are symmetric, they may have radically 111 different performance characteristics due to asymmetric queueing. 113 + Performance of an application may depend mostly on the performance 114 in one direction. For example, a file transfer using TCP may 115 depend more on the performance in the direction that data flows, 116 rather than the direction in which acknowledgements travel. 118 + In quality-of-service (QoS) enabled networks, provisioning in one 119 direction may be radically different than provisioning in the 120 reverse direction, and thus the QoS guarantees differ. Measuring 121 the paths independently allows the verification of both 122 guarantees. 124 It is outside the scope of this document to say precisely how loss 125 metrics would be applied to specific problems. 127 2.2. General Issues Regarding Time 129 {Comment: the terminology below differs from that defined by ITU-T 130 documents (e.g., G.810, "Definitions and terminology for 131 synchronization networks" and I.356, "B-ISDN ATM layer cell transfer 132 performance"), but is consistent with the IPPM Framework document. 133 In general, these differences derive from the different backgrounds; 134 the ITU-T documents historically have a telephony origin, while the 135 authors of this document (and the Framework) have a computer systems 136 background. Although the terms defined below have no direct 137 equivalent in the ITU-T definitions, after our definitions we will 138 provide a rough mapping. However, note one potential confusion: our 139 definition of "clock" is the computer operating systems definition 140 denoting a time-of-day clock, while the ITU-T definition of clock 141 denotes a frequency reference.} 143 Whenever a time (i.e., a moment in history) is mentioned here, it is 144 understood to be measured in seconds (and fractions) relative to UTC. 146 As described more fully in the Framework document, there are four 147 distinct, but related notions of clock uncertainty: 149 synchronization* 151 Synchronization measures the extent to which two clocks agree on 152 what time it is. For example, the clock on one host might be 153 5.4 msec ahead of the clock on a second host. {Comment: A rough 154 ITU-T equivalent is "time error".} 156 accuracy* 158 Accuracy measures the extent to which a given clock agrees with 159 UTC. For example, the clock on a host might be 27.1 msec behind 160 UTC. {Comment: A rough ITU-T equivalent is "time error from 161 UTC".} 163 resolution* 165 Resolution measures the precision of a given clock. For 166 example, the clock on an old Unix host might advance only once 167 every 10 msec, and thus have a resolution of only 10 msec. 168 {Comment: A very rough ITU-T equivalent is "sampling period".} 170 skew* 172 Skew measures the change of accuracy, or of synchronization, 173 with time. For example, the clock on a given host might gain 174 1.3 msec per hour and thus be 27.1 msec behind UTC at one time 175 and only 25.8 msec an hour later. In this case, we say that the 176 clock of the given host has a skew of 1.3 msec per hour relative 177 to UTC, which threatens accuracy. We might also speak of the 178 skew of one clock relative to another clock, which threatens 179 synchronization. {Comment: A rough ITU-T equivalent is "time 180 drift".} 182 3. A Singleton Definition for One-way Packet Loss 184 3.1. Metric Name: 186 Type-P-One-way-Packet-Loss 188 3.2. Metric Parameters: 190 + Src, the IP address of a host 192 + Dst, the IP address of a host 194 + T, a time 196 3.3. Metric Units: 198 The value of a Type-P-One-way-Packet-Loss is either a zero 199 (signifying successful transmission of the packet) or a one 200 (signifying loss). 202 3.4. Definition: 204 >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 0<< means 205 that Src sent the first bit of a Type-P packet to Dst at wire-time* T 206 and that Dst received that packet. 208 >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means 209 that Src sent the first bit of a type-P packet to Dst at wire-time T 210 and that Dst did not receive that packet. 212 3.5. Discussion: 214 Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way- 215 Delay is a finite value, and it is 1 exactly when Type-P-One-way- 216 Delay is undefined. 218 The following issues are likely to come up in practice: 220 + A given methodology will have to include a way to distinguish 221 between a packet loss and a very large (but finite) delay. As 222 noted by Mahdavi and Paxson [3], simple upper bounds (such as the 223 255 seconds theoretical upper bound on the lifetimes of IP 224 packets [4]) could be used, but good engineering, including an 225 understanding of packet lifetimes, will be needed in practice. 226 {Comment: Note that, for many applications of these metrics, there 227 may be no harm in treating a large delay as packet loss. An audio 228 playback packet, for example, that arrives only after the playback 229 point may as well have been lost.} 231 + If the packet arrives, but is corrupted, then it is counted as 232 lost. {Comment: one is tempted to count the packet as received 233 since corruption and packet loss are related but distinct 234 phenomena. If the IP header is corrupted, however, one cannot be 235 sure about the source or destination IP addresses and is thus on 236 shaky grounds about knowing that the corrupted received packet 237 corresponds to a given sent test packet. Similarly, if other 238 parts of the packet needed by the methodology to know that the 239 corrupted received packet corresponds to a given sent test packet, 240 then such a packet would have to be counted as lost. Counting 241 these packets as lost but packet with corruption in other parts of 242 the packet as not lost would be inconsistent.} 244 + If the packet is duplicated along the path (or paths) so that 245 multiple non-corrupt copies arrive at the destination, then the 246 packet is counted as received. 248 + If the packet is fragmented and if, for whatever reason, 249 reassembly does not occur, then the packet will be deemed lost. 251 3.6. Methodologies: 253 As with other Type-P-* metrics, the detailed methodology will depend 254 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 255 precedence). 257 Generally, for a given Type-P, one possible methodology would proceed 258 as follows: 260 + Arrange that Src and Dst have clocks that are synchronized with 261 each other. The degree of synchronization is a parameter of the 262 methodology, and depends on the threshold used to determine loss 263 (see below). 265 + At the Src host, select Src and Dst IP addresses, and form a test 266 packet of Type-P with these addresses. 268 + At the Dst host, arrange to receive the packet. 270 + At the Src host, place a timestamp in the prepared Type-P packet, 271 and send it towards Dst. 273 + If the packet arrives within a reasonable period of time, the one- 274 way packet-loss is taken to be zero. 276 + If the packet fails to arrive within a reasonable period of time, 277 the one-way packet-loss is taken to be one. Note that the 278 threshold of "reasonable" here is a parameter of the methodology. 280 {Comment: The definition of reasonable is intentionally vague, and 281 is intended to indicate a value "Th" so large that any value in 282 the closed interval [Th-delta, Th+delta] is an equivalent 283 threshold for loss. Here, delta encompasses all error in clock 284 synchronization along the measured path. If there is a single 285 value after which the packet must be counted as lost, then we 286 reintroduce the need for a degree of clock synchronization similar 287 to that needed for one-way delay. Therefore, if a measure of 288 packet loss parameterized by a specific non-huge "reasonable" 289 time-out value is needed, one can always measure one-way delay and 290 see what percentage of packets from a given stream exceed a given 291 time-out value.} 293 Issues such as the packet format, the means by which Dst knows when 294 to expect the test packet, and the means by which Src and Dst are 295 synchronized are outside the scope of this document. {Comment: We 296 plan to document elsewhere our own work in describing such more 297 detailed implementation techniques and we encourage others to as 298 well.} 300 3.7. Errors and Uncertainties: 302 The description of any specific measurement method should include an 303 accounting and analysis of various sources of error or uncertainty. 304 The Framework document provides general guidance on this point. 306 For loss, there are three sources of error: 308 + Synchronization between clocks on Src and Dst. 310 + The packet-loss threshold (which is related to the synchronization 311 between clocks). 313 + Resource limits in the network interface or software on the 314 receiving instrument. 316 The first two sources are interrelated and could result in a test 317 packet with finite delay being reported as lost. Type-P-One-way- 318 Packet-Loss is 0 if the test packet does not arrive, or if it does 319 arrive and the difference between Src timestamp and Dst timestamp is 320 greater than the "reasonable period of time", or loss threshold. If 321 the clocks are not sufficiently synchronized, the loss threshold may 322 not be "reasonable" - the packet may take much less time to arrive 323 than its Src timestamp indicates. Similarly, if the loss threshold 324 is set too low, then many packets may be counted as lost. The loss 325 threshold must be high enough, and the clocks synchronized well 326 enough so that a packet that arrives is rarely counted as lost. (See 327 the discussions in the previous two sections.) 329 Since the sensitivity of packet loss measurement to lack of clock 330 synchronization is less than for delay, we refer the reader to the 331 treatment of synchronization errors in the One-way Delay metric [2] 332 for more details. 334 The last source of error, resource limits, cause the packet to be 335 dropped by the measurement instrument, and counted as lost when in 336 fact the network delivered the packet in reasonable time. 338 The measurement instruments should be calibrated such that the loss 339 threshold is reasonable for application of the metrics and the clocks 340 are synchronized enough so the loss threshold remains reasonable. 342 In addition, the instruments should be checked to ensure the that the 343 possibility a packet arrives at the network interface, but is lost 344 due to congestion on the interface or to other resource exhaustion 345 (e.g., buffers) on the instrument is low. 347 3.8. Reporting the metric: 349 The calibration and context in which the metric is measured MUST be 350 carefully considered, and SHOULD always be reported along with metric 351 results. We now present four items to consider: Type-P of the test 352 packets, the loss threshold, instrument calibration, and the path 353 traversed by the test packets. This list is not exhaustive; any 354 additional information that could be useful in interpreting 355 applications of the metrics should also be reported. 357 3.8.1. Type-P 359 As noted in the Framework document [1], the value of the metric may 360 depend on the type of IP packets used to make the measurement, or 361 "Type-P". The value of Type-P-One-way-Delay could change if the 362 protocol (UDP or TCP), port number, size, or arrangement for special 363 treatment (e.g., IP precedence or RSVP) changes. The exact Type-P 364 used to make the measurements MUST be accurately reported. 366 3.8.2. Loss threshold 368 The threshold (or methodology to distinguish) between a large finite 369 delay and loss MUST be reported. 371 3.8.3. Calibration results 373 The degree of synchronization between the Src and Dst clocks MUST be 374 reported. If possible, possibility that a test packet that arrives 375 at the Dst network interface is reported as lost due to resource 376 exhaustion on Dst SHOULD be reported. 378 3.8.4. Path 380 Finally, the path traversed by the packet SHOULD be reported, if 381 possible. In general it is impractical to know the precise path a 382 given packet takes through the network. The precise path may be 383 known for certain Type-P on short or stable paths. If Type-P 384 includes the record route (or loose-source route) option in the IP 385 header, and the path is short enough, and all routers* on the path 386 support record (or loose-source) route, then the path will be 387 precisely recorded. This is impractical because the route must be 388 short enough, many routers do not support (or are not configured for) 389 record route, and use of this feature would often artificially worsen 390 the performance observed by removing the packet from common-case 391 processing. However, partial information is still valuable context. 392 For example, if a host can choose between two links* (and hence two 393 separate routes from Src to Dst), then the initial link used is 394 valuable context. {Comment: For example, with Merit's NetNow setup, 395 a Src on one NAP can reach a Dst on another NAP by either of several 396 different backbone networks.} 398 4. A Definition for Samples of One-way Packet Loss 400 Given the singleton metric Type-P-One-way-Packet-Loss, we now define 401 one particular sample of such singletons. The idea of the sample is 402 to select a particular binding of the parameters Src, Dst, and Type- 403 P, then define a sample of values of parameter T. The means for 404 defining the values of T is to select a beginning time T0, a final 405 time Tf, and an average rate lambda, then define a pseudo-random 406 Poisson process of rate lambda, whose values fall between T0 and Tf. 407 The time interval between successive values of T will then average 408 1/lambda. 410 {Comment: Note that Poisson sampling is only one way of defining a 411 sample. Poisson has the advantage of limiting bias, but other 412 methods of sampling might be appropriate for different situations. 413 We encourage others who find such appropriate cases to use this 414 general framework and submit their sampling method for 415 standardization.} 417 4.1. Metric Name: 419 Type-P-One-way-Packet-Loss-Poisson-Stream 421 4.2. Metric Parameters: 423 + Src, the IP address of a host 425 + Dst, the IP address of a host 427 + T0, a time 429 + Tf, a time 431 + lambda, a rate in reciprocal seconds 433 4.3. Metric Units: 435 A sequence of pairs; the elements of each pair are: 437 + T, a time, and 439 + L, either a zero or a one 441 The values of T in the sequence are monotonic increasing. Note that 442 T would be a valid parameter to Type-P-One-way-Packet-Loss, and that 443 L would be a valid value of Type-P-One-way-Packet-Loss. 445 4.4. Definition: 447 Given T0, Tf, and lambda, we compute a pseudo-random Poisson process 448 beginning at or before T0, with average arrival rate lambda, and 449 ending at or after Tf. Those time values greater than or equal to T0 450 and less than or equal to Tf are then selected. At each of the times 451 in this process, we obtain the value of Type-P-One-way-Packet-Loss at 452 this time. The value of the sample is the sequence made up of the 453 resulting pairs. If there are no such pairs, the 454 sequence is of length zero and the sample is said to be empty. 456 4.5. Discussion: 458 The reader should be familiar with the in-depth discussion of Poisson 459 sampling in the Framework document [1], which includes methods to 460 compute and verify the pseudo-random Poisson process. 462 We specifically do not constrain the value of lambda, except to note 463 the extremes. If the rate is too large, then the measurement traffic 464 will perturb the network, and itself cause congestion. If the rate 465 is too small, then you might not capture interesting network 466 behavior. {Comment: We expect to document our experiences with, and 467 suggestions for, lambda elsewhere, culminating in a "best current 468 practices" document.} 470 Since a pseudo-random number sequence is employed, the sequence of 471 times, and hence the value of the sample, is not fully specified. 472 Pseudo-random number generators of good quality will be needed to 473 achieve the desired qualities. 475 The sample is defined in terms of a Poisson process both to avoid the 476 effects of self-synchronization and also capture a sample that is 477 statistically as unbiased as possible. The Poisson process is used 478 to schedule the delay measurements. The test packets will generally 479 not arrive at Dst according to a Poisson distribution, since they are 480 influenced by the network. 482 {Comment: there is, of course, no claim that real Internet traffic 483 arrives according to a Poisson arrival process. 485 It is important to note that, in contrast to this metric, loss rates 486 observed by transport connections do not reflect unbiased samples. 487 For example, TCP transmissions both (1) occur in bursts, which can 488 induce loss due to the burst volume that would not otherwise have 489 been observed, and (2) adapt their transmission rate in an attempt to 490 minimize the loss rate observed by the connection.} 492 All the singleton Type-P-One-way-Packet-Loss metrics in the sequence 493 will have the same values of Src, Dst, and Type-P. 495 Note also that, given one sample that runs from T0 to Tf, and given 496 new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the 497 subsequence of the given sample whose time values fall between T0' 498 and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream 499 sample. 501 4.6. Methodologies: 503 The methodologies follow directly from: 505 + the selection of specific times, using the specified Poisson 506 arrival process, and 508 + the methodologies discussion already given for the singleton Type- 509 P-One-way-Packet-Loss metric. 511 Care must be given to correctly handle out-of-order arrival of test 512 packets; it is possible that the Src could send one test packet at 513 TS[i], then send a second one (later) at TS[i+1], while the Dst could 514 receive the second test packet at TR[i+1], and then receive the first 515 one (later) at TR[i]. 517 4.7. Errors and Uncertainties: 519 In addition to sources of errors and uncertainties associated with 520 methods employed to measure the singleton values that make up the 521 sample, care must be given to analyze the accuracy of the Poisson 522 arrival process of the wire-times of the sending of the test packets. 523 Problems with this process could be caused by several things, 524 including problems with the pseudo-random number techniques used to 525 generate the Poisson arrival process. The Framework document shows 526 how to use the Anderson-Darling test verify the accuracy of the 527 Poisson process over small time frames. {Comment: The goal is to 528 ensure that the test packets are sent "close enough" to a Poisson 529 schedule, and avoid periodic behavior.} 531 4.8. Reporting the metric: 533 The calibration and context for the underlying singletons MUST be 534 reported along with the stream. (See "Reporting the metric" for 535 Type-P-One-way-Packet-Loss.) 537 5. Some Statistics Definitions for One-way Packet Loss 539 Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we 540 now offer several statistics of that sample. These statistics are 541 offered mostly to be illustrative of what could be done. 543 5.1. Type-P-One-way-Packet-Loss-Average 545 Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all 546 the L values in the Stream. In addition, the Type-P-One-way-Packet- 547 Loss-Average is undefined if the sample is empty. 549 Example: suppose we take a sample and the results are: 550 Stream1 = < 551 552 553 554 555 556 > 557 Then the average would be 0.2. 559 Note that, since healthy Internet paths should be operating at loss 560 rates below 1% (particularly if high delay-bandwidth products are to 561 be sustained), the sample sizes needed might be larger than one would 562 like. Thus, for example, if one wants to discriminate between 563 various fractions of 1% over one-minute periods, then several hundred 564 samples per minute might be needed. This would result in larger 565 values of lambda than one would ordinarily want. 567 Note that although the loss threshold should be set such that any 568 errors in loss are not significant, if the possibility that a packet 569 which arrived is counted as lost due to resource exhaustion is 570 significant compared to the loss rate of interest, Type-P-One-way- 571 Packet-Loss-Average will be meaningless. 573 6. Security Considerations 575 Conducting Internet measurements raises both security and privacy 576 concerns. This memo does not specify an implementation of the 577 metrics, so it does not directly affect the security of the Internet 578 nor of applications which run on the Internet. However, 579 implementations of these metrics must be mindful of security and 580 privacy concerns. 582 There are two types of security concerns: potential harm caused by 583 the measurements, and potential harm to the measurements. The 584 measurements could cause harm because they are active, and inject 585 packets into the network. The measurement parameters MUST be 586 carefully selected so that the measurements inject trivial amounts of 587 additional traffic into the networks they measure. If they inject 588 "too much" traffic, they can skew the results of the measurement, and 589 in extreme cases cause congestion and denial of service. 591 The measurements themselves could be harmed by routers giving 592 measurement traffic a different priority than "normal" traffic, or by 593 an attacker injecting artificial measurement traffic. If routers can 594 recognize measurement traffic and treat it separately, the 595 measurements will not reflect actual user traffic. If an attacker 596 injects artificial traffic that is accepted as legitimate, the loss 597 rate will be artificially lowered. Therefore, the measurement 598 methodologies SHOULD include appropriate techniques to reduce the 599 probability measurement traffic can be distinguished from "normal" 600 traffic. Authentication techniques, such as digital signatures, may 601 be used where appropriate to guard against injected traffic attacks. 603 The privacy concerns of network measurement are limited by the active 604 measurements described in this memo. Unlike passive measurements, 605 there can be no release of existing user data. 607 7. Acknowledgements 609 Thanks are due to Matt Mathis for encouraging this work and for 610 calling attention on so many occasions to the significance of packet 611 loss. 613 Thanks are due also to Vern Paxson for his valuable comments on early 614 drafts, and to Garry Couch and Will Leland for several useful 615 suggestions. 617 8. References 619 [1] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for 620 IP Performance Metrics", RFC 2330, May 1998. 622 [2] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 623 Metric for IPPM", Internet-Draft , 624 May, 1999. 626 [3] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring 627 Connectivity", RFC 2498, January 1999. 629 [4] J. Postel, "Internet Protocol", RFC 791, September 1981. 631 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 632 Levels", RFC 2119, March 1997. 634 [7] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 635 2026, October 1996. 637 9. Authors' Addresses 639 Guy Almes 640 Advanced Network & Services, Inc. 641 200 Business Park Drive 642 Armonk, NY 10504 643 USA 645 Phone: +1 914 765 1120 646 EMail: almes@advanced.org 648 Sunil Kalidindi 649 Advanced Network & Services, Inc. 650 200 Business Park Drive 651 Armonk, NY 10504 652 USA 654 Phone: +1 914 765 1128 655 EMail: kalidindi@advanced.org 656 Matthew J. Zekauskas 657 Advanced Network & Services, Inc. 658 200 Buisiness Park Drive 659 Armonk, NY 10504 660 USA 662 Phone: +1 914 765 1112 663 EMail: matt@advanced.org 665 Expiration date: November, 1999