idnits 2.17.1 draft-ietf-ippm-rate-problem-04.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 (September 19, 2013) is 3872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1305' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC5618' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC5938' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC6038' is defined on line 467, 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 (-07) exists of draft-ietf-ippm-lmap-path-00 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-model-based-metrics-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 September 19, 2013 5 Expires: March 23, 2014 7 Rate Measurement Test Protocol Problem Statement 8 draft-ietf-ippm-rate-problem-04 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 March 23, 2014. 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 . . . . . . . . . . . . . . . . . . . 6 63 4. Measurement Method Categories . . . . . . . . . . . . . . . . 7 64 5. Test Protocol Control & Generation Requirements . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 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 / 92 The access-rate scenario or use case has received wide-spread 93 attention of Internet access subscribers and seemingly all Internet 94 industry players, including regulators. This problem is being 95 approached with many different measurement methods. 97 2. Purpose and Scope 99 The scope and purpose of this memo is to define the measurement 100 problem statement for test protocols conducting access rate 101 measurement on production networks. Relevant test protocols include 102 [RFC4656] and [RFC5357], but the problem is stated in a general way 103 so that it can be addressed by any existing test protocol, such as 104 [RFC6812]. 106 This memo discusses possibilities for methods of measurement, but 107 does not specify exact methods which would normally be part of the 108 solution, not the problem. 110 We are interested in access measurement scenarios with the following 111 characteristics: 113 o The Access portion of the network is the focus of this problem 114 statement. The user typically subscribes to a service with bi- 115 directional access partly described by rates in bits per second. 116 The rates may be expressed as raw capacity or restricted capacity 117 as described in [RFC6703]. These are the quantities that must be 118 measured according to one or more standard metrics, and for which 119 measurement methods must also be agreed as a part of the solution. 121 o Referring to the reference path illustrated below and defined in 122 [I-D.ietf-ippm-lmap-path], possible measurement points include a 123 Subscriber's host, the access service demarcation point, Intra IP 124 access where a globally routable address is present, or the 125 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 128 GRA = Globally Routable Address, GW = Gateway 130 o Rates at some links near the edge of the provider's network can 131 often be several orders of magnitude less than link rates in the 132 aggregation and core portions of the network. 134 o Asymmetrical access rates on ingress and egress are prevalent. 136 o Extremely large scale of access services requires low complexity 137 devices participating at the user end of the path. 139 This problem statement assumes that the most-likely bottleneck device 140 or link is adjacent to the remote (user-end) measurement device, or 141 is within one or two router/switch hops of the remote measurement 142 device. 144 Other use cases for rate measurement involve situations where the 145 packet switching and transport facilities are leased by one operator 146 from another and the link capacity available cannot be directly 147 determined (e.g., from device interface utilization). These 148 scenarios could include mobile backhaul, Ethernet Service access 149 networks, and/or extensions of layer 2 or layer 3 networks. The 150 results of rate measurements in such cases could be employed to 151 select alternate routing, investigate whether capacity meets some 152 previous agreement, and/or adapt the rate of traffic sources if a 153 capacity bottleneck is found via the rate measurement. In the case 154 of aggregated leased networks, available capacity may also be 155 asymmetric. In these cases, the tester is assumed to have a sender 156 and receiver location under their control. We refer to this scenario 157 below as the aggregated leased network case. 159 Support of active measurement methods will be addressed here, 160 consistent with the IPPM working group's traditional charter. Active 161 measurements require synthetic traffic dedicated to testing, and do 162 not make measurements on user traffic. 164 As noted in [RFC2330] the actual traffic handling may influence the 165 rate measurement results for some forms of access, as it may differ 166 between user and test traffic if the test traffic has different 167 characteristics, primarily in terms of the packets themselves (see 168 section 13 of [RFC2330] for the considerations on packet type, or 169 Type-P). 171 There are several aspects of Type-P where user traffic may be 172 examined and selected for special treatment that may affect 173 transmission rates. Without being exhaustive, the possibilities 174 include: 176 o Packet length 178 o IP addresses 180 o Transport protocol (e.g. where TCP packets may be routed 181 differently from UDP) 183 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, especially In-Service testing. One key tenet of IPPM methods 230 is to minimize test traffic effects on user traffic in the production 231 network. Section 5 of [RFC2680] lists the problems with high 232 measurement traffic rates, and the most relevant for rate measurement 233 is the tendency for measurement traffic to skew the results, followed 234 by the possibility of introducing congestion on the access link. In- 235 Service testing MUST respect these traffic constraints. Obviously, 236 categories of rate measurement methods that use less active test 237 traffic than others with similar accuracy are preferred for In- 238 Service testing. 240 On the other hand, Out-of-Service tests where the test path shares no 241 links with In-Service user traffic have none of the congestion or 242 skew concerns, but these tests must address other practical matters 243 such as conducting measurements within a reasonable time from the 244 tester's point of view. Out-of-Service tests where some part of the 245 test path is shared with In-Service traffic MUST respect the In- 246 Service constraints. 248 The **intended metrics to be measured** have strong influence over 249 the categories of measurement methods required. For example, using 250 the terminology of [RFC5136], a it may be possible to measure a Path 251 Capacity Metric while In-Service if the level of background (user) 252 traffic can be assessed and included in the reported result. 254 The measurement *architecture* MAY be either of one-way (e.g., 255 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 256 aspects of end-user or aggregated access measurement clearly favor 257 two-way (with low-complexity user-end device and round-trip results 258 collection, as found in [RFC5357]). However, the asymmetric rates of 259 many access services mean that the measurement system MUST be able to 260 evaluate performance in each direction of transmission. In the two- 261 way architecture, it is expected that both end devices MUST include 262 the ability to launch test streams and collect the results of 263 measurements in both (one-way) directions of transmission (this 264 requirement is consistent with previous protocol specifications, and 265 it is not a unique problem for rate measurements). 267 The following paragraphs describe features for the roles of test 268 packet SENDER, RECEIVER, and results REPORTER. 270 SENDER: 272 Generate streams of test packets with various characteristics as 273 desired (see Section 4). The SENDER MAY be located at the user end 274 of the access path or elsewhere in the production network, such as at 275 one end of an aggregated leased network segment. 277 RECEIVER: 279 Collect streams of test packets with various characteristics (as 280 described above), and make the measurements necessary to support rate 281 measurement at the receiving end of an access or aggregated leased 282 network segment. 284 REPORTER: 286 Use information from test packets and local processes to measure 287 delivered packet rates, and prepare results in the required format. 289 4. Measurement Method Categories 291 A protocol that addresses the rate measurement problem MUST serve the 292 test stream generation and measurement functions (SENDER and 293 RECEIVER). The follow-up phase of analyzing the measurement results 294 to produce a report is outside the scope of this problem and memo 295 (REPORTER). 297 For the purposes of this problem statement, we categorize the many 298 possibilities for rate measurement stream generation as follows; 300 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 301 random time intervals between pairs in a test stream. 303 2. Multiple streams of packet pairs, with a range of intra-pair 304 spacing and inter-pair intervals. 306 3. One or more packet ensembles in a test stream, using a fixed 307 ensemble size in packets and one or more fixed intra-ensemble 308 packet spacings (including zero spacing, meaning that back-to- 309 back burst ensembles and constant rate ensembles fall in this 310 category). 312 4. One or more packet chirps, where intra-packet spacing typically 313 decreases between adjacent packets in the same chirp and each 314 pair of packets represents a rate for testing purposes. 316 The test protocol SHALL support test packet ensemble generation 317 (category 3), as this appears to minimize the demands on measurement 318 accuracy. Other stream generation categories are OPTIONAL. 320 For all categories, the test protocol MUST support: 322 a. Variable payload lengths among packet streams 324 b. Variable length (in packets) among packet streams or ensembles 326 c. Variable IP header markings among packet streams 328 d. Choice of UDP transport and variable port numbers, OR, choice of 329 TCP transport and variable port numbers for two-way architectures 330 only, OR BOTH. 332 e. Variable number of packets-pairs, ensembles, or streams used in a 333 test session 335 The items above are additional variables that the test protocol MUST 336 be able to identify and control. The ability to revise these 337 variables during an established test session is OPTIONAL, as multiple 338 test sessions could serve the same purpose. 340 For measurement systems employing TCP as the transport protocol, the 341 ability to generate specific stream characteristics requires a sender 342 with the ability to establish and prime the connection such that the 343 desired stream characteristics are allowed. See Mathis' work in 344 progress for more background [I-D.ietf-ippm-model-based-metrics]. 346 Beyond simple connection handshake and options establishment, an 347 "open-loop" TCP sender requires the SENDER ability to: 349 o generate TCP packets with well-formed headers (all fields valid), 350 including Acknowledgement aspects. 352 o produce packet streams at controlled rates and variable inter- 353 packet spacings, including packet ensembles (back-to-back at 354 server rate). 356 o continue the configured sending stream characteristics despite all 357 control indications except receive window exhaust. 359 The corresponding TCP RECEIVER performs normally, having some ability 360 to configure the receive window sufficiently large so as to allow the 361 SENDER to transmit at will (up to a configured target). 363 It may also be useful to provide a control for Bulk Transfer Capacity 364 measurement with fully-specified (and congestion-controlled) TCP 365 senders and receivers, as envisioned in [RFC3148], but this would be 366 a brute-force assessment which does not follow the conservative 367 tenets of IPPM measurement [RFC2330]. 369 Measurements for each UDP test packet transferred between SENDER and 370 RECEIVER MUST be compliant with the singleton measurement methods 371 described in IPPM RFCs [RFC2679][RFC2680] (these could be listed 372 later, if desired). The time-stamp information or loss/arrival 373 status for each packet MUST be available for communication to the 374 protocol entity that collects results. 376 5. Test Protocol Control & Generation Requirements 378 Essentially, the test protocol MUST support the measurement features 379 described in the sections above. This requires: 381 1. Communicating all test variables to the SENDER and RECEIVER 383 2. Results collection in a one-way architecture 385 3. Remote device control for both one-way and two-way architectures 387 4. Asymmetric packet size and/or pseudo-one-way test capability in a 388 two-way measurement architecture (along with symmetric packet 389 size tests in common use) 391 The ability to control packet size on the tested path and enable 392 asymmetrical packet size testing in a two-way architecture are 393 REQUIRED. This allows both the conventional symmetric packet size 394 testing and asymmetrical packet size testing to employed to solve 395 various aspects of rate measurement: real-time communications often 396 have symmetrical streams, while file transfers have highly 397 asymmetrical streams in the data and acknowledgement traffic 398 directions. 400 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 401 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 402 metrics are OPTIONAL. 404 6. Security Considerations 406 The security considerations that apply to any active measurement of 407 live networks are relevant here as well. See [RFC4656] and 408 [RFC5357]. 410 There may be a serious issue if a proprietary Service Level Agreement 411 involved with the access network segment provider were somehow leaked 412 in the process of rate measurement. To address this, test protocols 413 SHOULD NOT convey this information in a way that could be discovered 414 by unauthorized parties. 416 7. IANA Considerations 418 This memo makes no requests of IANA. 420 8. Acknowledgements 422 Dave McDysan provided comments and text for the aggregated leased use 423 case. Yaakov Stein suggested many considerations to address, 424 including the In-Service vs. Out-of-Service distinction and its 425 implication on test traffic limits and protocols. Bill Cerveny, 426 Marcelo Bagnulo, and Kostas Pentikousis (a persistent reviewer) have 427 contributed insightful, clarifying comments that made this a better 428 draft. 430 9. References 432 9.1. Normative References 434 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 435 Specification, Implementation", RFC 1305, March 1992. 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 441 "Framework for IP Performance Metrics", RFC 2330, 442 May 1998. 444 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 445 Delay Metric for IPPM", RFC 2679, September 1999. 447 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 448 Packet Loss Metric for IPPM", RFC 2680, September 1999. 450 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 451 Zekauskas, "A One-way Active Measurement Protocol 452 (OWAMP)", RFC 4656, September 2006. 454 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 456 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 457 RFC 5357, October 2008. 459 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 460 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 461 August 2009. 463 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 464 Feature for the Two-Way Active Measurement Protocol 465 (TWAMP)", RFC 5938, August 2010. 467 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 468 Protocol (TWAMP) Reflect Octets and Symmetrical Size 469 Features", RFC 6038, October 2010. 471 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 472 IP Network Performance Metrics: Different Points of View", 473 RFC 6703, August 2012. 475 9.2. Informative References 477 [I-D.ietf-ippm-lmap-path] 478 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 479 A. Morton, "A Reference Path and Measurement Points for 480 LMAP", draft-ietf-ippm-lmap-path-00 (work in progress), 481 July 2013. 483 [I-D.ietf-ippm-model-based-metrics] 484 Mathis, M. and A. Morton, "Model Based Bulk Performance 485 Metrics", draft-ietf-ippm-model-based-metrics-00 (work in 486 progress), June 2013. 488 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 489 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 490 July 2001. 492 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 493 RFC 5136, February 2008. 495 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 496 S., and E. Yedavalli, "Cisco Service-Level Assurance 497 Protocol", RFC 6812, January 2013. 499 Author's Address 501 Al Morton 502 AT&T Labs 503 200 Laurel Avenue South 504 Middletown,, NJ 07748 505 USA 507 Phone: +1 732 420 1571 508 Fax: +1 732 368 1192 509 Email: acmorton@att.com 510 URI: http://home.comcast.net/~acmacm/