idnits 2.17.1 draft-ietf-ippm-rate-problem-03.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 (April 24, 2013) is 4019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1305' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC5618' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC5938' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC6038' is defined on line 456, 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) Summary: 3 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 A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Informational April 24, 2013 5 Expires: October 26, 2013 7 Rate Measurement Test Protocol Problem Statement 8 draft-ietf-ippm-rate-problem-03 10 Abstract 12 This memo presents an access rate-measurement problem statement for 13 test protocols to measure IP Performance Metrics. The rate 14 measurement scenario has wide-spread attention of Internet access 15 subscribers and seemingly all industry players, including regulators. 16 Key test protocol aspects require the ability to control packet size 17 on the tested path and enable asymmetrical packet size testing in a 18 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 October 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 There are many possible rate measurement scenarios. This memo 76 describes one rate measurement problem and presents a rate- 77 measurement problem statement for test protocols to measure IP 78 Performance Metrics (IPPM). 80 When selecting a form of access to the Internet, subscribers are 81 interested in the performance characteristics of the various 82 alternatives. Standardized measurements can be a basis for 83 comparison between these alternatives. There is an underlying need 84 to coordinate measurements that support such comparisons, and test 85 control protocols to fulfill this need. The figure below depicts 86 some typical measurement points of access networks. 88 User ====== Fiber ======= Access Node \ 89 Device ----- Copper ------- Access Node -|--- Infrastructure --- GW 90 or Host ------ Radio ------- Access Node / 91 The access-rate scenario or use case has received wide-spread 92 attention of Internet access subscribers and seemingly all Internet 93 industry players, including regulators. This problem is being 94 approached with many different measurement methods. 96 2. Purpose and Scope 98 The scope and purpose of this memo is to define the measurement 99 problem statement for test protocols conducting access rate 100 measurement on production networks. Relevant test protocols include 101 [RFC4656] and [RFC5357], but the problem is stated in a general way 102 so that it can be addressed by any existing test protocol, such as 103 [RFC6812]. 105 This memo discusses possibilities for methods of measurement, but 106 does not specify exact methods which would normally be part of the 107 solution, not the problem. 109 We are interested in access measurement scenarios with the following 110 characteristics: 112 o The Access portion of the network is the focus of this problem 113 statement. The user typically subscribes to a service with bi- 114 directional access partly described by rates in bits per second. 115 The rates may be expressed as raw capacity or restricted capacity 116 as described in [RFC6703]. These are the quantities that must be 117 measured according to one or more standard metrics, and for which 118 measurement methods must also be agreed as a part of the solution. 120 o Referring to the reference path defined in 121 [I-D.morton-ippm-lmap-path], possible measurement points include a 122 Subscriber's host, the access service demarcation point, Intra IP 123 access where a globally routable address is present, or the 124 gateway between the measured access network and other networks. 126 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 127 device Net #1 Net #2 Demarc. Access GW GRA GW 129 GRA = Globally Routable Address, GW = Gateway 131 o Rates at some links near the edge of the provider's network can 132 often be several orders of magnitude less links in than 133 aggregation and core portions of the network. 135 o Asymmetrical access rates on ingress and egress are prevalent. 137 o Extremely large scale of access services requires low complexity 138 devices participating at the user end of the path. 140 This problem statement assumes that the most-likely bottleneck device 141 or link is adjacent to the remote (user-end) measurement device, or 142 is within one or two router/switch hops of the remote measurement 143 device. 145 Other use cases for rate measurement involve situations where the 146 packet switching and transport facilities are leased by one operator 147 from another and the link capacity available cannot be directly 148 determined (e.g., from device interface utilization). These 149 scenarios could include mobile backhaul, Ethernet Service access 150 networks, and/or extensions of layer 2 or layer 3 networks. The 151 results of rate measurements in such cases could be employed to 152 select alternate routing, investigate whether capacity meets some 153 previous agreement, and/or adapt the rate of traffic sources if a 154 capacity bottleneck is found via the rate measurement. In the case 155 of aggregated leased networks, available capacity may also be 156 asymmetric. In these cases, the tester is assumed to have a sender 157 and receiver location under their control. We refer to this scenario 158 below as the aggregated leased network case. 160 Support of active measurement methods will be addressed here, 161 consistent with the IPPM working group's traditional charter. Active 162 measurements require synthetic traffic dedicated to testing, and do 163 not make measurements on user traffic. 165 As noted in [RFC2330] the actual traffic handling may influence the 166 rate measurement results for some forms of access, as it may differ 167 between user and test traffic if the test traffic has different 168 characteristics, primarily in terms of the packets themselves (see 169 section 13 of [RFC2330] for the considerations on packet type, or 170 Type-P). 172 There are several aspects of Type-P where user traffic may be 173 examined and selected for special treatment that may affect 174 transmission rates. Without being exhaustive, the possibilities 175 include: 177 o Packet length 179 o IP addresses 181 o Transport protocol (where TCP packets may be routed differently 182 from UDP) 184 o Transport Protocol port numbers 185 This issue requires further discussion when specific solutions/ 186 methods of measurement are proposed, but for this problem statement 187 it is sufficient to identify the problem and indicate that the 188 solution may require an extremely close emulation of user traffic, in 189 terms of one or more factors above. 191 Although the user may have multiple instances of network access 192 available to them, the primary problem scope is to measure one form 193 of access at a time. It is plausible that a solution for the single 194 access problem will be applicable to simultaneous measurement of 195 multiple access instances, but treatment of this scenario is beyond 196 the current scope this document. 198 A key consideration is whether active measurements will be conducted 199 with user traffic present (In-Service testing), or not present (Out- 200 of-Service testing), such as during pre-service testing or 201 maintenance that interrupts service temporarily. Out-of-Service 202 testing includes activities described as "service commissioning", 203 "service activation", and "planned maintenance". Opportunistic In- 204 Service testing when there is no user traffic present throughout the 205 test interval is essentially equivalent to Out-of-Service testing. 206 Both In-Service and Out-of-Service testing are within the scope of 207 this problem. 209 It is a non-goal to solve the measurement protocol specification 210 problem in this memo. 212 It is a non-goal to standardize methods of measurement in this memo. 213 However, the problem statement will mandate support for one or more 214 categories of rate measurement methods in the test protocol and 215 adequate control features for the methods in the control protocol 216 (assuming the control and test protocols are separate). 218 3. Active Rate Measurement 220 This section lists features of active measurement methods needed to 221 measure access rates in production networks. 223 Coordination between source and destination devices through control 224 messages and other basic capabilities described in the methods of 225 IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as 226 [RFC5357] and [RFC4656], are taken as given. 228 Most forms of active testing intrude on user performance to some 229 degree. One key tenet of IPPM methods is to minimize test traffic 230 effects on user traffic in the production network. Section 5 of 231 [RFC2680] lists the problems with high measurement traffic rates, and 232 the most relevant for rate measurement is the tendency for 233 measurement traffic to skew the results, followed by the possibility 234 of introducing congestion on the access link. In-Service testing 235 MUST respect these traffic constraints. Obviously, categories of 236 rate measurement methods that use less active test traffic than 237 others with similar accuracy are preferred for In-Service testing. 239 On the other hand, Out-of-Service tests where the test path shares no 240 links with In-Service user traffic have none of the congestion or 241 skew concerns, but these tests must address other practical matters 242 such as conducting measurements within a reasonable time from the 243 tester's point of view. Out-of-Service tests where some part of the 244 test path is shared with In-Service traffic MUST respect the In- 245 Service constraints. 247 The **intended metrics to be measured** have strong influence over 248 the categories of measurement methods required. For example, using 249 the terminology of [RFC5136], a it may be possible to measure a Path 250 Capacity Metric while In-Service if the level of background (user) 251 traffic can be assessed and included in the reported result. 253 The measurement *architecture* MAY be either of one-way (e.g., 254 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 255 aspects of end-user or aggregated access measurement clearly favor 256 two-way (with low-complexity user-end device and round-trip results 257 collection, as found in [RFC5357]). However, the asymmetric rates of 258 many access services mean that the measurement system MUST be able to 259 evaluate performance in each direction of transmission. In the two- 260 way architecture, it is expected that both end devices MUST include 261 the ability to launch test streams and collect the results of 262 measurements in both (one-way) directions of transmission (this 263 requirement is consistent with previous protocol specifications, and 264 it is not a unique problem for rate measurements). 266 The following paragraphs describe features for the roles of test 267 packet SENDER, RECEIVER, and results REPORTER. 269 SENDER: 271 Generate streams of test packets with various characteristics as 272 desired (see Section 4). The SENDER may be located at the user end 273 of the access path, or may be located elsewhere in the production 274 network, such as at one end of an aggregated leased network segment. 276 RECEIVER: 278 Collect streams of test packets with various characteristics (as 279 described above), and make the measurements necessary to support rate 280 measurement at the receiving end of an access or aggregated leased 281 network segment. 283 REPORTER: 285 Use information from test packets and local processes to measure 286 delivered packet rates, and prepare results in the required format. 288 4. Measurement Method Categories 290 The design of rate measurement methods can be divided into two 291 phases: test stream design and measurement (SENDER and RECEIVER), and 292 a follow-up phase for analysis of the measurement to produce results 293 (REPORTER). The measurement protocol that addresses this problem 294 MUST only serve the test stream generation and measurement functions. 296 For the purposes of this problem statement, we categorize the many 297 possibilities for rate measurement stream generation as follows; 299 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 300 random time intervals between pairs in a test stream. 302 2. Multiple streams of packet pairs, with a range of intra-pair 303 spacing and inter-pair intervals. 305 3. One or more packet ensembles in a test stream, using a fixed 306 ensemble size in packets and one or more fixed intra-ensemble 307 packet spacings (including zero spacing, meaning that back-to- 308 back burst ensembles and constant rate ensembles fall in this 309 category). 311 4. One or more packet chirps, where intra-packet spacing typically 312 decreases between adjacent packets in the same chirp and each 313 pair of packets represents a rate for testing purposes. 315 For all categories, the test protocol MUST support: 317 a. Variable payload lengths among packet streams 319 b. Variable length (in packets) among packet streams or ensembles 321 c. Variable IP header markings among packet streams 323 d. Choice of UDP transport and variable port numbers, OR, choice of 324 TCP transport and variable port numbers for two-way architectures 325 only, OR BOTH. 327 e. Variable number of packets-pairs, ensembles, or streams used in a 328 test session 330 The items above are additional variables that the test protocol MUST 331 be able to identify and control. The ability to revise these 332 variables during an established test session is OPTIONAL, as multiple 333 test sessions could serve the same purpose. 335 The test protocol SHALL support test packet ensemble generation 336 (category 3), as this appears to minimize the demands on measurement 337 accuracy. Other stream generation categories are OPTIONAL. 339 For measurement systems employing TCP Transport protocol, the ability 340 to generate specific stream characteristics requires a sender with 341 the ability to establish and prime the connection such that the 342 desired stream characteristics are allowed. See Mathis' work in 343 progress for more background [I-D.mathis-ippm-model-based-metrics]. 345 >>>>>> 347 The general requirement statements needed to describe an "open-loop" 348 TCP sender require some additional discussion. It may be necessary 349 to defer specification of the details required to configure and 350 control a TCP SENDER for future work. 352 >>>>>> 354 It may also be useful to specify a control for Bulk Transfer Capacity 355 measurement with fully-specified TCP senders and receivers, as 356 envisioned in [RFC3148], but this would be a brute-force assessment 357 which does not follow the conservative tenets of IPPM measurement 358 [RFC2330]. 360 >>>>>> 362 Measurements for each UDP test packet transferred between SENDER and 363 RECEIVER MUST be compliant with the singleton measurement methods 364 described in IPPM RFCs [RFC2679][RFC2680] (these could be listed 365 later, if desired). The time-stamp information or loss/arrival 366 status for each packet MUST be available for communication to the 367 protocol entity that collects results. 369 5. Test Protocol Control & Generation Requirements 371 Essentially, the test protocol MUST support the measurement features 372 described in the sections above. This requires: 374 1. Communicating all test variables to the Sender and Receiver 375 2. Results collection in a one-way architecture 377 3. Remote device control for both one-way and two-way architectures 379 4. Asymmetric packet size and/or pseudo-one-way test capability in a 380 two-way measurement architecture (along with symmetric packet 381 size tests in common use) 383 The ability to control packet size on the tested path and enable 384 asymmetrical packet size testing in a two-way architecture are 385 REQUIRED. This allows both the conventional symmetric packet size 386 testing and asymmetrical packet size testing to employed to solve 387 various aspects of rate measurement: real-time communications often 388 have symmetrical streams, while file transfers have highly 389 asymmetrical streams in the data and acknowledgement traffic 390 directions. 392 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 393 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 394 metrics are OPTIONAL. 396 6. Security Considerations 398 The security considerations that apply to any active measurement of 399 live networks are relevant here as well. See [RFC4656] and 400 [RFC5357]. 402 There may be a serious issue if a proprietary Service Level Agreement 403 involved with the access network segment provider were somehow leaked 404 in the process of rate measurement. To address this, test protocols 405 SHOULD NOT convey this information in a way that could be discovered 406 by unauthorized parties. 408 7. IANA Considerations 410 This memo makes no requests of IANA. 412 8. Acknowledgements 414 Dave McDysan provided comments and text for the aggregated leased use 415 case. Yaakov Stein suggested many considerations to address, 416 including the In-Service vs. Out-of-Service distinction and its 417 implication on test traffic limits and protocols. Bill Cerveny, 418 Marcelo Bagnulo, and Kostas Pentikousis have contributed insightful, 419 clarifying comments that made this a better draft. 421 9. References 422 9.1. Normative References 424 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 425 Specification, Implementation", RFC 1305, March 1992. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 431 "Framework for IP Performance Metrics", RFC 2330, May 432 1998. 434 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 435 Delay Metric for IPPM", RFC 2679, September 1999. 437 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 438 Packet Loss Metric for IPPM", RFC 2680, September 1999. 440 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 441 Zekauskas, "A One-way Active Measurement Protocol 442 (OWAMP)", RFC 4656, September 2006. 444 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 445 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 446 RFC 5357, October 2008. 448 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 449 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 450 August 2009. 452 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 453 Feature for the Two-Way Active Measurement Protocol 454 (TWAMP)", RFC 5938, August 2010. 456 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 457 Protocol (TWAMP) Reflect Octets and Symmetrical Size 458 Features", RFC 6038, October 2010. 460 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 461 IP Network Performance Metrics: Different Points of View", 462 RFC 6703, August 2012. 464 9.2. Informative References 466 [I-D.mathis-ippm-model-based-metrics] 467 Mathis, M. and A. Morton, "Model Based Internet 468 Performance Metrics", draft-mathis-ippm-model-based- 469 metrics-01 (work in progress), February 2013. 471 [I-D.morton-ippm-lmap-path] 472 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 473 A. Morton, "A Reference Path and Measurement Points for 474 LMAP", draft-morton-ippm-lmap-path-01 (work in progress), 475 February 2013. 477 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 478 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 479 2001. 481 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 482 RFC 5136, February 2008. 484 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 485 S., and E. Yedavalli, "Cisco Service-Level Assurance 486 Protocol", RFC 6812, January 2013. 488 Author's Address 490 Al Morton 491 AT&T Labs 492 200 Laurel Avenue South 493 Middletown,, NJ 07748 494 USA 496 Phone: +1 732 420 1571 497 Fax: +1 732 368 1192 498 Email: acmorton@att.com 499 URI: http://home.comcast.net/~acmacm/