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