idnits 2.17.1 draft-deng-ippm-passive-wireless-usecase-01.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 == Line 99 has weird spacing: '...nd with the ...' == Line 191 has weird spacing: '...tinuous graph...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Jan 11, 2015) is 3392 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2991' is mentioned on line 101, but not defined == Missing Reference: 'RFC2119' is mentioned on line 150, but not defined == Unused Reference: 'ECMP' is defined on line 325, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LMAP Working Group L. Deng 3 INTERNET-DRAFT China Mobile 4 Intended Status: Informational L. Zheng 5 Expires: July 13, 2015 Huawei 6 M, Ackermann 7 BCBS Michigan 8 G. Mirsky 9 Ericsson 10 Jan 11, 2015 12 Use-cases for Passive Measurement in Wireless Networks 13 draft-deng-ippm-passive-wireless-usecase-01 15 Abstract 17 This document presents use-cases for passive IP performance 18 measurements in wireless networks. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Conventions Used in This Document . . . . . . . . . . . . . . . 4 60 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 Requirements Language . . . . . . . . . . . . . . . . . . . 4 62 3 Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1 Performance Monitoring for Network Planning/Optimization . . 4 64 3.2 End-to-end Measurement for Wireless Subscribers . . . . . . 5 65 3.3 Accurate Fault Identification . . . . . . . . . . . . . . . 6 66 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 70 6.2 Informative References . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1 Introduction 75 It is well-accepted that mobile Internet usage is going to increase 76 fast in the coming years and replace the traditional voice service as 77 the dominant revenue source for mobile operators. In the meantime, 78 fast evolving network and terminal technologies and changing service 79 trends (e.g. social networking, video on demand, online reading, 80 etc.) result in more stringent user service requirements. Therefore, 81 as the basic infrastructure service providers, operators are deemed 82 responsible for mobile Internet end-to-end performance because 83 subscribers want to get what they want, which gives rise to a basic 84 yet important question: how does network service provider manage end- 85 to-end Quality of Service (QoS)? In particular, there are two goals 86 for operator's quality management initiative: 88 o to make sure and validate the QoS metrics of specific IP flows 89 against the values pre-defined by the service Service Level 90 Agreement(SLA) from the perspective of either the subscriber or 91 the Internet Content Provider (ICP); and 93 o to make sure and validate the sanity of network devices/links. 95 Passive measurements, where observation on existing traffic is the 96 only means for measurement entities, have been extensively used in 97 scenarios where active measurement alone may not be sufficient to 98 characterize performance over a particular service path. For example, 99 the active measurement traffic may not be in-band with the real 100 traffic that it is intended to simulate as a result of dynamics in 101 routing techniques, e.g. Equal Cost Multi-Path (ECMP) [RFC2991] or 102 device pooling[3GPP TS23.236]. 104 Overall there are many characteristics of injected active test 105 traffic that can render behaviors and measured metrics may be 106 different from the actual user traffic flows and performance. Since 107 the ultimate goal is understanding the actual user traffic 108 performance, measuring the actual (Passive) traffic itself, 109 represents an important measurement method to achieve effective and 110 accurate results. 112 In this draft, we present three use-cases of passive measurements for 113 wireless networks, where active IP performance measurements are not 114 desirable or accurate enough in achieving the above goals. 116 It is worth notice that some of the use-cases are not unique to 117 Wireless networks, and can be applied to wired networks as well. 119 2 Conventions Used in This Document 121 2.1 Terminology 123 ECMP - Equal Cost Multi-Path 125 ISP - Internet Service Provider 127 QoE - Quality of Experience 129 QoS - Quality of Service 131 RAN - Radio Access Network 133 SLA - Service Level Agreement 135 UE - User Equipment 137 MP - Measurement Point, a node or juncture within an IP Network 138 Session Path at which information regarding the performance or 139 reliability of the session path is observed, examined or measured. 141 Ma - Measurement Agent, the software entity integrated into a 142 measurement point that actually does the function of performance 143 measurement related tasks. 145 2.2 Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3 Use-cases 153 In light of the introduction of more capable passive measurement 154 methods than pure observation in[I.D-zheng-ippm-framework-passive], 155 it is expected that passive measurements would be the basic building 156 block in performance monitoring in highly dynamic and resource- 157 limited production networks like wireless access networks. 159 This section presents use-cases for passive measurements in wireless 160 networks. 162 3.1 Performance Monitoring for Network Planning/Optimization 164 As mentioned earlier, it is important for Internet Service Providers 165 (ISPs) to understand their network performance through continuous and 166 accurate performance monitoring in terms of the experience of network 167 customers in addition to the status of the physical network. 169 However, due to the traffic dynamics in terms of its geographic and 170 time distribution, accurate monitoring of actual traffic QoS, 171 necessary for network planning or adaptive network optimization, 172 cannot be achieved by active measurements alone. Because active 173 measurement methods measure performance metrics by means of carefully 174 designed and injected active measurement traffic, whose 175 characteristics may be quite different from those of the real traffic 176 in a production network, and not flexible to account for the impact 177 from traffic dynamics. Moreover, the injected active traffic could 178 even skew results or measurements, rendering the continuous non- 179 interfering monitoring of traffic QoS impossible with active 180 measurements along. This could be especially problematic when 181 associated results are used for performing network planning and 182 optimization. E.g. for network planning, it is important to evaluate 183 the Quality of Experience (QoE) and network performance during the 184 peak hours, when active measurements are least desirable. It is also 185 helpful to understand the user experience during non-peak hours in 186 order to better assist the application and verify its sophisticated 187 dynamic resource provisioning schemes, such as elastic resource 188 pooling. 190 Alternatively, deploying passive measurement points/agents in the 191 wireless network, operators can draw a continuous graph of the 192 network usage and performance metric as the basis of network/resource 193 planning. Since interference to network performance introduced by 194 data collection of a passive measurement may be viewed as negligent, 195 it can be initiated almost any time of the day and applied to rush 196 hours as well. 198 3.2 End-to-end Measurement for Wireless Subscribers 200 For wireless networks, almost all the time, the wireless "last mile" 201 would be the bottleneck for end-to-end QoS and QoE, indicating the 202 necessity to include the wireless segment into the measurement path. 204 However, due to the limited availability and/or relatively high cost 205 of wireless resources, it is not economic for either ISP or the user 206 to conduct resource-demanding active measurements over the wireless 207 link. 209 For instance, unlike the fixed network providers where the access 210 network resource is shared by a group of subscribers who are charged 211 by the duration of their subscriptions independent of their actual 212 network usage, wireless/mobile ISPs make extensive use of resource 213 allocation and reservation for individual terminals/IP flows and 214 often use the traffic volume consumption as the basis for 215 subscription billing. In other words, the subscriber may be charged 216 for the active measurement traffic despite the fact that it degrades 217 QoE of real application data transfer during the Active measurement. 219 Therefore, measurements pertaining to the performance of Subscribers 220 or End Users, are particularly dependent upon passive measurements. 221 As stated, Active measurements conducted in this realm can be 222 expensive and even affect QoE. Possibly even greater concern is that 223 the results of the Active measurements may not match the results of 224 the actual End User traffic (for various reasons discussed in Section 225 3.1). The Passive measurements more likely match the results of the 226 actual End User traffic, because they are based on the same traffic. 228 3.3 Accurate Fault Identification 230 It is quite common that there are multiple domains (belonging to 231 different operational or administrative bodies) along the data path 232 from a mobile user equipment (UE) to the Internet. 234 Case 1: intermediary ISP: consider the example of a mobile subscriber 235 getting access from a 3GPP network. Besides a local mobile network 236 operator, intermediary ISPs may exist in between before subscriber's 237 traffic reaches the Internet. 239 Case2: path partitioning: as shown in Figure 1, within the local 240 operator's network, radio access network (RAN), RAN backhaul and 241 local core network could actually be constructed and managed by staff 242 from different departments. 244 Case3: geographic partitioning: for large operators, employing 245 layered network operation and management architecture based on 246 geographic partitions, there may be a further more subpath 247 partitioning between local IP backhaul (managed by state sub- 248 ordinaries) and national IP backhaul (managed by headquarters). 250 \|/ 251 | 252 | 253 +-|---+ +------+ +------+ +----+ 254 +--+ | | Tunnel1 | | Tunnel2 | | Ext | | 255 |UE|-(RAN)-| eNB |===========| S-GW |=========| P-GW |--------|SP | 256 +--+ | | RAN | | Core | |Network | | 257 +-+---+ Backhaul +---+--+ Network +---+--+ +--+-+ 259 Figure 1: Example of path partition in 3GPP network 261 Case4: roaming partitioning: Moreover, for roaming cases under home- 262 routed mode, all the traffic from a roaming UE would first traverse 263 from the visited ISP and potentially another Internet operator before 264 getting back to homing ISP network. 266 In these cross-domain scenarios, in order to do effective trouble 267 shooting for degraded QoS, one needs to first identify the faulty 268 domain or cross-domain interconnection from well performing domains, 269 and then further drill down for the overloaded device/link within the 270 identified domain. If Active measurements are employed, cross- 271 boundary traffic and cross-provider coordination on the 272 interconnections may be required to complicate the process. 274 On the contrary, passive measurements can help in accurate trouble- 275 shooting and problem demarcation between various networking 276 technologies or operational domains that together compose an end-to- 277 end traffic path, since it does not require extra cross-boundary 278 traffic to be injected into the path or strict synchronization to be 279 conducted between participating measurement points/agents as Active 280 measurements do. 282 Passive measurements can be used both for the end-to-end problem 283 identification and the hop-by-hop demarcation. By deploying 284 measurement points/agents both within the domains and at the cross- 285 boundary interconnections, passive measurements can quickly identify 286 the faulty domain/device/link without introducing extra cross- 287 boundary measurement traffic. 289 For instance, Passive measurement points/agents can be deployed at 290 both the ingress and the egress point of each domain and work 291 independently along the path for the passive performance measurement. 292 A simple aggregation at a third-party data collector can do the 293 drilling measurement result analysis to identify the problematic 294 flow. 296 More importantly, in the above cross-domain cases, timely fault 297 isolation is critical. Alerts/alarms and other indications of 298 potential faults may be provided more quickly by monitoring and 299 measuring on data traffic. As alluded to in the previous paragraphs, 300 active monitoring may require significant set up and coordination. 301 By the time this occurs, it is conceivable that network conditions, 302 may have changed. It is also conceivable that the difference in 303 traffic characteristics between the actual traffic, and active 304 traffic injected into the network, (no matter how slight the 305 differences), may not experience the same issues or faults. 307 4 Security Considerations 309 TBA. 311 5 IANA Considerations 313 There is no IANA action in this document. 315 6 References 317 6.1 Normative References 319 6.2 Informative References 321 [I.D-zheng-ippm-framework-passive] L. Zheng et al. "Framework for IP 322 Passive Measurements", draft-zheng-ippm-framework-passive- 323 00(work in progress), June 2014. 325 [ECMP] D. Thaler et al. "Multipath Issues in Unicast and Multicast 326 Next-Hop Selection", RFC 2991, November 2000. 328 [3GPP TS23.236] 3GPP TS 23.236: "Intra Domain Connection of RAN Nodes 329 to Multiple CN Nodes", Release 5, November 2004. 331 Authors' Addresses 333 Lingli Deng 334 China Mobile 335 China 337 Email: denglingli@chinamobile.com 339 Lianshu Zheng 340 Huawei Technologies 341 China 343 Email: vero.zheng@huawei.com 345 Michael Ackermann 346 Blue Cross Blue Shield of Michigan 347 USA 349 Email: mike.ackermann@bcbsmi.com 351 Greg Mirsky 352 Ericsson 353 USA 355 Email: gregory.mirsky@ericsson.com