idnits 2.17.1 draft-ietf-ippm-loss-05.txt: 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-16) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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 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 (November 1998) is 9284 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) ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Almes 3 INTERNET-DRAFT S. Kalidindi 4 Expiration Date: May 1999 M. Zekauskas 5 Advanced Network & Services 6 November 1998 8 A One-way Packet Loss Metric for IPPM 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months, and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts shadow 25 directories on ftp.is.co.za (Africa), nic.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 This memo provides information for the Internet community. This memo 30 does not specify an Internet standard of any kind. Distribution of 31 this memo is unlimited. 33 2. Introduction 35 This memo defines a metric for one-way packet loss across Internet 36 paths. It builds on notions introduced and discussed in the IPPM 37 Framework document, RFC 2330 [1]; the reader is assumed to be 38 familiar with that document. 40 This memo is intended to be parallel in structure to a companion 41 document for One-way Delay (currently "A One-way Delay Metric for 42 IPPM" ) [2]; the reader is assumed to 43 be familiar with that document. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [5]. 48 Although RFC 2119 was written with protocols in mind, the key words 49 are used in this document for similar reasons. They are used to 50 ensure the results of measurements from two different implementations 51 are comparable, and to note instances when an implementation could 52 perturb the network. 54 The structure of the memo is as follows: 56 + A 'singleton' analytic metric, called Type-P-One-way-Loss, is 57 introduced to measure a single observation of packet transmission 58 or loss. 60 + Using this singleton metric, a 'sample', called Type-P-One-way- 61 Loss-Poisson-Stream, is introduced to measure a sequence of 62 singleton transmissions and/or losses measured at times taken from 63 a Poisson process. 65 + Using this sample, several 'statistics' of the sample are defined 66 and discussed. 68 This progression from singleton to sample to statistics, with clear 69 separation among them, is important. 71 Whenever a technical term from the IPPM Framework document is first 72 used in this memo, it will be tagged with a trailing asterisk. For 73 example, "term*" indicates that "term" is defined in the Framework. 75 2.1. Motivation: 77 Understanding one-way packet loss of Type-P* packets from a source 78 host* to a destination host is useful for several reasons: 80 + Some applications do not perform well (or at all) if end-to-end 81 loss between hosts is large relative to some threshold value. 83 + Excessive packet loss may make it difficult to support certain 84 real-time applications (where the precise threshold of "excessive" 85 depends on the application). 87 + The larger the value of packet loss, the more difficult it is for 88 transport-layer protocols to sustain high bandwidths. 90 + The sensitivity of real-time applications and of transport-layer 91 protocols to loss become especially important when very large 92 delay-bandwidth products must be supported. 94 The measurement of one-way loss instead of round-trip loss is 95 motivated by the following factors: 97 + In today's Internet, the path from a source to a destination may 98 be different than the path from the destination back to the source 99 ("asymmetric paths"), such that different sequences of routers are 100 used for the forward and reverse paths. Therefore round-trip 101 measurements actually measure the performance of two distinct 102 paths together. Measuring each path independently highlights the 103 performance difference between the two paths which may traverse 104 different Internet service providers, and even radically different 105 types of networks (for example, research versus commodity 106 networks, or ATM versus packet-over-SONET). 108 + Even when the two paths are symmetric, they may have radically 109 different performance characteristics due to asymmetric queueing. 111 + Performance of an application may depend mostly on the performance 112 in one direction. For example, a file transfer using TCP may 113 depend more on the performance in the direction that data flows, 114 rather than the direction in which acknowledgements travel. 116 + In quality-of-service (QoS) enabled networks, provisioning in one 117 direction may be radically different than provisioning in the 118 reverse direction, and thus the QoS guarantees differ. Measuring 119 the paths independently allows the verification of both 120 guarantees. 122 It is outside the scope of this document to say precisely how loss 123 metrics would be applied to specific problems. 125 2.2. General Issues Regarding Time 127 Whenever a time (i.e., a moment in history) is mentioned here, it is 128 understood to be measured in seconds (and fractions) relative to UTC. 130 As described more fully in the Framework document, there are four 131 distinct, but related notions of clock uncertainty: 133 synchronization* 135 Synchronization measures the extent to which two clocks agree on 136 what time it is. For example, the clock on one host might be 137 5.4 msec ahead of the clock on a second host. 139 accuracy* 140 Accuracy measures the extent to which a given clock agrees with 141 UTC. For example, the clock on a host might be 27.1 msec behind 142 UTC. 144 resolution* 146 Resolution measures the precision of a given clock. For 147 example, the clock on an old Unix host might advance only once 148 every 10 msec, and thus have a resolution of only 10 msec. 150 skew* 152 Skew measures the change of accuracy, or of synchronization, 153 with time. For example, the clock on a given host might gain 154 1.3 msec per hour and thus be 27.1 msec behind UTC at one time 155 and only 25.8 msec an hour later. In this case, we say that the 156 clock of the given host has a skew of 1.3 msec per hour relative 157 to UTC, which threatens accuracy. We might also speak of the 158 skew of one clock relative to another clock, which threatens 159 synchronization. 161 3. A Singleton Definition for One-way Packet Loss 163 3.1. Metric Name: 165 Type-P-One-way-Packet-Loss 167 3.2. Metric Parameters: 169 + Src, the IP address of a host 171 + Dst, the IP address of a host 173 + T, a time 175 3.3. Metric Units: 177 The value of a Type-P-One-way-Packet-Loss is either a zero 178 (signifying successful transmission of the packet) or a one 179 (signifying loss). 181 3.4. Definition: 183 >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 0<< means 184 that Src sent the first bit of a Type-P packet to Dst at wire-time* T 185 and that Dst received that packet. 187 >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means 188 that Src sent the first bit of a type-P packet to Dst at wire-time T 189 and that Dst did not receive that packet. 191 3.5. Discussion: 193 Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way- 194 Delay is a finite positive value, and it is 1 exactly when Type-P- 195 One-way-Delay is undefined. 197 The following issues are likely to come up in practice: 199 + A given methodology will have to include a way to distinguish 200 between a packet loss and a very large (but finite) delay. As 201 noted by Mahdavi and Paxson [3], simple upper bounds (such as the 202 255 seconds theoretical upper bound on the lifetimes of IP 203 packets [4]) could be used, but good engineering, including an 204 understanding of packet lifetimes, will be needed in practice. 205 {Comment: Note that, for many applications of these metrics, there 206 may be no harm in treating a large delay as packet loss. An audio 207 playback packet, for example, that arrives only after the playback 208 point may as well have been lost.} 210 + If the packet arrives, but is corrupted, then it is counted as 211 lost. {Comment: one is tempted to count the packet as received 212 since corruption and packet loss are related but distinct 213 phenomena. If the IP header is corrupted, however, one cannot be 214 sure about the source or destination IP addresses and is thus on 215 shaky grounds about knowing that the corrupted received packet 216 corresponds to a given sent test packet. Similarly, if other 217 parts of the packet needed by the methodology to know that the 218 corrupted received packet corresponds to a given sent test packet, 219 then such a packet would have to be counted as lost. Counting 220 these packets as lost but packet with corruption in other parts of 221 the packet as not lost would be inconsistent.} 223 + If the packet is duplicated along the path (or paths) so that 224 multiple non-corrupt copies arrive at the destination, then the 225 packet is counted as received. 227 + If the packet is fragmented and if, for whatever reason, 228 reassembly does not occur, then the packet will be deemed lost. 230 3.6. Methodologies: 232 As with other Type-P-* metrics, the detailed methodology will depend 233 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 234 precedence). 236 Generally, for a given Type-P, one possible methodology would proceed 237 as follows: 239 + Arrange that Src and Dst have clocks that are synchronized with 240 each other. The degree of synchronization is a parameter of the 241 methodology, and depends on the threshold used to determine loss 242 (see below). 244 + At the Src host, select Src and Dst IP addresses, and form a test 245 packet of Type-P with these addresses. 247 + At the Dst host, arrange to receive the packet. 249 + At the Src host, place a timestamp in the prepared Type-P packet, 250 and send it towards Dst. 252 + If the packet arrives within a reasonable period of time, the one- 253 way packet-loss is taken to be zero. 255 + If the packet fails to arrive within a reasonable period of time, 256 the one-way packet-loss is taken to be one. Note that the 257 threshold of "reasonable" here is a parameter of the methodology. 259 {Comment: The definition of reasonable is intentionally vague, and 260 is intended to indicate a value "Th" so large that any value in 261 the closed interval [Th-delta, Th+delta] is an equivalent 262 threshold for loss. Here, delta encompasses all error in clock 263 synchronization along the measured path. If there is a single 264 value after which the packet must be counted as lost, then we 265 reintroduce the need for a degree of clock synchronization similar 266 to that needed for one-way delay. Therefore, if a measure of 267 packet loss parameterized by a specific non-huge "reasonable" 268 time-out value is needed, one can always measure one-way delay and 269 see what percentage of packets from a given stream exceed a given 270 time-out value.} 272 Issues such as the packet format, the means by which Dst knows when 273 to expect the test packet, and the means by which Src and Dst are 274 synchronized are outside the scope of this document. {Comment: We 275 plan to document elsewhere our own work in describing such more 276 detailed implementation techniques and we encourage others to as 277 well.} 279 3.7. Errors and Uncertainties: 281 The description of any specific measurement method should include an 282 accounting and analysis of various sources of error or uncertainty. 283 The Framework document provides general guidance on this point. 285 For loss, there are three sources of error: 287 + Synchronization between clocks on Src and Dst. 289 + The packet-loss threshold (which is related to the synchronization 290 between clocks). 292 + Resource limits in the network interface or software on the 293 receiving instrument. 295 The first two sources are interrelated and could result in a test 296 packet with finite delay being reported as lost. Type-P-One-way- 297 Packet-Loss is 0 if the test packet does not arrive, or if it does 298 arrive and the difference between Src timestamp and Dst timestamp is 299 greater than the "reasonable period of time", or loss threshold. If 300 the clocks are not sufficiently synchronized, the loss threshold may 301 not be "reasonable" - the packet may take much less time to arrive 302 than its Src timestamp indicates. Similarly, if the loss threshold 303 is set too low, then many packets may be counted as lost. The loss 304 threshold must be high enough, and the clocks synchronized well 305 enough so that a packet that arrives is rarely counted as lost. (See 306 the discussions in the previous two sections.) 308 Since the sensitivity of packet loss measurement to lack of clock 309 synchronization is less than for delay, we refer the reader to the 310 treatment of synchronization errors in the One-way Delay metric [2] 311 for more details. 313 The last source of error, resource limits, cause the packet to be 314 dropped by the measurement instrument, and counted as lost when in 315 fact the network delivered the packet in reasonable time. 317 The measurement instruments should be calibrated such that the loss 318 threshold is reasonable for application of the metrics and the clocks 319 are synchronized enough so the loss threshold remains reasonable. 321 In addition, the instruments should be checked to ensure the that the 322 possibility a packet arrives at the network interface, but is lost 323 due to congestion on the interface or to other resource exhaustion 324 (e.g., buffers) on the instrument is low. 326 3.8. Reporting the metric: 328 The calibration and context in which the metric is measured MUST be 329 carefully considered, and SHOULD always be reported along with metric 330 results. We now present four items to consider: Type-P of the test 331 packets, the loss threshold, instrument calibration, and the path 332 traversed by the test packets. This list is not exhaustive; any 333 additional information that could be useful in interpreting 334 applications of the metrics should also be reported. 336 3.8.1. Type-P 338 As noted in the Framework document [1], the value of the metric may 339 depend on the type of IP packets used to make the measurement, or 340 "Type-P". The value of Type-P-One-way-Delay could change if the 341 protocol (UDP or TCP), port number, size, or arrangement for special 342 treatment (e.g., IP precedence or RSVP) changes. The exact Type-P 343 used to make the measurements MUST be accurately reported. 345 3.8.2. Loss threshold 347 The threshold (or methodology to distinguish) between a large finite 348 delay and loss MUST be reported. 350 3.8.3. Calibration results 352 The degree of synchronization between the Src and Dst clocks MUST be 353 reported. If possible, possibility that a test packet that arrives 354 at the Dst network interface is reported as lost due to resource 355 exhaustion on Dst SHOULD be reported. 357 3.8.4. Path 359 Finally, the path traversed by the packet SHOULD be reported, if 360 possible. In general it is impractical to know the precise path a 361 given packet takes through the network. The precise path may be 362 known for certain Type-P on short or stable paths. If Type-P 363 includes the record route (or loose-source route) option in the IP 364 header, and the path is short enough, and all routers* on the path 365 support record (or loose-source) route, then the path will be 366 precisely recorded. This is impractical because the route must be 367 short enough, many routers do not support (or are not configured for) 368 record route, and use of this feature would often artificially worsen 369 the performance observed by removing the packet from common-case 370 processing. However, partial information is still valuable context. 371 For example, if a host can choose between two links* (and hence two 372 separate routes from Src to Dst), then the initial link used is 373 valuable context. {Comment: For example, with Merit's NetNow setup, 374 a Src on one NAP can reach a Dst on another NAP by either of several 375 different backbone networks.} 377 4. A Definition for Samples of One-way Packet Loss 379 Given the singleton metric Type-P-One-way-Packet-Loss, we now define 380 one particular sample of such singletons. The idea of the sample is 381 to select a particular binding of the parameters Src, Dst, and Type- 382 P, then define a sample of values of parameter T. The means for 383 defining the values of T is to select a beginning time T0, a final 384 time Tf, and an average rate lambda, then define a pseudo-random 385 Poisson process of rate lambda, whose values fall between T0 and Tf. 386 The time interval between successive values of T will then average 387 1/lambda. 389 {Comment: Note that Poisson sampling is only one way of defining a 390 sample. Poisson has the advantage of limiting bias, but other 391 methods of sampling might be appropriate for different situations. 392 We encourage others who find such appropriate cases to use this 393 general framework and submit their sampling method for 394 standardization.} 396 4.1. Metric Name: 398 Type-P-One-way-Packet-Loss-Poisson-Stream 400 4.2. Metric Parameters: 402 + Src, the IP address of a host 404 + Dst, the IP address of a host 406 + T0, a time 407 + Tf, a time 409 + lambda, a rate in reciprocal seconds 411 4.3. Metric Units: 413 A sequence of pairs; the elements of each pair are: 415 + T, a time, and 417 + L, either a zero or a one 419 The values of T in the sequence are monotonic increasing. Note that 420 T would be a valid parameter to Type-P-One-way-Packet-Loss, and that 421 L would be a valid value of Type-P-One-way-Packet-Loss. 423 4.4. Definition: 425 Given T0, Tf, and lambda, we compute a pseudo-random Poisson process 426 beginning at or before T0, with average arrival rate lambda, and 427 ending at or after Tf. Those time values greater than or equal to T0 428 and less than or equal to Tf are then selected. At each of the times 429 in this process, we obtain the value of Type-P-One-way-Packet-Loss at 430 this time. The value of the sample is the sequence made up of the 431 resulting pairs. If there are no such pairs, the 432 sequence is of length zero and the sample is said to be empty. 434 4.5. Discussion: 436 The reader should be familiar with the in-depth discussion of Poisson 437 sampling in the Framework document [1], which includes methods to 438 compute and verify the pseudo-random Poisson process. 440 We specifically do not constrain the value of lambda, except to note 441 the extremes. If the rate is too large, then the measurement traffic 442 will perturb the network, and itself cause congestion. If the rate 443 is too small, then you might not capture interesting network 444 behavior. {Comment: We expect to document our experiences with, and 445 suggestions for, lambda elsewhere, culminating in a "best current 446 practices" document.} 448 Since a pseudo-random number sequence is employed, the sequence of 449 times, and hence the value of the sample, is not fully specified. 450 Pseudo-random number generators of good quality will be needed to 451 achieve the desired qualities. 453 The sample is defined in terms of a Poisson process both to avoid the 454 effects of self-synchronization and also capture a sample that is 455 statistically as unbiased as possible. The Poisson process is used 456 to schedule the delay measurements. The test packets will generally 457 not arrive at Dst according to a Poisson distribution, since they are 458 influenced by the network. 460 {Comment: there is, of course, no claim that real Internet traffic 461 arrives according to a Poisson arrival process. 463 It is important to note that, in contrast to this metric, loss rates 464 observed by transport connections do not reflect unbiased samples. 465 For example, TCP transmissions both (1) occur in bursts, which can 466 induce loss due to the burst volume that would not otherwise have 467 been observed, and (2) adapt their transmission rate in an attempt to 468 minimize the loss rate observed by the connection.} 470 All the singleton Type-P-One-way-Packet-Loss metrics in the sequence 471 will have the same values of Src, Dst, and Type-P. 473 Note also that, given one sample that runs from T0 to Tf, and given 474 new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the 475 subsequence of the given sample whose time values fall between T0' 476 and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream 477 sample. 479 4.6. Methodologies: 481 The methodologies follow directly from: 483 + the selection of specific times, using the specified Poisson 484 arrival process, and 486 + the methodologies discussion already given for the singleton Type- 487 P-One-way-Packet-Loss metric. 489 Care must be given to correctly handle out-of-order arrival of test 490 packets; it is possible that the Src could send one test packet at 491 TS[i], then send a second one (later) at TS[i+1], while the Dst could 492 receive the second test packet at TR[i+1], and then receive the first 493 one (later) at TR[i]. 495 4.7. Errors and Uncertainties: 497 In addition to sources of errors and uncertainties associated with 498 methods employed to measure the singleton values that make up the 499 sample, care must be given to analyze the accuracy of the Poisson 500 arrival process of the wire-times of the sending of the test packets. 501 Problems with this process could be caused by several things, 502 including problems with the pseudo-random number techniques used to 503 generate the Poisson arrival process. The Framework document shows 504 how to use the Anderson-Darling test verify the accuracy of the 505 Poisson process over small time frames. {Comment: The goal is to 506 ensure that the test packets are sent "close enough" to a Poisson 507 schedule, and avoid periodic behavior.} 509 4.8. Reporting the metric: 511 The calibration and context for the underlying singletons MUST be 512 reported along with the stream. (See "Reporting the metric" for 513 Type-P-One-way-Packet-Loss.) 515 5. Some Statistics Definitions for One-way Packet Loss 517 Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we 518 now offer several statistics of that sample. These statistics are 519 offered mostly to be illustrative of what could be done. 521 5.1. Type-P-One-way-Packet-Loss-Average 523 Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all 524 the L values in the Stream. In addition, the Type-P-One-way-Packet- 525 Loss-Average is undefined if the sample is empty. 527 Example: suppose we take a sample and the results are: 528 Stream1 = < 529 530 531 532 533 534 > 535 Then the average would be 0.2. 537 Note that, since healthy Internet paths should be operating at loss 538 rates below 1% (particularly if high delay-bandwidth products are to 539 be sustained), the sample sizes needed might be larger than one would 540 like. Thus, for example, if one wants to discriminate between 541 various fractions of 1% over one-minute periods, then several hundred 542 samples per minute might be needed. This would result in larger 543 values of lambda than one would ordinarily want. 545 Note that although the loss threshold should be set such that any 546 errors in loss are not significant, if the possibility that a packet 547 which arrived is counted as lost due to resource exhaustion is 548 significant compared to the loss rate of interest, Type-P-One-way- 549 Packet-Loss-Average will be meaningless. 551 6. Security Considerations 553 Conducting Internet measurements raises both security and privacy 554 concerns. This memo does not specify an implementation of the 555 metrics, so it does not directly affect the security of the Internet 556 nor of applications which run on the Internet. However, 557 implementations of these metrics must be mindful of security and 558 privacy concerns. 560 There are two types of security concerns: potential harm caused by 561 the measurements, and potential harm to the measurements. The 562 measurements could cause harm because they are active, and inject 563 packets into the network. The measurement parameters MUST be 564 carefully selected so that the measurements inject trivial amounts of 565 additional traffic into the networks they measure. If they inject 566 "too much" traffic, they can skew the results of the measurement, and 567 in extreme cases cause congestion and denial of service. 569 The measurements themselves could be harmed by routers giving 570 measurement traffic a different priority than "normal" traffic, or by 571 an attacker injecting artificial measurement traffic. If routers can 572 recognize measurement traffic and treat it separately, the 573 measurements will not reflect actual user traffic. If an attacker 574 injects artificial traffic that is accepted as legitimate, the loss 575 rate will be artificially lowered. Therefore, the measurement 576 methodologies SHOULD include appropriate techniques to reduce the 577 probability measurement traffic can be distinguished from "normal" 578 traffic. Authentication techniques, such as digital signatures, may 579 be used where appropriate to guard against injected traffic attacks. 581 The privacy concerns of network measurement are limited by the active 582 measurements described in this memo. Unlike passive measurements, 583 there can be no release of existing user data. 585 7. Acknowledgements 587 Thanks are due to Matt Mathis for encouraging this work and for 588 calling attention on so many occasions to the significance of packet 589 loss. 591 Thanks are due also to Vern Paxson for his valuable comments on early 592 drafts. 594 8. References 596 [1] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for 597 IP Performance Metrics", RFC 2330, May 1998. 599 [2] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay 600 Metric for IPPM", Internet-Draft , 601 August 1998. 603 [3] J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring 604 Connectivity", Internet-Draft , August 1998. 607 [4] J. Postel, "Internet Protocol", RFC 791, September 1981. 609 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 610 Levels", RFC 2119, March 1997. 612 9. Authors' Addresses 614 Guy Almes 615 Advanced Network & Services, Inc. 616 200 Business Park Drive 617 Armonk, NY 10504 618 USA 620 Phone: +1 914 765 1120 621 EMail: almes@advanced.org 622 Sunil Kalidindi 623 Advanced Network & Services, Inc. 624 200 Business Park Drive 625 Armonk, NY 10504 626 USA 628 Phone: +1 914 765 1128 629 EMail: kalidindi@advanced.org 631 Matthew J. Zekauskas 632 Advanced Network & Services, Inc. 633 200 Buisiness Park Drive 634 Armonk, NY 10504 635 USA 637 Phone: +1 914 765 1112 638 EMail: matt@advanced.org 640 Expiration date: May, 1999