RFC 7068
Diameter Overload Control Requirements
Part 1 of 6 🎀
RFC 7068: Diameter Overload Control Requirements 💅
Okay bestie, here's the tea on this one ☕✨
Request for Comments: 7068, from the Internet Engineering Task Force (IETF) 🌸
Authors: E. McMurry and B. Campbell, both at Oracle 💖
Category: Informational, so it's published for info, not as a standards-track spec 🧚
ISSN: 2070-1721 🦋
Date: November 2013 🍓
Obsoletes and updates: none listed. This doc doesn't replace or change any other RFCs 🫶
Abstract ✨
When a Diameter server or agent gets overloaded, it needs to be able to gracefully reduce its load, usually by telling clients to slow down for a bit. If it doesn't, it keeps burning resources parsing and answering Diameter messages, and the overload can get worse and worse 😭 Diameter's existing mechanisms just aren't enough to manage overload. This doc walks through their limitations and lays out requirements for new overload management mechanisms 💅
Status of This Memo 🎀
This document is not an Internet Standards Track specification. It's published for informational purposes only 📚
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 🔍
For the latest status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7068 🌈
Copyright Notice 🔒
Copyright (c) 2013 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧾
Table of Contents 📖
1. Introduction ....................................................4
1.1. Documentation Conventions ..................................4
1.2. Causes of Overload .........................................5
1.3. Effects of Overload ........................................6
1.4. Overload vs. Network Congestion ............................6
1.5. Diameter Applications in a Broader Network .................7
2. Overload Control Scenarios ......................................7
2.1. Peer-to-Peer Scenarios .....................................8
2.2. Agent Scenarios ...........................................10
2.3. Interconnect Scenario .....................................14
3. Diameter Overload Case Studies .................................15
3.1. Overload in Mobile Data Networks ..........................15
3.2. 3GPP Study on Core Network Overload .......................16
4. Existing Mechanisms ............................................17
5. Issues with the Current Mechanisms .............................18
5.1. Problems with Implicit Mechanism ..........................18
5.2. Problems with Explicit Mechanisms .........................18
6. Extensibility and Application Independence .....................19
7. Solution Requirements ..........................................20
7.1. General ...................................................20
7.2. Performance ...............................................21
7.3. Heterogeneous Support for Solution ........................22
7.4. Granular Control ..........................................23
7.5. Priority and Policy .......................................23
7.6. Security ..................................................23
7.7. Flexibility and Extensibility .............................24
8. Security Considerations ........................................25
8.1. Access Control ............................................25
8.2. Denial-of-Service Attacks .................................26
8.3. Replay Attacks ............................................26
8.4. Man-in-the-Middle Attacks .................................26
8.5. Compromised Hosts .........................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................27
Appendix A. Contributors ..........................................29
Appendix B. Acknowledgements ......................................291. Introduction 🧚
A Diameter [RFC6733] node counts as overloaded when it doesn't have enough resources to successfully process every Diameter request it receives 😩 When a node gets overloaded, it needs to be able to gracefully reduce its load, usually by telling clients to slow down for some period of time. If it doesn't, it keeps burning resources parsing and responding to Diameter messages, and the overload can get progressively more severe. The mechanisms Diameter already provides aren't enough for managing overload. This doc describes their limitations and gives requirements for new overload management mechanisms 💖
This doc builds on the SIP overload control work ([RFC5390], [RFC6357]), plus experience handling overload in Signaling System No. 7 (SS7) networks, and studies done by the Third Generation Partnership Project (3GPP) (Section 3) 📚
Diameter isn't usually an end-user protocol. It's generally one piece of a bigger setup that supports some end-user activity 🫶
For example, a SIP server might use Diameter to authenticate and authorize user access. Overload in the Diameter backend will likely affect what the end user sees in the SIP application 😬
How Diameter overload hits the client application is out of scope here. A client application might use Diameter along with other protocols to do its job 🎀
This doc has non-normative descriptions of causes of overload, plus related scenarios and studies. At the end, it offers a set of normative requirements for an improved overload indication mechanism 👑
1.1. Documentation Conventions 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as defined in [RFC2119]. The one difference is that they aren't meant for interoperability of implementations. Instead, they describe requirements for future specifications, where the interoperability requirements will be defined 🔥
Heads up bestie: these key words are not meant for interoperability in this doc. They're just describing what future specs will need 💅
The terms "client", "server", "agent", "node", "peer", "upstream", and "downstream" are used as defined in [RFC6733] 🌸
1.2. Causes of Overload 💀
Overload happens when an element, like a Diameter server or agent, doesn't have enough resources to successfully process all the traffic it's getting 😵 Resources cover everything the element uses to process a request, including CPU, memory, I/O, and disk. It can also include external resources, like a database or DNS server. In that case, those elements' CPU, memory, I/O, and disk effectively become part of the logical element handling the request 🧠
External resources can include upstream Diameter nodes. For example, a Diameter agent can get effectively overloaded if one or more of its upstream nodes are overloaded 🌊
A Diameter node can get overloaded because request levels go past its capacity, because its available resources drop (say, a local or upstream hardware failure), or because of a mix of both 🫠
Overload can happen for lots of reasons, including:
- Inadequate capacity: Designing Diameter networks (that's application-layer, multi-node Diameter deployments) is super hard, because it's tough to predict every scenario that could cause extra traffic. It can also cost more than a network operator thinks is worth it to support some scenarios. So a Diameter network probably won't have enough capacity for every situation 📉
- Dependency failures: A Diameter node can get overloaded when a resource it depends on fails or gets overloaded, which greatly cuts down the node's logical capacity. In these cases, even minimal traffic might push the node into overload. Examples include DNS servers, databases, disks, and network interfaces that have failed or become overloaded 🥲
- Component failures: A Diameter node can get overloaded when it's part of a cluster of servers that all share the traffic load, and one or more other members of the cluster fail. The remaining nodes then take over the failed nodes' work. Normally, capacity planning accounts for these failures, and servers usually run with enough spare capacity to handle another node failing. Still, unusual failure conditions can make lots of nodes fail at once. This often happens with software failures, where a bad packet or bad database entry hits the same bug across a set of nodes in a cluster 🐛
- Network-initiated traffic flood: Certain access network events can set off floods of Diameter signaling traffic. For example, operational changes can trigger avalanche restarts, or frequent radio overlay handovers can generate excessive authorization requests. A Diameter proxy failing can also cause a big pile of signaling as connections and sessions get reestablished 🌊
- Subscriber-initiated traffic flood: Big gatherings of subscribers, or events that get lots of subscribers using the network at nearly the same time, can cause Diameter signaling floods. For example, right after a huge fireworks show ends, tons of subscribers might post messages, pictures, and videos all concentrated on one part of the network 🎆 Subscriber devices like smartphones can also use aggressive registration strategies that cause unusually high Diameter traffic loads 📱
- DoS attacks: An attacker who wants to disrupt service can send a huge amount of traffic at a target element. That can come from one central source or through a distributed DoS attack. Either way, the volume of traffic far exceeds the element's capacity and sends the system into overload 🚨
1.3. Effects of Overload ✨
okay so picture this, bestie 🫶 modern Diameter networks are made of lots of Diameter elements spread across multiple nodes at the application layer, and they can handle absolutely HUGE transaction volumes 💅 if one node gets overloaded or, even worse, totally fails 😭 a ton of messages can get lost super fast. even with redundant servers, plenty of messages can vanish while failover is still happening 💀
a Diameter client or agent should be able to retry those requests, obviously 🎀 but here's the catch: an overloaded peer can cause a sudden giant spike in retries, which fills up local queues or otherwise makes the local node overloaded too 🥲 it's giving domino effect fr fr. so Diameter devices need to be able to shed load before critical failures can happen 🦋
1.4. Overload vs. Network Congestion 🌸
so this document uses "overload" to mean application-layer overload at Diameter nodes ✨ that is not the same thing as "network congestion," which is congestion at the lower networking layers that can mess with delivery of Diameter messages between nodes 🙈 ngl they're totally intertwined though: element overload and network congestion can feed into each other, and overload can cause congestion and vice versa 🔄
network congestion is better handled by the transport protocols 🚚 Diameter uses TCP and the Stream Control Transmission Protocol (SCTP), and both of them already have congestion management features 💖 whether those features are enough for transport-level congestion between Diameter nodes, and whether any further work to mitigate network congestion is needed, is out of scope for both this document and the work it proposes 🚫 not our vibe here, bestie.
1.5. Diameter Applications in a Broader Network 🌍
most elements that run Diameter applications don't use Diameter exclusively 💅 and it's important to realize that an element can become overloaded for a bunch of reasons that have nothing to do with Diameter or Diameter applications 🧚
so an element that doesn't use Diameter exclusively needs to be able to tell its Diameter peers that it's overloaded, no matter what caused it 🫶 because the overload will hit its ability to process Diameter transactions anyway 😭 if the element talks other protocols too, it might also need to signal the overload on those, depending on its function and on the architecture and application it's serving 🌈 whether that's needed can only be decided within that specific architecture and use cases 🤓
this spec details the requirements for a mechanism for signaling overload with Diameter ✨ it lets Diameter nodes tell their Diameter peers about overload, which handles that part of the problem 💜 Diameter nodes may need to use this alongside other mechanisms to fix their broader overload issues 🛠️ and indicating overload on protocols other than Diameter is out of scope for this document and the work it proposes 🙅♀️
2. Overload Control Scenarios 🎬
several Diameter deployment scenarios exist that can impact overload management 🍓 the scenarios below help motivate the requirements for an overload management mechanism 💅
these scenarios are by no means exhaustive, and they're simplified for clarity 🦋 specifically, this document assumes that the client sends Diameter requests to the server and the server sends responses back to the client, even though Diameter supports bidirectional applications 🔁 each direction can be modeled separately ✨
in a large-scale deployment, lots of the nodes in these scenarios would actually be clusters of servers 🌸 this document assumes that a cluster manages its own internal load-balancing and overload management, so it looks like a single Diameter node 👑 other Diameter nodes can treat it as one big monolithic node for overload management purposes 🫶
these scenarios don't show the client application 🙈 as mentioned in Section 1, Diameter isn't usually an end-user protocol; it's generally used to support some other client application 💖 these scenarios also don't consider how Diameter overload affects that client application 🤷♀️
2.1. Peer-to-Peer Scenarios 🤝
this section covers Diameter peer-to-peer scenarios, meaning a Diameter client talks directly to a Diameter server with no Diameter agent in the middle 💜
Figure 1 shows the simplest possible Diameter relationship 🎀 the client and server have a one-to-one peer-to-peer relationship 🫶 if the server gets overloaded, either because the client is sending more than the server can handle or because the server's capacity dropped due to some resource dependency, the client needs to reduce how much Diameter traffic it sends to the server 📉 since the client can't forward requests to another server, it has to either queue requests until the server recovers or become overloaded itself, in the context of the client application and any other protocols it uses too 😭
+------------------+
| |
| |
| Server |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+Figure 1: Basic Peer-to-Peer Scenario 📸
Figure 2 shows a similar setup, except this time the client has multiple servers that can handle work for a specific realm and application 🌈 if Server 1 gets overloaded, the client can forward traffic to Server 2 🔀 assuming Server 2 has enough reserve capacity to handle the forwarded traffic, the client should be able to keep serving its client application users 🙌 if Server 1 is approaching overload but can still handle some new requests, it needs to be able to tell the client to forward a subset of its traffic to Server 2 🧚
+------------------+ +------------------+
| | | |
| | | |
| Server 1 | | Server 2 |
| | | |
+--------+-`.------+ +------.'+---------+
`. .'
`. .'
`. .'
`. .'
+-------`.'--------+
| |
| |
| Client |
| |
+------------------+Figure 2: Multiple-Server Peer-to-Peer Scenario 🌟
Figure 3 illustrates a peer-to-peer scenario with multiple Diameter realm and application combinations 🗺️ in this example, Server 2 can handle work for both applications 👯 each application might have different resource dependencies 🗄️ for example, a server might need to access one database for Application A and a different one for Application B 🙃 this creates a possibility that Server 2 becomes overloaded for Application A but not for Application B 😬 in that case the client would need to divert some of its Application A requests to Server 1, but it should not divert any Application B requests 🚫 this requires that Server 2 be able to tell the applications apart when it signals an overload condition to the client 🧠
on the other hand, servers can host many applications 🏢 if Server 2 becomes overloaded for all applications, it would be undesirable for it to notify the client separately for each one 🙅♀️ so it also needs a way to indicate that it's overloaded for all possible applications 🌍
+---------------------------------------------+
| Application A +----------------------+----------------------+
|+------------------+ | +----------------+ | +------------------+|
|| | | | | | | ||
|| | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | ||
|+--------+---------+ | +-------+--------+ | +-+----------------+|
| | | | | | |
+---------+-----------+----------+-----------+ | |
| | | | |
| | | | Application B |
| +----------+----------------+-----------------+
``-.._ | |
`-..__ | _.-''
`--._ | _.-''
``-._ | _.-''
+-----`-.-''-----+
| |
| |
| Client |
| |
+----------------+Figure 3: Multiple-Application Peer-to-Peer Scenario 💫
2.2. Agent Scenarios 🎀
okay so this section is all about scenarios with a Diameter agent in the middle, either a Diameter relay or a Diameter proxy 🦋. We're skipping Diameter redirect agents bc they're way easier to model as end servers, fr. The examples are kept super simple on purpose so the basic ideas are clear, but real topologies can get WAY more complicated, with multiple intermediate agents on a path connected in all kinds of ways 💀
Figure 4 shows the simplest version: one client, one agent, and one server 💖. Overload can happen at the server, at the agent, or at both. But ngl, in most cases the client acts the same either way. From the client's point of view, server overload and agent overload are literally the same thing 😭
+------------------+
| |
| |
| Server |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Agent |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
Figure 4: Basic Agent ScenarioFigure 5 is an agent with multiple servers ✨. If Server 1 gets overloaded but Server 2 has spare capacity, the agent may be able to quietly divert some or all of the Diameter requests headed for Server 1 over to Server 2. Iconic agent behavior 💅.
+------------------+ +------------------+
| | | |
| | | |
| Server 1 | | Server 2 |
| | | |
+--------+-`.------+ +------.'+---------+
`. .'
`. .'
`. .'
`. .'
+-------`.'--------+
| |
| |
| Agent |
| |
+--------+---------+
|
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
Figure 5: Multiple-Server Agent ScenarioThe client usually doesn't know much about the Diameter topology upstream of the agent 🙈. If the agent uses dynamic discovery to find eligible servers, the client may not be able to list the eligible servers at all. So most of the time the agent has to handle upstream overload issues in a way that's transparent to the client. If one server tells the agent it's overloaded, that notification should not get passed back to the client in a way the client could mistakenly think the agent itself is overloaded 🫶. And if every possible destination upstream of the agent no longer has enough room for incoming load, then the agent itself becomes effectively overloaded 😩.
BUT there are times the client needs to pick a particular server behind an agent 🧚. Like, if a Diameter request is part of a multiple-round-trip authentication, or it's otherwise part of a Diameter "session", it may carry a Destination-Host Attribute-Value Pair (AVP) that says the request has to be served by Server 1. So the agent may need to tell the client that a specific upstream server is overloaded or otherwise unavailable. Also, a server can be specified in lots of different ways, and each one can have different implications (e.g., by IP address, by host name, etc) 👑.
Figure 6 shows an agent routing requests to a set of servers for more than one Diameter realm and application 🌈. If Server 1 becomes overloaded or unavailable while Server 2 still has available capacity, the agent may effectively run at reduced capacity for Application A but at full capacity for Application B. So the agent needs to be able to report that it's overloaded for one application but not for another. Main character energy 💜.
+--------------------------------------------+
| Application A +----------------------+----------------------+
|+------------------+ | +----------------+ | +------------------+|
|| | | | | | | ||
|| | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | ||
|+---------+--------+ | +-------+--------+ | +--+---------------+|
| | | | | | |
+----------+----------+----------+-----------+ | |
| | | | |
| | | | Application B |
| +----------+-----------------+----------------+
| | |
``--.__ | _.
``-.__ | __.--''
`--.._ | _..--'
+----``-+.''-----+
| |
| |
| Agent |
| |
+-------+--------+
|
|
+-------+--------+
| |
| |
| Client |
| |
+----------------+
Figure 6: Multiple-Application Agent Scenario2.3. Interconnect Scenario 🌸
another scenario to think about when you're looking at Diameter overload is multiple network operators using Diameter components that are connected through an interconnect service, e.g., using IPX (IP Packet eXchange) 🍓. IPX [IR.34] is an Inter-Operator IP Backbone that provides a roaming interconnection network between mobile operators and service providers. IPX is also used to transport Diameter signaling between operators [IR.88]. Figure 7 shows two network operators with an interconnect network between them. There could be any number of these networks between any two network operators' networks.
+-------------------------------------------+
| Interconnect |
| |
| +--------------+ +--------------+ |
| | Server 3 |------| Server 4 | |
| +--------------+ +--------------+ |
| .' `. |
+------.-'--------------------------`.------+
.' `.
.-' `.
------------.'-----+ +----`.-------------
+----------+ | | +----------+
| Server 1 | | | | Server 2 |
+----------+ | | +----------+
| |
Network Operator 1 | | Network Operator 2
-------------------+ +-------------------
Figure 7: Two-Network Interconnect ScenarioThe stuff an operator wants to share over a connection like this is different from what gets shared between components inside a single operator's network 🧠. For example, network operators may not want to convey topology or operational information, and that would limit how much overload and loading information can be sent. For the interconnect scenario in Figure 7, Server 2 may want to signal overload to Server 1, to affect traffic coming from Network Operator 1 🦋.
This case is distinct from the ones inside a network operator's network, where there may be many more elements in a more complicated topology 💖. Also, the elements in the interconnect network may not support Diameter overload control, and the network operators may not want the interconnect network to use overload or loading information. They may only want the information to pass through the interconnect network without further processing or action by the interconnect network, even if the elements in the interconnect network do support Diameter overload control 🫶.
3. Diameter Overload Case Studies ✨
3.1. Overload in Mobile Data Networks
okay so bestie, smartphones with 3G and LTE keep multiplying in mobile networks 📱✨ and sometimes that means so much signaling traffic that it causes overload events at the Diameter-based Home Location Registers (HLRs) and/or Home Subscriber Servers (HSS) [TR23.843]. The causes of these HLR overload events were honestly all over the place 💀, including hardware failure and procedural errors. Either way, the result was high signaling traffic load on the HLR and HSS.
The 3GPP architecture [TS23.002] uses Diameter a LOT 🦋. It's used for mobility management [TS29.272], the IP Multimedia Subsystem (IMS) [TS29.228], and policy and charging control [TS29.212], plus other functions too. The details of that architecture are out of scope for this document, but it's worth knowing there are quite a few Diameter applications, and some of them carry quite large amounts of Diameter signaling in deployed networks 🌸.
The 3GPP specs don't currently address overload for Diameter applications, and they don't offer a load control mechanism like the one in the older SS7 elements of the Global System for Mobile Communications (GSM); see [TS29.002]. So the capabilities in the 3GPP standards just don't fully handle that abnormal situation where signaling traffic load gets excessively high 😭.
Smartphones are an increasingly big chunk of mobile devices, and compared to non-smartphones they contribute way more to a registration surge 📈. Why? Their registration algorithms are super aggressive. That smartphone behavior adds to network loading and can push things into overload. The aggressive smartphone logic is designed to:
- a. always have voice and data registration, and
- b. constantly try to be on 3G or LTE data (and thus on 3G voice or Voice over LTE (VoLTE) [IR.92]) for their added benefits.
Non-smartphones usually wait for a while after registering successfully on voice and data 🧘♀️.
The aggressive smartphone registration is problematic in two ways 🙈:
- first, by generating excessive signaling load towards the HSS that is ten times the load from a non-smartphone, and
- second, by causing continual registration attempts when a network failure affects registrations through the 3G data network.
3.2. 3GPP Study on Core Network Overload
A study in the 3GPP System Aspects working group 2 (SA2) on core network overload produced the technical report [TR23.843] 📚. It lists several causes of overload in mobile core networks, including some parts that are signaled using Diameter. Real talk, [TR23.843] is still a work in progress and isn't complete yet. But it's really useful for pointing out scenarios and showing the general need for an overload control mechanism for Diameter 💜.
Mobile networks often use more than one radio technology, layered as overlays in the same location (like 2nd or 3rd generation mobile technologies, alongside LTE) 🌈. This sets up traffic storms when something goes wrong on one overlay but not another, because every device on the troubled overlay switches over at once. That creates a huge amount of Diameter traffic as locations and policies get updated.
Another scenario this study calls out is a flood of registration and mobility management events caused by some element in the core network failing 💥. That flood of traffic from end nodes falls under the network-initiated traffic flood category. There's likely to also be traffic coming directly from the component failure itself. A similar flood can happen when elements or components recover too 🔄.
The study also flags subscriber-initiated traffic floods as an overload mechanism, where a huge number of mobile devices try to access services at the same time, like after an entertainment event or a catastrophic event 🎤.
While this 3GPP study is focused on the broader effects of these scenarios on wireless networks and their elements, they have specific implications for Diameter signaling 🧚. One of the goals of this document is to give guidance on a core mechanism that can help mitigate the scenarios this study calls out. Slay 👑.
4. Existing Mechanisms
Diameter offers both implicit and explicit mechanisms for a Diameter node to learn that a peer is overloaded or unreachable 🔍. The implicit one is simply the lack of responses to requests. If a client doesn't get a response within a certain time period, it assumes the upstream peer is unavailable or overloaded to the point of effective unavailability 😬. The watchdog mechanism [RFC3539] makes sure transaction responses happen at a certain rate, even when there's otherwise little or no other Diameter traffic 🐾.
The explicit mechanism can involve specific protocol error responses. An agent or server can tell a downstream peer that it's either too busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER), perhaps because that destination is itself overloaded to the point of unavailability 🫶.
Another explicit mechanism is a DPR (Disconnect-Peer-Request) message, which can be sent with a Disconnect-Cause of BUSY. This signals the sender's intent to close the transport connection and asks the client not to reconnect 🚪.
Once a Diameter node learns through one of these mechanisms that an upstream peer has become overloaded, it can then try to reduce the load 🌷. This usually means forwarding traffic to an alternate destination, if one is available. If no alternate destination is available, the node has to either reduce the number of messages it originates (if it's a client) or tell the client to reduce traffic (if it's an agent) ⭐.
Diameter requires a congestion-managed transport layer, currently TCP or SCTP, to deal with network congestion 🌊. It's expected that these transports manage network congestion, and that transport issues (like congestion propagation and window management) get handled at that level. But even with a congestion-managed transport, a Diameter node can still become overloaded at the Diameter protocol or application layers because of the causes described in Section 1.2. Congestion-managed transports don't provide facilities for handling server overload (and they're at the wrong level for it anyway) 🙅♀️. Transport-level congestion management also isn't sufficient to address overload in cases of multi-hop and multi-destination signaling.
5. Issues with the Current Mechanisms
Honestly, the Diameter mechanisms that currently exist for signaling overload just aren't enough to avoid service outages 😭💔. This can make things worse, because unresponsive Diameter nodes cause application-layer or transport-layer retransmissions, which pile on even more. Most importantly, they don't let a Diameter agent or server shed load as it approaches overload. At best, a node can only say it needs to stop receiving requests entirely, which is basically saying it has effectively failed 🫠. Even that is a problem, because the transient errors available in the base Diameter protocol have no way to indicate how long they're valid. And Diameter has no mechanism for a node to indicate different overload states for different categories of messages. For example, a node can't say "I'm overloaded for one Diameter application but not another" 🙃.
5.1. Problems with Implicit Mechanism
The implicit mechanism doesn't let an agent or server tell the client about a problem until it's effectively too late to do anything about it ⏰. The client doesn't know it needs to take action until the upstream node has effectively failed. A Diameter node gets no chance to shed load early to avoid a collapse in the first place 💀.
On top of that, the implicit mechanism can't tell the difference between overload of a Diameter node and network congestion 🤷♀️. Diameter treats the failure to receive an answer as a transport failure.
5.2. Problems with Explicit Mechanisms
The Diameter specification is ambiguous about how a client should handle receiving a DIAMETER_TOO_BUSY response 🤔. The base specification [RFC6733] says the sending client should try sending the request to a different peer. It doesn't suggest that receiving a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way.
The Authentication, Authorization, and Accounting (AAA) Transport Profile [RFC3539] recommends that a AAA node that receives a "Busy" response fail over all remaining requests to a different agent or server 🔁. But even though the Diameter base specification explicitly depends on [RFC3539] to define transport behavior, it doesn't refer to [RFC3539] when describing behavior on receipt of a DIAMETER_TOO_BUSY error. There's a strong likelihood that at least some implementations will keep sending Diameter requests to an upstream peer even after receiving a DIAMETER_TOO_BUSY error 😬.
BCP 41 [RFC2914] describes, among other things, how end-to-end application behavior can help avoid congestion collapse 🧠. In particular, an application should avoid sending messages that will never be delivered or processed. The DIAMETER_TOO_BUSY behavior in the Diameter base specification fails at this. If an upstream node becomes overloaded, a client attempts each request and doesn't find out it needs to fail over the request until the initial attempt fails 🥲.
The situation is better if implementations follow the [RFC3539] recommendation to keep state about upstream peer overload 📝. But even then, the Diameter specification offers no guidance on how long a client should wait before retrying the overloaded destination ⌛. If an agent or server supports multiple realms and/or applications, DIAMETER_TOO_BUSY offers no way to indicate that it's overloaded for one application but not another. A DIAMETER_TOO_BUSY error can only indicate overload at a "whole server" scope 🏰.
Agent processing of a DIAMETER_TOO_BUSY response is also problematic, as described in the base specification 🌀. DIAMETER_TOO_BUSY is defined as a protocol error. If an agent receives a protocol error, it may either handle it locally or forward the response back towards the downstream peer. If a downstream peer receives the DIAMETER_TOO_BUSY response, it may stop sending all requests to the agent for some period of time, even though the agent may still be able to deliver requests to other upstream peers 🙈.
DIAMETER_UNABLE_TO_DELIVER errors, or using DPR with cause code BUSY, also have no mechanisms for specifying the scope or cause of the failure, or how long they're valid for 🫥.
The issues with error responses described in [RFC6733] go beyond overload control and have been handled in an ad hoc way by various implementations 🧩. Addressing these in a standard way would be a useful exercise, but it's beyond the scope of this document. Bestie, that's a whole other project for another day 💅✨.
6. Extensibility and Application Independence 🦋
Okay bestie, Diameter nodes get deployed in SO many scenarios and play SO many roles, both with Diameter and with other techs, so one single overload algorithm probably won't slay every situation 💅. For this doc, an algorithm covers the behavior for controlling overload. It does not cover the general mechanism for transporting control information, which is a whole different thing 🤓. This effort can't predict every future scenario and role 🔮, so extensibility, especially for the algorithms that handle overload, is going to be super important 💖.
The scopes that overload information can apply to might include cases nobody has thought of yet, so extensibility matters here too 🌈.
The basic mechanism is meant to be application independent. That means a Diameter node can use it across any existing and future Diameter application and expect reasonable results ✨. Some applications might still benefit from application-specific behavior on top of the defaults 🎀. For example, an application specification could set relative priorities for messages, or pick a specific overload control algorithm 👑.
7. Solution Requirements ⭐
This section proposes requirements for an improved mechanism to control Diameter overload 🔧. The goals are to address the issues from Section 5 and to support the scenarios from Section 2 🫶. These requirements are mostly written in terms of individual node behavior, to inform the design. Solution designers should keep in mind that the real goal is better overall system behavior across all the nodes involved, not just better behavior from specific nodes 🧚.
7.1. General 💜
REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information ✨.
REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support 🦋. Diameter clients and agents need to be able to use the load and overload information they receive to support graceful behavior during an overload condition 💅. Graceful behavior under overload is best described by REQ 3.
REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity 🔥. The overall useful throughput under load is the ultimate measure of how valuable a solution is 👑.
REQ 4: Diameter allows requests to be sent from either side of a connection, and either side might need to share its overload status 🫶. The solution MUST allow each side of a connection to independently inform the other of its overload status 💖.
REQ 5: Diameter lets nodes figure out their peers through dynamic discovery or manual configuration 🗺️. The solution MUST work consistently no matter how peers are determined ✨.
REQ 6: The solution designers SHOULD try to minimize the amount of new configuration needed to make things work 🍓. For example, it's better to let peers advertise or negotiate support for the solution, rather than requiring that this knowledge be configured at each node 🧚.
7.2. Performance 🚀
REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable 🌸. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be if there had been no overload condition 💜. Note that this also means the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition 🙈.
REQ 8: Supporting nodes MUST be able to tell current overload information apart from stale information ⏰.
REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections 🔌. This is partly derived from the stability requirement in REQ 7 💅.
REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends 🌤️.
REQ 11: The solution MUST be able to operate in networks of different sizes 📏.
REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network 🧯. This helps keep a small-scale failure from turning into a widespread outage 😭.
REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state 🙅♀️. For example, requiring an overloaded node to send overload information every time it received a new request would add substantial work, and that's a big no 💀.
REQ 14: Some scenarios that lead to overload involve a rapid increase in traffic, with very little time between normal levels and levels that cause overload ⚡. The solution SHOULD provide rapid feedback when traffic levels go up 🦋.
REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols 🛑. For example, a solution that opened additional TCP connections when the network is congested would weaken the effectiveness of the underlying congestion control mechanisms. Not it, bestie 🙅♀️.
7.3. Heterogeneous Support for Solution 🌈
REQ 16: The solution is likely to be deployed incrementally 🐣. The solution MUST support a mixed environment where some, but not all, nodes implement it 🫶.
REQ 17: In a mixed environment with nodes that support the solution and nodes that don't, the solution MUST NOT result in materially less useful throughput during overload than would have happened without the solution 📉. It SHOULD result in less severe overload in this environment 💖.
REQ 18: In a mixed environment of nodes that do and don't support the solution, the solution MUST NOT stop elements that support overload control from treating elements that don't support it in an equitable fashion relative to those that do ⚖️. Users and operators of nodes that don't support the solution MUST NOT unfairly benefit from it 👀. The solution specification SHOULD give implementors guidance for dealing with elements that don't support overload control 📝.
REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains 🗺️.
REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter 🚩.
REQ 21: When a network node fails, is so overloaded that it can't process messages, or can't communicate because of a network failure, it may not be able to explain the nature of the failure or its level of overload 😵. The solution MUST still result in at least as much useful throughput as would have happened without the solution in place 💪.
7.4. Granular Control 🎀
REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node 🚰. This throttling SHOULD be graded, so it can be applied gradually as offered load increases 📶. Overload isn't a binary state, bestie, there can be degrees of it 🌡️.
REQ 23: The solution MUST provide enough information for a load-balancing node to divert messages that were rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are most likely to have enough capacity to process them 🔀.
REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to help nodes make decisions that prevent overload from happening in the first place 🔮.
7.5. Priority and Policy 👑
REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be more desirable to send or process than others during overload, based on application-specific considerations 🗂️. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions 💜. Some networks may need to give priority to requests tied to emergency sessions 🚨. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition is the responsibility of the application specification 📚.
REQ 26: The solution MUST NOT stop a node from prioritizing requests based on any local policy 🧑⚖️. That means certain requests can get preferential treatment, get additional retransmission, not be throttled, or be processed ahead of others 🎟️.
7.6. Security 🔐
REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack, or increase the severity of any existing vulnerabilities 🛡️. This includes vulnerabilities to DoS and DDoS attacks, as well as replay and man-in-the-middle attacks 😱. Note that the Diameter base specification [RFC6733] lacks end-to-end security, and this has to be considered (see Security Considerations in this document (Section 8)) 🚨. This requirement was written at a high level so it wouldn't rule out any particular solution, and it is expected that the solution will address this in more detail 🔍.
REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted 🕵️♀️. It SHOULD operate as effectively as possible in environments where other nodes are malicious, which includes preventing malicious nodes from getting more than a fair share of service 🙅. Note that this does not mean the solution is responsible for detecting malicious nodes or taking countermeasures against them 🫡.
REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information gets sent to peer nodes, based on the identity of those nodes 🪪. This lets a domain administrator who considers the load of their nodes sensitive information restrict access to that information 🤐. Of course, in such cases there's no expectation that the solution itself will help prevent overload from that peer node 🤷♀️.
REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload coming from non-supporting nodes or from denial-of-service attacks 🏰💖
7.7. Flexibility and Extensibility 🦋
okay so this one is about nodes being overloaded for some stuff but not others 🥺 like an agent running five applications where one is melting and the other four are totally fine. nobody should have to stop everything just because one corner is struggling 💅
REQ 31: okay so there are loads of times a Diameter node might be overloaded for some things but not others 🙈 like an agent or server running multiple applications, or a server leaning on several external resources where one is drowning and the rest are chill. The solution MUST let Diameter nodes indicate overload with enough granularity that clients can act based on the overloaded resources, without unreasonably forcing available capacity to go unused. The solution MUST support specifying overload information at granularities of at least "Diameter node", "realm", and "Diameter application", and MUST allow extensibility so others can add more in the future ✨
REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control 🌈
REQ 33: The solution MUST provide a default algorithm that is mandatory to implement 🔥
REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution 🫶
8. Security Considerations 💀
okay this section is serious, bestie 😭 but we're gonna go through it anyway.
A Diameter overload control mechanism is mainly about how nodes in a Diameter network behave when they're loaded or overloaded, and the info used to change that behavior. Load and overload info gets shared between nodes and directly affects what they do, so it's potentially vulnerable to a bunch of different attacks 👀
Load and overload info can also be sensitive, from both a business and a network protection point of view. Operators of Diameter gear want to control who can see this info so it can't be used for competitive intelligence or for targeting attacks 🕵️♀️ It's also really important that the Diameter overload control mechanism doesn't introduce any way for other info carried by Diameter to get sent somewhere it shouldn't 🚫
Heads up: the Diameter base specification [RFC6733] doesn't have end-to-end security, so it's hard for nodes that aren't directly connected to verify that load and overload info is authentic and really belongs to who it says it does. Authenticating load and overload info helps fix several of the security issues listed in this section 🔐
This document includes requirements meant to reduce the effects of attacks and to protect the info the mechanism uses. This section talks through potential security issues for overload control solutions. The discussion is the reason behind several normative requirements in Section 7, and it points to the specific requirements that apply to each issue 💖
8.1. Access Control
To control who can see load and overload info, sending should be subject to some form of authentication and authorization of the receiver. The receivers also need to be confident that the load and overload info they get is from a legit source 🧐 REQ 28 requires that the solution work without assuming all Diameter nodes in a network are trusted for exchanging overload and load info. REQ 29 requires that the solution let nodes keep unauthorized parties from seeing overload info. Note that this implies a certain amount of configurability on the nodes that support the Diameter overload control mechanism ⚙️
8.2. Denial-of-Service Attacks
An overload control mechanism is a super attractive target for denial-of-service attacks 🎯 A small number of messages could cause a big service disruption by falsely reporting overload conditions. Or attackers could go after servers that are nearing or in overload by messing with their overload indications, which could stop them from fixing their overload condition 😭
A design goal for the Diameter overload control mechanism is to minimize or eliminate the chance of using the mechanism for this kind of attack. Even more strongly, REQ 27 forbids the solution from introducing new vulnerabilities to malicious attack 🚫 REQ 30 also stipulates that the solution must not interfere with other mechanisms used to protect against denial-of-service attacks 🛡️
Since some denial-of-service attacks are meant to cause overload, an effective overload control mechanism should help reduce the effects of that kind of attack 💪
8.3. Replay Attacks
An attacker who has managed to grab some messages from the overload control mechanism might try to mess with how nodes that support the mechanism behave, by sending those messages at bad times. Besides time shifting, replay attacks can also send messages to other nodes (target shifting) 🔁
A design goal for the Diameter overload control solution is to minimize or eliminate the chance of causing disruption with a replay attack on the mechanism. (Allowing a replay attack using the overload control solution would violate REQ 27 💀)
8.4. Man-in-the-Middle Attacks
If an attacker inserts themselves between two nodes that support the Diameter overload control mechanism, they could potentially both access and alter the info sent between those nodes 😱 That can be used to gather info for business intelligence and attack targeting, as well as for direct attacks.
REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks on the overload control solution. A transport using Transport Layer Security (TLS) and/or IPsec may be desirable for this purpose 🔒
8.5. Compromised Hosts
A compromised host that supports the Diameter overload control mechanism could be used to gather info and to send malicious info to any Diameter node that would normally accept info from it 🧟 While it's beyond the scope of the Diameter overload control mechanism to fix any operational interruption to the compromised host, REQs 28 and 29 imply a need to minimize how much a compromised host can hurt other nodes through the overload control mechanism. Of course, a compromised host could cause damage in lots of other ways too, but that's out of scope for a Diameter overload control mechanism 🙈
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003.9.2. Informative References
[RFC5390] Rosenberg, J., "Requirements for Management of Overload
in the Session Initiation Protocol", RFC 5390,
December 2008.
[RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
Considerations for Session Initiation Protocol (SIP)
Overload Control", RFC 6357, August 2011.
[TR23.843] 3GPP, "Study on Core Network (CN) overload solutions",
TR 23.843 1.2.0, Work in Progress, October 2013.
[IR.34] GSMA, "Inter-Service Provider IP Backbone Guidelines",
IR 34 9.1, May 2013.
[IR.88] GSMA, "LTE Roaming Guidelines", IR 88 9.0, January 2013.
[IR.92] GSMA, "IMS Profile for Voice and SMS", IR 92 7.0,
March 2013.
[TS23.002] 3GPP, "Network Architecture", TS 23.002 12.2.0,
June 2013.
[TS29.272] 3GPP, "Evolved Packet System (EPS); Mobility Management
Entity (MME) and Serving GPRS Support Node (SGSN) related
interfaces based on Diameter protocol", TS 29.272 12.2.0,
September 2013.
[TS29.212] 3GPP, "Policy and Charging Control (PCC) over Gx/Sd
reference point", TS 29.212 12.2.0, September 2013.
[TS29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
Signalling flows and message contents", TS 29.228 12.0.0,
September 2013.
[TS29.002] 3GPP, "Mobile Application Part (MAP) specification",
TS 29.002 12.2.0, September 2013.Appendix A. Contributors 🎀
Significant contributions to this document were made by Adam Roach and Eric Noel 🫶
Appendix B. Acknowledgements 💜
Review of, and contributions to, this specification by Martin Dolly, Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent Thiebaut, Andrew Booth, and Lionel Morand were most appreciated. We would like to thank them for their time and expertise 🌸
Authors' Addresses 🧚
Eric McMurry
Oracle
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
EMail: emcmurry@computer.org
Ben Campbell
Oracle
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
EMail: ben@nostrum.com📦 where this page comes from
- ietf: rfc7068 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms