idnits 2.17.1 draft-morton-ippm-rate-problem-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 29, 2012) is 4411 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1305' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC5618' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC5938' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC6038' is defined on line 340, 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: Standards Track February 29, 2012 5 Expires: September 1, 2012 7 Rate Measurement Problem Statement 8 draft-morton-ippm-rate-problem-02 10 Abstract 12 There is a rate measurement scenario which has wide-spread attention 13 of users and seemingly all industry participants, including 14 regulators. This memo presents an access rate-measurement problem 15 statement for IP Performance Metrics. Key aspects require the 16 ability to control packet size on the tested path and enable 17 asymmetrical packet size testing in a controller-responder 18 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 September 1, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 4 63 4. Measurement Method Categories . . . . . . . . . . . . . . . . . 6 64 5. Test Protocol Control & Generation Requirements . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 IP Performance Metrics (IPPM). 79 The access-rate scenario or use case has wide-spread attention of 80 users and seemingly all industry participants, including regulators. 81 It is being approached with many different measurement methods. 83 2. Purpose and Scope 85 The scope and purpose of this memo is to define the measurement 86 problem statement for access rate measurement on production networks. 87 We characterize this scenario as follows: 89 o Rates at the edge of the network are several orders of magnitude 90 less than aggregation and core portions. 92 o Asymmetrical ingress and egress rates are prevalent. 94 o Extremely large scale of access services requires low complexity 95 devices participating at the user end of the path. 97 Today, the majority of widely deployed access services achieve rates 98 less than 100 Mbit/s, and this is the rate-regime for which a 99 solution is sought now. 101 This problem statement assumes that the most-likely bottleneck device 102 or link is adjacent to the remote (user-end) measurement device, or 103 is within one or two router/switch hops of the remote measurement 104 device. 106 Other use cases for rate measurement involve situations where the 107 packet switching and transport facilities are leased by one operator 108 from another and the actual capacity available cannot be directly 109 determined (e.g., from device interface utilization). These 110 scenarios could include mobile backhaul, Ethernet Service access 111 networks, and/or extensions of a layer 2 or layer 3 networks. The 112 results of rate measurements in such cases could be employed to 113 select alternate routing, investigate whether capacity meets some 114 previous agreement, and/or adapting the rate of certain traffic 115 sources if a capacity bottleneck is found via the rate measurement. 116 In the case of aggregated leased networks, available capacity may 117 also be asymmetric. In these cases, the tester is assumed to have a 118 sender and receiver location under their control. We refer to this 119 scenario below as the aggregated leased network case. 121 Only active measurement methods will be addressed here, consistent 122 with the IPPM working group's current charter. Active measurements 123 require synthetic traffic dedicated to testing, and do not use user 124 traffic. 126 A key consideration is whether active measurements will be conducted 127 with user traffic present (In-Service Testing), or not present (Out- 128 of-Service Testing), such as during pre-service testing or 129 maintenance that interrupts service temporarily. Out-of-Service 130 testing includes activities described as "service commissioning", 131 "service activation", and "planned maintenance". Both In-Service and 132 Out-of-Service Testing are within the scope of this problem. 134 It is a non-goal to solve the measurement protocol specification 135 problem in this memo. 137 It is a non-goal to standardize methods of measurement in this memo. 138 However, the problem statement will mandate that support for one or 139 more categories of rate measurement methods and adequate control 140 features for the methods in the test protocol. 142 3. Active Rate Measurement 144 This section lists features of active measurement methods needed to 145 measure access rates in production networks. 147 Test coordination between Source and Destination devices through 148 control messages and other basic capabilities described in the 149 methods of IPPM RFCs [RFC2679][RFC2680] are taken as given (these 150 could be listed later, if desired). 152 Most forms of active testing intrude on user performance to some 153 degree. One key tenet of IPPM methods is to minimize test traffic 154 effects on user traffic in the production network. Section 5 of 155 [RFC2680] lists the problems with high measurement traffic rates, and 156 the most relevant for rate measurement is the tendency for 157 measurement traffic to skew the results, followed by the possibility 158 to introduce congestion on the access link. Obviously, categories of 159 rate measurement methods that use less active test traffic than 160 others with similar accuracy SHALL be preferred for In-Service 161 Testing. 163 On the other hand, Out-of-Service Tests where the test path shares no 164 links with In-Service user traffic have none of the congestion or 165 skew concerns, but must address other practical concerns such as 166 conducting measurements within a reasonable time from the tester's 167 point of view. Out-of-Service Tests where some part of the test path 168 is shared with In-Service traffic MUST respect the In-Service 169 constraints. 171 The **intended metrics to be measured** have strong influence over 172 the categories of measurement methods required. For example, using 173 the terminology of [RFC5136], a it may be possible to measure a Path 174 Capacity Metric while In-Service if the level of background (user) 175 traffic can be assessed and included in the reported result. 177 The measurement *architecture* MAY be either of one-way (e.g., 178 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 179 aspects of end-user or aggregated access measurement clearly favor 180 two-way (with low-complexity user-end device and round-trip results 181 collection, as found in [RFC5357]). However, the asymmetric rates of 182 many access services mean that the measurement system MUST be able to 183 assess each direction of transmission. In the two-way architecture, 184 it is expected that both end devices MUST include the ability to 185 launch test streams and collect the results of measurements in both 186 (one-way) directions of transmission (this requirement is consistent 187 with previous protocol specifications, it is not a unique problem for 188 rate measurements). 190 The following paragraphs describe features for the roles of test 191 packet SENDER, RECEIVER, and results REPORTER. 193 SENDER: 195 Ability to generate streams of test packets with various 196 characteristics as desired (see Section 4). The SENDER may be 197 located at the user end of the access path, or may be located 198 elsewhere in the production network, such as at one end of an 199 aggregated leased network segment. 201 RECEIVER: 203 Ability to collect streams of test packets with various 204 characteristics (as described above), and make the measurements 205 necessary to support rate measurement at the other end of an end-user 206 access or aggregated leased network segment. 208 REPORTER: 210 Ability to use information from test packets and local processes to 211 measure delivered packet rates. 213 4. Measurement Method Categories 215 The design of rate measurement methods can be divided into two 216 phases: test stream design and measurement (SENDER and RECEIVER), and 217 a follow-up phase for analysis of the measurement to produce results 218 (REPORTER). The measurement protocol that addresses this problem 219 MUST only serve the test stream generation and measurement functions. 221 For the purposes of this problem statement, we categorize the many 222 possibilities for rate measurement stream generation as follows; 224 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 225 random time intervals between pairs in a test stream. 227 2. Multiple streams of packet pairs, with a range intra-pair spacing 228 and inter-pair intervals. 230 3. One or more packet ensembles in a test stream, using a fixed 231 ensemble size in packets and one or more fixed intra-ensemble 232 packet spacings (including zero). 234 4. One or more packet chirps, where intra-packet spacing typically 235 decreases between adjacent packets in the same chirp and each 236 pair of packets represents a rate for testing purposes. 238 For all categories, the test protocol MUST support: 240 1. Variable payload lengths among packet streams 242 2. Variable length (in packets) among packet streams or ensembles 244 3. Variable header markings among packet streams 246 4. Variable number of packets-pairs, ensembles, or streams used in a 247 test session 249 are additional variables that the test protocol MUST be able to 250 communicate. 252 The test protocol SHALL support test packet ensemble generation 253 (category 3), as this appears to minimize the demands on measurement 254 accuracy. Other stream generation categories are OPTIONAL. 256 Measurements for each test packet transferred between SENDER and 257 RECEIVER MUST be compliant with the singleton measurement methods 258 described in IPPM RFCs [RFC2679][RFC2680] (these could be listed 259 later, if desired). The time-stamp information or loss/arrival 260 status for each packet MUST be available for communication to the 261 protocol entity that collects results. 263 5. Test Protocol Control & Generation Requirements 265 Essentially, the test protocol MUST support the measurement features 266 described in the sections above. This requires: 268 1. Communicating all test variables to the Sender and Receiver 270 2. Results collection in a one-way architecture 272 3. Remote device control for both one-way and two-way architectures 274 4. Asymmetric and/or pseudo-one-way test capability in a two-way 275 measurement architecture 277 The ability to control packet size on the tested path and enable 278 asymmetrical packet size testing in a two-way architecture are 279 REQUIRED. 281 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 282 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 283 metrics are OPTIONAL. 285 6. Security Considerations 287 The security considerations that apply to any active measurement of 288 live networks are relevant here as well. See [RFC4656] and 289 [RFC5357]. 291 There may be a serious issue if a proprietary Service Level Agreement 292 involved with the access network segment provider were somehow leaked 293 in the process of rate measurement. To address this, test protocols 294 SHOULD NOT convey this information in a way that could be discovered 295 by unauthorized parties. 297 7. IANA Considerations 299 This memo makes no requests of IANA. 301 8. Acknowledgements 303 Dave McDysan provided comments and text for the aggregated leased use 304 case. Yaakov Stein suggested many considerations to address, 305 including the in-service vs. out-of-service distinction and its 306 implication on test traffic limits. 308 9. References 310 9.1. Normative References 312 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 313 Specification, Implementation", RFC 1305, March 1992. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 319 Delay Metric for IPPM", RFC 2679, September 1999. 321 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 322 Packet Loss Metric for IPPM", RFC 2680, September 1999. 324 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 325 Zekauskas, "A One-way Active Measurement Protocol 326 (OWAMP)", RFC 4656, September 2006. 328 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 329 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 330 RFC 5357, October 2008. 332 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 333 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 334 August 2009. 336 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 337 Feature for the Two-Way Active Measurement Protocol 338 (TWAMP)", RFC 5938, August 2010. 340 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 341 Protocol (TWAMP) Reflect Octets and Symmetrical Size 342 Features", RFC 6038, October 2010. 344 9.2. Informative References 346 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 347 RFC 5136, February 2008. 349 Author's Address 351 Al Morton 352 AT&T Labs 353 200 Laurel Avenue South 354 Middletown,, NJ 07748 355 USA 357 Phone: +1 732 420 1571 358 Fax: +1 732 368 1192 359 Email: acmorton@att.com 360 URI: http://home.comcast.net/~acmacm/