RFC 6357
Design Considerations for Session Initiation Protocol (SIP) Overload Control
Internet Engineering Task Force (IETF) 🎀
Title block (the vibe check): This is RFC 6357 🦋, titled Design Considerations for Session Initiation Protocol (SIP) Overload Control. The authors are V. Hilt (Bell Labs/Alcatel-Lucent), E. Noel (AT&T Labs), C. Shen (Columbia University), and A. Abdelal (Sonus Networks). It's Informational, with ISSN 2070-1721, and it's dated August 2011 🗓️. It doesn't say it obsoletes or updates anything, so it's a standalone doc 💅.
Abstract ✨
okay so overload happens in SIP networks when SIP servers don't have enough resources to handle every SIP message they get 😭. SIP does have a little overload control thing through its 503 (Service Unavailable) response code, but servers are still super vulnerable to overload anyway 💀. This doc talks about models and design considerations for a SIP overload control mechanism 🧚.
Status of This Memo 📋
this one is not an Internet Standards Track spec. It's published just for informational purposes 🌸.
It's a product of the Internet Engineering Task Force (IETF), so 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 🫶.
If you want the current status, any errata, or a way to give feedback, check http://www.rfc-editor.org/info/rfc6357 🔗.
Copyright Notice ©️
Copyright (c) 2011 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 they stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this doc 📜. 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're provided without warranty as described in the Simplified BSD License ⚖️.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIP Overload Problem . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit vs. Implicit Overload Control . . . . . . . . . . . . 5
4. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Degree of Cooperation . . . . . . . . . . . . . . . . . . . . 8
5.1. Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Local Overload Control . . . . . . . . . . . . . . . . . . 11
6. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 14
9. Explicit Overload Control Feedback . . . . . . . . . . . . . . 15
9.1. Rate-Based Overload Control . . . . . . . . . . . . . . . 15
9.2. Loss-Based Overload Control . . . . . . . . . . . . . . . 17
9.3. Window-Based Overload Control . . . . . . . . . . . . . . 18
9.4. Overload Signal-Based Overload Control . . . . . . . . . . 19
9.5. On-/Off Overload Control . . . . . . . . . . . . . . . . . 19
10. Implicit Overload Control . . . . . . . . . . . . . . . . . . 20
11. Overload Control Algorithms . . . . . . . . . . . . . . . . . 20
12. Message Prioritization . . . . . . . . . . . . . . . . . . . . 21
13. Operational Considerations . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 251. Introduction 🌷
okay so any network element can get overloaded, and SIP servers are no exception 😭. A SIP [RFC3261] server can suffer from overload when the number of SIP messages it receives is more than the number it can process. Overload happens when a SIP server doesn't have enough resources to process all incoming SIP messages. Those resources can include CPU, memory, input/output, or disk 💻.
Overload can be a serious problem for a network of SIP servers 🚨. During overload periods, the throughput of SIP messages across the network can get seriously degraded. Like, the overload in one server can get amplified by retransmissions of SIP messages, and the throughput drops to a tiny fraction of the original processing capacity 💀. This is often called congestion collapse 🫠.
An overload control mechanism lets a SIP server keep processing SIP messages close to its capacity limit when things get overloaded 🙌. Overload control is used by a SIP server when it can't process all SIP requests because of resource constraints. There are other failure cases where a SIP server can successfully process incoming requests but still has to reject them for other reasons. For example, a PSTN gateway that runs out of trunk lines but still has plenty of capacity to process SIP messages should reject incoming INVITEs with a 488 (Not Acceptable Here) response, as described in [RFC4412] 📞. Similarly, a SIP registrar that has lost connectivity to its registration database but can still process SIP messages should reject REGISTER requests with a 500 (Server Error) response [RFC3261] 🗄️. Overload control mechanisms don't apply in these cases, and SIP has appropriate response codes for them ✅.
There are cases where a SIP server runs other services that don't involve processing SIP messages, like processing RTP packets, database queries, software updates, and event handling 🎧. These services may or may not be correlated with the SIP message volume. They can use up a big chunk of the resources on the server (like CPU cycles) and leave the server unable to process all incoming SIP requests 🥲. In these cases, the SIP server applies SIP overload control mechanisms to avoid congestion collapse on the SIP signaling plane. But here's the tea ☕: controlling the number of SIP requests may not significantly reduce the load on the server if the resource shortage was created by another service. In these cases, it's expected that the server uses appropriate methods for controlling the resource usage of those other services. The specifics of controlling the resource usage of other services, and how that coordinates, are out of scope for this document 🙅♀️.
The SIP protocol has a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header 🍓. However, this mechanism can't prevent overload of a SIP server, and it can't prevent congestion collapse. In fact, it may cause traffic to oscillate and shift between SIP servers, which can make an overload condition even worse 😩. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header, and the requirements for a SIP overload control mechanism can be found in [RFC5390] 📚. Also, 503 is used for other situations, not just SIP server overload. So a SIP overload control process based on 503 would have to specify exactly which cause values trigger the overload control 🧐.
This document discusses the models, assumptions, and design considerations for a SIP overload control mechanism 💅. It originated in the SIP overload control design team and has been further developed by the SIP Overload Control (SOC) working group 👑.
2. SIP Overload Problem 💔
A key contributor to SIP congestion collapse [RFC5390] is the regenerative behavior of overload in the SIP protocol 🔄. When SIP runs over UDP, it will retransmit messages that were dropped or excessively delayed by a SIP server because of overload. That increases the offered load on the server that's already overloaded 😵. This increase in load makes the overload worse and, in turn, causes even more messages to be dropped. A congestion collapse can occur [Hilt] [Noel] [Shen] [Abdelal] 🌪️.
Regenerative behavior under overload should ideally be avoided by any protocol, because it leads to unstable operation under overload 🙃. However, this is often hard to achieve in practice. For example, changing the SIP retransmission timer mechanisms can reduce the degree of regeneration during overload, but it will impact SIP's ability to recover from message losses 🫤. Without any retransmission, each message dropped due to SIP server overload will eventually lead to a failed transaction 💔.
For a SIP INVITE transaction to succeed, a minimum of three messages need to be forwarded by a SIP server. Often an INVITE transaction has five or more SIP messages 📨. If a SIP server under overload randomly discards messages without evaluating them, the chances that all messages belonging to a transaction get forwarded successfully will decrease as the load increases. So the number of transactions that complete successfully drops, even if the message throughput of the server stays up, and even assuming the overload behavior is fully non-regenerative 📉. A SIP server might (partially) parse incoming messages to figure out whether it's a new request or a message belonging to an existing transaction. But discarding a SIP message after spending resources to parse it is expensive 💸. So the number of successful transactions declines as load goes up, since fewer resources can be spent forwarding messages and more resources get eaten up inspecting messages that will eventually be dropped 😭. How fast the decline happens depends on how many resources get spent inspecting each message 🕰️.
Another challenge for SIP overload control is controlling the rate of the true traffic source 🎯. Overload is often caused by a large number of user agents (UAs), each of which creates only a single message. But the sum of their traffic can overload a SIP server 🌊. The overload mechanisms that work for controlling a SIP server (like rate control) may not be effective for individual UAs 🤷♀️. In some cases, there are other non-SIP mechanisms for limiting the load from the UAs. These may operate independently from, or in conjunction with, the SIP overload mechanisms described here. Either way, they're out of scope for this document 🫶✨.
3. Explicit vs. Implicit Overload Control ✨
okay so the big difference between explicit and implicit overload control is how a SIP server that's about to hit overload tells its upstream neighbors about it 🫶
With explicit overload control, the server sends an explicit overload signal to say "hey, I'm reaching my capacity limit." 💅 Its upstream neighbors get that signal and adjust how fast they send, to a level the downstream server can handle. The signal lets the server steer the load it's getting to a rate where it can perform at maximum capacity. It's giving control 👑
Implicit overload control doesn't use any signal at all. Instead it reads the absence of responses and packet loss as the sign that something's wrong 🙈 A SIP server that senses this reduces the load it forwards to a downstream neighbor. Since there's no explicit signal to rely on, this mechanism is robust, because it doesn't depend on the overloaded server doing anything itself. no cap, that's the whole point 🧚
The two ideas are actually complementary, and I'm obsessed with this part 💜 By considering implicit overload indications, a server can avoid overloading a downstream neighbor that's not responding. An explicit overload signal, meanwhile, lets a SIP server actively steer the incoming load to a desired level. Together they're iconic 🦋
4. System Model 🎀
Here's the model shown in Figure 1. It breaks an explicit SIP overload control mechanism into its fundamental components:
- SIP Processor: This is the component that handles SIP messages, and it's the one being protected by overload control 🛡️
- Monitor: The Monitor measures the current load of the SIP Processor on the receiving entity. It has the mechanisms needed to figure out how much of the resources relevant to the SIP Processor are in use, and it sends load samples (S) to the Control Function. 📊
- Control Function: This is the brain 🧠 It runs the overload control algorithm, uses the load samples (S) to decide whether overload has happened, and figures out whether a throttle (T) needs to be set to adjust the load going to the SIP Processor on the receiving entity. The Control Function on the receiving entity also sends load feedback (F) back to the sending entity.
- Actuator: The Actuator carries out the throttles (T) and makes sure the amount of traffic forwarded to the receiving entity meets the throttle's criteria. For example, a throttle might tell the Actuator to not forward more than 100 INVITE messages per second. The Actuator works out how to hit that target, e.g., using message gapping 🌸 It also picks which messages get affected and decides whether they're rejected or redirected.
The type of feedback (F) sent from the receiving entity to the sending entity depends on the overload control method in use (that's loss-based, rate-based, window-based, or signal-based overload control; see Section 9), the overload control algorithm (see Section 11), and other design parameters. The feedback (F) lets the sending entity adjust how much traffic it forwards to the receiving entity, so it lands at a level the receiving entity can accept without overloading ✨
Figure 1 is a general system model for overload control. In this diagram there's one instance of the control function on the sending entity (associated with the actuator) and one on the receiving entity (associated with the Monitor). But a specific mechanism might not need both. In that case, one of the two control function elements can be empty and simply pass feedback along. For example, if (F) is defined as a loss-rate (e.g., reduce traffic by 10%), there's no need for a control function on the sending entity, because the content of (F) can be copied straight into (T). 🍓
The model in Figure 1 shows one sending entity and one receiving entity. In a more realistic scenario, a receiving entity gets traffic from multiple sending entities, and vice versa (see Section 6). So the feedback from a Monitor will often be spread across multiple Actuators. A Monitor needs to be able to split the load it can process across multiple sending entities and generate feedback that correctly adjusts what each sending entity is allowed to send. Similarly, an Actuator has to be ready to receive different levels of feedback from different receiving entities and throttle its traffic to each of them accordingly. multitasking queen behavior 👑
In a realistic deployment, SIP messages flow in both directions: from server B to server A, and from server A to server B. The overload control mechanisms in each direction can be looked at independently. For messages flowing from server A to server B, the sending entity is server A and the receiving entity is server B, and the other way around too. The control loops in both directions operate independently 💖
Sending Receiving
Entity Entity
+----------------+ +----------------+
| Server A | | Server B |
| +----------+ | | +----------+ | -+
| | Control | | F | | Control | | |
| | Function |<-+------+--| Function | | |
| +----------+ | | +----------+ | |
| T | | | ^ | | Overload
| v | | | S | | Control
| +----------+ | | +----------+ | |
| | Actuator | | | | Monitor | | |
| +----------+ | | +----------+ | |
| | | | ^ | -+
| v | | | | -+
| +----------+ | | +----------+ | |
<-+--| SIP | | | | SIP | | | SIP
--+->|Processor |--+------+->|Processor |--+-> | System
| +----------+ | | +----------+ | |
+----------------+ +----------------+ -+
Figure 1: System Model for Explicit Overload Control5. Degree of Cooperation 🤝
A SIP request is usually processed by more than one SIP server on its path to the destination. So a design choice for an explicit overload control mechanism is where to place the overload control components along the request's path, especially where to put the Monitor and Actuator. That choice decides the degree of cooperation between the SIP servers on the path 🦋 Overload control can be implemented hop-by-hop, with the Monitor on one server and the Actuator on its direct upstream neighbor. It can be implemented end-to-end, with Monitors on all SIP servers along the request's path and an Actuator on the sender. In that case, the Control Functions associated with each Monitor have to cooperate to jointly determine the overall feedback for that path. Finally, overload control can be implemented locally on a SIP server if the Monitor and Actuator live on the same server. Here the sending entity and receiving entity are the same SIP server, and the Actuator and Monitor operate on the same SIP Processor (although the Actuator typically works at a pre-processing stage in local overload control).
Local overload control is an internal mechanism, since the control loop runs entirely inside one server. Hop-by-hop and end-to-end are external overload control mechanisms. All three configurations are shown in Figure 2 🌈
+---------+ +------(+)---------+
+------+ | | | ^ |
| | | +---+ | | +---+
v | v //=>| C | v | //=>| C |
+---+ +---+ // +---+ +---+ +---+ // +---+
| A |===>| B | | A |===>| B |
+---+ +---+ \\ +---+ +---+ +---+ \\ +---+
^ \\=>| D | ^ | \\=>| D |
| +---+ | | +---+
| | | v |
+---------+ +------(+)---------+
(a) hop-by-hop (b) end-to-end
+-+
v |
+-+ +-+ +---+
v | v | //=>| C |
+---+ +---+ // +---+
| A |===>| B |
+---+ +---+ \\ +---+
\\=>| D |
+---+
^ |
+-+
(c) local
==> SIP request flow
<-- Overload feedback loop
Figure 2: Degree of Cooperation between Servers5.1. Hop-by-Hop 🫧
The idea behind hop-by-hop overload control is to set up a separate control loop between every pair of neighboring SIP servers that directly exchange traffic. So the Actuator sits on the SIP server that's the direct upstream neighbor of the SIP server holding the matching Monitor. Each control loop between two servers is completely independent of the loops further up- or downstream. In the Figure 2(a) example, three independent overload control loops get set up: A - B, B - C, and B - D. Each loop only controls a single hop. Overload feedback that comes from a downstream neighbor doesn't get forwarded further upstream. Instead, a SIP server acts on that feedback itself, for example by rejecting SIP messages if needed. If the upstream neighbor of a server also becomes overloaded, it reports that problem to its own upstream neighbors, and they take action based on the reported feedback in turn. So in hop-by-hop overload control, overload always gets resolved by the direct upstream neighbors of the overloaded server, without involving entities multiple SIP hops away. Main character energy for the neighbors, honestly 💅
Hop-by-hop overload control reduces the impact of overload on a SIP network and can avoid congestion collapse. It's simple and scales well to networks with lots of SIP entities 🌸 An advantage is that feedback never has to be transmitted across multiple hops, possibly crossing multiple trust domains. Feedback only goes to the next hop. And it doesn't require a SIP entity to aggregate a large number of overload status values or keep track of the overload status of SIP servers it isn't communicating with. Simple, clean, iconic 🎀
5.2. End-to-End 🛣️
okay so end-to-end overload control runs an overload control loop along the entire path of a SIP request, from the user agent client (UAC) all the way to the user agent server (UAS) ✨ it's giving full journey. it gathers overload info from every SIP server along the way (that means every proxy AND the UAS) and uses that info to throttle traffic as far upstream as possible 💅. to make this work, an end-to-end mechanism has to be able to frequently collect the overload status of all the servers on the potential path(s) to a destination and mash it all together into meaningful overload feedback 🔥.
a UA or SIP server only throttles requests if it knows those requests will eventually get forwarded to an overloaded server 🙈. like, if D is overloaded in Figure 2(b), A should only throttle the requests it forwards to B when it knows they'll be forwarded to D. it should not throttle requests that will eventually be forwarded to C, since server C is not overloaded. it's hard for A to figure out which requests will be routed to C and D, since that depends on the local routing decision B makes 😭. those routing decisions can be super variable and depend on things like call-routing policies configured by the user, services invoked on a call, load-balancing policies, etc. and a previous message to a target that got routed through an overloaded server doesn't necessarily mean the next message to that target will go through the same server. unpredictable, bestie 💀.
the main problem with end-to-end overload control is its inherent complexity 🥴. UAC or SIP servers need to monitor all the potential paths to a destination so they can figure out which requests should be throttled and which requests may be sent. even if that info is available, it's not clear which path a specific request will take.
a variant of end-to-end overload control is to run a control loop between a set of well-known SIP servers along the path of a SIP request 🧚. for example, a control loop can be set up between a server that only has one downstream neighbor, or a set of closely coupled SIP servers. a control loop spanning multiple hops can be used if the sending entity has full knowledge about the SIP servers on the path of a SIP message.
overload control for SIP servers is different from the end-to-end congestion control used by transport protocols such as TCP 🌈. the traffic exchanged between SIP servers is made up of many individual SIP messages, and each SIP message is created by a SIP UA to achieve a specific goal (e.g., to start setting up a call). all messages have their own source and destination addresses. even SIP messages containing identical SIP URIs (e.g., a SUBSCRIBE and an INVITE message to the same SIP URI) can be routed to different destinations. this is different from TCP, where the traffic exchanged between routers is packets belonging to a usually longer flow of messages exchanged between a source and a destination (e.g., to transmit a file). if congestion happens, the sources can detect it and adjust the rate at which the next packets are transmitted.
5.3. Local Overload Control 🎀
the idea of local overload control (see Figure 2(c)) is to run the Monitor and Actuator on the same server 👑. this lets the server keep an eye on its current resource usage and reject messages that can't be processed without overusing local resources. the fundamental assumption behind local overload control is that it's less resource-consuming for a server to reject messages than to process them. so a server can reject the excess messages it can't process to stop all retransmissions of those messages. but since rejecting messages does consume resources on a SIP server, local overload control alone can't prevent a congestion collapse 😭.
local overload control can be used in conjunction with other overload control mechanisms and gives an extra layer of protection against overload 🛡️. it's fully implemented within a SIP server and doesn't require cooperation between servers. in general, SIP servers should apply other overload control techniques to control load before a local overload control mechanism is activated as a mechanism of last resort.
6. Topologies 🗺️
the following topologies describe four generic SIP server configurations 🍓. these topologies illustrate specific challenges for an overload control mechanism. an actual SIP server topology is likely to consist of combinations of these generic scenarios.
in the "load balancer" configuration shown in Figure 3(a), a set of SIP servers (D, E, and F) receives traffic from a single source A. a load balancer is a typical example of this kind of configuration 🧺. in this configuration, overload control needs to prevent server A (i.e., the load balancer) from sending too much traffic to any of its downstream neighbors D, E, and F. if one of the downstream neighbors becomes overloaded, A can direct traffic to the servers that still have capacity. if one of the servers acts as a backup, it can be activated once one of the primary servers reaches overload.
if A can reliably determine that D, E, and F are its only downstream neighbors and all of them are in overload, it may choose to report overload upstream on behalf of D, E, and F. however, if the set of downstream neighbors is not fixed or only some of them are in overload, then A should not activate an overload control, since A can still forward the requests destined to non-overloaded downstream neighbors. these requests would be throttled as well if A would use overload control towards its upstream neighbors.
in some cases, the servers D, E, and F are in a server farm and are configured to appear as a single server to their upstream neighbors 🏠. in this case, server A can report overload on behalf of the server farm. if the load balancer is not a SIP entity, servers D, E, and F can report the overall load of the server farm (i.e., the load of the virtual server) in their messages. as an alternative, one of the servers (e.g., server E) can report overload on behalf of the server farm. in this case, not all messages contain overload control information, and all upstream neighbors need to be served by server E periodically to ensure that updated information is received.
in the "multiple sources" configuration shown in Figure 3(b), a SIP server D receives traffic from multiple upstream sources A, B, and C 🌊. each of these sources can contribute a different amount of traffic, which can vary over time. the set of active upstream neighbors of D can change, as servers may become inactive, and previously inactive servers may start contributing traffic to D.
if D becomes overloaded, it needs to generate feedback to reduce the amount of traffic it receives from its upstream neighbors. D needs to decide by how much each upstream neighbor should reduce traffic. this decision can require the consideration of the amount of traffic sent by each upstream neighbor, and it may need to be re-adjusted as the traffic contributed by each upstream neighbor varies over time. server D can use a local fairness policy to determine how much traffic it accepts from each upstream neighbor.
in many configurations, SIP servers form a "mesh" as shown in Figure 3(c). here, multiple upstream servers A, B, and C forward traffic to multiple alternative servers D and E. this configuration is a combination of the "load balancer" and "multiple sources" scenarios.
+---+ +---+
/->| D | | A |-\
/ +---+ +---+ \
/ \ +---+
+---+-/ +---+ +---+ \->| |
| A |------>| E | | B |------>| D |
+---+-\ +---+ +---+ /->| |
\ / +---+
\ +---+ +---+ /
\->| F | | C |-/
+---+ +---+
(a) load balancer (b) multiple sources
+---+
| A |---\ a--\
+---+-\ \---->+---+ \
\/----->| D | b--\ \--->+---+
+---+--/\ /-->+---+ \---->| |
| B | \/ c-------->| D |
+---+---\/\--->+---+ | |
/\---->| E | ... /--->+---+
+---+--/ /-->+---+ /
| C |-----/ z--/
+---+
(c) mesh (d) edge proxy
Figure 3: Topologiesoverload control that is based on reducing the number of messages a sender is allowed to send is not suited for servers that receive requests from a very large population of senders, each of which only sends a very small number of requests. this scenario is shown in Figure 3(d). an edge proxy that is connected to many UAs is a typical example of this configuration 🌸. since each UA typically sends requests infrequently, and those requests are often related to the same session, it can't decrease its message rate to resolve the overload.
a SIP server that receives traffic from many sources, each of which contributes only a small number of requests, can resort to local overload control by rejecting a percentage of the requests it receives with 503 (Service Unavailable) responses 🙅♀️. since it has many upstream neighbors, it can send 503 (Service Unavailable) to a fraction of them to gradually reduce load without entirely stopping all incoming traffic. the Retry-After header can be used in 503 (Service Unavailable) responses to ask upstream neighbors to wait a given number of seconds before trying the request again. using 503 (Service Unavailable) can, however, not prevent overload if a large number of sources create requests (e.g., to place calls) at the same time.
Note: The requirements of the "edge proxy" topology are different from the ones of the other topologies, which may require a different method for overload control. 💅
7. Fairness ⚖️
there are many different ways to define fairness between multiple upstream neighbors of a SIP server. in the context of SIP server overload, it is helpful to describe two categories of fairness: basic fairness and customized fairness. with basic fairness, a SIP server treats all requests equally and ensures that each request has the same chance of succeeding. with customized fairness, the server allocates resources according to different priorities. an example application of the basic fairness criteria is the "Third caller receives free tickets" scenario 🎟️, where each call attempt should have an equal success probability in connecting through an overloaded SIP server, irrespective of the service provider in which the call was initiated. an example of customized fairness would be a server that assigns different resource allocations to its upstream neighbors (e.g., service providers) as defined in a service level agreement (SLA).
8. Performance Metrics 📊✨
okay so the performance of an overload control mechanism can be measured using different metrics, and we're about to get into them 💅
The key performance indicator is the goodput of a SIP server under overload 🔥. Ideally, the server gets to perform at its maximum capacity during periods of overload. For example, if a SIP server has a processing capacity of 140 INVITE transactions per second, then an overload control mechanism should enable it to process 140 INVITEs per second even if the offered load is much higher 🚀. Delay is another big deal. The overload control mechanism should make sure the delay a SIP message experiences is not increased significantly during overload, because significantly increased delay can lead to time-outs and retransmission of SIP messages, which makes the overload worse 😭.
Responsiveness and stability are the next vibes 🫶. An overload control mechanism should quickly react to an overload and make sure a SIP server doesn't become overloaded, even during sudden peaks of load. It should also quickly stop rejecting requests if the overload disappears. Stability is another important criteria 🦋. The mechanism should not cause significant oscillations of load on a SIP server. The performance of SIP overload control mechanisms is discussed in [Noel], [Shen], [Hilt], and [Abdelal], so go check those if you want the receipts 🤓.
In addition to the above metrics, there are other indicators that matter when you're evaluating an overload control mechanism 👑:
- Fairness: Which type of fairness does the overload control mechanism implement?
- Self-limiting: Is the overload control self-limiting if a SIP server becomes unresponsive?
- Changes in neighbor set: How does the mechanism adapt to a changing set of sending entities?
- Data points to monitor: Which and how many data points does an overload control mechanism need to monitor?
- Computational load: What is the (CPU) load created by the overload "Monitor" and "Actuator"?
9. Explicit Overload Control Feedback 🎀
Explicit overload control feedback is when a receiver tells the sender how much traffic it wants to receive 💖. Explicit overload control mechanisms can be told apart by the type of information carried in the overload control feedback, and by whether the control function lives in the receiving or the sending entity (receiver- vs. sender-based overload control), or both 🧚.
9.1. Rate-Based Overload Control 🚦
The key idea of rate-based overload control is to limit the request rate at which an upstream element is allowed to forward traffic to its downstream neighbor 💅. If overload occurs, a SIP server instructs each upstream neighbor to send, at most, X requests per second. Each upstream neighbor can be assigned a different rate cap, which is very iconic of it 🌈.
An example algorithm for an Actuator in the sending entity is request gapping ✨. After transmitting a request to a downstream neighbor, a server waits for 1/X seconds before it transmits the next request to the same neighbor. Requests that arrive during the waiting period are not forwarded and are either redirected, rejected, or buffered. Request gapping only affects requests that are targeted by overload control (e.g., requests that initiate a transaction and not retransmissions in an ongoing transaction), so retransmissions in an ongoing transaction aren't the ones getting gapped 🙈.
The rate cap ensures that the number of requests received by a SIP server never increases beyond the sum of all rate caps granted to upstream neighbors 🍓. Rate-based overload control protects a SIP server against overload, even during load spikes, assuming there are no new upstream neighbors that start sending traffic. New upstream neighbors need to be considered in the rate caps assigned to all upstream neighbors. The rate assigned to upstream neighbors needs to be adjusted when new neighbors join. During periods when new neighbors are joining, overload can occur in extreme cases until the rate caps of all servers are adjusted to again match the overall rate cap of the server. The overall rate cap of a SIP server is determined by an overload control algorithm, e.g., based on system load 💜.
Rate-based overload control requires a SIP server to assign a rate cap to each of its upstream neighbors while it is activated. Effectively, a server needs to assign a share of its overall capacity to each upstream neighbor 🫶. A server needs to ensure that the sum of all rate caps assigned to upstream neighbors does not substantially oversubscribe its actual processing capacity. This requires a SIP server to keep track of the set of upstream neighbors and to adjust the rate cap if a new upstream neighbor appears or an existing neighbor stops transmitting. For example, if the capacity of the server is X and this server is receiving traffic from two upstream neighbors, it can assign a rate of X/2 to each of them. If a third sender appears, the rate for each sender is lowered to X/3. If the overall rate cap is too high, a server may experience overload. If the cap is too low, the upstream neighbors will reject requests even though they could be processed by the server 😬.
An approach for estimating a rate cap for each upstream neighbor is using a fixed proportion of a control variable, X, where X is initially equal to the capacity of the SIP server. The server then increases or decreases X until the workload arrival rate matches the actual server capacity. Usually, this will mean that the sum of the rate caps sent out by the server (=X) exceeds its actual capacity, but it enables upstream neighbors who are not generating more than their fair share of the work to be effectively unrestricted 🦋. In this approach, the server only has to measure the aggregate arrival rate. However, since the overall rate cap is usually higher than the actual capacity, brief periods of overload may occur. It's a trade-off, bestie ⚖️.
9.2. Loss-Based Overload Control 🌸
A loss percentage enables a SIP server to ask an upstream neighbor to reduce the number of requests it would normally forward to this server by X% 🎀. For example, a SIP server can ask an upstream neighbor to reduce the number of requests this neighbor would normally send by 10%. The upstream neighbor then redirects or rejects 10% of the traffic that is destined for this server.
To implement a loss percentage, the sending entity may employ an algorithm to draw a random number between 1 and 100 for each request to be forwarded. The request is not forwarded to the server if the random number is less than or equal to X 🎲.
An advantage of loss-based overload control is that the receiving entity does not need to track the set of upstream neighbors or the request rate it receives from each upstream neighbor. It is sufficient to monitor the overall system utilization 🧠. To reduce load, a server can ask its upstream neighbors to lower the traffic forwarded by a certain percentage. The server calculates this percentage by combining the loss percentage that is currently in use (i.e., the loss percentage the upstream neighbors are currently using when forwarding traffic), the current system utilization, and the desired system utilization. For example, if the server load approaches 90% and the current loss percentage is set to a 50% traffic reduction, then the server can decide to increase the loss percentage to 55% in order to get to a system utilization of 80%. Similarly, the server can lower the loss percentage if permitted by the system utilization 🙌.
Loss-based overload control requires that the throttle percentage be adjusted to the current overall number of requests received by the server. This is particularly important if the number of requests received fluctuates quickly 😭. For example, if a SIP server sets a throttle value of 10% at time t1 and the number of requests increases by 20% between time t1 and t2 (t1<t2), then the server will see an increase in traffic by 10% between time t1 and t2. This is even though all upstream neighbors have reduced traffic by 10%. Thus, percentage throttling requires an adjustment of the throttling percentage in response to the traffic received and may not always be able to prevent a server from encountering brief periods of overload in extreme cases. So the math isn't always mathing, periodt 💀✨
9.3. Window-Based Overload Control ✨
okay so the big idea here is letting a sender send a set number of messages before it has to hear back 💌 Each sender keeps an overload window, which caps how many messages can be out in the wild without a confirmation. Window-based overload control is inspired by TCP [RFC0793], so if you've ever wondered where this vibe comes from, it's giving classic TCP 🦋
Every sender keeps an unconfirmed message counter for each downstream neighbor it's talking to. Send a message to that neighbor and the counter goes up. Get a confirmation back and it goes down. Once the counter hits the current window size, the sender stops transmitting to that neighbor 🛑
The window size is a crucial parameter for performance 👑 Each sender starts with an initial window size it uses when it first sends a request, and that number can change based on the feedback the receiver sends back 🌸
The sender updates its window size the moment the matching feedback arrives. If the new window size is smaller than the current unconfirmed message counter, the sender pauses. It waits until enough messages get confirmed that the counter drops below the window size, and only then starts sending again 🫶
Heads up, bestie: a100 (Trying)response is NOT a confirmation. 💀 Here's the tea.100 (Trying)responses are often created by a SIP server very early in processing, so they don't mean the message was successfully processed and cleared from the input buffer. If the downstream neighbor is a stateless proxy, it won't create100 (Trying)responses at all. It'll just pass along the ones created by the next stateful server. Also,100 (Trying)responses are typically only created forINVITErequests. Explicit message confirmations don't have any of these problems, which is why they're the real MVP 🏆
Window-based overload control is kind of similar to rate-based overload control, because the receiver's total available buffer space still has to be split among all the upstream neighbors 🍰 The difference is that window-based control is self-limiting, and it can keep the receiver buffer from overflowing under normal conditions. Senders only send as fast as confirmations come back in, so the flow is clocked by the receiver itself ⏱️ The one exception is an extreme case where a huge number of new upstream neighbors show up all at once. Overflow can happen then. Still, senders will eventually stop sending new requests once their initial sending window closes, so it's not all doom 🌈
Here's a wild one: in window-based control, the number of messages a sender can send can often be set to zero 😭 When that happens, the sender still needs to find out when it's allowed to send again and when the receiver window has reopened. But because it's not allowed to send anything, the receiver can't just piggyback the new window size onto a response to another message. So the receiver has to tell the sender some other way, for example by sending a message that carries the new window size 💜
9.4. Overload Signal-Based Overload Control 🚦
The main idea of overload signal-based overload control is to treat a 503 (Service Unavailable) response as a signal that the downstream neighbor is overloaded 📡 When a sender gets one, it cuts back on the load it forwards to that neighbor so it doesn't set off even more 503 (Service Unavailable) responses. If more of them keep coming in, the sender keeps dialing the load down 📉
Quick note: this scheme is based on 503 (Service Unavailable) responses without the Retry-After header. Why? Because Retry-After would make a sender stop forwarding requests entirely, and that's not the vibe here 🙅♀️ It's also worth knowing that 503 responses can be generated for reasons other than overload, like server maintenance 🔧
A sender that hasn't seen any 503 (Service Unavailable) responses for a while, but is still throttling its traffic, can start raising the offered load again 🌱 By slowly ramping up the traffic it forwards, the sender can tell when the overload downstream has cleared and more load can go through. It keeps increasing the load until it gets another 503 (Service Unavailable) response, or until it's forwarding everything it has ✨ One possible algorithm for adjusting traffic like this is additive increase/multiplicative decrease (AIMD) 📈
Overload signal-based overload control is a sender-based overload control mechanism 🙌
9.5. On-/Off Overload Control 🔌
On-/off overload control feedback lets a SIP server switch the traffic it's receiving either on or off 💡 The 503 (Service Unavailable) response with a Retry-After header is what implements on-/off overload control. Real talk though, it's less effective at controlling load than the fine-grained methods above 😬 The good news is that all of the methods above can actually realize on-/off control too, for example by setting the allowed rate to either zero or unlimited 🎀
10. Implicit Overload Control 🕵️♀️
Implicit overload control keeps a SIP server's transmission self-limiting ✨ It slows down a sender's transmission rate when there's a sign that the receiving entity is overloaded. That sign can be the receiving entity not responding within the expected timeframe, or not responding at all 😶 The big idea is that senders should try to sense overload in a downstream neighbor even when there's no explicit overload control feedback. That way, a server that's overloaded enough to stop generating overload control feedback doesn't get buried in requests 🫠
Window-based overload control is inherently self-limiting, since a sender can't keep passing messages along without getting confirmations back 🪟 Every other explicit overload control scheme described above lacks that property, so they all need extra implicit controls to limit transmissions in case an overloaded downstream neighbor doesn't send any explicit feedback 🧸
11. Overload Control Algorithms 🧮
The overload control algorithm is a really important part of designing an overload control mechanism 💅 It decides when the amount of traffic going to a SIP server needs to go down, and when it can go back up. In terms of the model from Section 4, the control algorithm takes (S) as an input and produces (T) as the result 🔢
Overload control algorithms have been studied a LOT, and tons of them exist 📚 With so many options out there, it makes sense for a SIP overload control spec to suggest a baseline algorithm, while still letting people use other algorithms as long as they provide the same protocol semantics. That leaves room for future algorithms, which might lead to better performance 🚀 Going the other way, the overload control mechanism should let people use different algorithms as long as those algorithms stick to the defined protocol semantics 🫶
12. Message Prioritization 🏷️
Overload control can require a SIP server to prioritize requests and pick which ones to reject or redirect 🙈 How that selection works is mostly a matter of the SIP server's local policy, the overall network, and the services the server provides.
There are lots of factors that can affect how SIP requests get prioritized, but the Resource-Priority Header (RPH) field [RFC4412] is a prime candidate for marking that priority 🥇 Depending on the network and the services it offers, a particular namespace and priority value in the RPH could mean one of three things:
- a high priority request, which should be preserved if possible during overload,
- a low priority request, which should be dropped during overload, or
- a label, which has no impact on message prioritization in this network.
Now, responses shouldn't be targeted to reduce SIP server load, and there are a few reasons for that 🙅♀️ Responses can't be rejected, so they'd have to be dropped. That triggers retransmission of the request plus the response, which means even MORE load 🤯 Also, the request tied to a response has already been processed, so dropping the response wastes all the effort already spent on the request. Most importantly, rejecting a request effectively removes the request and the response. If no requests get passed along, there won't be any responses coming back either 🔄
Overload control doesn't change SIP's retransmission behavior 💫 Retransmissions are triggered using the procedures defined in RFC 3261 [RFC3261], and they aren't subject to throttling.
13. Operational Considerations 🛠️
Besides the design considerations we just covered, implementations of a SIP overload control mechanism need to think about the following operational aspects 📋 They matter, but they're out of scope for this document and get left for discussion in other documents 🧚
- Selection of feedback type: A SIP overload control mechanism can support one type of explicit overload control feedback or several. Using a single type (for example, loss-based feedback) keeps the protocol and implementations simpler 🍓 Supporting multiple types (for example, loss- and rate-based feedback) gives more flexibility, but it means there has to be a way to select which feedback type gets used between two servers 🎛️
- Event reporting: Overload is a serious condition for any network of SIP servers, even when an overload control mechanism handles it properly 😤 So overload events should be reported by a SIP server, for example through a logging or management interface 📝
14. Security Considerations ✨
okay bestie, this section is the serious one 🫶 The doc is basically an overview of overload feedback mechanisms, and these mechanisms are meant to be input for other documents that will specify an actual feedback mechanism. Any security measures for a specific mechanism will get talked about in the document that specifies that mechanism. BUT there are common security considerations that must be taken into account no matter which final mechanism gets picked, so we're doing those here 🔒
First up, the rate-based mechanism from Section 9.1 gives a fixed portion of the overloaded server's total inbound traffic to each of its upstream neighbors. So an attacker can pop in a brand new upstream server for a short moment, and the overloaded server lowers the proportional traffic rate to every other existing server. If the attacker brings in lots of these short-lived servers, the total rate arriving at the overloaded server can drop a lot 📉 That cuts the service the attacked server can offer, and it leads to a denial-of-service attack [RFC4732]. Not it. 💀
The same problem shows up in the window-based mechanism from Section 9.3, but it's way less dramatic because of the window acknowledgments the overloaded server sends. An attacker would have to spend resources by constantly sending traffic to keep the receiver window full, so it's a bit more work for them 💪
Every mechanism assumes that the upstream neighbors of an overloaded server actually follow the feedback they get. In the rate- and window-based mechanisms, a server can directly check whether its upstream neighbors are following the requested policies ✅ The loss-based mechanism from Section 9.2 is trickier. It asks upstream neighbors to reduce traffic by a fraction, but the current offered load at the upstream neighbor is unknown. So a server can't directly verify compliance, except when the traffic reduction is set to 100%. In that case, the server has to rely on heuristics to spot upstream neighbors that are trying to get an advantage by not reducing load, or by not reducing it at the requested loss-rate 🕵️♀️ A policing mechanism can be used to throttle or block traffic from unfair or malicious upstream neighbors. Without a widespread policing mechanism like that, the communication link between the upstream neighbors and the overloaded server should be set up so that the identity of both servers at the ends of each link can be established and logged 📝 Transport Layer Security (TLS) and mutual authentication of upstream neighbors [RFC3261] [RFC5922] can be used for this purpose 🔐
Now the scary one. If an attacker controls a server, they can maliciously advertise overload feedback to all of that server's neighbors, even when the server isn't actually overloaded 😱 This forces all the upstream neighbors to reject or queue messages that are headed for the fake-overloaded server. It basically drains the serving capacity of the upstream neighbors, since they now have to handle their normal traffic AND reject or quarantine the traffic meant for the overloaded server. Every mechanism lets the attacker advertise a capacity of 0, which effectively shuts off all traffic to the server pretending to be overloaded and makes all the upstream neighbors burn resources dealing with it. Major villain behavior 🦹♀️
The fix is the same as before: use a communication link where the identity of the servers at both ends is established and logged. TLS and mutual authentication of neighbors [RFC3261] [RFC5922] can be used for this purpose 🫶
Last one, and it's a sneaky one. If an attacker controls several servers in a load-balanced cluster, they can maliciously advertise overload feedback from those servers to all senders. Senders that have a policy to redirect traffic an overloaded server can't process will start redirecting that traffic to the servers that haven't reported overload. That can be used to create a denial-of-service attack on those servers. And if those servers are compromised, the attack can be used to increase the amount of traffic passing through the compromised servers 😭 The good news is this attack is ineffective if servers reject traffic based on overload feedback instead of redirecting it 🙌
15. Informative References
Here are all the references the doc uses for context. Every entry is kept exactly as written 📚
[Abdelal] Abdelal, A. and W. Matragi, "Signal-Based Overload
Control for SIP Servers", 7th Annual IEEE Consumer
Communications and Networking Conference (CCNC-10), Las
Vegas, Nevada, USA, January 2010.
[Hilt] Hilt, V. and I. Widjaja, "Controlling overload in
networks of SIP servers", IEEE International Conference
on Network Protocols (ICNP'08), Orlando, Florida, October
2008.
[Noel] Noel, E. and C. Johnson, "Novel Overload Controls for SIP
Networks", International Teletraffic Congress (ITC 21),
Paris, France, September 2009.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC
4412, February 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload
in the Session Initiation Protocol", RFC 5390, December
2008.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010.
[Shen] Shen, C., Schulzrinne, H., and E. Nahum, "Session
Initiation Protocol (SIP) Server Overload Control: Design
and Evaluation, Principles", Systems and Applications of
IP Telecommunications (IPTComm'08), Heidelberg, Germany,
July 2008.Appendix A. Contributors 🎀
Huge thank-yous to everyone who helped with the contributions, comments, and feedback on this document! 💖 They are: Mary Barnes (Nortel), Janet Gunn (CSC), Carolyn Johnson (AT&T Labs), Paul Kyzivat (Cisco), Daryl Malas (CableLabs), Tom Phelan (Sonus Networks), Jonathan Rosenberg (Cisco), Henning Schulzrinne (Columbia University), Robert Sparks (Tekelec), Nick Stewart (British Telecommunications plc), Rich Terpstra (Level 3), and Fangzhe Chang (Bell Labs/Alcatel-Lucent). You all are literally the best 🌸🫶
Authors' Addresses 🦋
Meet the authors! 🧚
Volker Hilt
Bell Labs/Alcatel-Lucent
791 Holmdel-Keyport Rd
Holmdel, NJ 07733
USA
EMail: volker.hilt@alcatel-lucent.com
Eric Noel
AT&T Labs
EMail: eric.noel@att.com
Charles Shen
Columbia University
EMail: charles@cs.columbia.edu
Ahmed Abdelal
Sonus Networks
EMail: aabdelal@sonusnet.com📦 where this page comes from
- ietf: rfc6357 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms