idnits 2.17.1 draft-ietf-conex-mobile-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 17, 2014) is 3503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-ecn-encap-guidelines-03 == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-08 == Outdated reference: A later version (-12) exists of draft-ietf-conex-destopt-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CONEX WG D. Kutscher 3 Internet-Draft F. Mir 4 Intended status: Informational R. Winter 5 Expires: March 21, 2015 NEC 6 S. Krishnan 7 Y. Zhang 8 Ericsson 9 CJ. Bernardos 10 UC3M 11 September 17, 2014 13 Mobile Communication Congestion Exposure Scenario 14 draft-ietf-conex-mobile-04 16 Abstract 18 This memo describes a mobile communications use case for congestion 19 exposure (ConEx) with a particular focus on those mobile 20 communication networks that are architecturally similar to the 3GPP 21 Evolved Packet System (EPS). The draft provides a brief overview of 22 the architecture of these networks (both access and core networks), 23 current QoS mechanisms and then discusses how congestion exposure 24 concepts could be applied. Based on this, this memo suggests a set 25 of requirements for ConEx mechanisms that particularly apply to these 26 mobile networks. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 21, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. ConEx Use Cases in Mobile Communication Networks . . . . . . . 3 64 2.1. ConEx as a Basis for Traffic Management . . . . . . . . . 4 65 2.2. ConEx to Incentivize Scavenger Transports . . . . . . . . 6 66 2.3. Accounting for Congestion Volume . . . . . . . . . . . . . 6 67 2.4. Partial vs. Full Deployment . . . . . . . . . . . . . . . 7 68 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. CONEX in the EPS . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9 71 3.2. Implementing CONEX Functions in the EPS . . . . . . . . . 13 72 3.2.1. CONEX Protocol Mechanisms . . . . . . . . . . . . . . 13 73 3.2.2. CONEX Functions in the Mobile Network . . . . . . . . 14 74 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 81 Appendix B. Overview of 3GPP's Evolved Packet System (EPS) . . . 20 82 Appendix C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 22 83 C.1. draft-ietf-conex-mobile-04 . . . . . . . . . . . . . . . . 22 84 C.2. draft-ietf-conex-mobile-03 . . . . . . . . . . . . . . . . 22 85 C.3. Earlier . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Introduction 90 Mobile data traffic continues to grow rapidly. The challenge 91 wireless operators face is to support more subscribers with an 92 increasing bandwidth demand. To meet these bandwidth requirements, 93 there is a need for new technologies that assist the operators in 94 efficiently utilizing the available network resources. Two specific 95 areas where such new technologies could be deemed useful are resource 96 allocation and flow management. 98 Analysis of cellular network data traffic has shown that most flows 99 are short-lived and low-volume, but a comparatively small number of 100 high-volume flows constitute a large fraction of the overall traffic 101 volume [lte-sigcomm2013]. That means that potentially a small 102 fraction of users is responsible for the majority of traffic in 103 cellular networks. In view of such highly skewed user behavior and 104 limited and expensive resources (e.g. the wireless spectrum), 105 resource allocation and usage accountability are two important issues 106 for operators to solve in order to achieve both a better network 107 resource utilization and fair resource sharing. ConEx, as described 108 in [RFC6789], is a technology that can be used to achieve these 109 goals. 111 The ConEx congestion exposure mechanism is designed to be a general 112 technology that could be applied as a key element of congestion 113 management solutions for a variety of use cases. The IETF CONEX WG 114 decided to initially start to work on a specific use case, where the 115 end hosts and the network that contains the destination end hosts are 116 ConEx-enabled but other networks need not be. 118 A specific example of such a use case can be a mobile communication 119 network such as a 3GPP Evolved Packet System (EPS) network, where UEs 120 (User Equipment, i.e. mobile end hosts), servers and caches, the 121 access network and possibly an operator's core network can be ConEx- 122 enabled. I.e., hosts support the ConEx mechanisms, and the network 123 provides policing/auditing functions at its edges. 125 This document provides a brief overview of the architecture of such 126 networks (access and core networks) and current QoS mechanisms. It 127 further discusses how such networks can benefit from congestion 128 exposure concepts and how they should be applied. Using this use 129 case as a basis, a set of requirements for ConEx mechanisms are 130 described. 132 2. ConEx Use Cases in Mobile Communication Networks 134 In general, quality of service and good network resource utilization 135 are important requirements for mobile communication network 136 operators. Radio access and backhaul capacity are considered scarce 137 resources, and bandwidth (and radio resource) demand is difficult to 138 predict precisely due to user mobility, radio propagation effects 139 etc. Hence today's architectures and protocols go to significant 140 extent in order to provide network-controlled quality of service. 141 These efforts often lead to complexity and cost. ConEx could be 142 simpler and more capable approach to efficient resource sharing in 143 these networks. 145 In the following, we discuss ways how congestion exposure could be 146 beneficial for supporting resource management in such mobile 147 communication networks. [RFC6789] describes fundamental congestion 148 exposure concepts and a set of use cases for applying congestion 149 exposure mechanisms to realize different traffic management functions 150 such as flow policy-based traffic management or traffic offloading. 151 Readers that are not familiar with the 3GPP Evolved Packet System 152 (EPS) should refer to Appendix B first. 154 2.1. ConEx as a Basis for Traffic Management 156 Traffic management is a very important function in mobile 157 communication networks. Since wireless resources are considered 158 scarce and since user mobility and shared bandwidth in the wireless 159 access create certain dynamics with respect to available bandwidth, 160 commercially operated mobile networks provide mechanisms for tight 161 resource management (admission control for bearer establishment). 162 However, sometimes these mechanisms are not easily applicable to IP- 163 and HTTP-dominated traffic mixes, for example, most Internet traffic 164 in today's mobile network is transmitted over the (best-effort) 165 default bearer. 167 Given the above, and in the light of the significant increase of 168 overall data volume in 3G networks, Deep-Packet-Inspection (DPI) is 169 often considered a desirable function to have in the EPC -- despite 170 its cost and complexity. With the increase of encrypted data 171 traffic, traffic management using DPI alone however will become even 172 more challenging. 174 Congestion exposure can be employed to address resource management 175 requirements in different ways: 177 1. It can enable or enhance flow policy-based traffic management. 178 At present, DPI-based resource management is often used to 179 prioritize certain application classes with respect to others in 180 overload situations, so that effectively more users can be served 181 on the network. In overload situations, operators use DPI to 182 identify dispensable flows and make them yield to other flows (of 183 different application classes) through policing. Such traffic 184 management is thus based on operator decisions -- using partly 185 static configuration and some estimation about the future per- 186 flow bandwidth demand. With congestion exposure it would be 187 possible to assess the contribution to congestion of individual 188 flows. This information can then be used as input to a policer 189 that can optimize network utilization more accurately and 190 dynamically. By using ConEx congestion contribution as a metric, 191 such policers would not need to be aware of specific link loads 192 (e.g., in wireless base stations) or flow application types. 194 2. It can reduce the need for complex DPI by allowing for a bulk 195 packet traffic management system that does not have to consider 196 the application classes flows belong to and individual sessions. 197 Instead, traffic management would be based on the current cost 198 (contribution to congestion) incurred by different flows and 199 enable operators to apply policing/accounting depending on their 200 preference. Such traffic management would be simpler and more 201 robust (no real-time flow application type identification 202 required, no static configuration of application classes) and 203 perform better as decisions can be taken based on real-time 204 actual cost contribution. With ConEx, accurate downstream path 205 information would be visible to ingress network operators, which 206 can respond to incipient congestion in time. This can be 207 equivalent to offering different levels of QoS, e.g. premium 208 service with zero congestion response. For that, ConEx could be 209 used in two different ways: 211 1. as additional information to assist network functions to 212 impose different QoS for different application sessions; and 214 2. as a tool to let applications decide on their response to 215 congestion notification, while incentivizing them to react 216 (in general) appropriately, e.g., by enforcing overall limits 217 for congestion contribution or by accounting and charging for 218 such congestion contribution. Note that this level of 219 responsiveness would be on a different level then, say, 220 application-layer responsive in protocols such as DASH 221 [dash], however it could interwork with such protocols, for 222 example by triggering earlier responses. 224 3. It can further be used to more effectively trigger the offload of 225 selected traffic to a non-3GPP network. Nowadays, it is common 226 that users are equipped with dual mode mobile phones (e.g., 227 integrating third/fourth generation cellular and WiFi radio 228 devices) capable of attaching to available networks either 229 sequentially or simultaneously. With this scenario in mind, 3GPP 230 is currently looking at mechanisms to seamlessly and selectively 231 switch over a single IP flow (e.g., user application) to a 232 different radio access, while keeping all other ongoing 233 connections untouched. The decision on when and which IP flows 234 move is typically based on statically configured rules, whereas 235 the use of ConEx mechanisms could also factor in real-time 236 congestion information into the decision. 238 In summary, it can be said that traffic management in the 3GPP EPS 239 and other mobile communication architectures is very important. 240 Currently, more static approaches based on admission control and 241 static QoS are in use, but recently, there has been a perceived need 242 for more dynamic mechanisms based on DPI. Introducing ConEx could 243 make these mechanisms more efficient or even remove the need for some 244 of the DPI functions deployed today. 246 2.2. ConEx to Incentivize Scavenger Transports 248 As 3G and LTE networks are turning into universal access networks 249 that are shared between mobile (smart) phone users, mobile users with 250 laptop PCs, home users with LTE access and others, capacity-sharing 251 among different users and application flows becomes increasingly 252 important in these mobile communication networks. 254 Most of this traffic is likely to be classified as best-effort 255 traffic, without differentiating for example periodic OS updates, 256 application store downloads from web (browser)-based or other more 257 real-time communication. For many of the bulk data transfers, 258 completion times aren't important within certain bounds and therefore 259 if scavenger (or less-than best effort) transports like e.g. LEDBAT 260 [RFC6817] were used, it would improve the overall utility of the 261 network. The use of these transports by the end user however needs 262 to be incentivized. ConEx could be used to build an incentive scheme 263 e.g. by allowing users that contribute less to congestion to give 264 them a larger bandwidth allowance or e.g. to lower the next monthly 265 subscription fee. In principle, this would be possible to implement 266 with current specifications. 268 2.3. Accounting for Congestion Volume 270 3G and LTE networks provide extensive support for accounting and 271 charging already, for example cf. the Policy Charging Control (PCC) 272 architecture. In fact, most operators today account transmitted data 273 volume on a very fine granular basis and either correlate monthly 274 charging to the exact number of packets/bytes transmitted, or employ 275 some form of flat rate (or flexible flat rate), often with a so- 276 called fair-use policy. With such policies, users are typically 277 limited to an administratively configured maximum bandwidth limit, 278 after they have used up their contractual data volume budget for the 279 charging period. 281 Changing this data volume-based accounting to a congestion-based 282 accounting would be possible in principle, especially since there 283 already is an elaborate per-user accounting system available. Also, 284 an operator-provided mobile communication network can be seen as a 285 network domain within such congestion volume accounting would be 286 possible, without requiring any support from the global Internet, in 287 particular since the typical scare resources such as the wireless 288 access and the mobile backhaul are all within this domain. Traffic 289 normally leaves/enters the operator's network via well-defined 290 egress/ingress points that would be ideal candidates for policing 291 functions. Moreover, in most commercially operated networks, 292 accounting is performed for both received and sent data, which would 293 facilitate congestion volume accounting as well. 295 With respect to the current PCC framework, accounting for congestion 296 volume could be added as another feature to the "Usage Monitoring 297 Control" capability that is currently based on data volume. This 298 would not require any new interface (reference points) at all. 300 2.4. Partial vs. Full Deployment 302 In general, ConEx lends itself to partial deployment as the mechanism 303 does not require all routers and hosts to support congestion 304 exposure. Moreover, assuming a policing infrastructure has been put 305 in place, it is not required to modify all hosts. Since ConEx is 306 about senders exposing congestion contribution to the network, 307 senders need to be made ConEx-aware (assuming a congestion 308 notification mechanisms such as ECN is in place). 310 [I-D.briscoe-conex-initial-deploy] provides specific examples of how 311 ConEx deployments can be initiated, focusing on unilaterial 312 deployments by single networks, i.e., partial deployment. 314 When moving towards full deployment in a specific operator's network, 315 different ways for introducing ConEx support on UEs are feasible. 316 Since mobile communication networks are multi-vendor networks, 317 standardizing ConEx support on UEs (e.g., in 3GPP specifications) 318 appears useful. Still, not all UEs would have to support ConEx, and 319 operators would be free to choose their policing approach in such 320 deployment scenarios. Leveraging existing PCC architectures, 3GPP 321 network operators could for example decide policing/accounting 322 approaches per UE -- i.e., apply fixed volume caps for non-ConEx UEs 323 and more flexible schemes for ConEx-enabled UEs. 325 Moreover, it should be noted that network support for ConEx is a 326 feature that some operators may choose to deploy if they wish, but it 327 is not required that all operators (or all other networks) do so. 329 Depending on the extent of ConEx support, specific aspects such as 330 roaming have to be taken into account. I.e., what happens when a 331 user is roaming in a ConEx-enabled network, but their UE is not 332 ConEx-enabled and vice versa. Although these may not be fundamental 333 problems, they need to be considered. For supporting mobility in 334 general, it can be required to shift users' policing state during 335 hand-over. There is existing work in [raghavan2007] on distributed 336 rate limiting and in [nec.euronf-2011] on specific optimizations for 337 congestion exposure and policing in mobility scenarios. 339 Another aspect to consider is the addition of Selected IP Traffic 340 Offload (SIPTO) and Local Breakout (LIPA), also see [3GPP.23.829], 341 i.e., the idea that some traffic (e.g., high-volume Internet traffic) 342 is actually not passed through the EPC but is offloaded at a "break- 343 out point" closer to (or in) the access network. On the other hand, 344 ConEx can also enable more dynamic decisions on what traffic to 345 actually offload by considering congestion exposure in bulk traffic 346 aggregates -- thus making traffic offload more effective. 348 2.5. Summary 350 In summary, the 3GPP EPS is a system architecture that can benefit 351 from congestion exposure in multiple ways. Dynamic traffic and 352 congestion management is an acknowledged and important requirement 353 for the EPS, also illustrated by the current DPI-related work for 354 EPS. 356 Moreover, networks such as an EPS mobile communication network would 357 be quite amenable for deploying ConEx as a mechanism, since they 358 represent clearly defined and well separated operational domains, in 359 which local ConEx deployment would be possible. Aside from roaming 360 (which needs to be considered for a specific solution), such a 361 deployment is fully under the control of a single operator, which can 362 enable operator-local enhancement without the need for major changes 363 to the architecture. 365 In 3GPP EPS, interfaces between all elements of the architecture are 366 subject to standardization, including UE interfaces and eNodeB 367 interfaces, so that a more general approach, involving more than one 368 single operator's network, can be feasible as well. 370 3. CONEX in the EPS 372 At the time of writing, the CONEX mechanism is still work in progress 373 in the IETF working group. Still, discussing a few options for how 374 such a mechanism (and possibly additional policing functions) could 375 eventually be deployed in 3GPP's EPS is useful at this point. Note 376 that this description of options is not intended as a complete set of 377 possible approaches -- it is merely intended for discussing the most 378 promising options. 380 3.1. Possible Deployment Scenarios 382 There are different possible ways how CONEX functions on hosts and 383 network elements can be used. For example, CONEX could be used for a 384 limited part of the network only -- e.g., for the access network -- 385 congestion exposure and sender adaptation could involve the mobile 386 nodes or not, or, finally, the CONEX feedback loop could extend 387 beyond a single operator's domain or not. 389 We present three different deployment scenarios for congestion 390 exposure in the figures below: 392 1. In Figure 1 CONEX is supported by servers for sending data (here: 393 web servers in the Internet and caches in an operator's network) 394 but not by UEs (neither for receiving nor sending). An operator 395 who chooses to run a policing function on the network ingress 396 (e.g., on the P-GW) can still benefit from congestion exposure 397 without requiring any change on UEs. 399 2. CONEX is universally employed between operators (as depicted in 400 Figure 2), with an end-to-end CONEX feedback loop. Here, 401 operators could still employ local policies, congestion 402 accounting schemes etc., and they could use information about 403 congestion contribution for determining interconnection 404 agreements. This deployment scenario would imply the willingness 405 of operators to expose congestion to each other. 407 3. Isolated CONEX domains as depicted in Figure 3, where CONEX is 408 solely applied locally, in the operator network, and there is no 409 end-to-end congestion exposure. This could be the case when 410 CONEX is only implemented in a few networks, or when operators 411 decide to not expose ECN and account for congestion for inter- 412 domain traffic. Independent of the actual scenario, it is likely 413 that there will be border gateways (as in today's deployments) 414 that are associated with policing and accounting functions. 416 4. [conex-lite] describes an approach called "ConEx Lite" for mobile 417 networks that is intended for initial deployment of congestion 418 exposure concepts in LTE, specifically in the backhaul and core 419 network segments. As depicted in Figure 4 ConEx Lite allows a 420 tunnel receiver to monitor the volume of bytes that has been lost 421 or dropped (or ECN-CE marked) between the tunnel sender and 422 receiver. For that purpose, a new field is introduced to the 423 tunnel header called the Byte Sequence Marker (BSN) that 424 identifies the byte in the flow of data from the tunnel sender to 425 the tunnel receiver. A policer at the tunnel sender is expected 426 to re-act according to the tunnel congestion volume (see 427 [conex-lite] for details.) 429 +------------+ 430 | Web server | 431 | w/ CONEX | 432 +------------+ 433 | 434 | 435 | 436 ----------------------- 437 | | | 438 | Internet | | 439 | | | 440 ----------------------- 441 | 442 --------------------------------------------|-------- 443 | | | 444 | +-----------+ | 445 | | Web cache | | 446 | | w/ CONEX | | 447 | +-----------+ | 448 | | | 449 | +----+ +-------+ +-------+ +-------+ | 450 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 451 | +----+ +-------+ +-------+ +-------+ | 452 | | 453 | Operator A | 454 ----------------------------------------------------- 456 Figure 1: CONEX support on servers and caches 458 ----------------------------------------------------- 459 | +----+ +-------+ +-------+ +-------+ | 460 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 461 | +----+ +-------+ +-------+ +-------+ | 462 | | | 463 | Operator A | | 464 --------------------------------------------|-------- 465 | 466 ----------------------- 467 | | 468 | Internet | 469 | | 470 ----------------------- 471 | 472 --------------------------------------------|-------- 473 | +----+ +-------+ +-------+ +-------+ | 474 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 475 | +----+ +-------+ +-------+ +-------+ | 476 | | 477 | Operator B | 478 ----------------------------------------------------- 480 Figure 2: CONEX deployment across operator domains 482 ----------------------------------------------------- 483 | |--- CONEX path ---| | 484 | v v | 485 | +----+ +-------+ +-------+ +-------+ | 486 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 487 | +----+ +-------+ +-------+ +-------+ | 488 | | | 489 | Operator A | | 490 --------------------------------------------|-------- 491 | 492 ----------------------- 493 | | 494 | Internet | 495 | | 496 ----------------------- 497 | 498 --------------------------------------------|-------- 499 | +----+ +-------+ +-------+ +-------+ | 500 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 501 | +----+ +-------+ +-------+ +-------+ | 502 | | 503 | Operator B | 504 ----------------------------------------------------- 506 Figure 3: CONEX deployment in a single operator domain 508 Backhaul Network Core Network 509 +---------------+ +--------------+ 510 | | | | 511 | BSN or ECN-CE | | | 512 | marked | | | 513 | packets | | | 514 | <--- | | | 515 +----+ +-------+ +----------+ +-------+ +--------+ 516 | | | | GTP-U | | GTP-U | | | | 517 | UE |=====| eNB |=======| S-GW |=======| P-GW |==|Internet| 518 | | | | Tunnel| | Tunnel| | | | 519 +----+ +-------+ +----------+ +-------+ +--------+ 520 | ---> | | | 521 | User/control | | User/control | 522 | packets with | | packet with | 523 | DL congestion | | DL congestion| 524 | vol counters | | vol counters | 525 | | | | 526 +---------------+ +--------------+ 528 Figure 4: CONEX-lite deployment 530 We consider all three scenarios to be relevant and believe that all 531 of them are within the scope of the CONEX WG charter. A more 532 detailed description will be provided in a future version of this 533 document. 535 3.2. Implementing CONEX Functions in the EPS 537 We expect a CONEX solution to consist of different functions that 538 should be considered when implementing congestion exposure in 3GPP's 539 EPS. [I-D.ietf-conex-abstract-mech] is describing the following 540 congestion exposure components: 542 o Modified senders that send congestion exposure information in 543 response to congestion feedback. 545 o Receivers that generate congestion feedback (leveraging existing 546 behavior or requiring new functions). 548 o Audit functions that audit CONEX signals against actual 549 congestion, e.g., by monitoring flows or aggregate of flows. 551 o Policy devices that monitor congestion exposure information and 552 act on the flows according to the operator's policy. 554 Two aspects are important to consider: 1) how the CONEX protocol 555 mechanisms would be implemented and what modifications to existing 556 networks would be required and 2) where CONEX functional entities 557 would be placed best (to allow for a non-invasive addition). We 558 discuss these two aspects in the following sections. 560 3.2.1. CONEX Protocol Mechanisms 562 As described in [I-D.briscoe-conex-initial-deploy], the most 563 important step in introducing CONEX (initially) is adding the 564 congestion exposure functionality to senders. For an initial 565 deployment, no further modification to senders and receivers would be 566 required. Specifically, there is no fundamental dependency on ECN, 567 i.e., CONEX can be introduced without requiring ECN to be 568 implemented. 570 Congestion exposure information for IPv6 [I-D.ietf-conex-destopt] is 571 contained in a destination option header field, which requires 572 minimal changes at senders and nodes that want to assess path 573 congestion -- and that does not affect non-CONEX nodes in a network. 575 In 3GPP networks, IP tunneling is used intensively, i.e., using 576 either IP-in-GTP-U or PMIPv6 (i.e., IP-in-IP) tunnels. In general, 577 the CONEX destination option of encapsulated packets should be made 578 available for network nodes on the tunnel path, i.e., a tunnel 579 ingress should copy the CONEX destination option field to the outer 580 header. 582 For an effective and efficient capacity sharing, we envisage the 583 deployment of ECN in conjunction with CONEX so that ECN-enabled 584 receivers and senders get more accurate and more timely information 585 about their flows congestion contribution. ECN is already partially 586 introduced into 3GPP networks: Section 11.6 in [3GPP.36.300] 587 specifies the usage of ECN for congestion notification on the radio 588 link (between eNB and UE), and [3GPP.26.114] specifies how this can 589 be leveraged for voice codec adaptation. A complete, end-to-end 590 support of ECN would require specification of tunneling behaviour, 591 which should be based on [RFC6040] (for IP-in-IP tunnels) and on 592 [I-D.briscoe-tsvwg-ecn-encap-guidelines]. Specifically, a 593 specification for tunneling ECN in GTP-U will be needed. 595 3.2.2. CONEX Functions in the Mobile Network 597 In the following, we discuss some possible placement strategies for 598 CONEX functional entities (addressing both policing and auditing 599 functions) in the EPS and for possible optimizations for both the 600 uplink and the downlink. 602 In general, CONEX information (exposed congestion) is declared by a 603 sender and remains unchanged on the path, hence reading CONEX 604 information (e.g., by policing functions) is placement-agnostic. 605 Auditing CONEX normally requires assessing declared congestion 606 contribution and current actual congestion. If the latter is, for 607 example, done using ECN, such a function would best be placed at the 608 end of the path. 610 In order to provide a comprehensive CONEX-based capacity management 611 framework for EPS, it would be advantageous to consider user 612 contribution to congestion for both the radio access and the core 613 network. For a non-invasive introduction of CONEX, it can be 614 beneficial to combine CONEX functions with existing logical EPS 615 entities. For example, potential places for CONEX policing and 616 auditing functions would then be eNBs, S-GWs or the P-GWs. Operator 617 deployments may of course still provide additional intermediary 618 CONEX-enabled IP network elements. 620 For a more specific discussion it will be beneficial to distinguish 621 downlink and uplink traffic directions (also see [nec.globecom2010] 622 for a more detailed discussion). In today's networks and usage 623 models, downlink traffic is dominating (also reflected by the 624 asymmetric capacity provided by the LTE radio interface). That does 625 however not imply that uplink congestion is not an issue, since the 626 asymmetric maximum bandwidth configuration can create a smaller 627 bottleneck for uplink traffic -- and there are of course backhaul 628 links, gateways etc. that could be overloaded as well. 630 For managing downlink traffic -- e.g., in scenarios such as the one 631 depicted in Figure 1, operators can have different requirements for 632 policing traffic. Although policing is in principle location- 633 agnostic, it is important to consider requirements related to the EPS 634 architecture (Figure 5) such as tunneling between P-GWs and eNBs. 635 Policing can require access to subscriber information (e.g., 636 congestion contribution quota) or user-specific accounting, which 637 suggests that the CONEX function could be co-located with the P-GW 638 that already has an interface towards the PCRF. 640 Still, policing can serve different purposes. For example, if the 641 objective is to police bulk traffic induced by peer networks, 642 additional monitoring functions can be placed directly at 643 corresponding ingress points to monitor traffic and possible drive 644 out-of-band functions such as triggering border contract penalties. 646 The auditing function which should be placed at the end of the path 647 (at least after/at the last bottleneck) would likely be placed best 648 on the eNB (wireless base station). 650 For the uplink direction, there are naturally different options for 651 designing monitoring and policy enforcement functions. A likely 652 approach can be to monitor congestion exposure on central gateway 653 nodes (such as P-GWs) that provide the required interfaces to the 654 PCRF, but to perform policing actions in the access network, i.e., in 655 eNBs, e.g., to police traffic at the ingress, before it reaches 656 concentration points in the core network. 658 Such a setup would enable all the CONEX use cases described in 659 Section 2, without requiring significant changes to the EPS 660 architecture, while enabling operators to re-use existing 661 infrastructure, specifically wireless base stations, PCRF and HSS 662 systems. 664 For CONEX functions on elements such as the S-GWs and P-GWs, it is 665 important to consider mobility and tunneling protocol requirements. 666 LTE provides two alternative approaches: Proxy-Mobile-IPv6 (PMIPv6, 667 [3GPP.23.402]) and GPRS Tunneling Protocol (GTP). For the 668 propagation of congestion information (responses) tunneling 669 considerations are therefore very important. 671 In general, policing will be done based on per-user (per subscriber) 672 information such as congestion quota, current quota usage etc. and 673 network operator policies, e.g., specifying how to react to 674 persistent congestion contribution. In the EPS, per-user information 675 is normally part of the user profile (stored in the HSS) that would 676 be accessed by PCC entities such as the PCRF for dynamic updates, 677 enforcement etc. 679 4. Summary 681 We have shown how congestion exposure can be useful for efficient 682 resource management in mobile communication networks. The premise 683 for this discussion was the observation that data communication, 684 specifically best-effort bulk data transmission, is becoming a 685 commodity service whereas resources are obviously still limited -- 686 which calls for efficient, scalable, yet effective capacity sharing 687 in such networks. 689 CONEX can be a mechanism that enables such capacity sharing, while 690 allowing operators to apply these mechanisms in different ways, e.g., 691 for implementing different use cases as described in Section 2. It 692 is important to note that CONEX is fundamentally a mechanism that can 693 be applied in different ways -- to realize different operators 694 policies. 696 CONEX may also be used to complement 3GPP-based mechanisms for 697 congestion management which are currently under development, such as 698 in the User Plane Congestion Management (UPCON) work item described 699 in [3GPP.23.705]. 701 We have described a few possibilities for adding CONEX as a mechanism 702 to 3GPP LTE-based networks and have shown how this could be done 703 incrementally (starting with partial deployment). It is quite 704 feasible that such partial deployments be done on a per-operator- 705 domain basis, without requiring changes to standard 3GPP interfaces. 706 For a network-wide deployment, e.g., with congestion exposure between 707 operators, more considerations might be needed. 709 We have also identified a few implications/requirements that should 710 be taken into consideration when enabling congestion exposure in such 711 networks: 713 Performance: In mobile communication networks -- with more expensive 714 resources and more stringent QoS requirements -- the feasibility 715 of applying CONEX as well as its performance and deployment 716 scenarios need to be examined closer. For instance, a mobile 717 communication network may encounter longer delay and higher loss 718 rates, which can impose specific requirements on the timeliness 719 and accuracy of congestion exposure information. 721 Mobility: One of the unique characteristics in cellular network is 722 the presence of user mobility compared to wired networks. As the 723 user location changes, the same device can be connected to the 724 network via different base stations (eNodeBs) or even go through 725 switching gateways. Thus, the CONEX scheme must to be able to 726 carry latest congestion information per user/flow across multiple 727 network nodes in real-time. 729 Multi-access: In cellular networks, multiple access technologies can 730 co-exist. In such cases, a user can use multiple access 731 technologies for multiple applications or even a single 732 application simultaneously. If the congestion policies are set 733 based on each user, then CONEX should have the capability to 734 enable information exchange across multiple access domains. 736 Tunneling: Both 3G and LTE networks make extensive usage of 737 tunneling. The CONEX mechanism should be designed in a way to 738 support usage with different tunneling protocols such as PMIPv6 739 and GTP. For ECN-based congestion notification, [RFC6040] 740 specifies how the ECN field of the IP header should be constructed 741 on entry and exit from IP-in-IP tunnels, and 742 [I-D.briscoe-tsvwg-ecn-encap-guidelines] provides guidelines for 743 adding congestion notification to protocols that encapsulate IP. 745 Roaming: Independent of the specific architecture, mobile 746 communication networks typically differentiate between non-roaming 747 and roaming scenarios. Roaming scenarios are typically more 748 demanding regarding implementing operator policies, charging etc. 749 It can be expected that this would also hold for deploying CONEX. 750 A more detailed analysis of this problem will be provided in a 751 future revision of this document. 753 It is important to note that CONEX is intended to be used as a 754 supplement and not a replacement to the existing QoS mechanisms in 755 mobile networks. For example, CONEX deployed in 3GPP mobile networks 756 can provide useful input to the existing 3GPP PCC mechanisms by 757 supplying more dynamic network information to supplement the fairly 758 static information used by the PCC. This would enable the mobile 759 network to make better policy control decisions than is possible with 760 only static information. 762 5. IANA Considerations 764 No IANA considerations. 766 6. Security Considerations 768 Security considerations for applying CONEX to EPS include, but are 769 not limited to, the security considerations that apply to the CONEX 770 protocols. 772 7. References 774 7.1. Normative References 776 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 777 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 778 December 2012. 780 7.2. Informative References 782 [3GPP.23.401] 783 3GPP, "General Packet Radio Service (GPRS) enhancements 784 for Evolved Universal Terrestrial Radio Access Network 785 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 787 [3GPP.23.402] 788 3GPP, "Architecture enhancements for non-3GPP accesses", 789 3GPP TS 23.402 10.8.0, September 2012. 791 [3GPP.23.705] 792 3GPP, "System Enhancements for User Plane Congestion 793 Management", 3GPP TR 23.705 0.8.0, October 2013. 795 [3GPP.23.829] 796 3GPP, "Local IP Access and Selected IP Traffic Offload 797 (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. 799 [3GPP.26.114] 800 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 801 telephony; Media handling and interaction", 3GPP TS 26.114 802 10.7.0, June 2013. 804 [3GPP.29.060] 805 3GPP, "General Packet Radio Service (GPRS); GPRS 806 Tunnelling Protocol (GTP) across the Gn and Gp interface", 807 3GPP TS 29.060 3.19.0, March 2004. 809 [3GPP.29.274] 810 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 811 Packet Radio Service (GPRS) Tunnelling Protocol for 812 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 813 June 2013. 815 [3GPP.36.300] 816 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) 817 and Evolved Universal Terrestrial Radio Access Network 818 (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 819 10.11.0, September 2013. 821 [I-D.briscoe-conex-initial-deploy] 822 Briscoe, B., "Initial Congestion Exposure (ConEx) 823 Deployment Examples", 824 draft-briscoe-conex-initial-deploy-03 (work in progress), 825 July 2012. 827 [I-D.briscoe-tsvwg-ecn-encap-guidelines] 828 Briscoe, B., Kaippallimalil, J., and P. Thaler, 829 "Guidelines for Adding Congestion Notification to 830 Protocols that Encapsulate IP", 831 draft-briscoe-tsvwg-ecn-encap-guidelines-03 (work in 832 progress), September 2013. 834 [I-D.ietf-conex-abstract-mech] 835 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 836 Concepts and Abstract Mechanism", 837 draft-ietf-conex-abstract-mech-08 (work in progress), 838 October 2013. 840 [I-D.ietf-conex-destopt] 841 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 842 Destination Option for ConEx", draft-ietf-conex-destopt-05 843 (work in progress), October 2013. 845 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 846 Notification", RFC 6040, November 2010. 848 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 849 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 850 December 2012. 852 [conex-lite] 853 Baillargeon and Johansson, "ConEx Lite for Mobile 854 Networks", in proceedings of ACM SIGCOMM-2014 Capacity 855 Sharing Workshop (CSWS-2014), August 2014. 857 [dash] ISO/IEC, "ISO/IEC 23009-1: Information Technology -- 858 Dynamic Adaptive Streaming over HTTP (DASH) --", 859 April 2012. 861 [lte-sigcomm2013] 862 Huang, Qian, Guo, Zhou, Xu, Mao, Sen, and Spatscheck, "An 863 In-depth Study of LTE: Effect of Network Protocol and 864 Application Behavior on Performance", in proceedings 865 of ACM SIGCOMM-2013, August 2013. 867 [nec.euronf-2011] 868 Mir, Kutscher, and Brunner, "Congestion Exposure in 869 Mobility Scenarios", in proceedings of 7th EURO-NF 870 CONFERENCE ON NEXT GENERATION INTERNET, June 2011. 872 [nec.globecom2010] 873 Kutscher, Lundqvist, and Mir, "Congestion Exposure in 874 Mobile Wireless Communications", in proceedings of IEEE 875 GLOBECOM 2010, December 2010. 877 [raghavan2007] 878 Raghavan, Vishwanath, Ramabhadran, Yocum, and Snoeren, 879 "Cloud Control with Distributed Rate Limiting", in 880 proceedings of ACM SIGCOMM 2007, 2007. 882 DOI: http://doi.acm.org/10.1145/1282427.1282419 884 Appendix A. Acknowledgments 886 We would like to thank Bob Briscoe and Ingemar Johansson for their 887 support in shaping the overall idea and in improving the draft by 888 providing constructive comments. We would also like to thank Andreas 889 Maeder and Dirk Staehle for reviewing the draft and for providing 890 helpful comments. 892 Appendix B. Overview of 3GPP's Evolved Packet System (EPS) 894 This section provides an overview of 3GPP's "Evolved Packet System" 895 (EPS [3GPP.36.300], [3GPP.23.401]) as a specific example of a mobile 896 communication architecture. Of course other architectures exist but 897 the EPS is used as one example to demonstrate the applicability of 898 congestion exposure concepts and mechanisms. 900 The EPS architecture and some of its standardized interfaces are 901 depicted in Figure 1. The EPS provides IP connectivity to user 902 equipment (UE) (i.e., mobile nodes) and access to operator services, 903 such as global Internet access and voice communications. The EPS 904 comprises the radio access network called evolved UMTS Terrestrial 905 Radio Access Network (E-UTRAN) and the core network called Evolved 906 Packet Core (EPC). QoS is supported through an EPS bearer concept, 907 providing bindings to resource reservation within the network. 909 The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, 910 is part of the access network that provides radio resource 911 management, header compression, security and connectivity to the core 912 network through the S1 interface. In an LTE network, the control 913 plane signaling traffic and the data traffic are handled separately. 914 The eNBs transmit the control traffic and data traffic separately via 915 two logically separate interfaces. 917 The Home Subscriber Server, HSS, is a database that contains user 918 subscriptions and QoS profiles. The Mobility Management Entity, MME, 919 is responsible for mobility management, user authentication, bearer 920 establishment and modification and maintenance of the UE context. 922 The Serving gateway, S-GW, is the mobility anchor and manages the 923 user plane data tunnels during the inter-eNB handovers. It tunnels 924 all user data packets and buffers downlink IP packets destined for 925 UEs that happen to be in idle mode. 927 The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP 928 address allocation to the UE and is a tunnel endpoint for user and 929 control plane protocols. It is also responsible for charging, packet 930 filtering, and policy-based control of flows. It interconnects the 931 mobile network to external IP networks, e.g. the Internet. 933 In this architecture, data packets are not sent directly on an IP 934 network between the eNB and the gateways. Instead, every packet is 935 tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP 936 [3GPP.29.060]) over UDP/IP. A GTP path is identified in each node 937 with the IP address and a UDP port number on the eNB/gateways. The 938 GTP protocol carries both the data traffic (GTP-U tunnels) and the 939 control traffic (GTP-C tunnels [3GPP.29.274]). Alternatively Proxy 940 Mobile IP (PMIPv6) is used on the S5 interface between S-GW and P-GW. 942 The above is very different from an end-to-end path on the Internet 943 where the packet forwarding is performed at the IP level. 944 Importantly, we observe that these tunneling protocols give the 945 operator a large degree of flexibility to control the congestion 946 mechanism incorporated with the GTP/PMIPv6 protocols. 948 +-------+ 949 +-------+ | PCRF | 950 | HSS | /+-------+\ 951 +-------+ Gx/ \Rx 952 | / \ 953 | / \ 954 | +-------+ SGi +-------+ 955 | | P-GW |=========| AF | 956 | +-------+ +-------+ 957 HPMN | | 958 ------------------------------|--------------|---------------------- 959 VPLMN | | 960 +-------+ | 961 | MME | | 962 /+-------+\ |S8 963 S1-MME / \ | 964 / \S11 | 965 / \ | 966 +-----------+ \ | 967 +----+ LTE-Uu | | \ | 968 | UE |========| | S1-U +-------+ 969 +----+ | E-UTRAN |==============| S-GW | 970 | (eNBs) | +-------+ 971 | | 972 +-----------+ 974 Figure 5: EPS architecture overview (Roaming Case) 976 Appendix C. ChangeLog 978 C.1. draft-ietf-conex-mobile-04 980 o added conex lite to deployment scenarios 982 o added reference to LTE study paper at SIGCOMM-2013" 984 o restructured section 2 and 3 (moved 3GPP specifics out of section2 986 o added normative references section and put RFC6789 there 988 o updated references 990 C.2. draft-ietf-conex-mobile-03 992 o implemented suggestions for improving 3GPP EPS descriptions by 993 Andreas Maeder 995 o mentioned 3GPP UPCON and added reference 997 o updated references 999 o In section 3.1 (CONEX as a Basis for Traffic Management), changed 1000 the wording in the first abstract of the enumerated list to state 1001 that ConEx can enable/enhance flow policy-based traffic management 1002 -- not DPI (as we earlier said). DPI is not the objective -- it 1003 is the tool that is currently used... 1005 o merged section 3.4 (CONEX as a Form of Differential QoS) into 3.1 1006 (CONEX as a Basis for Traffic Management) 1008 o moved section 2 (Overview of 3GPP's Evolved Packet System (EPS)) 1009 to appendix. 1011 o renamed section "CONEX Use Cases in the Mobile Communication 1012 Scenario" to "CONEX Use Cases in Mobile Communication Networks" 1014 o updated TDF text in "CONEX as a Basis for Traffic Management" 1016 o added reference to 3GPP UPCON to summary 1018 C.3. Earlier 1020 o changed title to "Mobile Communication Congestion Exposure 1021 Scenario" (was "use case") 1023 o added new section 3 on "CONEX Uses Cases in mobile communication 1024 scenario" 1026 o removed "Motivation" section in section 4 1028 o removed "isolated connex deployment section in section 4" 1030 o renamed "EPS integration" section in section 4 to "Additional EPS 1031 integration options" 1033 o added a (still empty) summary section to section 4 1035 o s/Re-ECN/CONEX/g 1037 o added references 1039 o added acknowledgments 1041 Authors' Addresses 1043 Dirk Kutscher 1044 NEC 1045 Kurfuersten-Anlage 36 1046 Heidelberg, 1047 Germany 1049 Phone: 1050 Email: kutscher@neclab.eu 1052 Faisal Ghias Mir 1053 NEC 1054 Kurfuersten-Anlage 36 1055 Heidelberg, 1056 Germany 1058 Phone: 1059 Email: faisal.mir@neclab.eu 1061 Rolf Winter 1062 NEC 1063 Kurfuersten-Anlage 36 1064 Heidelberg, 1065 Germany 1067 Phone: 1068 Email: rolf.winter@neclab.eu 1070 Suresh Krishnan 1071 Ericsson 1072 8400 Blvd Decarie 1073 Town of Mount Royal, Quebec 1074 Canada 1076 Phone: 1077 Email: suresh.krishnan@ericsson.com 1078 Ying Zhang 1079 Ericsson 1080 200 Holger Way 1081 San Jose, CA 95134 1082 USA 1084 Phone: 1085 Email: ying.zhang@ericsson.com 1087 Carlos J. Bernardos 1088 Universidad Carlos III de Madrid 1089 Av. Universidad, 30 1090 Leganes, Madrid 28911 1091 Spain 1093 Phone: +34 91624 6236 1094 Email: cjbc@it.uc3m.es 1095 URI: http://www.it.uc3m.es/cjbc/