RFC 7778
Mobile Communication Congestion Exposure Scenario
Mobile Communication Congestion Exposure Scenario 🦋
(Part 1 of 5)
Okay bestie, let's start with the title block 📋✨ This is RFC 7778, and it's dated March 2016. It's in the Informational category, which means it's published for information and is not a standards-track spec 💅 Its ISSN is 2070-1721. The authors are D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang and CJ. Bernardos, from NEC, Ericsson, Hewlett Packard Labs and UC3M. It doesn't obsolete or update any other RFCs, since none are listed in the title block 🌸
Abstract ✨
Okay so this memo is all about a mobile communications use case for congestion exposure (ConEx) 📱 It focuses on mobile networks that are architecturally similar to the 3GPP Evolved Packet System (EPS), which is giving main character energy 💖 It gives a quick overview of how these networks work (both the access and core networks) and the current QoS mechanisms, then talks about how congestion exposure concepts could be applied. From that discussion, it suggests a set of requirements for ConEx mechanisms that especially apply to these mobile networks 🧚
Status of This Memo 🌈
This document is not an Internet Standards Track specification, so it's just published for informational purposes 🫶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it's gone through public review, and it's been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🔥
You can find info about the current status of this document, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc7778 💜
Copyright Notice 🎀
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🍓
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
2. ConEx Use Cases in Mobile Communication Networks . . . . . . 4
2.1. ConEx as a Basis for Traffic Management . . . . . . . . . 5
2.2. ConEx to Incentivize Scavenger Transports . . . . . . . . 7
2.3. Accounting for Congestion Volume . . . . . . . . . . . . 7
2.4. Partial vs. Full Deployment . . . . . . . . . . . . . . . 8
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. ConEx in the EPS . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9
3.2. Implementing ConEx Functions in the EPS . . . . . . . . . 14
3.2.1. ConEx Protocol Mechanisms . . . . . . . . . . . . . . 15
3.2.2. ConEx Functions in the Mobile Network . . . . . . . . 15
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Overview of 3GPP's EPS . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 241. Introduction ✨
Mobile data traffic keeps growing super fast 📈 The challenge wireless operators are facing is supporting more subscribers while bandwidth demand keeps climbing 😭 To meet those bandwidth requirements, we need new technologies that help operators use the available network resources efficiently. Two areas where new technologies could be really useful are resource allocation and flow management 💅
Analysis of data traffic in cellular networks has shown that most flows are short lived and low volume, but a comparatively small number of high-volume flows make up a large fraction of the overall traffic volume [lte-sigcomm2013]. So potentially a small fraction of users is responsible for most of the traffic in cellular networks 🙈 Given this highly skewed user behavior and limited, expensive resources (e.g., the wireless spectrum), resource allocation and usage accountability are two big issues operators need to solve in order to get better network resource utilization and fair resource sharing. ConEx, as described in [RFC6789], is a technology that can be used to achieve these goals 🔥
The ConEx mechanism is designed to be a general technology that could be applied as a key element of congestion management solutions for a variety of use cases. In particular, the use cases of interest for initial deployment are those where the end hosts and the network that contains the destination end hosts are ConEx-enabled, but other networks need not be 🌈
A specific example of such a use case is a mobile communication network such as a 3GPP EPS network, where UEs (User Equipment) (i.e., mobile end hosts), servers and caches, the access network, and possibly an operator's core network can be ConEx-enabled. That is, hosts support the ConEx mechanisms, and the network provides policing/auditing functions at its edges 🧚
This document gives a brief overview of the architecture of such networks (access and core networks) and the current QoS mechanisms. It then discusses how such networks can benefit from congestion exposure concepts and how they should be applied. Using this use case as a basis, a set of requirements for ConEx mechanisms is described 🦋
1.1. Acronyms 🌸
In this section, we expand some acronyms that are used throughout the text. Most are explained and put in a system context in Appendix A and in the 3GPP, ECN, and ConEx specifications referenced there 💜
eNB: Evolved NodeB: LTE base stationHSS: Home Subscriber ServerS-GW: Serving Gateway: mobility anchor and tunnel endpointP-GW: Packet Data Network (PDN) Gateway: tunnel endpoint for user-plane and control-plane protocols -- typically the GW to the Internet or an operator's service networkUE: User Equipment: mobile terminalsGTP: GPRS Tunneling Protocol [TS29060]GTP-U: GTP User Data Tunneling [TS29060]GTP-C: GTP Control [TS29060]
2. ConEx Use Cases in Mobile Communication Networks 🎀
In general, quality of service and good network resource utilization are important requirements for mobile communication network operators 👑 Radio access and backhaul capacity are considered scarce resources, and bandwidth (and radio resource) demand is hard to predict precisely because of user mobility, radio propagation effects, etc. So today's architectures and protocols go to great lengths to provide network-controlled quality of service. Those efforts often lead to complexity and cost 😭 ConEx could be a simpler and more capable approach to efficient resource sharing in these networks ✨
In the following sections, we discuss ways that congestion exposure could be beneficial for supporting resource management in such mobile communication networks. [RFC6789] describes fundamental congestion exposure concepts and a set of use cases for applying congestion exposure mechanisms to realize different traffic management functions, such as flow policy-based traffic management or traffic offloading 🍓 If you're not familiar with the 3GPP EPS, read Appendix A first, bestie 🫶
2.1. ConEx as a Basis for Traffic Management 🎀
okay bestie, traffic management is SO important in mobile networks 💅 Wireless resources are scarce, and user mobility plus shared bandwidth on the wireless access make the available bandwidth super dynamic. So commercial mobile networks have tight resource management tools (admission control for bearer establishment) 🦋. ngl, those tools don't always fit IP- and HTTP-heavy traffic mixes. Like, most internet traffic on today's mobile network just rides the (best-effort) default bearer 🌸
Given all that, and the huge jump in overall data volume in 3G networks, Deep Packet Inspection (DPI) is often seen as a desirable thing to have in the Evolved Packet Core (EPC), even though it's pricey and complicated 💀. And with more encrypted data traffic, traffic management using DPI alone is gonna get even more challenging 😭
Congestion exposure can help with resource management requirements in a few different ways:
- It can enable or enhance flow policy-based traffic management. Right now, DPI-based resource management is often used to prioritize certain application classes over others in overload situations, so more users can be served effectively on the network ✨. Operators use DPI to spot dispensable flows and make them yield to other flows (of different application classes) through policing. This kind of traffic management is based on operator decisions, using partly static configuration and some estimation about future per-flow bandwidth demand 🙈. With congestion exposure, it would be possible to assess the contribution to congestion of individual flows. That info can then feed a policer that can optimize network utilization more accurately and dynamically 👑. By using ConEx congestion contribution as a metric, such policers would not need to be aware of specific link loads (e.g., in wireless base stations) or flow application types 🧚
- It can reduce the need for complex DPI by allowing for a bulk packet traffic management system that doesn't have to consider either the application classes flows belong to or the individual sessions 💖. Instead, traffic management would be based on the current cost (contribution to congestion) incurred by different flows, and it would let operators apply policing/accounting depending on their preference. Such traffic management would be simpler and more robust (no real-time flow application type identification required, no static configuration of application classes). It would also perform better, since decisions can be made based on real-time actual cost contribution 🔥. With ConEx, accurate downstream path information would be visible to ingress network operators, who can respond to incipient congestion in time. This can be equivalent to offering different levels of QoS, e.g., premium service with zero congestion response. For that, ConEx could be used in two different ways:
A. as additional information to assist network functions to impose different QoS for different application sessions; and
B. as a tool to let applications decide on their response to congestion notification, while incentivizing them to react (in general) appropriately, e.g., by enforcing overall limits for congestion contribution or by accounting and charging for such congestion contribution. Note that this level of responsiveness would be on a different level than, say, application-layer responsiveness in protocols such as Dynamic Adaptive Streaming over HTTP (DASH) [dash]. However, it could interwork with such protocols, for example, by triggering earlier responses 🦋
- It can further be used to more effectively trigger the offload of selected traffic to a non-3GPP network. Nowadays, it's common for users to have dual-mode mobile phones (e.g., integrating third/fourth generation cellular and Wi-Fi radio devices) that can attach to available networks either sequentially or simultaneously 📱. With this scenario in mind, 3GPP is currently looking at mechanisms to seamlessly and selectively switch over a single IP flow (e.g., a user application) to a different radio access, while keeping all other ongoing connections untouched. The decision on when and which IP flows move is typically based on statically configured rules, whereas ConEx mechanisms could also factor real-time congestion information into the decision 🌈
In summary, traffic management in the 3GPP EPS and other mobile communication architectures is very important. Right now, more static approaches based on admission control and static QoS are in use, but recently there's been a perceived need for more dynamic mechanisms based on DPI. Introducing ConEx could make these mechanisms more efficient, or even remove the need for some of the DPI functions deployed today ⭐
2.2. ConEx to Incentivize Scavenger Transports 🍓
3G and LTE networks are turning into universal access networks that are shared between mobile (smart) phone users, mobile users with laptop PCs, home users with LTE access, and others 🌸. Capacity sharing among different users and application flows is becoming increasingly important in these mobile communication networks.
Most of this traffic is likely to be classified as best-effort traffic without differentiation. Think periodic OS updates and application store downloads, plus web-based (i.e., browser-based) communication or other real-time communication 💅. For many bulk data transfers, completion times aren't important within certain bounds. So if scavenger transports (or transports that are less than best effort) such as Low Extra Delay Background Transport (LEDBAT) [RFC6817] were used, it would improve the overall utility of the network 🧚. The use of these transports by the end user, however, needs to be incentivized. ConEx could be used to build an incentive scheme, e.g., by giving a larger bandwidth allowance to users who contribute less to congestion, or by lowering the next monthly subscription fee 💖. In principle, this would be possible to implement with current specifications.
2.3. Accounting for Congestion Volume 💜
3G and LTE networks already provide extensive support for accounting and charging. For example, see the Policy Charging Control (PCC) architecture [TS23203] 📊. In fact, most operators today account transmitted data volume on a very fine granular basis. They either correlate monthly charging to the exact number of packets/bytes transmitted, or employ some form of flat rate (or flexible flat rate), often with a so-called fair-use policy. With such policies, users are typically limited to an administratively configured maximum bandwidth limit after they've used up their contractual data volume budget for the charging period 🙈.
Changing this from volume-based accounting to congestion-based accounting would be possible in principle, especially since there's already an elaborate per-user accounting system available 👑. Also, an operator-provided mobile communication network can be seen as a network domain that would allow for such congestion volume accounting. This wouldn't require any support from the global Internet, especially since the typical scarce resources (such as the wireless access and the mobile backhaul) are all within this domain 🦋. Traffic normally leaves or enters the operator's network via well-defined egress/ingress points, which would be ideal candidates for policing functions. Moreover, in most commercially operated networks, accounting is performed for both received and sent data, which would make congestion volume accounting easier as well 🌈
With respect to the current Path Computation Client (PCC) framework, accounting for congestion volume could be added as another feature to the "Usage Monitoring Control" capability that is currently based on data volume. This wouldn't require a new interface (reference points) at all ✨
2.4. Partial vs. Full Deployment 🌸
In general, ConEx lends itself to partial deployment, since the mechanism doesn't require all routers and hosts to support congestion exposure 💖. Moreover, assuming a policing infrastructure has been put in place, it's not required to modify all hosts. Since ConEx is about senders exposing congestion contribution to the network, senders need to be made ConEx-aware (assuming a congestion notification mechanism such as Explicit Congestion Notification (ECN) is in place) 🫶
When moving towards full deployment in a specific operator's network, there are different ways to introduce ConEx support on UEs. Since mobile communication networks are multi-vendor networks, standardizing ConEx support on UEs (e.g., in 3GPP specifications) appears useful 🧚. Still, not all UEs would have to support ConEx, and operators would be free to choose their policing approach in such deployment scenarios. Leveraging existing PCC architectures, 3GPP network operators could, for example, decide policing/accounting approaches per UE. That means applying fixed volume caps for non-ConEx UEs and more flexible schemes for ConEx-enabled UEs 💅
Also worth noting: network support for ConEx is a feature that some operators may choose to deploy if they wish, but it's not required that all operators (or all other networks) do so 🦋
Depending on the extent of ConEx support, specific aspects such as roaming have to be taken into account. That means asking what happens when a user is roaming in a ConEx-enabled network but their UE isn't ConEx-enabled, and vice versa. Although these may not be fundamental problems, they still need to be considered 🙈. For supporting mobility in general, it can be required to shift users' policing state during a handover. There's existing work on distributed rate limiting (see [raghavan2007]) and on specific optimizations (see [nec.euronf-2011]) for congestion exposure and policing in mobility scenarios 🌈
Another aspect to consider is the addition of Selected IP Traffic Offload (SIPTO) and Local IP Access (LIPA) [TR23829]), i.e., the idea that some traffic, such as high-volume Internet traffic, is actually not passed through the EPC. Instead, it's offloaded at a "break-out point" closer to (or in) the access network 👑. On the other hand, ConEx can also enable more dynamic decisions on what traffic to actually offload, by considering congestion exposure in bulk traffic aggregates. That makes traffic offload more effective ⭐
2.5. Summary ✨
okay so the big takeaway 💅 the 3GPP EPS is a system architecture that can benefit from congestion exposure in multiple ways. Dynamic traffic and congestion management is an acknowledged and important requirement for the EPS, and the current DPI-related work for EPS shows that too 🔥
and honestly? EPS mobile networks would be super amenable to deploying ConEx as a mechanism 🦋 they're clearly defined, well-separated operational domains where local ConEx deployment would be possible. the one wrinkle is roaming, which needs its own consideration for any specific solution. otherwise the whole deployment is fully under a single operator's control, which means operator-local enhancements without needing major architecture changes. not me being impressed 😭
also, in 3GPP EPS, interfaces between all the elements of the architecture are subject to standardization, including UE interfaces and eNB interfaces 🌈 so a more general approach that involves more than one operator's network can be feasible too. bestie, the possibilities 🧚
3. ConEx in the EPS 💖
in this section we chat about a few options for how such a mechanism (and possibly additional policing functions) could eventually get deployed in the 3GPP EPS 🎀 quick disclaimer though: this isn't meant to be a complete list of every possible approach. it just covers the most promising options ✨
3.1. Possible Deployment Scenarios
there are different ways ConEx functions can be used on hosts and network elements 🌸 for example, ConEx could be used for only a limited part of the network (like the access network), congestion exposure and sender adaptation could involve the mobile nodes or not, or the ConEx feedback loop could extend beyond a single operator's domain or stay inside it. so many choices, iykyk 💅
we present four different deployment scenarios for congestion exposure in the figures below:
- In Figure 1, ConEx is supported by servers for sending data (web servers on the Internet and caches in an operator's network) but not by UEs, neither for receiving nor sending. an operator who runs a policing function on the network ingress, e.g., on the P-GW, can still benefit from congestion exposure without needing any change on UEs 🦋
- ConEx is universally employed between operators (as depicted in Figure 2) with an end-to-end ConEx feedback loop 🫶 operators could still use local policies, congestion accounting schemes, etc., and they could use information about congestion contribution to decide their interconnection agreements. this scenario would mean operators are willing to expose congestion to each other, which is a whole vibe 👑
- for Isolated ConEx domains (as depicted in Figure 3), ConEx is only applied locally inside the operator network, and there's no end-to-end congestion exposure 🙈 this could happen when ConEx is only implemented in a few networks, or when operators decide not to expose ECN and not to account for congestion on inter-domain traffic. no matter the actual scenario, there will likely be border gateways (like in today's deployments) associated with policing and accounting functions 🌈
- [conex-lite] describes an approach called "ConEx Lite" for mobile networks, intended for the initial deployment of congestion exposure concepts in LTE, specifically in the backhaul and core network segments 💜 as depicted in Figure 4, ConEx Lite lets a tunnel receiver monitor the volume of bytes that has been lost, dropped, or ECN-CE (Congestion Experienced) marked between the tunnel sender and receiver. to do that, a new field called the Byte Sequence Marker (BSN) is added to the tunnel header to identify the byte in the flow of data from the tunnel sender to the tunnel receiver ⭐ a policer at the tunnel sender is expected to react according to the tunnel congestion volume (see [conex-lite] for details) 🧚
+------------+
| Web server |
| w/ ConEx |
+------------+
|
|
|
-----------------------
| | |
| Internet | |
| | |
-----------------------
|
--------------------------------------------|--------
| | |
| +-----------+ |
| | Web cache | |
| | w/ ConEx | |
| +-----------+ |
| | |
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator A |
-----------------------------------------------------
Figure 1: ConEx Support on Servers and Caches -----------------------------------------------------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| | |
| Operator A | |
--------------------------------------------|--------
|
-----------------------
| |
| Internet |
| |
-----------------------
|
--------------------------------------------|--------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator B |
-----------------------------------------------------
Figure 2: ConEx Deployment across Operator Domains -----------------------------------------------------
| |--- ConEx path ---| |
| v v |
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| | |
| Operator A | |
--------------------------------------------|--------
|
-----------------------
| |
| Internet |
| |
-----------------------
|
--------------------------------------------|--------
| +----+ +-------+ +-------+ +-------+ |
| | UE |=====| eNB |=====| S-GW |=====| P-GW | |
| +----+ +-------+ +-------+ +-------+ |
| |
| Operator B |
-----------------------------------------------------
Figure 3: ConEx Deployment in a Single Operator Domain Backhaul Network Core Network
+---------------+ +--------------+
| | | |
| BSN or ECN-CE | | |
| marked | | |
| packets | | |
| <--- | | |
+----+ +-------+ +----------+ +-------+ +--------+
| | | | GTP-U | | GTP-U | | | |
| UE |=====| eNB |=======| S-GW |=======| P-GW |==|Internet|
| | | | Tunnel| | Tunnel| | | |
+----+ +-------+ +----------+ +-------+ +--------+
| ---> | | |
| User/control | | User/control |
| packets with | | packet with |
| DL congestion | | DL congestion|
| vol counters | | vol counters |
| | | |
+---------------+ +--------------+
Figure 4: ConEx Lite DeploymentNote: DL stands for "downlink".
3.2. Implementing ConEx Functions in the EPS
we expect a ConEx solution to consist of different functions that should be considered when implementing congestion exposure in the 3GPP EPS 🍓 [RFC7713] describes the following congestion exposure components:
- Modified senders that send congestion exposure information in response to congestion feedback. 📤
- Receivers that generate congestion feedback (leveraging existing behavior or requiring new functions). 📥
- Audit functions that audit ConEx signals against actual congestion, e.g., by monitoring flows or aggregates of flows. 🕵️
- Policy devices that monitor congestion exposure information and act on the flows according to the operator's policy. 👮
two aspects are important to consider: 1) how the ConEx protocol mechanisms would be implemented and what modifications to existing networks would be required, and 2) where ConEx functional entities would be placed best (to allow for a non-invasive addition) 🫶 we'll dig into these two aspects in the following sections, so stay tuned, bestie 💜
3.2.1. ConEx Protocol Mechanisms
okay bestie 💅 the most important step when introducing ConEx is adding the congestion exposure functionality to senders ✨. For an initial deployment, no further modification to senders and receivers is required 🫶. There's no fundamental dependency on ECN, so ConEx can be introduced without ECN being implemented at all 🌸.
Congestion exposure information for IPv6 [CONEX-DESTOPT] lives in a destination option header field 🎀. It needs minimal changes at senders and at nodes that want to assess path congestion, and it does not affect non-ConEx nodes in a network 🦋.
In 3GPP networks, IP tunneling is used intensively 🌈, meaning either IP-in-GTP-U or Proxy Mobile IPv6 (PMIPv6) (i.e., IP-in-IP) tunnels. In general, the ConEx destination option of encapsulated packets should be made available to network nodes on the tunnel path. In other words, a tunnel ingress should copy the ConEx destination option field to the outer header 🧚.
For effective and efficient capacity sharing, we envisage deploying ECN alongside ConEx 💜. That way, ECN-enabled receivers and senders get more accurate and more timely information about the congestion contribution of their flows. ECN is already partially introduced into 3GPP networks: Section 11.6 in [TS36300] specifies the usage of ECN for congestion notification on the radio link (between eNB and UE), and [TS26114] specifies how this can be leveraged for voice codec adaptation. A complete, end-to-end support of ECN would require specification of tunneling behaviour, which should be based on [RFC6040] (for IP-in-IP tunnels). Specifically, a specification for tunneling ECN in GTP-U will be needed 😭.
3.2.2. ConEx Functions in the Mobile Network
this section is all about possible placement strategies for ConEx functional entities (covering both policing and auditing functions) in the EPS 🎀. We'll also look at possible optimizations for both the uplink and the downlink 🔥.
In general, ConEx information (exposed congestion) is declared by a sender and stays unchanged on the path. So reading ConEx information (e.g., by policing functions) is placement-agnostic 💅. Auditing ConEx is different: it normally requires assessing the declared congestion contribution against the current actual congestion. If the latter is done using ECN, for example, that auditing function would best be placed at the end of the path 🦋.
To build a comprehensive ConEx-based capacity management framework for the EPS, it would be advantageous to consider user contribution to congestion for both the radio access and the core network 🌸. For a non-invasive introduction, it can be beneficial to combine ConEx functions with existing logical EPS entities. For example, potential places for ConEx policing and auditing functions would be eNBs, S-GWs, or P-GWs. Operator deployments may, of course, still provide additional intermediary ConEx-enabled IP network elements ✨.
It's worth distinguishing downlink and uplink traffic directions for a more specific discussion (also see [nec.globecom2010] for a more detailed discussion) 🫶. In today's networks and usage models, downlink traffic dominates 🌈. This is also reflected by the asymmetric capacity provided by the LTE radio interface. That doesn't mean uplink congestion isn't an issue, though. The asymmetric maximum bandwidth configuration can create a smaller bottleneck for uplink traffic. And of course, backhaul links, gateways, etc., could be overloaded as well 💀.
For managing downlink traffic (e.g., in scenarios such as the one depicted in Figure 1), operators can have different requirements for policing traffic 💜. Policing is, in principle, location-agnostic. Still, it's important to consider requirements related to the EPS architecture (Figure 5), such as tunneling between P-GWs and eNBs 👑. Policing can require access to subscriber information (e.g., congestion contribution quota) or user-specific accounting. That suggests the ConEx function could be co-located with the P-GW, which already has an interface towards the Policy and Charging Rule Function (PCRF) 🧚.
Policing can also serve different purposes. For example, if the objective is to police bulk traffic induced by peer networks, additional monitoring functions can be placed directly at corresponding ingress points. Those monitoring functions can then monitor traffic and possibly drive out-of-band functions, such as triggering border contract penalties 😭.
The auditing function should be placed at the end of the path (at least after/at the last bottleneck). It would most likely be placed best on the eNB (wireless base station) 🍓.
For the uplink direction, there are naturally different options for designing monitoring and policy enforcement functions 🦋. A likely approach is to monitor congestion exposure on central gateway nodes (such as P-GWs) that provide the required interfaces to the PCRF. Then, policing actions are performed in the access network (i.e., in eNBs). For example, the traffic is policed at the ingress before it reaches concentration points in the core network 🌈.
This setup would enable all the ConEx use cases described in Section 2 without requiring significant changes to the EPS architecture 🎀. It would also let operators re-use existing infrastructure, specifically wireless base stations, PCRF, and Home Subscriber Server (HSS) systems 👑.
For ConEx functions on elements such as the S-GWs and P-GWs, it's important to consider mobility and tunneling protocol requirements 🌸. LTE provides two alternative approaches: PMIPv6 [TS23402] and the GPRS Tunneling Protocol (GTP). For the propagation of congestion information (responses), tunneling considerations are therefore very important 😭.
In general, policing will be done based on per-user (per-subscriber) information, such as congestion quota and current quota usage. It will also rely on network operator policies, e.g., specifying how to react to persistent congestion contribution 💅. In the EPS, per-user information is normally part of the user profile stored in the HSS. PCC entities such as the PCRF would access that profile for dynamic updates, enforcement, and so on ✨.
4. Summary ✨
okay so we've shown how congestion exposure can be useful for efficient resource management in mobile communication networks 🫶. The premise was the observation that data communication, specifically best-effort bulk data transmission, is becoming a commodity service, while resources are obviously still limited 💜. That calls for efficient, scalable, and yet effective capacity sharing in these networks 🌈.
ConEx can be a mechanism that enables that kind of capacity sharing, while letting operators apply it in different ways. For example, they can implement different use cases as described in Section 2 🎀. It's important to note that ConEx is fundamentally a mechanism that can be applied in different ways to realize the policies of different operators 👑.
ConEx may also be used to complement 3GPP-based mechanisms for congestion management that are currently under development, such as the User Plane Congestion Management (UPCON) work item described in [TR23705] 🦋.
We've described a few possibilities for adding ConEx as a mechanism to 3GPP LTE-based networks, and shown how this could be done incrementally (starting with partial deployment) 🌸. It's quite feasible that such partial deployments are done on a per-operator-domain basis without requiring changes to standard 3GPP interfaces 🧚.
For network-wide deployment, e.g., with congestion exposure between operators, more considerations might be needed 💀.
We've also identified a few implications and requirements that should be taken into consideration when enabling congestion exposure in these networks 🔥:
- Performance: In mobile communication networks with more expensive resources and more stringent QoS requirements, the feasibility of applying ConEx, as well as its performance and deployment scenarios, needs to be examined more closely. For instance, a mobile communication network may encounter longer delay and higher loss rates. That can impose specific requirements on the timeliness and accuracy of congestion exposure information 😭.
- Mobility: One of the unique characteristics of cellular networks, compared to wired networks, is the presence of user mobility. As the user's location changes, the same device can be connected to the network via different base stations (eNBs) or even go through switching gateways. Thus, the ConEx scheme must to be able to carry the latest congestion information per user/flow across multiple network nodes in real time 🛸.
- Multi-access: In cellular networks, multiple access technologies can co-exist. A user can use multiple access technologies for multiple applications, or even a single application, simultaneously. If congestion policies are set based on each user, then ConEx should have the capability to enable information exchange across multiple access domains 💜.
- Tunneling: Both 3G and LTE networks make extensive use of tunneling. The ConEx mechanism should be designed to support usage with different tunneling protocols, such as PMIPv6 and GTP. For ECN-based congestion notification, [RFC6040] specifies how the ECN field of the IP header should be constructed on entry and exit from IP-in-IP tunnels 🌈.
- Roaming: Independent of the specific architecture, mobile communication networks typically differentiate between non-roaming and roaming scenarios. Roaming scenarios are typically more demanding when it comes to implementing operator policies, charging, etc. It can be expected that this also holds for deploying ConEx. A more detailed analysis of this problem will be provided in a future revision of this document 🙈.
It's important to note that ConEx is intended to be used as a supplement, not a replacement, for the existing QoS mechanisms in mobile networks 👑. For example, ConEx deployed in 3GPP mobile networks can provide useful input to the existing 3GPP PCC mechanisms by supplying more dynamic network information. That supplements the fairly static information used by the PCC. This would enable the mobile network to make better policy control decisions than is possible with only static information 🎀.
5. Security Considerations 🔥
⚠️ this part is seriously important, so read it carefully, bestie!
For any ConEx deployment, it's vital to apply appropriate mechanisms that preclude applications and senders from misstating their congestion contribution 💀. [RFC7713] discusses this problem in detail and introduces the ConEx auditing concept. ConEx auditing can be performed in different ways. For example, flows can be constantly audited, or only audited on demand when network operators decide to do so 😭. Coarse-grained auditing may operate on flow aggregates for efficiency reasons, whereas fine-grained auditing would inspect individual flows 🧐. In mobile networks, there may be deployment strategies that favor efficiency over very exact auditing. It's important to understand these trade-offs and to apply ConEx auditing appropriately 🫶.
The ConEx protocol specifications [CONEX-DESTOPT] and [TCP-MOD] discuss additional security considerations that also apply to mobile network deployments 🛡️.
6. Informative References ✨
okay bestie, this is the receipts section 🧾 every paper, draft, and spec the RFC leaned on, and I'm copying each one exactly so nobody gets lost trying to find them 🔍
- [CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., Briscoe, B., and C. Ralli, "IPv6 Destination Option for Congestion Exposure (ConEx)", Work in Progress, draft-ietf-conex-destopt-12, January 2016.
- [conex-lite] Baillargeon, S. and I. Johansson, "ConEx Lite for Mobile Networks", In Proceedings of the 2014 ACM SIGCOMM Capacity Sharing Workshop, DOI 10.1145/2630088.2630091, August 2014.
- [dash] ISO/IEC, "Information Technology -- Dynamic Adaptive Streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2014, May 2014.
- [lte-sigcomm2013] Huang, J., Qian, F., Guo, Y., Zhou, Y., Xu, Q., Mao, Z., Sen, S., and O. Spatscheck, "An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance", In Proceedings of the 2013 ACM SIGCOMM Conference, DOI 10.1145/2486001.2486006, August 2013.
- [nec.euronf-2011] Mir, F., Kutscher, D., and M. Brunner, "Congestion Exposure in Mobility Scenarios", In Proceedings of the 7th Euro-NF Conference on Next Generation Internet (NGI), DOI 10.1109/NGI.2011.5985948, June 2011.
- [nec.globecom2010] Kutscher, D., Lundqvist, H., and F. Mir, "Congestion Exposure in Mobile Wireless Communications", In Proceedings of 2010 IEEE Global Telecommunications Conference (GLOBECOM), DOI 10.1109/GLOCOM.2010.5684362, December 2010.
- [raghavan2007] Raghavan, B., Vishwanath, K., Ramabhadran, S., Yocum, K., and A. Snoeren, "Cloud Control with Distributed Rate Limiting", ACM SIGCOMM Computer Communication Review, DOI 10.1145/1282427.1282419, October 2007.
- [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010,
<http://www.rfc-editor.org/info/rfc6040>. - [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012,
<http://www.rfc-editor.org/info/rfc6789>. - [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>. - [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015,
<http://www.rfc-editor.org/info/rfc7713>. - [TCP-MOD] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, draft-ietf-conex-tcp-modifications-10, October 2015.
- [TR23705] 3GPP, "System Enhancements for User Plane Congestion Management", 3GPP TR 23.705 13.0.0, December 2015.
- [TR23829] 3GPP, "Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011.
- [TS23203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 13.6.0, December 2015.
- [TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 13.5.0, December 2015.
- [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 13.4.0, December 2015.
- [TS26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 13.2.0, December 2015.
- [TS29060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 13.3.0, December 2015.
- [TS29274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 13.4.0, December 2015.
- [TS36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 13.2.0, January 2016.
Appendix A. Overview of 3GPP's EPS 🧚
okay so this appendix is a little tour of the 3GPP "Evolved Packet System" (EPS, see [TS36300] [TS23401]) 📡 it's used as one example of a mobile communication architecture. Of course other architectures exist, but the EPS shows how the congestion exposure ideas and mechanisms apply in practice 💅
The EPS architecture and some of its standardized interfaces are drawn in Figure 5 below 🌸 The EPS gives IP connectivity to UE (aka mobile nodes) and access to operator services, like global Internet access and voice calls 📞 It's made of two parts: the radio access network called Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and the core network called the Evolved Packet Core (EPC) 🫶 QoS is handled through an EPS bearer concept, which binds traffic to resource reservations inside the network 🎀
+-------+
+-------+ | PCRF |
| HSS | /+-------+\
+-------+ Gx/ \Rx
| / \
| / \
| +-------+ SGi +-------+
| | P-GW |=========| AF |
| +-------+ +-------+
HPLMN | |
------------------------------|--------------|----------------------
VPLMN | |
+-------+ |
| MME | |
/+-------+\ |S8
S1-MME / \ |
/ \S11 |
/ \ |
+-----------+ \ |
+----+ LTE-Uu | | \ |
| UE |========| | S1-U +-------+
+----+ | E-UTRAN |==============| S-GW |
| (eNBs) | +-------+
| |
+-----------+Figure 5: EPS Architecture Overview (Roaming Case)
Here's the cast of characters 👑 (the note from the figure, verbatim):
- HPLMN - Home Public Land Mobile Network
- VPLMN - Visited Public Land Mobile Network
- AF - Application Function
- SGi - Service Gateway Interface
- LTE-Uu - LTE Radio Interface
The Evolved NodeB (eNB) is the LTE base station 📶 It's part of the access network and handles radio resource management, header compression, security, and connectivity to the core network through the S1 interface. In an LTE network the control-plane signaling and the data traffic are handled separately, so the eNBs send control traffic and data traffic over two logically separate interfaces 🧠
The Home Subscriber Server (HSS) is a database holding user subscriptions and QoS profiles 🗂️ The Mobility Management Entity (MME) is in charge of mobility management, user authentication, bearer establishment and modification, and keeping up the UE context 🦋
The Serving Gateway (S-GW) is the mobility anchor and manages the user-plane data tunnels during inter-eNB handovers. It tunnels all user data packets and buffers downlink IP packets for UEs that happen to be in idle mode 💜
The PDN Gateway (P-GW) is responsible for allocating IP addresses to the UE, and it's a tunnel endpoint for user-plane and control-plane protocols 🌈 It also takes care of charging, packet filtering, and policy-based control of flows 💅 It connects the mobile network to external IP networks, like the Internet ✨
Now the plot twist 😭 In this architecture, data packets are NOT sent directly on an IP network between the eNB and the gateways. Instead, every packet goes through a tunneling protocol, the GPRS Tunneling Protocol (GTP) [TS29060] over UDP/IP 🧚 A GTP path is identified in each node by an IP address and a UDP port number on the eNB or gateways. GTP carries both the data traffic (GTP-U tunnels) and the control traffic (GTP-C tunnels [TS29274]). Alternatively, PMIPv6 is used on the S5 interface between the S-GW and the P-GW 🎀
This is super different from an end-to-end path on the Internet, where packet forwarding happens at the IP level 🌸 And the key thing: these tunneling protocols give the operator a LOT of flexibility to control the congestion mechanism built into the GTP/PMIPv6 protocols 👑
Acknowledgements 🫶
We're so grateful to Bob Briscoe and Ingemar Johansson 💖 They helped shape the overall idea and made the document better with constructive comments. We also want to thank Andreas Maeder and Dirk Staehle for reviewing the document and leaving helpful comments 🙈
Authors' Addresses 💌
Dirk Kutscher
NEC
Kurfuersten-Anlage 36
Heidelberg
Germany
Email: kutscher@neclab.eu
Faisal Ghias Mir
NEC
Kurfuersten-Anlage 36
Heidelberg
Germany
Email: faisal.mir@gmail.com
Rolf Winter
NEC
Kurfuersten-Anlage 36
Heidelberg
Germany
Email: rolf.winter@neclab.eu
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: suresh.krishnan@ericsson.com
Ying Zhang
Hewlett Packard Labs
3000 Hannover Street
Palo Alto, CA 94304
United States
Email: ying.zhang13@hp.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/🦋 and that's a wrap on RFC 7778, bestie 💖✨
📦 where this page comes from
- ietf: rfc7778 2016-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms