idnits 2.17.00 (12 Aug 2021) /tmp/idnits62256/draft-duffield-ippm-burst-loss-metrics-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 21, 2010) is 4437 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) -- Looks like a reference, but probably isn't: '0' on line 660 -- Looks like a reference, but probably isn't: '1' on line 660 ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Duffield 3 Internet-Draft AT&T Labs-Research 4 Intended status: Standards Track A. Morton 5 Expires: September 22, 2010 AT&T Labs 6 J. Sommers 7 Colgate University 8 March 21, 2010 10 Loss Episode Metrics for IPPM 11 draft-duffield-ippm-burst-loss-metrics-02 13 Abstract 15 The IPPM Working Group has developed a one way packet loss metric 16 that measures the loss rate on a Poisson probe stream between two 17 hosts. However, the impact of packet loss on applications is in 18 general sensitive not just to the average loss rate, but alsoto the 19 way in which packet losses are distributed in loss episodes (i.e., 20 maximal sets of consecutively lost probe packets). This draft 21 defines one-way packet loss episode metrics, specifically the 22 frequency and average duration of loss episodes, and a probing 23 methodology under which the loss episode metrics are to be measured. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119] 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on September 22, 2010. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. Background and Motivation . . . . . . . . . . . . . . . . 4 85 1.2. Loss Episode Metrics and Bi-Packet Probes . . . . . . . . 5 86 1.3. Outline and Contents . . . . . . . . . . . . . . . . . . . 6 87 2. Singleton Definition for Type-P-One-way Bi-Packet Loss . . . . 7 88 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 89 2.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 90 2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 7 91 2.4. Metric Definition . . . . . . . . . . . . . . . . . . . . 7 92 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 93 2.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 8 94 2.7. Errors and Uncertainties . . . . . . . . . . . . . . . . . 8 95 2.8. Reporting the Metric . . . . . . . . . . . . . . . . . . . 8 96 3. General Definition of samples for 97 Type-P-One-way-Bi-Packet-Loss . . . . . . . . . . . . . . . . 8 98 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 8 99 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 100 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 9 101 3.4. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 102 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 103 3.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 9 104 3.7. Errors and Uncertainties . . . . . . . . . . . . . . . . . 9 105 3.8. Reporting the Metric . . . . . . . . . . . . . . . . . . . 9 106 4. An active probing methodology for Bi-Packet Loss . . . . . . . 10 107 4.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 10 108 4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 10 109 4.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10 110 4.4. Metric Definition . . . . . . . . . . . . . . . . . . . . 10 111 4.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 11 112 4.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 113 4.7. Errors and Uncertainties . . . . . . . . . . . . . . . . . 11 114 4.8. Reporting the Metric . . . . . . . . . . . . . . . . . . . 12 115 5. Loss Epsiode Proto-Metrics . . . . . . . . . . . . . . . . . . 12 116 5.1. Loss-Pair-Counts . . . . . . . . . . . . . . . . . . . . . 12 117 5.2. Bi-Packet-Loss-Ratio . . . . . . . . . . . . . . . . . . . 12 118 5.3. Bi-Packet-Loss-Episode-Duration-Number . . . . . . . . . . 12 119 5.4. Bi-Packet-Loss-Episode-Frequency-Number . . . . . . . . . 13 120 6. Loss Episode Metrics derived from Bi-Packet Loss Probing . . . 13 121 6.1. Geometric Stream: Loss Ratio . . . . . . . . . . . . . . . 14 122 6.1.1. Metric Name . . . . . . . . . . . . . . . . . . . . . 14 123 6.1.2. Metric Parameters . . . . . . . . . . . . . . . . . . 14 124 6.1.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 14 125 6.1.4. Metric Definition . . . . . . . . . . . . . . . . . . 14 126 6.1.5. Discussion . . . . . . . . . . . . . . . . . . . . . . 14 127 6.1.6. Methodologies . . . . . . . . . . . . . . . . . . . . 15 128 6.1.7. Errors and Uncertainties . . . . . . . . . . . . . . . 15 129 6.1.8. Reporting the Metric . . . . . . . . . . . . . . . . . 15 130 6.2. Geometric Steam: Loss Episode Duration . . . . . . . . . . 15 131 6.2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . 15 132 6.2.2. Metric Parameters . . . . . . . . . . . . . . . . . . 15 133 6.2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 16 134 6.2.4. Metric Definition . . . . . . . . . . . . . . . . . . 16 135 6.2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . 16 136 6.2.6. Methodologies . . . . . . . . . . . . . . . . . . . . 16 137 6.2.7. Errors and Uncertainties . . . . . . . . . . . . . . . 16 138 6.2.8. Reporting the Metric . . . . . . . . . . . . . . . . . 16 139 6.3. Geometric Stream: Loss Episode Frequency . . . . . . . . . 16 140 6.3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . 16 141 6.3.2. Metric Parameters . . . . . . . . . . . . . . . . . . 16 142 6.3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 17 143 6.3.4. Metric Definition . . . . . . . . . . . . . . . . . . 17 144 6.3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . 17 145 6.3.6. Methodologies . . . . . . . . . . . . . . . . . . . . 17 146 6.3.7. Errors and Uncertainties . . . . . . . . . . . . . . . 17 147 6.3.8. Reporting the Metric . . . . . . . . . . . . . . . . . 18 148 7. Applicability of Loss Episode Metrics . . . . . . . . . . . . 18 149 7.1. Relation to Gilbert Model . . . . . . . . . . . . . . . . 18 150 8. IPR Considerations . . . . . . . . . . . . . . . . . . . . . . 18 151 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 152 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 153 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 154 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 155 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 156 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 159 1. Introduction 161 1.1. Background and Motivation 163 Packet loss in the Internet is a complex phenomenon due to the bursty 164 nature of traffic and congestion processes, influenced by both end- 165 users and applications, and the operation of transport protocols such 166 as TCP. For these reasons, the simplest model of packet loss--the 167 single parameter Bernoulli (independent) loss model--does not 168 represent the complexity of packet loss over periods of time. 169 Correspondingly, a single loss metric--the average packet loss ratio 170 over some period of time--arising, e.g., from a stream of Poisson 171 probes as in [RFC2680] is not sufficient to determine the effect of 172 packet loss on traffic in general. 174 Moving beyond single parameter loss models, Markovian and Markov- 175 modulated loss models involving transitions between a good and bad 176 state, each with an associated loss rate, have been proposed by 177 Gilbert and more generally by Elliot. In principle, Markovian models 178 can be formulated over state spaces involving patterns of loss of any 179 desired number of packets. However further increase in the size of 180 the state space makes such models cumbersome both for parameter 181 estimation (accuracy decreases) and prediction in practice (due to 182 computational complexity and sensitivity to parameter inaccuracy). 183 In general, the relevance and importance of particular models can 184 change in time, e.g. in response to the advent of new applications 185 and services. For this reason we are drawn to empirical metrics that 186 do not depend on a particular model for their interpretation. 188 An empirical measure of packet loss complexity, the index of 189 dispersion of counts (IDC), comprise, for each t >0, the ratio v(t) \ 190 a(t) of the variance v(t) and average a(t) of the number of losses 191 over successive measurement windows of a duration t. However, a full 192 characterization of packet loss over time requires specification of 193 the IDC for each window size t>0. 195 In the standards arena, loss pattern sample metrics are defined in 196 [RFC3357]. Following the Gilbert-Elliot model, burst metrics 197 specific for VoIP that characterize complete episodes of lost, 198 transmitted and discarded packets are defined in [RFC3611] 200 All these considerations motivate formulating empirical metrics of 201 one-way packet loss that provide the simplest generalization of the 202 successful [RFC2680] that can capture deviations from independent 203 packet loss in a robust model-independent manner, and, to define 204 efficient measurement methodologies for these metrics. 206 1.2. Loss Episode Metrics and Bi-Packet Probes 208 The losses experienced by the packet stream can be viewed as 209 occurring in loss episodes, i.e., maximal set of consecutively lost 210 packets. This memo describes one-way loss episode metrics: their 211 frequency and average duration. Although the average loss ratio can 212 be expressed in terms of these quantities, they go further in 213 characterizing the statistics of the patterns of packet loss within 214 the stream of probes. This is useful information in understanding 215 the effect of packet losses on application performance, since 216 different applications can have different sensitivities to patterns 217 of loss, being sensitive not only to the long term average loss rate, 218 but how losses are distributed in time. As an example: MPEG video 219 traffic may be sensitive to loss involving the I-frame in a group of 220 pictures, but further losses within an episode of sufficiently short 221 duration have no further impact; the damage is already done. 223 The loss episode metrics presented here represent have the following 224 useful properties: 226 1. the metrics are empirical and do not depend on an underlying 227 model; e.g., the loss process is not assumed to be Markovian. On 228 the other hand, it turns out that the metrics of this memo can be 229 related to the special case of the Gilbert Model parameters; see 230 Section 7. 232 2. the metric units can be directly compared with applications or 233 user requirements or tolerance for network loss performance, in 234 the frequency and duration of loss episodes, as well as the usual 235 packet loss ratio, which can be recovered from the loss episode 236 metrics upon dividing the average loss episode duration by the 237 loss episode frequency. 239 3. the metrics provide the smallest possible increment in complexity 240 beyond, but in the spirit of, the IPPM average packet loss ratio 241 metrics [RFC2680] i.e., moving from a single metric (average 242 packet loss ratio) to a pair of metrics (loss episode frequency 243 and average loss episode duration). 245 The draft also describes a probing methodology under which loss 246 episode metrics are to be measured. The methodology comprises 247 sending probe packets in pairs, where packets within each probe pair 248 have a fixed separation, and the time between pairs takes the form of 249 a geometric distributed number multiplied by the same separation. 250 This can be regarded a generalization of Poisson probing where the 251 probes are pairs rather than single packets as in [RFC2680], and also 252 of geometric probing described in [RFC2330]. However, it should be 253 distinguished from back to back packet pairs whose change in 254 separation on traversing a link is used to probe bandwidth. In this 255 draft, the separation between the packets in a pair is the temporal 256 resolution at which different loss episodes are to be distinguished. 257 One key feature of this methodology is its efficiency: it estimates 258 the average length of loss episodes without directly measuring the 259 complete episodes themselves. Instead, this information is encoded 260 in the observed relative frequencies of the 4 possible outcomes 261 arising from the loss or successful transmission of each of the two 262 packets of the probe pairs. This is distinct from the approach of 263 [RFC3611] that reports on directly measured episodes. 265 The metrics defined in this memo are "derived metrics", according to 266 Section 6.1 of [RFC2330] the IPPM framework. They are based on the 267 singleton loss metric defined in Section 2 of [RFC2680] . 269 This is a working draft with several sections still to be completed. 271 1.3. Outline and Contents 273 o Section 2 defines the fundamental singleton metric for the 274 possible outcomes of a probe pair: Type-P-One-way-Bi-Packet-Loss. 276 o Section 3 defines sample sets of this metric derived from a 277 general probe stream: Type-P-One-way-Bi-Packet-Loss-Stream. 279 o Section 4 defines the prime example of the Bi-Packet-Loss-Stream 280 metrics, specifically Type-P-One-way-Bi-Packet-Loss-Geometric- 281 Stream arising from the geometric stream of packet-pair probes 282 that was described informally in Section 1. 284 o Section 5 defines Loss episode proto-metrics that summarize the 285 outcomes from a stream metrics as an intermediate step to forming 286 the loss episode metrics; they need not be reported in general. 288 o Section 6 defines the final loss episode metrics that are the 289 focus of this memo, the new metrics Type-P-One-way-Bi-Packet-Loss- 290 Geometric-Stream-Episode-Duration, Type-P-One-way-Bi-Packet-Loss- 291 Geometric-Stream-Episode-Frequency, as well as Type-P-One-way-Bi- 292 Packet-Loss-Geometric-Stream-Ratio, which is the average packet 293 loss ratio metric arising from the geometric stream probing 294 methodology. 296 o Section 7 details applications and relations to existing loss 297 models. 299 2. Singleton Definition for Type-P-One-way Bi-Packet Loss 301 2.1. Metric Name 303 Type-P-One-way-Bi-Packet-Loss 305 2.2. Metric Parameters 307 o Src, the IP address of a source host 309 o Dst, the IP address of a destination host 311 o T1, a sending time of the first packet 313 o T2, a sending time of the second packet, with T2>T1 315 o F, a selection function defining unambiguously the two packets 316 from the stream selected for the metric. 318 o P, the specification of the packet type, over and above the source 319 and destination addresses 321 2.3. Metric Units 323 A Loss Pair is pair (l1, l2) where each of l1 and l2 is a binary 324 value 0 or 1, where 0 signifies successful transmission of a packet 325 and 1 signifies loss. 327 The metric unit for Type-P-One-way-Bi-Packet-Loss takes is a Loss 328 Pair 330 2.4. Metric Definition 332 1. "The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, 333 T2, F, P) is (1,1)" means that Src sent the first bit of a Type-P 334 packet to Dst at wire-time T1 and the first bit of a Type-P 335 packet to Dst a wire-time T2>T1, and that neither packet was 336 received at Dst. 338 2. The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, 339 T2, F, P) is (1,0)" means that Src sent the first bit of a Type-P 340 packet to Dst at wire-time T1 and the first bit of a Type-P 341 packet to Dst a wire-time T2>T1, and that the first packet was 342 not received at Dst, and the second packet was received at Dst 344 3. The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, 345 T2, F, P) is (0,1)" means that Src sent the first bit of a Type-P 346 packet to Dst at wire-time T1 and the first bit of a Type-P 347 packet to Dst a wire-time T2>T1, and that the first packet was 348 received at Dst, and the second packet was not received at Dst 350 4. The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, 351 T2, F, P) is (0,0)" means that Src sent the first bit of a Type-P 352 packet to Dst at wire-time T1 and the first bit of a Type-P 353 packet to Dst a wire-time T2>T1, and that both packet were 354 received at Dst. 356 2.5. Discussion 358 The purpose of the selection function is to specify exactly which 359 packets are to be used for measurement. The notion is taken from 360 Section 2.5 of [RFC3393], where examples are discussed. 362 2.6. Methodologies 364 The methodologies related to the Type-P-One-way-Packet-Loss metric in 365 Section 2.6 of [RFC2680] are similar for the Type-P-One-way-Bi- 366 Packet-Loss metric described above. In particular, the methodologies 367 described in RFC 2680 apply to both packets of the pair. 369 2.7. Errors and Uncertainties 371 Sources of error for the Type-P-One-way-Packet-Loss metric in Section 372 2.7 of [RFC2680] apply to each packet of the pair for the Type-P-One- 373 way-Bi-Packet-Loss metric. 375 2.8. Reporting the Metric 377 Refer to Section 2.8 of [RFC2680]. 379 3. General Definition of samples for Type-P-One-way-Bi-Packet-Loss 381 Given the singleton metric for Type-P-One-way-Bi-Packet-Loss, we now 382 define examples of samples of singletons. The basic idea is as 383 follows. We first specify a set of times T1 < T2 <...1 582 o 0 if N(0,1) + N(1,0) + N(1,1) = 0 (no probe packets lost) 584 o Undefined if N(0,1) + N(1,0) + N(0,0) = 0 (all probe packets lost) 586 Note N(0,1) + N(1,0) is zero if there are no transitions between loss 587 and no-loss outcomes. 589 5.4. Bi-Packet-Loss-Episode-Frequency-Number 591 The Bi-Packet-Loss-Episode-Frequency-Number associated with a set of 592 n loss pairs L1,,,,Ln is defined in terms of their Loss-Pair-Counts 593 as Bi-Packet-Loss-Ratio / Bi-Packet-Loss-Episode-Duration-Number, 594 when this can be defined, specifically, it is: 596 o (N(1,0)+N(1,1)) * (N(0,1)+N(1,0)) / (2*N(1,1)+N(0,1)+N(1,0) ) / n 597 if N(0,1)+N(0,1) > 0 599 o 0 if N(0,1)+N(1,0) +N(1,1) = 0 (no probe packets lost) 601 o 1 if N(0,1) +N(1,0) +N(0,0) = 0 (all probe packets lost) 603 6. Loss Episode Metrics derived from Bi-Packet Loss Probing 605 Metrics for the time frequency and time duration of loss episodes are 606 now defined as functions of set of n loss pairs L1,....,Ln. Although 607 a loss episode is defined as a maximal set of successive lost 608 packets, the loss episode metrics are not defined directly in terms 609 of the sequential patterns of packet loss exhibited by loss pairs. 610 This is because samples, including Type-P-One-way-Bi-Packet-Loss- 611 Geometric-Stream, generally do not report all lost packets in each 612 episode. Instead, the metrics are defined as functions of the Loss- 613 Pair-Counts of the sample, for reasons that are now described. 615 Consider an idealized Type-P-One-way-Bi-Packet-Loss-Geometric-Stream 616 sample in which the launch probability q =1. It is shown in [SBDR08] 617 that the average number of packets in a loss episode of this ideal 618 sample is exactly the Bi-Packet-Loss-Episode-Duration derived from 619 its set of loss pairs. Note this computation makes no reference to 620 the position of lost packet in the sequence of probes. 622 A general Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample with 623 launch probability q < 1, independently samples, with probability q, 624 each loss pair of an idealized sample. On average, the Loss-Pair- 625 Counts (if normalized by the total number of pairs) will be the same 626 as in the idealized sample. The loss episode metrics in the general 627 case are thus estimators of those for the idealized case; the 628 statistical properties of this estimation, including a derivation of 629 the estimation variance, is provided in [SBDR08]. 631 6.1. Geometric Stream: Loss Ratio 633 6.1.1. Metric Name 635 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Ratio 637 6.1.2. Metric Parameters 639 o Src, the IP address of a source host 641 o Dst, the IP address of a destination host 643 o T0, the randomly selected starting time [RFC3432] for periodic 644 launch opportunities 646 o d, the time spacing between potential launch times, Ti and Ti+1 648 o n, a count of potential measurement instants 650 o q, a launch probability 652 o F, a selection function defining unambiguously the two packets 653 from the stream selected for the metric. 655 o P, the specification of the packet type, over and above the source 656 and destination address 658 6.1.3. Metric Units 660 A number in the interval [0,1] 662 6.1.4. Metric Definition 664 The result obtained by computing the Bi-Packet-Loss-Ratio over a 665 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample with the metric 666 parameters. 668 6.1.5. Discussion 670 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Ratio estimates the 671 fraction of packets lost from the geometric stream of Bi-Packet 672 probes. 674 6.1.6. Methodologies 676 Refer to Section 4.6 678 6.1.7. Errors and Uncertainties 680 Because Type-P-One-way-Bi-Packet-Loss-Geometric-Stream is sampled in 681 general (when the launch probability q <1) the metrics described in 682 this Section can be regarded as statistical estimators of the 683 corresponding idealized version corresponding to q = 1. Estimation 684 variance as it applies to Type-P-One-way-Bi-Packet-Loss-Geometric- 685 Stream-Loss-Ratio is described in [SBDR08]. 687 For other issues refer to Section 4.7 689 6.1.8. Reporting the Metric 691 Refer to Section 4.8 693 6.2. Geometric Steam: Loss Episode Duration 695 6.2.1. Metric Name 697 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration 699 6.2.2. Metric Parameters 701 o Src, the IP address of a source host 703 o Dst, the IP address of a destination host 705 o T0, the randomly selected starting time [RFC3432] for periodic 706 launch opportunities 708 o d, the time spacing between potential launch times, Ti and Ti+1 710 o n, a count of potential measurement instants 712 o q, a launch probability 714 o F, a selection function defining unambiguously the two packets 715 from the stream selected for the metric. 717 o P, the specification of the packet type, over and above the source 718 and destination address 720 6.2.3. Metric Units 722 A non-negative number of seconds. 724 6.2.4. Metric Definition 726 The result obtained by computing the Bi-Packet-Loss-Episode-Duration- 727 Number over a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample 728 with the metric parameters, then multiplying the result by the launch 729 spacing parameter d. 731 6.2.5. Discussion 733 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration 734 estimates the average duration of a loss episode, measured in 735 seconds. The duration measured in packets is obtained by dividing 736 the metric value by the packet launch spacing parameter d. 738 6.2.6. Methodologies 740 Refer to Section 4.6 742 6.2.7. Errors and Uncertainties 744 Because Type-P-One-way-Bi-Packet-Loss-Geometric-Stream is sampled in 745 general (when the launch probability q <1) the metrics described in 746 this Section can be regarded as statistical estimators of the 747 corresponding idealized version corresponding to q = 1. Estimation 748 variance as it applies to Type-P-One-way-Bi-Packet-Loss-Geometric- 749 Stream-Episode-Duration is described in [SBDR08]. 751 For other issues refer to Section 4.7 753 6.2.8. Reporting the Metric 755 Refer to Section 4.8 757 6.3. Geometric Stream: Loss Episode Frequency 759 6.3.1. Metric Name 761 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Frequency 763 6.3.2. Metric Parameters 765 o Src, the IP address of a source host 766 o Dst, the IP address of a destination host 768 o T0, the randomly selected starting time [RFC3432] for periodic 769 launch opportunities 771 o d, the time spacing between potential launch times, Ti and Ti+1 773 o n, a count of potential measurement instants 775 o q, a launch probability 777 o F, a selection function defining unambiguously the two packets 778 from the stream selected for the metric. 780 o P, the specification of the packet type, over and above the source 781 and destination address 783 6.3.3. Metric Units 785 A positive number. 787 6.3.4. Metric Definition 789 The result obtained by computing the Bi-Packet-Loss-Episode-Frequency 790 over a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample with the 791 metric parameters, then dividing he result by the launch spacing 792 parameter d. 794 6.3.5. Discussion 796 Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Frequency 797 estimates the average frequency per unit time with which loss 798 episodes start (or finish). The frequency relative to the count of 799 potential probe launches is obtained by multiplying the metric value 800 by the packet launch spacing parameter d. 802 6.3.6. Methodologies 804 Refer toSection 4.6 806 6.3.7. Errors and Uncertainties 808 Because Type-P-One-way-Bi-Packet-Loss-Geometric-Stream is sampled in 809 general (when the launch probability q <1) the metrics described in 810 this Section can be regarded as statistical estimators of the 811 corresponding idealized version corresponding to q = 1. Estimation 812 variance as it applies to Type-P-One-way-Bi-Packet-Loss-Geometric- 813 Stream-Episode-Frequency is described in [SBDR08]. 815 For other issues refer to Section 4.7 817 6.3.8. Reporting the Metric 819 Refer to Section 4.8 821 7. Applicability of Loss Episode Metrics 823 7.1. Relation to Gilbert Model 825 The general Gilbert-Elliot model is a discrete time Markov chain over 826 two states, Good (g) and Bad (b), each with its own independent 827 packet loss rate. In the simplest case, the Good loss rate is 0 828 while the Bad loss rate is 1. Correspondingly, there are two 829 independent parameters, the Markov transition probabilities P(g|b) = 830 1- P(b|b) and P(b|g) = 1- P(g|g), where P(i|j) is the probability to 831 transition from state j and step n to state i at step n+1. With 832 these parameters, the fraction of steps spent in the bad state is 833 P(b|g)/(P(b|g) + P(g|b)) while the average duration of a sojourn in 834 the bad state is 1/P(g|b). 836 Now identify the steps of the Markov chain with the possible sending 837 times of packets for a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream 838 with launch spacing d. Suppose the loss episode metrics Type-P-One- 839 way-Bi-Packet-Loss-Geometric-Stream-Ratio and ype-P-One-way-Bi- 840 Packet-Loss-Geometric-Stream-Episode-Duration take the values r and m 841 respectively. Then from the discussion in Section 6.2.5 the 842 following can be equated: 844 r = P(b|g)/(P(b|g) + P(g|b)) and m/d = 1/P(g|b). 846 These relationships can be inverted in order to recover the Gilbert 847 model parameters: 849 P(g|b).= d/m and P(b|g)=d/m/(1/r - 1) 851 8. IPR Considerations 853 IPR disclosures concerning some of the material covered in this draft 854 has been made to the IETF: see https://datatracker.ietf.org/ipr/1009/ 855 , https://datatracker.ietf.org/ipr/1010/ , and 856 https://datatracker.ietf.org/ipr/1126/ 858 9. Security Considerations 860 Conducting Internet measurements raises both security and privacy 861 concerns. This memo does not specify an implementation of the 862 metrics, so it does not directly affect the security of the Internet 863 nor of applications which run on the Internet. 864 However,implementations of these metrics must be mindful of security 865 and privacy concerns. 867 There are two types of security concerns: potential harm caused by 868 the measurements, and potential harm to the measurements. The 869 measurements could cause harm because they are active, and inject 870 packets into the network. The measurement parameters MUST be 871 carefully selected so that the measurements inject trivial amounts of 872 additional traffic into the networks they measure. If they inject 873 "too much" traffic, they can skew the results of the measurement, and 874 in extreme cases cause congestion and denial of service. The 875 measurements themselves could be harmed by routers giving measurement 876 traffic a different priority than "normal" traffic, or by an attacker 877 injecting artificial measurement traffic. If routers can recognize 878 measurement traffic and treat it separately, the measurements may not 879 reflect actual user traffic. If an attacker injects artificial 880 traffic that is accepted as legitimate, the loss rate will be 881 artificially lowered. Therefore, the measurement methodologies 882 SHOULD include appropriate techniques to reduce the probability that 883 measurement traffic can be distinguished from "normal" traffic. 884 Authentication techniques, such as digital signatures, may be used 885 where appropriate to guard against injected traffic attacks. The 886 privacy concerns of network measurement are limited by the active 887 measurements described in this memo: they involve no release of user 888 data. 890 10. IANA Considerations 892 11. Acknowledgements 894 12. References 896 12.1. Normative References 898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, March 1997. 901 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 902 Packet Loss Metric for IPPM", RFC 2680, September 1999. 904 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 905 Metric for IP Performance Metrics (IPPM)", RFC 3393, 906 November 2002. 908 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 909 performance measurement with periodic streams", RFC 3432, 910 November 2002. 912 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 913 Protocol Extended Reports (RTCP XR)", RFC 3611, 914 November 2003. 916 12.2. Informative References 918 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 919 "Framework for IP Performance Metrics", RFC 2330, 920 May 1998. 922 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 923 Metrics", RFC 3357, August 2002. 925 [SBDR08] IEEE/ACM Transactions on Networking, 16(2): 307-320, "A 926 Geometric Approach to Improving Active Packet Loss 927 Measurement", 2008. 929 Authors' Addresses 931 Nick Duffield 932 AT&T Labs-Research 933 180 Park Avenue 934 Florham Park, NJ 07932 935 USA 937 Phone: +1 973 360 8726 938 Fax: 939 Email: duffield@research.att.com 940 URI: http://www.research.att.com/info/duffield 941 Al Morton 942 AT&T Labs 943 200 Laurel Avenue South 944 Middletown,, NJ 07748 945 USA 947 Phone: +1 732 420 1571 948 Fax: +1 732 368 1192 949 Email: acmorton@att.com 950 URI: http://home.comcast.net/~acmacm/ 952 Joel Sommers 953 Colgate University 954 304 McGregory Hall 955 Hamilton, NY 13346 956 USA 958 Phone: +1 315 228 7587 959 Fax: 960 Email: jsommers@colgate.edu 961 URI: http://cs.colgate.edu/faculty/jsommers