idnits 2.17.1 draft-ietf-ippm-rate-problem-08.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 (November 24, 2014) is 3440 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) == Outdated reference: A later version (-13) exists of draft-ietf-ippm-model-based-metrics-03 Summary: 2 errors (**), 0 flaws (~~), 2 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 November 24, 2014 5 Expires: May 28, 2015 7 Rate Measurement Test Protocol Problem Statement 8 draft-ietf-ippm-rate-problem-08 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 May 28, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 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. 127 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 128 device Net #1 Net #2 Demarc. Access GW GRA GW 130 GRA = Globally Routable Address, GW = Gateway 132 o Rates at some links near the edge of the provider's network can 133 often be several orders of magnitude less than link rates in the 134 aggregation and core portions of the network. 136 o Asymmetrical access rates on ingress and egress are prevalent. 138 o In many scenarios of interest, extremely large scale of access 139 services requires low complexity devices participating at the user 140 end of the path, and those devices place limits on clock and 141 control timing accuracy. 143 This problem statement assumes that the most-likely bottleneck device 144 or link is adjacent to the remote (user-end) measurement device, or 145 is within one or two router/switch hops of the remote measurement 146 device. 148 Other use cases for rate measurement involve situations where the 149 packet switching and transport facilities are leased by one operator 150 from another and the link capacity available cannot be directly 151 determined (e.g., from device interface utilization). These 152 scenarios could include mobile backhaul, Ethernet Service access 153 networks, and/or extensions of layer 2 or layer 3 networks. The 154 results of rate measurements in such cases could be employed to 155 select alternate routing, investigate whether capacity meets some 156 previous agreement, and/or adapt the rate of traffic sources if a 157 capacity bottleneck is found via the rate measurement. In the case 158 of aggregated leased networks, available capacity may also be 159 asymmetric. In these cases, the tester is assumed to have a sender 160 and receiver location under their control. We refer to this scenario 161 below as the aggregated leased network case. 163 Support of active measurement methods will be addressed here, 164 consistent with the IPPM working group's traditional charter. Active 165 measurements require synthetic traffic streams dedicated to testing, 166 and do not make measurements on user traffic. See section 2 of 167 [RFC2679], where the concept of a stream is first introduced in IPPM 168 literature as the basis for collecting a sample (defined in section 169 11 of [RFC2330]). 171 As noted in [RFC2330] the focus of access traffic management may 172 influence the rate measurement results for some forms of access, as 173 it may differ between user and test traffic if the test traffic has 174 different characteristics, primarily in terms of the packets 175 themselves (see section 13 of [RFC2330] for the considerations on 176 packet type, or Type-P). 178 There are several aspects of Type-P where user traffic may be 179 examined and selected for special treatment that may affect 180 transmission rates. Without being exhaustive, the possibilities 181 include: 183 o Packet length 185 o IP addresses 187 o Transport protocol (e.g. where TCP packets may be routed 188 differently from UDP) 190 o Transport Protocol port numbers 191 This issue requires further discussion when specific solutions/ 192 methods of measurement are proposed, but for this problem statement 193 it is sufficient to identify the problem and indicate that the 194 solution may require an extremely close emulation of user traffic, in 195 terms of one or more factors above. 197 Although the user may have multiple instances of network access 198 available to them, the primary problem scope is to measure one form 199 of access at a time. It is plausible that a solution for the single 200 access problem will be applicable to simultaneous measurement of 201 multiple access instances, but treatment of this scenario is beyond 202 the current scope this document. 204 A key consideration is whether active measurements will be conducted 205 with user traffic present (In-Service testing), or not present (Out- 206 of-Service testing), such as during pre-service testing or 207 maintenance that interrupts service temporarily. Out-of-Service 208 testing includes activities described as "service commissioning", 209 "service activation", and "planned maintenance". Opportunistic In- 210 Service testing when there is no user traffic present (e.g., outside 211 normal business hours) throughout the test interval is essentially 212 equivalent to Out-of-Service testing. Both In-Service and Out-of- 213 Service testing are within the scope of this problem. 215 It is a non-goal to solve the measurement protocol specification 216 problem in this memo. 218 It is a non-goal to standardize methods of measurement in this memo. 219 However, the problem statement will mandate support for one or more 220 categories of rate measurement methods in the test protocol and 221 adequate control features for the methods in the control protocol 222 (assuming the control and test protocols are separate). 224 3. Active Rate Measurement 226 This section lists features of active measurement methods needed to 227 measure access rates in production networks. 229 Coordination between source and destination devices through control 230 messages and other basic capabilities described in the methods of 231 IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as 232 [RFC5357] and [RFC4656], are taken as given. 234 Most forms of active testing intrude on user performance to some 235 degree, especially In-Service testing. One key tenet of IPPM methods 236 is to minimize test traffic effects on user traffic in the production 237 network. Section 5 of [RFC2680] lists the problems with high 238 measurement traffic rates, and the most relevant for rate measurement 239 is the tendency for measurement traffic to skew the results, followed 240 by the possibility of introducing congestion on the access link. In- 241 Service testing MUST respect these traffic constraints. Obviously, 242 categories of rate measurement methods that use less active test 243 traffic than others with similar accuracy are preferred for In- 244 Service testing. 246 On the other hand, Out-of-Service tests where the test path shares no 247 links with In-Service user traffic have none of the congestion or 248 skew concerns, but these tests must address other practical matters 249 such as conducting measurements within a reasonable time from the 250 tester's point of view. Out-of-Service tests where some part of the 251 test path is shared with In-Service traffic MUST respect the In- 252 Service constraints. 254 The intended metrics to be measured have strong influence over the 255 categories of measurement methods required. For example, using the 256 terminology of [RFC5136], it may be possible to measure a Path 257 Capacity Metric while In-Service if the level of background (user) 258 traffic can be assessed and included in the reported result. 260 The measurement *architecture* MAY be either of one-way (e.g., 261 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 262 aspects of end-user or aggregated access measurement clearly favor 263 two-way (with low-complexity user-end device and round-trip results 264 collection, as found in [RFC5357]). However, the asymmetric rates of 265 many access services mean that the measurement system MUST be able to 266 evaluate performance in each direction of transmission. In the two- 267 way architecture, it is expected that both end devices MUST include 268 the ability to launch test streams and collect the results of 269 measurements in both (one-way) directions of transmission (this 270 requirement is consistent with previous protocol specifications, and 271 it is not a unique problem for rate measurements). 273 The following paragraphs describe features for the roles of test 274 packet SENDER, RECEIVER, and results REPORTER. 276 SENDER: 278 Generate streams of test packets with various characteristics as 279 desired (see Section 4). The SENDER MAY be located at the user end 280 of the access path or elsewhere in the production network, such as at 281 one end of an aggregated leased network segment. 283 RECEIVER: 285 Collect streams of test packets with various characteristics (as 286 described above), and make the measurements necessary to support rate 287 measurement at the receiving end of an access or aggregated leased 288 network segment. 290 REPORTER: 292 Use information from test packets and local processes to measure 293 delivered packet rates, and prepare results in the required format 294 (the REPORTER role may be combined with another role, most likely the 295 SENDER). 297 4. Measurement Method Categories 299 A protocol that addresses the rate measurement problem MUST serve the 300 test stream generation and measurement functions (SENDER and 301 RECEIVER). The follow-up phase of analyzing the measurement results 302 to produce a report is outside the scope of this problem and memo 303 (REPORTER). 305 For the purposes of this problem statement, we categorize the many 306 possibilities for rate measurement stream generation as follows; 308 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 309 random time intervals between pairs in a test stream. 311 2. Multiple streams of packet pairs, with a range of intra-pair 312 spacing and inter-pair intervals. 314 3. One or more packet ensembles in a test stream, using a fixed 315 ensemble size in packets and one or more fixed intra-ensemble 316 packet spacings (including zero spacing, meaning that back-to- 317 back burst ensembles and constant rate ensembles fall in this 318 category). 320 4. One or more packet chirps (a set of packets with specified 321 characteristics), where intra-packet spacing typically decreases 322 between adjacent packets in the same chirp and each pair of 323 packets represents a rate for testing purposes. 325 The test protocol SHALL support test packet ensemble generation 326 (category 3), as this appears to minimize the demands on measurement 327 accuracy. Other stream generation categories are OPTIONAL. 329 For all categories, the test protocol MUST support: 331 a. Variable payload lengths among packet streams 333 b. Variable length (in packets) among packet streams or ensembles 334 c. Variable IP header markings among packet streams 336 d. Choice of UDP transport and variable port numbers, OR, choice of 337 TCP transport and variable port numbers for two-way architectures 338 only, OR BOTH. See below for additional requirements on TCP 339 transport generation. 341 e. Variable number of packets-pairs, ensembles, or streams used in a 342 test session. 344 The items above are additional variables that the test protocol MUST 345 be able to identify and control. The ability to revise these 346 variables during an established test session is OPTIONAL, as multiple 347 test sessions could serve the same purpose. Another OPTIONAL feature 348 is the ability to generate streams with VLAN tags and other markings. 350 For measurement systems employing TCP as the transport protocol, the 351 ability to generate specific stream characteristics requires a sender 352 with the ability to establish and prime the connection such that the 353 desired stream characteristics are allowed. See Mathis' work in 354 progress for more background [I-D.ietf-ippm-model-based-metrics]. 356 Beyond simple connection handshake and options establishment, an 357 "open-loop" TCP sender requires the SENDER ability to: 359 o generate TCP packets with well-formed headers (all fields valid), 360 including Acknowledgement aspects. 362 o produce packet streams at controlled rates and variable inter- 363 packet spacings, including packet ensembles (back-to-back at 364 server rate). 366 o continue the configured sending stream characteristics despite all 367 control indications except receive window exhaust. 369 The corresponding TCP RECEIVER performs normally, having some ability 370 to configure the receive window sufficiently large so as to allow the 371 SENDER to transmit at will (up to a configured target). 373 It may also be useful to provide a control for Bulk Transfer Capacity 374 measurement with fully-specified (and congestion-controlled) TCP 375 senders and receivers, as envisioned in [RFC3148], but this would be 376 a brute-force assessment which does not follow the conservative 377 tenets of IPPM measurement [RFC2330]. 379 Measurements for each UDP test packet transferred between SENDER and 380 RECEIVER MUST be compliant with the singleton measurement methods 381 described in IPPM RFCs [RFC2679][RFC2680] (these could be listed 382 later, if desired). The time-stamp information or loss/arrival 383 status for each packet MUST be available for communication to the 384 protocol entity that collects results. 386 5. Test Protocol Control & Generation Requirements 388 Essentially, the test protocol MUST support the measurement features 389 described in the sections above. This requires: 391 1. Communicating all test variables to the SENDER and RECEIVER 393 2. Results collection in a one-way architecture 395 3. Remote device control for both one-way and two-way architectures 397 4. Asymmetric packet size and/or coordinated one-way test 398 capabilities in a two-way measurement architecture (along with 399 symmetric packet size tests in common use) 401 The ability to control and generate asymmetric rates in a two-way 402 architecture is REQUIRED. Two-way architectures are RECOMMENDED to 403 include control and generation capability for both asymmetric and 404 symmetric packet sizes, because packet size often matters in the 405 scope of this problem and test systems SHOULD be equipped to detect 406 directional size dependency through comparative measurements. 408 Asymmetric packet size control is indicated when the result of a 409 measurement may depend on the size of the packets used in each 410 direction, i.e. when any of the following conditions hold: 412 o there is a link in the path with asymmetrical capacity in opposite 413 directions (in combination with one or more of the conditions 414 below, but their presence or specific details may be unknown to 415 the tester), 417 o there is a link in the path which aggregates (or divides) packets 418 into link-level frames, and may have a capacity that depends on 419 packet size, rate, or timing, 421 o there is a link in the path where transmission in one direction 422 influences performance in the opposite direction, 424 o there is a device in the path where transmission capacity depends 425 on packet header processing capacity (in other words, the capacity 426 is sensitive to packet size), 428 o the target application stream is nominally MTU size packets in one 429 direction vs. ACK stream in the other, (noting that there are a 430 vanishing number of symmetrical-rate application streams for which 431 rate measurement is wanted or interesting), 433 o the distribution of packet losses is critical to rate assessment, 435 and possibly other circumstances revealed by measurements comparing 436 streams with symmetrical size and asymmetrical size. 438 Implementations may support control and generation for only symmetric 439 packet sizes when none of the above conditions hold. 441 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 442 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 443 metrics are OPTIONAL. 445 6. Security Considerations 447 The security considerations that apply to any active measurement of 448 live networks are relevant here as well. See [RFC4656] and 449 [RFC5357]. 451 There may be a serious issue if a proprietary Service Level Agreement 452 involved with the access network segment provider were somehow leaked 453 in the process of rate measurement. To address this, test protocols 454 SHOULD NOT convey this information in a way that could be discovered 455 by unauthorized parties. 457 7. IANA Considerations 459 This memo makes no requests of IANA. 461 8. Acknowledgements 463 Dave McDysan provided comments and text for the aggregated leased use 464 case. Yaakov Stein suggested many considerations to address, 465 including the In-Service vs. Out-of-Service distinction and its 466 implication on test traffic limits and protocols. Bill Cerveny, 467 Marcelo Bagnulo, and Kostas Pentikousis (a persistent reviewer) have 468 contributed insightful, clarifying comments that made this a better 469 draft. Barry Constantine also provided suggestions for 470 clarification. 472 9. References 473 9.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 479 "Framework for IP Performance Metrics", RFC 2330, May 480 1998. 482 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 483 Delay Metric for IPPM", RFC 2679, September 1999. 485 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 486 Packet Loss Metric for IPPM", RFC 2680, September 1999. 488 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 489 Zekauskas, "A One-way Active Measurement Protocol 490 (OWAMP)", RFC 4656, September 2006. 492 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 493 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 494 RFC 5357, October 2008. 496 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 497 IP Network Performance Metrics: Different Points of View", 498 RFC 6703, August 2012. 500 9.2. Informative References 502 [I-D.ietf-ippm-lmap-path] 503 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 504 A. Morton, "A Reference Path and Measurement Points for 505 Large-Scale Measurement of Broadband Performance", draft- 506 ietf-ippm-lmap-path-07 (work in progress), October 2014. 508 [I-D.ietf-ippm-model-based-metrics] 509 Mathis, M. and A. Morton, "Model Based Bulk Performance 510 Metrics", draft-ietf-ippm-model-based-metrics-03 (work in 511 progress), July 2014. 513 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 514 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 515 2001. 517 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 518 RFC 5136, February 2008. 520 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 521 S., and E. Yedavalli, "Cisco Service-Level Assurance 522 Protocol", RFC 6812, January 2013. 524 Author's Address 526 Al Morton 527 AT&T Labs 528 200 Laurel Avenue South 529 Middletown,, NJ 07748 530 USA 532 Phone: +1 732 420 1571 533 Fax: +1 732 368 1192 534 Email: acmorton@att.com 535 URI: http://home.comcast.net/~acmacm/