idnits 2.17.1 draft-ietf-ippm-2330-update-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (October 15, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Mat98' is mentioned on line 462, but not defined == Unused Reference: 'RFC2026' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC5657' is defined on line 607, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Fabini 3 Internet-Draft Vienna University of Technology 4 Intended status: Informational A. Morton 5 Expires: April 18, 2014 AT&T Labs 6 October 15, 2013 8 Advanced Stream and Sampling Framework for IPPM 9 draft-ietf-ippm-2330-update-01 11 Abstract 13 To obtain repeatable results in modern networks, test descriptions 14 need an expanded stream parameter framework that also augments 15 aspects specified as Type-P for test packets. This memo proposes to 16 update the IP Performance Metrics (IPPM) Framework with advanced 17 considerations for measurement methodology and testing. The existing 18 framework mostly assumes deterministic connectivity, and that a 19 single test stream will represent the characteristics of the path 20 when it is aggregated with other flows. Networks have evolved and 21 test stream descriptions must evolve with them, otherwise unexpected 22 network features may dominate the measured performance. This memo 23 describes new stream parameters for both network characterization and 24 support of application design using IPPM metrics. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 18, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Definition: Reactive Path Behavior . . . . . . . . . . . . 3 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. New or Revised Stream Parameters . . . . . . . . . . . . . . . 4 70 3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . . 6 71 3.1.1. Multiple Test Packet Lengths . . . . . . . . . . . . . 6 72 3.1.2. Test Packet Payload Content Optimization . . . . . . . 6 73 3.2. Packet History . . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Access Technology Change . . . . . . . . . . . . . . . . . 7 75 3.4. Time-Slotted Randomness Cancellation . . . . . . . . . . . 7 76 4. Quality of Metrics and Methodologies . . . . . . . . . . . . . 9 77 4.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 9 78 4.2. Continuity . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.3. Actionable . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.4. Conservative . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.5. Spatial and Temporal Composition . . . . . . . . . . . . . 12 82 4.6. Poisson Sampling . . . . . . . . . . . . . . . . . . . . . 12 83 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 The IETF IP Performance Metrics (IPPM) working group first created a 95 framework for metric development in [RFC2330]. This framework has 96 stood the test of time and enabled development of many fundamental 97 metrics, while only being updated once in a specific area [RFC5835]. 99 The IPPM framework [RFC2330] generally relies on several assumptions, 100 one of which is not explicitly stated but assumed: lightly loaded 101 paths conform to the linear "delay = packet size / capacity" 102 equation, being state/history-less (with some exceptions, firewalls 103 are mentioned). However, this does not hold true for many modern 104 network technologies, such as reactive paths (those with demand- 105 driven resource allocation) and links with time-slotted operation. 106 Per-flow state can be observed on test packet streams, and such 107 treatment will influence network characterization if it is not taken 108 into account. Flow history will also affect the performance of 109 applications and be perceived by their users. 111 Moreover, Sections 4 and 6.2 of [RFC2330] explicitly recommend 112 repeatable measurement metrics and methodologies. Measurements in 113 today's access networks illustrate that methodological guidelines of 114 [RFC2330] must be extended to capture the reactive nature of these 115 networks. Although the proposed extensions can support methodologies 116 to fulfill the continuity requirement stated in section 6.2 of 117 [RFC2330], there is no guarantee. Practical measurements confirm 118 that some link types exhibit distinct responses to repeated 119 measurements with identical stimulus, i.e., identical traffic 120 patterns. If feasible, appropriate fine-tuning of measurement 121 traffic patterns can improve measurement continuity and repeatability 122 for these link types as shown in [IBD]. 124 We stress that this update of [RFC2330] does not invalidate or 125 require changes to the analytic metric definitions prepared in the 126 IPPM working group to date. Rather, it adds considerations for 127 active measurement methodologies and expands the importance of 128 existing conventions and notions in [RFC2330], such as "packets of 129 Type-P". 131 Among the evolutionary networking changes is a phenomenon we call 132 "reactive behavior", defined below. 134 1.1. Definition: Reactive Path Behavior 136 Reactive path behavior will be observable by the test packet stream 137 as a repeatable phenomenon where packet transfer performance 138 characteristics *change* according to prior observations of the 139 packet flow of interest (at the reactive host or link). Therefore, 140 reactive path behavior is nominally deterministic with respect to the 141 flow of interest. Other flows or traffic load conditions may result 142 in additional performance-affecting reactions, but these are external 143 to the characteristics of the flow of interest. 145 In practice, a sender may not have absolute control of the ingress 146 packet stream characteristics at a reactive host or link, but this 147 does not change the deterministic reactions present there. If we 148 measure a path and the arrival characteristics at the reactive host/ 149 link depend on both the sending characteristics and the transfer 150 characteristics of intervening hosts and links, then the reaction 151 will appear less deterministic owing to the noise in the pattern at 152 the reactive host/link. 154 Other than the size of the payload at the layer of interest and the 155 header itself, packet content does not influence the measurement. 156 Reactive behavior at the IP layer is not influenced by the TCP ports 157 in use, for example. Therefore, the indication of reactive behavior 158 must include the layer at which measurements are instituted. 160 Examples include links with Active/In-active state detectors, and 161 hosts or links that revise their traffic serving and forwarding rates 162 (up or down) based on packet arrival history. 164 Although difficult to handle from a measurement point of view, 165 reactive paths entities are usually designed to improve overall 166 network performance and user experience, for example by making 167 capacity available to an active user. Reactive behavior may be an 168 artifact of solutions to allocate scarce resources according to the 169 demands of users, thus it is an important problem to solve for 170 measurement and other disciplines, such as application design. 172 2. Scope 174 The scope of this memo is to describe useful stream parameters in 175 addition to the information in Section 11.1 of [RFC2330] and 176 described in [RFC3432] for periodic streams. The purpose is to 177 foster repeatable measurement results in modern networks by 178 highlighting the key aspects of test streams and packets and make 179 them part of the IPPM performance metric framework. 181 3. New or Revised Stream Parameters 183 There are several areas where measurement methodology definition and 184 test result interpretation will benefit from an increased 185 understanding of the stream characteristics and the (possibly 186 unknown) network condition that influence the measured metrics. 188 1. Network treatment depends on the fullest extent on the "packet of 189 Type-P" definition in [RFC2330], and has for some time. 191 * State is often maintained on the per-flow basis at various 192 points in the path, where "flows" are determined by IP and 193 other layers. Significant treatment differences occur with 194 the simplest of Type-P parameters: packet length. Use of 195 multiple lengths is RECOMMENDED. 197 * Payload content optimization (compression or format 198 conversion) in intermediate segments. This breaks the 199 convention of payload correspondence when correlating 200 measurements made at different points in a path. 202 2. Packet history (instantaneous or recent test rate or inactivity, 203 also for non-test traffic) profoundly influences measured 204 performance, in addition to all the Type-P parameters described 205 in [RFC2330]. 207 3. Access technology may change during testing. A range of transfer 208 capacities and access methods may be encountered during a test 209 session. When different interfaces are used, the host seeking 210 access will be aware of the technology change which 211 differentiates this form of path change from other changes in 212 network state. Section 14 of [RFC2330] treats the possibility 213 that a host may have more than one attachment to the network, and 214 also that assessment of the measurement path (route) is valid for 215 some length of time (in Section 5 and Section 7 of [RFC2330]). 216 Here we combine these two considerations under the assumption 217 that changes may be more frequent and possibly have greater 218 consequences on performance metrics. 220 4. Paths including links or nodes with time-slotted service 221 opportunities represent several challenges to measurement (when 222 service time period is appreciable): 224 * Random/unbiased sampling is not possible beyond one such link 225 in the path. 227 * The above encourages a segmented approach to end to end 228 measurement, as described in [RFC6049] for Network 229 Characterization (as defined in [RFC6703]) to understand the 230 full range of delay and delay variation on the path. 231 Alternatively, if application performance estimation is the 232 goal (also defined in [RFC6703]), then a stream with un-biased 233 or known-bias properties [RFC3432] may be sufficient. 235 * Multi-modal delay variation makes central statistics 236 unimportant, others must be used instead. 238 Each of these topics is treated in detail below. 240 3.1. Test Packet Type-P 242 We recommend two Type-P parameters to be added to the factors which 243 have impact on path performance measurements, namely packet length 244 and payload type. Carefully choosing these parameters can improve 245 measurement methodologies in their continuity and repeatability when 246 deployed in reactive paths. 248 3.1.1. Multiple Test Packet Lengths 250 Many instances of network characterization using IPPM metrics have 251 relied on a single test packet length. When testing to assess 252 application performance or an aggregate of traffic, benchmarking 253 methods have used a range of fixed lengths and frequently augmented 254 fixed size tests with a mixture of sizes, or IMIX as described in 255 [RFC6985]. 257 Test packet length influences delay measurements, in that the IPPM 258 one-way delay metric [RFC2679] includes serialization time in its 259 first-bit to last bit time stamping requirements. However, different 260 sizes can have a larger effect on link delay and link delay variation 261 than serialization would explain alone. This effect can be non- 262 linear and change the instantaneous network performance when a 263 different size is used, or the performance of packets following the 264 size change. 266 Repeatability is a main measurement methodology goal as stated in 267 section 6.2 of [RFC2330]. To eliminate packet length as a potential 268 measurement uncertainty factor, successive measurements must use 269 identical traffic patterns. In practice a combination of random 270 payload and random start time can yield representative results as 271 illustrated in [IRR]. 273 3.1.2. Test Packet Payload Content Optimization 275 The aim for efficient network resource use has resulted in deployment 276 of server-only or client-server lossless or lossy payload compression 277 techniques on some links or paths. These optimizers attempt to 278 compress high-volume traffic in order to reduce network load. Files 279 are analyzed by application-layer parsers and parts (like comments) 280 might be dropped. Although typically acting on HTTP or JPEG files, 281 compression might affect measurement packets, too. In particular 282 measurement packets are qualified for efficient compression when they 283 use standard plain-text payload. 285 IPPM-conforming measurements should add packet payload content as a 286 Type-P parameter which can help to improve measurement determinism. 287 Some packet payloads are more susceptible to compression than others, 288 but optimizers in the measurement path can be out ruled by using 289 incompressible packet payload. This payload content could be either 290 generated by a random device or by using part of a compressed file 291 (e.g., a part of a ZIP compressed archive). 293 3.2. Packet History 295 Recent packet history and instantaneous data rate influence 296 measurement results for reactive links supporting on-demand capacity 297 allocation. Measurement uncertainty may be reduced by knowledge of 298 measurement packet history and total host load. Additionally, small 299 changes in history, e.g., because of lost packets along the path, can 300 be the cause of large performance variations. 302 For instance delay in reactive 3G networks like High Speed Packet 303 Access (HSPA) depends to a large extent on the test traffic data 304 rate. The reactive resource allocation strategy in these networks 305 affects the uplink direction in particular. Small changes in data 306 rate can be the reason of more than 200% increase in delay, depending 307 on the specific packet size. 309 3.3. Access Technology Change 311 [RFC2330] discussed the scenario of multi-homed hosts. If hosts 312 become aware of access technology changes (e.g., because of IP 313 address changes or lower layer information) and make this information 314 available, measurement methodologies can use this information to 315 improve measurement representativeness and relevance. 317 However, today's various access network technologies can present the 318 same physical interface to the host. A host may or may not become 319 aware when its access technology changes on such an interface. 320 Measurements for paths which support on-demand capacity allocation 321 are therefore challenging in that it is difficult to differentiate 322 between access technology changes (e.g., because of mobility) and 323 reactive path behavior (e.g., because of data rate change). 325 3.4. Time-Slotted Randomness Cancellation 327 Time-Slotted operation of path entities - interfaces, routers or 328 links - in a network path is a particular challenge for measurements, 329 especially if the time slot period is substantial. The central 330 observation as an extension to Poisson stream sampling in [RFC2330] 331 is that the first such time-slotted component cancels unbiased 332 measurement stream sampling. In the worst case, time-slotted 333 operation converts an unbiased, random measurement packet stream into 334 a periodic packet stream. Being heavily biased, these packets may 335 interact with periodic behavior of subsequent time-slotted network 336 entities[TSRC]. 338 Time-slotted randomness cancellation (TSRC) sources can be found in 339 virtually any system, network component or path, their impact on 340 measurements being a matter of the order of magnitude when compared 341 to the metric under observation. Examples of TSRC sources include 342 but are not limited to system clock resolution, operating system 343 ticks, time-slotted component or network operation, etc. The amount 344 of measurement bias is determined by the particular measurement 345 stream, relative offset between allocated time-slots in subsequent 346 path entities, delay variation in these paths, and other sources of 347 variation. Measurement results might change over time, depending on 348 how accurately the sending host, receiving host, and time-slotted 349 components in the measurement path are synchronized to each other and 350 to global time. If path segments maintain flow state, flow parameter 351 change or flow re-allocations can cause substantial variation in 352 measurement results. 354 Practical measurements confirm that such interference limits delay 355 measurement variation to a sub-set of theoretical value range. 356 Measurement samples for such cases can aggregate on artificial 357 limits, generating multi-modal distributions as demonstrated in 358 [IRR]. In this context, the desirable measurement sample statistics 359 differentiate between multi-modal delay distributions caused by 360 reactive path behavior and the ones due to time-slotted interference. 362 Measurement methodology selection for time-slotted paths depends to a 363 large extent on the respective viewpoint. End-to-end metrics can 364 provide accurate measurement results for short-term sessions and low 365 likelihood of flow state modifications. Applications or services 366 which aim at approximating path performance for a short time interval 367 (in the order of minutes) and expect stable path conditions should 368 therefore prefer end-to-end metrics. Here stable path conditions 369 refer to any kind of global knowledge concerning measurement path 370 flow state and flow parameters. 372 However, if long-term forecast of time-slotted path performance is 373 the main measurement goal, a segmented approach relying on 374 measurement of sub-path metrics is preferred. Re-generating unbiased 375 measurement traffic at any hop can help to reveal the true range of 376 path performance for all path segments. 378 4. Quality of Metrics and Methodologies 380 [RFC6808] proposes repeatability and continuity as one of the metric 381 and methodology properties to infer on measurement quality. 382 Depending mainly on the set of controlled measurement parameters, 383 measurements repeated for a specific network path using a specific 384 methodology may or may not yield repeatable results. Challenging 385 measurement scenarios for adequate parameter control include 386 wireless, reactive, or time-slotted networks as discussed earlier in 387 this document. This section presents an expanded definition of 388 "repeatability" beyond the definition in [RFC2330] and an expanded 389 examination of the [RFC2330] concept of "continuity" and its limited 390 applicability. 392 4.1. Repeatability 394 [RFC2330] defines repeatability in a general way: 396 "A methodology for a metric should have the property that it is 397 repeatable: if the methodology is used multiple times under identical 398 conditions, the same measurements should result in the same 399 measurements." 401 The challenge is to develop this definition further, such that it 402 becomes an objective measurable criterion (and does not depend on the 403 concept of continuity discussed below). Fortunately, this topic has 404 been treated in other IPPM work. In BCP 176 [RFC6576], the criteria 405 of equivalent results was agreed as the surrogate for 406 interoperability when assessing metric RFCs for standards track 407 advancement. The criteria of equivalence were expressed as objective 408 statistical requirements for comparison across same implementations 409 and independent implementations in the test plans specific to each 410 RFC evaluated ([RFC2679] in the test plan of [RFC6808]). 412 The tests of [RFC6808] rely on nearly identical conditions to be 413 present for analysis, but accept that these conditions cannot be 414 exactly identical in the production network paths used. The test 415 plans allow some correction factors to be applied (some statistical 416 tests are hyper-sensitive to differences in the mean of 417 distributions), and recognize the original findings of [RFC2330] 418 regarding excess sample sizes. 420 One way to view the reliance on identical conditions is to view it as 421 a challenge: how few parameters and path conditions need to be 422 controlled and still produce repeatable methods/measurements? 424 Although the [RFC6808] test plan documented numerical criteria for 425 equivalence, we cannot specify the exact numerical criteria for 426 repeatability *in general*. The process in the BCP [RFC6576] and 427 statistics in [RFC6808] have been used successfully, and the 428 numerical criteria to declare a metric repeatable should be agreed by 429 all interested parties prior to measurement. 431 We revise the definition slightly, as follows: 433 "A methodology for a metric should have the property that it is 434 repeatable: if the methodology is used multiple times under identical 435 conditions, the methods should produce equivalent measurement 436 results." 438 4.2. Continuity 440 In the original framework [RFC2330], the concept of continuity was 441 introduced to provide a relaxed criteria for judging repeatability, 442 and was described in section 6.2 of [RFC2330] as follows: 444 "...a methodology for a given metric exhibits continuity if, for 445 small variations in conditions, it results in small variations in the 446 resulting measurements." 448 Although there are conditions where metrics may exhibit continuity, 449 there are others where this criteria would fail for both user traffic 450 and active measurement traffic. Consider link fragmentation, and the 451 non-linear increase in delay when we increase packet size just beyond 452 the limit of a single fragment. An active measurement packet would 453 see the same delay increase when exceeding the fragment size. 455 The Bulk Transfer Capacity (BTC) [RFC3148] gives another example at 456 bottom of page 2: 458 "There is also evidence that most TCP implementations exhibit non- 459 linear performance over some portion of their operating region. It 460 is possible to construct simple simulation examples where incremental 461 improvements to a path (such as raising the link data rate) results 462 in lower overall TCP throughput (or BTC) [Mat98]." 464 Clearly, the time-slotted network elements described in section 3.4 465 above also qualifies as a new exception to the ideal of continuity. 466 Therefore, we deprecate continuity as an alternate criterion on 467 metrics, and prefer the more exact evaluation of repeatability 468 instead. 470 4.3. Actionable 472 The IP Performance Metrics Framework [RFC2330] includes usefulness as 473 a metric criterion: 475 "...The metrics must be useful to users and providers in 476 understanding the performance they experience or provide...". 478 When considering measurements as part of a maintenance process, 479 evaluation of measurement results for a path under observation can 480 draw attention to potential performance problems "somewhere" on the 481 path. Anomaly detection is therefore an important phase and first 482 step which already satisfies the usefulness criterion for many 483 metrics. 485 This concept of usefulness can be extended, becoming a sub-set of 486 what we refer to as "actionable" criterion in the following. Central 487 to maintenance is the isolation of the root cause of reported 488 anomalies down to a specific sub-path, link or host, and metrics 489 should support this second step as well. While detection of path 490 anomaly may be the result of an on-going monitoring process, the 491 second step of cause isolation consists of specific, directed on- 492 demand measurements on components and sub-paths. Metrics must 493 support users in this directed search, becoming actionable: 495 Metrics must enable users and operators to understand path 496 performance and SHOULD help to direct corrective actions when 497 warranted, based on the measurement results. 499 Besides characterizing metrics, usefulness and actionable properties 500 are also applicable to methodologies and measurements. 502 4.4. Conservative 504 [RFC2330] adopts the term "conservative" for measurement 505 methodologies for which: 507 "... the act of measurement does not modify, or only slightly 508 modifies, the value of the performance metric the methodology 509 attempts to measure." 511 It should be noted that this definition of "conservative" in the 512 sense of [RFC2330] depends to a large extent on the measurement 513 path's technology and characteristics. In particular, when deployed 514 on reactive paths, sub-paths, links or hosts conforming to the 515 definition in Section 1.1 of this document, measurement packets can 516 originate capacity (re)allocations. In addition, small measurement 517 flow variations can result in other users on the same path perceiving 518 significant variations in measurement results. 520 4.5. Spatial and Temporal Composition 522 Concepts related to temporal and spatial composition of metrics in 523 Section 9 of [RFC2330] have been extended in [RFC5835]. [RFC5835] 524 defines multiple new types of metrics, including Spatial Composition, 525 Temporal Aggregation, and Spatial Aggregation. So far, only the 526 metrics for Spatial Composition have been standardized [RFC6049], 527 providing the ability to estimate the performance of a complete path 528 from subpath metrics. Spatial Composition aligns with the finding of 529 [TSRC], that unbiased sampling is not possible beyond the first time- 530 slotted link within a measurement path. In cases where measurement 531 of subpaths is not feasible, restoring randomness of measurement 532 samples when necessary is recommended as presented in [TSRC]. 534 4.6. Poisson Sampling 536 Section 11.1.1 of [RFC2330] describes Poisson sampling, where the 537 inter-packet send times have a Poisson distribution. A path element 538 with reactive behavior sensitive to flow inactivity could change 539 state if the random inter-packet time is too long. It is recommended 540 to truncate the tail of Poisson distribution to avoid reactive 541 element state changes. Truncation has been used without issue to 542 ensure that minimum sample sizes can be attained in a fixed test 543 interval. 545 5. Conclusions 547 Safeguarding repeatability as a key property of measurement 548 methodologies is highly challenging and sometimes impossible in 549 reactive paths. Measurements in paths with demand-driven allocation 550 strategies must use a prototypical application packet stream to infer 551 a specific application's performance. Measurement repetition with 552 unbiased network and flow states (e.g., by rebooting measurement 553 hosts) can help to avoid interference with periodic network behavior, 554 randomness being a mandatory feature for avoiding correlation with 555 network timing. Inferring the path performance between one 556 measurement session or packet stream and other streams with alternate 557 characteristics is generally discouraged with reactive paths because 558 of the huge set of global parameters which have influence 559 instantaneous path performance. 561 6. Security Considerations 563 The security considerations that apply to any active measurement of 564 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 566 7. IANA Considerations 568 This memo makes no requests of IANA. 570 8. Acknowledgements 572 The authors thank Rudiger Geib, Matt Mathis and Konstantinos 573 Pentikousis for their helpful comments on this draft. 575 9. References 577 9.1. Normative References 579 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 580 3", BCP 9, RFC 2026, October 1996. 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 586 "Framework for IP Performance Metrics", RFC 2330, 587 May 1998. 589 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 590 Delay Metric for IPPM", RFC 2679, September 1999. 592 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 593 Packet Loss Metric for IPPM", RFC 2680, September 1999. 595 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 596 performance measurement with periodic streams", RFC 3432, 597 November 2002. 599 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 600 Zekauskas, "A One-way Active Measurement Protocol 601 (OWAMP)", RFC 4656, September 2006. 603 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 604 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 605 RFC 5357, October 2008. 607 [RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation 608 and Implementation Reports for Advancement to Draft 609 Standard", BCP 9, RFC 5657, September 2009. 611 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 612 Composition", RFC 5835, April 2010. 614 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 615 Metrics", RFC 6049, January 2011. 617 [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP 618 Performance Metrics (IPPM) Standard Advancement Testing", 619 BCP 176, RFC 6576, March 2012. 621 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 622 IP Network Performance Metrics: Different Points of View", 623 RFC 6703, August 2012. 625 9.2. Informative References 627 [IBD] Fabini, J., Karner, W., Wallentin, L., and T. Baumgartner, 628 "The Illusion of Being Deterministic - Application-Level 629 Considerations on Delay in 3G HSPA Networks", Lecture 630 Notes in Computer Science, Springer, Volume 5550, 2009, 631 pp 301-312 , May 2009. 633 [IRR] Fabini, J., Wallentin, L., and P. Reichl, "The Importance 634 of Being Really Random: Methodological Aspects of IP-Layer 635 2G and 3G Network Delay Assessment", ICC'09 Proceedings of 636 the 2009 IEEE International Conference on 637 Communications, doi: 10.1109/ICC.2009.5199514, June 2009. 639 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 640 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 641 July 2001. 643 [RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test 644 Plan and Results Supporting Advancement of RFC 2679 on the 645 Standards Track", RFC 6808, December 2012. 647 [RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet 648 Sizes for Additional Testing", RFC 6985, July 2013. 650 [TSRC] Fabini, J. and M. Abmayer, "Delay Measurement Methodology 651 Revisited: Time-slotted Randomness Cancellation", IEEE 652 Transactions on Instrumentation and Measurement doi: 653 10.1109/TIM.2013.2263914, October 2013. 655 Authors' Addresses 657 Joachim Fabini 658 Vienna University of Technology 659 Gusshausstrasse 25/E389 660 Vienna, 1040 661 Austria 663 Phone: +43 1 58801 38813 664 Fax: +43 1 58801 38898 665 Email: Joachim.Fabini@tuwien.ac.at 666 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 668 Al Morton 669 AT&T Labs 670 200 Laurel Avenue South 671 Middletown, NJ 07748 672 USA 674 Phone: +1 732 420 1571 675 Fax: +1 732 368 1192 676 Email: acmorton@att.com 677 URI: http://home.comcast.net/~acmacm/