idnits 2.17.1 draft-ietf-ippm-rate-problem-02.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 (February 1, 2013) is 4095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1305' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC5618' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC5938' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC6038' is defined on line 436, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) == Outdated reference: A later version (-01) exists of draft-mathis-ippm-model-based-metrics-00 == Outdated reference: A later version (-01) exists of draft-morton-ippm-lmap-path-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Informational February 1, 2013 5 Expires: August 5, 2013 7 Rate Measurement Test Protocol Problem Statement 8 draft-ietf-ippm-rate-problem-02 10 Abstract 12 There is a rate measurement scenario which has wide-spread attention 13 of Internet access subscribers and seemingly all industry players, 14 including regulators. This memo presents an access rate-measurement 15 problem statement for test protocols to measure IP Performance 16 Metrics. Key test protocol aspects require the ability to control 17 packet size on the tested path and enable asymmetrical packet size 18 testing in a controller-responder architecture. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 5, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5 63 4. Measurement Method Categories . . . . . . . . . . . . . . . . 7 64 5. Test Protocol Control & Generation Requirements . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 10.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 There are many possible rate measurement scenarios. This memo 77 describes one rate measurement problem and presents a rate- 78 measurement problem statement for test protocols to measure IP 79 Performance Metrics (IPPM). 81 The access-rate scenario or use case has wide-spread attention of 82 Internet access subscribers and seemingly all Internet industry 83 players, including regulators. This problem is being approached with 84 many different measurement methods. This memo 86 2. Purpose and Scope 88 The scope and purpose of this memo is to define the measurement 89 problem statement for test protocols conducting access rate 90 measurement on production networks. Relevant test protocols include 91 [RFC4656] and [RFC5357]), but the problem is stated in a general way 92 so that it can be addressed by any existing test protocol, such as 93 [RFC6812]. 95 This memo discusses possibilities for methods of measurement, but 96 does not specify exact methods which would normally be part of the 97 solution, not the problem. 99 We characterize the access rate measurement scenario as follows: 101 o The Access portion of the network is the focus of this problem 102 statement. The user typically subscribes to a service with bi- 103 directional access partly described by rates in bits per second. 104 The rates may be expressed as raw capacity or restricted capacity 105 as described in [RFC6703]. These are the quantities that must be 106 measured according to one or more standard metrics for which 107 methods must also be agreed as a part of the solution. 109 o Referring to the reference path defined in 110 [I-D.morton-ippm-lmap-path], possible measurement points include a 111 Subscriber's host (mp000), the access service demarcation point 112 (mp100), Intra IP access where a globally routable address is 113 present (mp150), or the gateway between the measured access 114 network and other networks (mp190). 116 o Rates at the edge of the network are several orders of magnitude 117 less than aggregation and core portions. 119 o Asymmetrical ingress and egress rates are prevalent. 121 o Extremely large scale of access services requires low complexity 122 devices participating at the user end of the path. 124 Today, the majority of widely deployed access services achieve rates 125 less than 100 Mbit/s, and this is the order of magnitude for which a 126 solution is sought now. 128 This problem statement assumes that the most-likely bottleneck device 129 or link is adjacent to the remote (user-end) measurement device, or 130 is within one or two router/switch hops of the remote measurement 131 device. 133 Other use cases for rate measurement involve situations where the 134 packet switching and transport facilities are leased by one operator 135 from another and the actual capacity available cannot be directly 136 determined (e.g., from device interface utilization). These 137 scenarios could include mobile backhaul, Ethernet Service access 138 networks, and/or extensions of layer 2 or layer 3 networks. The 139 results of rate measurements in such cases could be employed to 140 select alternate routing, investigate whether capacity meets some 141 previous agreement, and/or adapt the rate of traffic sources if a 142 capacity bottleneck is found via the rate measurement. In the case 143 of aggregated leased networks, available capacity may also be 144 asymmetric. In these cases, the tester is assumed to have a sender 145 and receiver location under their control. We refer to this scenario 146 below as the aggregated leased network case. 148 Support of active measurement methods will be addressed here, 149 consistent with the IPPM working group's traditional charter. Active 150 measurements require synthetic traffic dedicated to testing, and do 151 not use user traffic. 153 The actual path used by traffic may influence the rate measurement 154 results for some forms of access, as it may differ between user and 155 test traffic if the test traffic has different characteristics, 156 primarily in terms of the packets themselves (the Type-P described in 157 [RFC2330]). 159 There are several aspects of Type-P where user traffic may be 160 examined and directed to special treatment that may affect 161 transmission rates. The possibilities include: 163 o Packet length 165 o IP addresses used 167 o Transport protocol used (where TCP packets may be routed 168 differently from UDP) 170 o Transport Protocol port numbers used 172 This issue requires further discussion when specific solutions/ 173 methods of measurement are proposed, but for this problem statement 174 it is sufficient to Identify the problem and indicate that the 175 solution may require an extremely close emulation of user traffic, in 176 terms of the factors above. 178 Although the user may have multiple instances of network access 179 available to them, the primary problem scope is to measure one form 180 of access at a time. It is plausible that a solution for the single 181 access problem will be applicable to simultaneous measurement of 182 multiple access instances, but discussion of this is beyond the 183 current scope. 185 A key consideration is whether active measurements will be conducted 186 with user traffic present (In-Service testing), or not present (Out- 187 of-Service testing), such as during pre-service testing or 188 maintenance that interrupts service temporarily. Out-of-Service 189 testing includes activities described as "service commissioning", 190 "service activation", and "planned maintenance". Opportunistic In- 191 Service testing when there is no user traffic present throughout the 192 test interval is essentially equivalent to Out-of-Service testing. 193 Both In-Service and Out-of-Service testing are within the scope of 194 this problem. 196 It is a non-goal to solve the measurement protocol specification 197 problem in this memo. 199 It is a non-goal to standardize methods of measurement in this memo. 200 However, the problem statement will mandate that support for one or 201 more categories of rate measurement methods and adequate control 202 features for the methods in the test protocol. 204 3. Active Rate Measurement 206 This section lists features of active measurement methods needed to 207 measure access rates in production networks. 209 Test coordination between source and destination devices through 210 control messages and other basic capabilities described in the 211 methods of IPPM RFCs [RFC2679][RFC2680] are taken as given (these 212 could be listed later, if desired). 214 Most forms of active testing intrude on user performance to some 215 degree. One key tenet of IPPM methods is to minimize test traffic 216 effects on user traffic in the production network. Section 5 of 218 [RFC2680] lists the problems with high measurement traffic rates, and 219 the most relevant for rate measurement is the tendency for 220 measurement traffic to skew the results, followed by the possibility 221 of introducing congestion on the access link. Obviously, categories 222 of rate measurement methods that use less active test traffic than 223 others with similar accuracy SHALL be preferred for In-Service 224 testing. 226 On the other hand, Out-of-Service tests where the test path shares no 227 links with In-Service user traffic have none of the congestion or 228 skew concerns, but these tests must address other practical concerns 229 such as conducting measurements within a reasonable time from the 230 tester's point of view. Out-of-Service tests where some part of the 231 test path is shared with In-Service traffic MUST respect the In- 232 Service constraints. 234 The **intended metrics to be measured** have strong influence over 235 the categories of measurement methods required. For example, using 236 the terminology of [RFC5136], a it may be possible to measure a Path 237 Capacity Metric while In-Service if the level of background (user) 238 traffic can be assessed and included in the reported result. 240 The measurement *architecture* MAY be either of one-way (e.g., 241 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 242 aspects of end-user or aggregated access measurement clearly favor 243 two-way (with low-complexity user-end device and round-trip results 244 collection, as found in [RFC5357]). However, the asymmetric rates of 245 many access services mean that the measurement system MUST be able to 246 evaluate performance in each direction of transmission. In the two- 247 way architecture, it is expected that both end devices MUST include 248 the ability to launch test streams and collect the results of 249 measurements in both (one-way) directions of transmission (this 250 requirement is consistent with previous protocol specifications, and 251 it is not a unique problem for rate measurements). 253 The following paragraphs describe features for the roles of test 254 packet SENDER, RECEIVER, and results REPORTER. 256 SENDER: 258 Generate streams of test packets with various characteristics as 259 desired (see Section 4). The SENDER may be located at the user end 260 of the access path, or may be located elsewhere in the production 261 network, such as at one end of an aggregated leased network segment. 263 RECEIVER: 265 Collect streams of test packets with various characteristics (as 266 described above), and make the measurements necessary to support rate 267 measurement at the other end of an end-user access or aggregated 268 leased network segment. 270 REPORTER: 272 Use information from test packets and local processes to measure 273 delivered packet rates. 275 4. Measurement Method Categories 277 The design of rate measurement methods can be divided into two 278 phases: test stream design and measurement (SENDER and RECEIVER), and 279 a follow-up phase for analysis of the measurement to produce results 280 (REPORTER). The measurement protocol that addresses this problem 281 MUST only serve the test stream generation and measurement functions. 283 For the purposes of this problem statement, we categorize the many 284 possibilities for rate measurement stream generation as follows; 286 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 287 random time intervals between pairs in a test stream. 289 2. Multiple streams of packet pairs, with a range of intra-pair 290 spacing and inter-pair intervals. 292 3. One or more packet ensembles in a test stream, using a fixed 293 ensemble size in packets and one or more fixed intra-ensemble 294 packet spacings (including zero spacing). 296 4. One or more packet chirps, where intra-packet spacing typically 297 decreases between adjacent packets in the same chirp and each 298 pair of packets represents a rate for testing purposes. 300 For all categories, the test protocol MUST support: 302 1. Variable payload lengths among packet streams 304 2. Variable length (in packets) among packet streams or ensembles 306 3. Variable IP header markings among packet streams 308 4. Choice of UDP transport and variable port numbers, OR, choice of 309 TCP transport and variable port numbers for two-way architectures 310 only, OR BOTH. 312 5. Variable number of packets-pairs, ensembles, or streams used in a 313 test session 315 The items above are additional variables that the test protocol MUST 316 be able to identify and control. 318 The test protocol SHALL support test packet ensemble generation 319 (category 3), as this appears to minimize the demands on measurement 320 accuracy. Other stream generation categories are OPTIONAL. 322 >>>>>> 324 Note: For measurement systems employing TCP Transport protocol, the 325 ability to generate specific stream characteristics requires a sender 326 with the ability to establish and prime the connection such that the 327 desired stream characteristics are allowed. See Mathis' work in 328 progress for more background [I-D.mathis-ippm-model-based-metrics]. 329 The general requirement statements needed to describe an "open-loop" 330 TCP sender require some additional discussion. 332 It may also be useful to specify a control for Bulk Transfer Capacity 333 measurement with fully-specified TCP senders and receivers, as 334 envisioned in [RFC3148], but this would be a brute-force assessment 335 which does not follow the conservative tenets of IPPM measurement 336 [RFC2330]. 338 >>>>>> 340 Measurements for each test packet transferred between SENDER and 341 RECEIVER MUST be compliant with the singleton measurement methods 342 described in IPPM RFCs [RFC2679][RFC2680] (these could be listed 343 later, if desired). The time-stamp information or loss/arrival 344 status for each packet MUST be available for communication to the 345 protocol entity that collects results. 347 5. Test Protocol Control & Generation Requirements 349 Essentially, the test protocol MUST support the measurement features 350 described in the sections above. This requires: 352 1. Communicating all test variables to the Sender and Receiver 354 2. Results collection in a one-way architecture 356 3. Remote device control for both one-way and two-way architectures 357 4. Asymmetric and/or pseudo-one-way test capability in a two-way 358 measurement architecture 360 The ability to control packet size on the tested path and enable 361 asymmetrical packet size testing in a two-way architecture are 362 REQUIRED. 364 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 365 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 366 metrics are OPTIONAL. 368 6. Security Considerations 370 The security considerations that apply to any active measurement of 371 live networks are relevant here as well. See [RFC4656] and 372 [RFC5357]. 374 There may be a serious issue if a proprietary Service Level Agreement 375 involved with the access network segment provider were somehow leaked 376 in the process of rate measurement. To address this, test protocols 377 SHOULD NOT convey this information in a way that could be discovered 378 by unauthorized parties. 380 7. IANA Considerations 382 This memo makes no requests of IANA. 384 8. Acknowledgements 386 Dave McDysan provided comments and text for the aggregated leased use 387 case. Yaakov Stein suggested many considerations to address, 388 including the In-Service vs. Out-of-Service distinction and its 389 implication on test traffic limits and protocols. Bill Cerveny and 390 Marcelo Bagnulo have contributed insightful, clarifying comments that 391 made this a better draft. 393 9. Appendix 395 This Appendix was proposed to briefly summarize previous rate 396 measurement experience. (There is a large body of research on rate 397 measurement, so there is a question of what to include and what to 398 omit. Suggestions are welcome.) 400 10. References 402 10.1. Normative References 404 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 405 Specification, Implementation", RFC 1305, March 1992. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 411 "Framework for IP Performance Metrics", RFC 2330, 412 May 1998. 414 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 415 Delay Metric for IPPM", RFC 2679, September 1999. 417 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 418 Packet Loss Metric for IPPM", RFC 2680, September 1999. 420 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 421 Zekauskas, "A One-way Active Measurement Protocol 422 (OWAMP)", RFC 4656, September 2006. 424 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 425 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 426 RFC 5357, October 2008. 428 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 429 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 430 August 2009. 432 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 433 Feature for the Two-Way Active Measurement Protocol 434 (TWAMP)", RFC 5938, August 2010. 436 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 437 Protocol (TWAMP) Reflect Octets and Symmetrical Size 438 Features", RFC 6038, October 2010. 440 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 441 IP Network Performance Metrics: Different Points of View", 442 RFC 6703, August 2012. 444 10.2. Informative References 446 [I-D.mathis-ippm-model-based-metrics] 447 Mathis, M., "Model Based Internet Performance Metrics", 448 draft-mathis-ippm-model-based-metrics-00 (work in 449 progress), October 2012. 451 [I-D.morton-ippm-lmap-path] 452 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 453 A. Morton, "A Reference Path and Measurement Points for 454 LMAP", draft-morton-ippm-lmap-path-00 (work in progress), 455 January 2013. 457 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 458 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 459 July 2001. 461 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 462 RFC 5136, February 2008. 464 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 465 S., and E. Yedavalli, "Cisco Service-Level Assurance 466 Protocol", RFC 6812, January 2013. 468 Author's Address 470 Al Morton 471 AT&T Labs 472 200 Laurel Avenue South 473 Middletown,, NJ 07748 474 USA 476 Phone: +1 732 420 1571 477 Fax: +1 732 368 1192 478 Email: acmorton@att.com 479 URI: http://home.comcast.net/~acmacm/