idnits 2.17.1 draft-ietf-ippm-2330-update-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 10, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC5657' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC6576' is defined on line 426, 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 (~~), 6 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: January 11, 2014 AT&T Labs 6 July 10, 2013 8 Advanced Stream and Sampling Framework for IPPM 9 draft-ietf-ippm-2330-update-00 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 January 11, 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 Network Behavior . . . . . . . . . . 3 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. New Stream Parameters . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . . 5 71 3.1.1. Test Packet Length . . . . . . . . . . . . . . . . . . 6 72 3.1.2. Test Packet Payload Content Optimization . . . . . . . 6 73 3.2. Packet History . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Access Technology Change . . . . . . . . . . . . . . . . . 7 75 3.4. Time-Slotted Randomness Cancellation . . . . . . . . . . . 7 76 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 The IETF IP Performance Metrics (IPPM) working group first created a 88 framework for metric development in [RFC2330]. This framework has 89 stood the test of time and enabled development of many fundamental 90 metrics, while only being updated once in a specific area [RFC5835]. 92 The IPPM framework [RFC2330] generally relies on several assumptions, 93 one of which is not explicitly stated but assumed: the network 94 behaves (halfway) deterministic and without state/history-less (with 95 some exceptions, firewalls are mentioned). However, this does not 96 hold true for many modern network technologies, such as reactive 97 networks (those with demand-driven resource allocation) and links 98 with time-slotted operation. Per-flow state can be observed on test 99 packet streams, and such treatment will influence network 100 characterization if it is not taken into account. Flow history will 101 also affect the performance of applications and be perceived by their 102 users. 104 Moreover, Sections 4 and 6.2 of [RFC2330] explicitly recommend 105 repeatable measurement metrics and methodologies. Measurements in 106 today's access networks illustrate that methodological guidelines of 107 [RFC2330] must be extended to capture the reactive nature of these 108 networks. Although the proposed extensions can support methodologies 109 to fulfill the continuity requirement stated in section 6.2 of 110 [RFC2330], there is no guarantee. Practical measurements confirm 111 that some link types exhibit distinct responses to repeated 112 measurements with identical stimulus, i.e., identical traffic 113 patterns. If feasible, appropriate fine-tuning of measurement 114 traffic patterns can improve measurement continuity and repeatability 115 for these link types as shown in [IBD]. 117 1.1. Definition: Reactive Network Behavior 119 A network or network path is defined to be reactive when at least one 120 of the links or hosts in it exhibits reactive behavior. Reactive 121 behavior is present when link-or host-internal sensing (measurement) 122 of packet arrival for the flow of interest indicates that traffic is 123 absent or present, or that traffic during a measurement interval is 124 above or below a threshold, and the results of one or more successive 125 measurements cause one or more network components to process future 126 packets using a different mode of operation than for other 127 measurement outcomes. 129 Reactive network behavior must be observable by the test packet 130 stream as a repeatable phenomenon where packet transfer performance 131 characteristics *change* according to prior node- or link-internal 132 observations of the packet flow of interest. Therefore, reactive 133 network behavior is deterministic with respect to the flow of 134 interest. Other flows or traffic load conditions may result in 135 additional performance-affecting reactions, but these are external to 136 the characteristics of the flow of interest. 138 Other than the size of the payload at the layer of interest and the 139 header itself, packet content does not influence the measurement. 140 Reactive behavior at the IP layer is not influenced by the TCP ports 141 in use, for example. Therefore, the indication of reactive behavior 142 must include the layer at which measurements are instituted. 144 Examples include links with Active/In-active state detectors, and 145 network devices or links that revise their traffic serving and 146 forwarding rates (up or down) based on packet arrival history. 148 2. Scope 150 The scope of his memo is to describe useful stream parameters in 151 addition to the information in Section 11.1 of [RFC2330] and 152 described in [RFC3432] for periodic streams. The purpose is to 153 foster repeatable measurement results in modern networks by 154 highlighting the key aspects of test streams and packets and make 155 them part of the IPPM performance metric framework. 157 3. New Stream Parameters 159 There are several areas where measurement methodology definition and 160 test result interpretation will benefit from an increased 161 understanding of the stream characteristics and the (possibly 162 unknown) network condition that influence the measured metrics. 164 1. Network treatment depends on the fullest extent on the "packet of 165 Type-P" definition in [RFC2330], and has for some time. 167 * State is often maintained on the per-flow basis at various 168 points in the network, where "flows" are determined by IP and 169 other layers. Significant treatment differences occur with 170 the simplest of Type-P parameters: packet length. 172 * Payload content optimization (compression or format 173 conversion) in intermediate segments. This breaks the 174 convention of payload correspondence when correlating 175 measurements made at different points in a path. 177 2. Packet history (instantaneous or recent test rate or inactivity, 178 also for non-test traffic) profoundly influences measured 179 performance, in addition to all the Type-P parameters described 180 in [RFC2330]. 182 3. Access technology may change during testing. A range of transfer 183 capacities and access methods may be encountered during a test 184 session. When different interfaces are used, the host seeking 185 access will be aware of the technology change which 186 differentiates this form of path change from other changes in 187 network state. Section 14 of [RFC2330] treats the possibility 188 that a host may have more than one attachment to the network, and 189 also that assessment of the measurement path (route) is valid for 190 some length of time (in Section 5 and Section 7 of [RFC2330]). 191 Here we combine these two considerations under the assumption 192 that changes may be more frequent and possibly have greater 193 consequences on performance metrics. 195 4. Paths including links or nodes with time-slotted service 196 opportunities represent several challenges to measurement (when 197 service time period is appreciable): 199 * Random/unbiased sampling is not possible beyond one such link 200 in the path. 202 * The above encourages a segmented approach to end to end 203 measurement, as described in [RFC6049] for Network 204 Characterization (as defined in [RFC6703]) to understand the 205 full range of delay and delay variation on the path. 206 Alternatively, if application performance estimation is the 207 goal (also defined in [RFC6703]), then a stream with un-biased 208 or known-bias properties [RFC3432] may be sufficient. 210 * Multi-modal delay variation makes central statistics 211 unimportant, others must be used instead. 213 Each of these topics is treated in detail below. 215 3.1. Test Packet Type-P 217 We recommend two Type-P parameters to be added to the factors which 218 have impact on network performance measurements, namely packet length 219 and payload type. Carefully choosing these parameters can improve 220 measurement methodologies in their continuity and repeatability when 221 deployed in reactive networks. 223 3.1.1. Test Packet Length 225 Many instances of network characterization using IPPM metrics have 226 relied on a single test packet length. When testing to assess 227 application performance or an aggregate of traffic, benchmarking 228 methods have used a range of fixed lengths and frequently augmented 229 fixed size tests with a mixture of sizes, or IMIX as described in 230 [I-D.ietf-bmwg-imix-genome]. 232 Test packet length influences delay measurements, in that the IPPM 233 one-way delay metric [RFC2679] includes serialization time in its 234 first-bit to last bit time stamping requirements. However, different 235 sizes can have a larger effect on link delay and link delay variation 236 than serialization would explain alone. This effect can be non- 237 linear and change instantaneous or future network performance. 239 Repeatability is a main measurement methodology goal as stated in 240 section 6.2 of [RFC2330]. To eliminate packet length as a potential 241 measurement uncertainty factor, successive measurements must use 242 identical traffic patterns. In practice a combination of random 243 payload and random start time can yield representative results as 244 illustrated in [IRR]. 246 3.1.2. Test Packet Payload Content Optimization 248 The aim for efficient network resource use has resulted in a series 249 of "smart" networks to deploy server-only or client-server lossless 250 or lossy payload compression techniques on some links or paths. 251 These optimizers attempt to compress high-volume traffic in order to 252 reduce network load. Files are analyzed by application-layer parsers 253 and parts (like comments) might be dropped. Although typically 254 acting on HTTP or JPEG files, compression might affect measurement 255 packets, too. In particular measurement packets are qualified for 256 efficient compression when they use standard plain-text payload. 258 IPPM-conforming measurements should add packet payload content as a 259 Type-P parameter which can help to improve measurement determinism. 260 Some packet payloads are more susceptible to compression than others, 261 but optimizers in the measurement path can be out ruled by using 262 incompressible packet payload. This payload content could be either 263 generated by a random device or by using part of a compressed file 264 (e.g., a part of a ZIP compressed archive). 266 3.2. Packet History 268 Recent packet history and instantaneous data rate influence 269 measurement results for reactive links supporting on-demand capacity 270 allocation. Measurement uncertainty may be reduced by knowledge of 271 measurement packet history and total host load. Additionally, small 272 changes in history, e.g., because of lost packets along the path, can 273 be the cause of large performance variations. 275 For instance delay in reactive 3G networks like High Speed Packet 276 Access (HSPA) depends to a large extent on the test traffic data 277 rate. The reactive resource allocation strategy in these networks 278 affects the uplink direction in particular. Small changes in data 279 rate can be the reason of more than 200% increase in delay, depending 280 on the specific packet size. 282 3.3. Access Technology Change 284 [RFC2330] discussed the scenario of multi-homed hosts. If hosts 285 become aware of access technology changes (e.g., because of IP 286 address changes or lower layer information) and make this information 287 available, measurement methodologies can use this information to 288 improve measurement representativeness and relevance. 290 However, today's various access network technologies can present the 291 same physical interface to the host. A host may or may not become 292 aware when its access technology changes on such an interface. 293 Measurements for networks which support on-demand capacity allocation 294 are therefore challenging in that it is difficult to differentiate 295 between access technology changes (e.g., because of mobility) and 296 reactive network behavior (e.g., because of data rate change). 298 3.4. Time-Slotted Randomness Cancellation 300 Time-Slotted operation of network entities - interfaces, routers or 301 links - in a network path is a particular challenge for measurements, 302 especially if the time slot period is substantial. The central 303 observation as an extension to Poisson stream sampling in [RFC2330] 304 is that the first such time-slotted component cancels unbiased 305 measurement stream sampling. In the worst case, time-slotted 306 operation converts an unbiased, random measurement packet stream into 307 a periodic packet stream. Being heavily biased, these packets may 308 interact with periodic network behavior of subsequent time-slotted 309 network entities[TSRC]. 311 Time-slotted randomness cancellation (TSRC) sources can be found in 312 virtually any system, network component or path, their impact on 313 measurements being a matter of the order of magnitude when compared 314 to the metric under observation. Examples of TSRC sources include 315 but are not limited to system clock resolution, operating system 316 ticks, time-slotted component or network operation, etc. The amount 317 of measurement bias is determined by the particular measurement 318 stream, relative offset between allocated time-slots in subsequent 319 network entities, delay variation in these networks, and other 320 sources of variation. Measurement results might change over time, 321 depending on how accurately the sending host, receiving host, and 322 time-slotted components in the measurement path are synchronized to 323 each other and to global time. If network segments maintain flow 324 state, flow parameter change or flow re-allocations can cause 325 substantial variation in measurement results. 327 Practical measurements confirm that such interference limits delay 328 measurement variation to a sub-set of theoretical value range. 329 Measurement samples for such cases can aggregate on artificial 330 limits, generating multi-modal distributions as demonstrated in 331 [IRR]. In this context, the desirable measurement sample statistics 332 differentiate between multi-modal delay distributions caused by 333 reactive network behavior and the ones due to time-slotted 334 interference. 336 Measurement methodology selection for time-slotted paths depends to a 337 large extent on the respective viewpoint. End-to-end metrics can 338 provide accurate measurement results for short-term sessions and low 339 likelihood of flow state modifications. Applications or services 340 which aim at approximating network performance for a short time 341 interval (in the order of minutes) and expect stable network 342 conditions should therefore prefer end-to-end metrics. Here stable 343 network conditions refer to any kind of global knowledge concerning 344 measurement path flow state and flow parameters. 346 However, if long-term forecast of time-slotted network performance is 347 the main measurement goal, a segmented approach relying on 348 measurement of sub-path metrics is preferred. Re-generating unbiased 349 measurement traffic at any hop can help to reveal the true range of 350 network performance for all network segments. 352 4. Conclusions 354 Safeguarding continuity and repeatability as key properties of 355 measurement methodologies is highly challenging and sometimes 356 impossible in reactive networks. Measurements in networks with 357 demand-driven allocation strategies must use a prototypical 358 application packet stream to infer a specific application's 359 performance. Measurement repetition with unbiased network and flow 360 states (e.g., by rebooting measurement hosts) can help to avoid 361 interference with periodic network behavior, randomness being a 362 mandatory feature for avoiding correlation with network timing. 363 Inferring the network performance between one measurement session or 364 packet stream and other streams with alternate characteristics is 365 generally discouraged with reactive networks because of the huge set 366 of global parameters which have influence instantaneous network 367 performance. 369 5. Security Considerations 371 The security considerations that apply to any active measurement of 372 live networks are relevant here as well. See [RFC4656] and 373 [RFC5357]. 375 6. IANA Considerations 377 This memo makes no requests of IANA. 379 7. Acknowledgements 381 The authors thank Rudiger Geib and Matt Mathis for their helpful 382 comments on this draft. 384 8. References 386 8.1. Normative References 388 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 389 3", BCP 9, RFC 2026, October 1996. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 395 "Framework for IP Performance Metrics", RFC 2330, 396 May 1998. 398 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 399 Delay Metric for IPPM", RFC 2679, September 1999. 401 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 402 Packet Loss Metric for IPPM", RFC 2680, September 1999. 404 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 405 performance measurement with periodic streams", RFC 3432, 406 November 2002. 408 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 409 Zekauskas, "A One-way Active Measurement Protocol 410 (OWAMP)", RFC 4656, September 2006. 412 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 413 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 414 RFC 5357, October 2008. 416 [RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation 417 and Implementation Reports for Advancement to Draft 418 Standard", BCP 9, RFC 5657, September 2009. 420 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 421 Composition", RFC 5835, April 2010. 423 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 424 Metrics", RFC 6049, January 2011. 426 [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP 427 Performance Metrics (IPPM) Standard Advancement Testing", 428 BCP 176, RFC 6576, March 2012. 430 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 431 IP Network Performance Metrics: Different Points of View", 432 RFC 6703, August 2012. 434 8.2. Informative References 436 [I-D.ietf-bmwg-imix-genome] 437 Morton, A., "IMIX Genome: Specification of variable packet 438 sizes for additional testing", 439 draft-ietf-bmwg-imix-genome-05 (work in progress), 440 June 2013. 442 [IBD] Fabini, J., "The Illusion of Being Deterministic - 443 Application-Level Considerations on Delay in 3G HSPA 444 Networks", Lecture Notes in Computer Science, Springer, 445 Volume 5550, 2009, pp 301-312 , May 2009. 447 [IRR] Fabini, J., "The Importance of Being Really Random: 448 Methodological Aspects of IP-Layer 2G and 3G Network Delay 449 Assessment", ICC'09 Proceedings of the 2009 IEEE 450 International Conference on Communications, doi: 10.1109/ 451 ICC.2009.5199514, June 2009. 453 [TSRC] Fabini, J., "Delay Measurement Methodology Revisited: 454 Time-slotted Randomness Cancellation", IEEE Transactions 455 on Instrumentation and Measurement doi:10.1109/ 456 TIM.2013.2263914, July 2013. 458 Authors' Addresses 460 Joachim Fabini 461 Vienna University of Technology 462 Favoritenstrasse 9/E389 463 Vienna, 1040 464 Austria 466 Phone: +43 1 58801 38813 467 Fax: +43 1 58801 38898 468 Email: Joachim.Fabini@tuwien.ac.at 469 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 471 Al Morton 472 AT&T Labs 473 200 Laurel Avenue South 474 Middletown, NJ 07748 475 USA 477 Phone: +1 732 420 1571 478 Fax: +1 732 368 1192 479 Email: acmorton@att.com 480 URI: http://home.comcast.net/~acmacm/