idnits 2.17.1 draft-ietf-ippm-rate-problem-05.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 (December 12, 2013) is 3787 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1305' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC5618' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC5938' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC6038' is defined on line 472, 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-01 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-model-based-metrics-01 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 December 12, 2013 5 Expires: June 15, 2014 7 Rate Measurement Test Protocol Problem Statement 8 draft-ietf-ippm-rate-problem-05 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 June 15, 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 In many scenarios of interest, extremely large scale of access 137 services requires low complexity devices participating at the user 138 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 focus of access traffic management may 166 influence the rate measurement results for some forms of access, as 167 it may differ between user and test traffic if the test traffic has 168 different characteristics, primarily in terms of the packets 169 themselves (see section 13 of [RFC2330] for the considerations on 170 packet type, or 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 (e.g. where TCP packets may be routed 182 differently from UDP) 184 o Transport Protocol port numbers 186 This issue requires further discussion when specific solutions/ 187 methods of measurement are proposed, but for this problem statement 188 it is sufficient to identify the problem and indicate that the 189 solution may require an extremely close emulation of user traffic, in 190 terms of one or more factors above. 192 Although the user may have multiple instances of network access 193 available to them, the primary problem scope is to measure one form 194 of access at a time. It is plausible that a solution for the single 195 access problem will be applicable to simultaneous measurement of 196 multiple access instances, but treatment of this scenario is beyond 197 the current scope this document. 199 A key consideration is whether active measurements will be conducted 200 with user traffic present (In-Service testing), or not present (Out- 201 of-Service testing), such as during pre-service testing or 202 maintenance that interrupts service temporarily. Out-of-Service 203 testing includes activities described as "service commissioning", 204 "service activation", and "planned maintenance". Opportunistic In- 205 Service testing when there is no user traffic present (e.g., outside 206 normal business hours) throughout the test interval is essentially 207 equivalent to Out-of-Service testing. Both In-Service and Out-of- 208 Service testing are within the scope of this problem. 210 It is a non-goal to solve the measurement protocol specification 211 problem in this memo. 213 It is a non-goal to standardize methods of measurement in this memo. 214 However, the problem statement will mandate support for one or more 215 categories of rate measurement methods in the test protocol and 216 adequate control features for the methods in the control protocol 217 (assuming the control and test protocols are separate). 219 3. Active Rate Measurement 221 This section lists features of active measurement methods needed to 222 measure access rates in production networks. 224 Coordination between source and destination devices through control 225 messages and other basic capabilities described in the methods of 226 IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as 227 [RFC5357] and [RFC4656], are taken as given. 229 Most forms of active testing intrude on user performance to some 230 degree, especially In-Service testing. One key tenet of IPPM methods 231 is to minimize test traffic effects on user traffic in the production 232 network. Section 5 of [RFC2680] lists the problems with high 233 measurement traffic rates, and the most relevant for rate measurement 234 is the tendency for measurement traffic to skew the results, followed 235 by the possibility of introducing congestion on the access link. In- 236 Service testing MUST respect these traffic constraints. Obviously, 237 categories of rate measurement methods that use less active test 238 traffic than others with similar accuracy are preferred for In- 239 Service testing. 241 On the other hand, Out-of-Service tests where the test path shares no 242 links with In-Service user traffic have none of the congestion or 243 skew concerns, but these tests must address other practical matters 244 such as conducting measurements within a reasonable time from the 245 tester's point of view. Out-of-Service tests where some part of the 246 test path is shared with In-Service traffic MUST respect the In- 247 Service constraints. 249 The **intended metrics to be measured** have strong influence over 250 the categories of measurement methods required. For example, using 251 the terminology of [RFC5136], a it may be possible to measure a Path 252 Capacity Metric while In-Service if the level of background (user) 253 traffic can be assessed and included in the reported result. 255 The measurement *architecture* MAY be either of one-way (e.g., 256 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 257 aspects of end-user or aggregated access measurement clearly favor 258 two-way (with low-complexity user-end device and round-trip results 259 collection, as found in [RFC5357]). However, the asymmetric rates of 260 many access services mean that the measurement system MUST be able to 261 evaluate performance in each direction of transmission. In the two- 262 way architecture, it is expected that both end devices MUST include 263 the ability to launch test streams and collect the results of 264 measurements in both (one-way) directions of transmission (this 265 requirement is consistent with previous protocol specifications, and 266 it is not a unique problem for rate measurements). 268 The following paragraphs describe features for the roles of test 269 packet SENDER, RECEIVER, and results REPORTER. 271 SENDER: 273 Generate streams of test packets with various characteristics as 274 desired (see Section 4). The SENDER MAY be located at the user end 275 of the access path or elsewhere in the production network, such as at 276 one end of an aggregated leased network segment. 278 RECEIVER: 280 Collect streams of test packets with various characteristics (as 281 described above), and make the measurements necessary to support rate 282 measurement at the receiving end of an access or aggregated leased 283 network segment. 285 REPORTER: 287 Use information from test packets and local processes to measure 288 delivered packet rates, and prepare results in the required format 289 (the REPORTER role may be combined with another role, most likely the 290 SENDER). 292 4. Measurement Method Categories 294 A protocol that addresses the rate measurement problem MUST serve the 295 test stream generation and measurement functions (SENDER and 296 RECEIVER). The follow-up phase of analyzing the measurement results 297 to produce a report is outside the scope of this problem and memo 298 (REPORTER). 300 For the purposes of this problem statement, we categorize the many 301 possibilities for rate measurement stream generation as follows; 303 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 304 random time intervals between pairs in a test stream. 306 2. Multiple streams of packet pairs, with a range of intra-pair 307 spacing and inter-pair intervals. 309 3. One or more packet ensembles in a test stream, using a fixed 310 ensemble size in packets and one or more fixed intra-ensemble 311 packet spacings (including zero spacing, meaning that back-to- 312 back burst ensembles and constant rate ensembles fall in this 313 category). 315 4. One or more packet chirps, where intra-packet spacing typically 316 decreases between adjacent packets in the same chirp and each 317 pair of packets represents a rate for testing purposes. 319 The test protocol SHALL support test packet ensemble generation 320 (category 3), as this appears to minimize the demands on measurement 321 accuracy. Other stream generation categories are OPTIONAL. 323 For all categories, the test protocol MUST support: 325 a. Variable payload lengths among packet streams 327 b. Variable length (in packets) among packet streams or ensembles 329 c. Variable IP header markings among packet streams 331 d. Choice of UDP transport and variable port numbers, OR, choice of 332 TCP transport and variable port numbers for two-way architectures 333 only, OR BOTH. See below for additional requirements on TCP 334 transport generation. 336 e. Variable number of packets-pairs, ensembles, or streams used in a 337 test session. 339 The items above are additional variables that the test protocol MUST 340 be able to identify and control. The ability to revise these 341 variables during an established test session is OPTIONAL, as multiple 342 test sessions could serve the same purpose. Another OPTIONAL feature 343 is the ability to generate streams with VLAN tags and other markings. 345 For measurement systems employing TCP as the transport protocol, the 346 ability to generate specific stream characteristics requires a sender 347 with the ability to establish and prime the connection such that the 348 desired stream characteristics are allowed. See Mathis' work in 349 progress for more background [I-D.ietf-ippm-model-based-metrics]. 351 Beyond simple connection handshake and options establishment, an 352 "open-loop" TCP sender requires the SENDER ability to: 354 o generate TCP packets with well-formed headers (all fields valid), 355 including Acknowledgement aspects. 357 o produce packet streams at controlled rates and variable inter- 358 packet spacings, including packet ensembles (back-to-back at 359 server rate). 361 o continue the configured sending stream characteristics despite all 362 control indications except receive window exhaust. 364 The corresponding TCP RECEIVER performs normally, having some ability 365 to configure the receive window sufficiently large so as to allow the 366 SENDER to transmit at will (up to a configured target). 368 It may also be useful to provide a control for Bulk Transfer Capacity 369 measurement with fully-specified (and congestion-controlled) TCP 370 senders and receivers, as envisioned in [RFC3148], but this would be 371 a brute-force assessment which does not follow the conservative 372 tenets of IPPM measurement [RFC2330]. 374 Measurements for each UDP test packet transferred between SENDER and 375 RECEIVER MUST be compliant with the singleton measurement methods 376 described in IPPM RFCs [RFC2679][RFC2680] (these could be listed 377 later, if desired). The time-stamp information or loss/arrival 378 status for each packet MUST be available for communication to the 379 protocol entity that collects results. 381 5. Test Protocol Control & Generation Requirements 383 Essentially, the test protocol MUST support the measurement features 384 described in the sections above. This requires: 386 1. Communicating all test variables to the SENDER and RECEIVER 388 2. Results collection in a one-way architecture 390 3. Remote device control for both one-way and two-way architectures 392 4. Asymmetric packet size and/or pseudo-one-way test capability in a 393 two-way measurement architecture (along with symmetric packet 394 size tests in common use) 396 The ability to control packet size on the tested path and enable 397 asymmetrical packet size testing in a two-way architecture are 398 REQUIRED. This allows both the conventional symmetric packet size 399 testing and asymmetrical packet size testing to employed to solve 400 various aspects of rate measurement: real-time communications often 401 have symmetrical streams, while file transfers have highly 402 asymmetrical streams in the data and acknowledgement traffic 403 directions. 405 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 406 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 407 metrics are OPTIONAL. 409 6. Security Considerations 411 The security considerations that apply to any active measurement of 412 live networks are relevant here as well. See [RFC4656] and 413 [RFC5357]. 415 There may be a serious issue if a proprietary Service Level Agreement 416 involved with the access network segment provider were somehow leaked 417 in the process of rate measurement. To address this, test protocols 418 SHOULD NOT convey this information in a way that could be discovered 419 by unauthorized parties. 421 7. IANA Considerations 423 This memo makes no requests of IANA. 425 8. Acknowledgements 427 Dave McDysan provided comments and text for the aggregated leased use 428 case. Yaakov Stein suggested many considerations to address, 429 including the In-Service vs. Out-of-Service distinction and its 430 implication on test traffic limits and protocols. Bill Cerveny, 431 Marcelo Bagnulo, and Kostas Pentikousis (a persistent reviewer) have 432 contributed insightful, clarifying comments that made this a better 433 draft. Barry Constantine also provided suggestions for 434 clarification. 436 9. References 438 9.1. Normative References 440 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 441 Specification, Implementation", RFC 1305, March 1992. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 447 "Framework for IP Performance Metrics", RFC 2330, 448 May 1998. 450 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 451 Delay Metric for IPPM", RFC 2679, September 1999. 453 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 454 Packet Loss Metric for IPPM", RFC 2680, September 1999. 456 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 457 Zekauskas, "A One-way Active Measurement Protocol 458 (OWAMP)", RFC 4656, September 2006. 460 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 461 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 462 RFC 5357, October 2008. 464 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 465 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 466 August 2009. 468 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 469 Feature for the Two-Way Active Measurement Protocol 470 (TWAMP)", RFC 5938, August 2010. 472 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 473 Protocol (TWAMP) Reflect Octets and Symmetrical Size 474 Features", RFC 6038, October 2010. 476 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 477 IP Network Performance Metrics: Different Points of View", 478 RFC 6703, August 2012. 480 9.2. Informative References 482 [I-D.ietf-ippm-lmap-path] 483 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 484 A. Morton, "A Reference Path and Measurement Points for 485 LMAP", draft-ietf-ippm-lmap-path-01 (work in progress), 486 September 2013. 488 [I-D.ietf-ippm-model-based-metrics] 489 Mathis, M. and A. Morton, "Model Based Bulk Performance 490 Metrics", draft-ietf-ippm-model-based-metrics-01 (work in 491 progress), October 2013. 493 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 494 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 495 July 2001. 497 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 498 RFC 5136, February 2008. 500 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 501 S., and E. Yedavalli, "Cisco Service-Level Assurance 502 Protocol", RFC 6812, January 2013. 504 Author's Address 506 Al Morton 507 AT&T Labs 508 200 Laurel Avenue South 509 Middletown,, NJ 07748 510 USA 512 Phone: +1 732 420 1571 513 Fax: +1 732 368 1192 514 Email: acmorton@att.com 515 URI: http://home.comcast.net/~acmacm/