RFC 7339
Session Initiation Protocol (SIP) Overload Control
RFC 7339: Session Initiation Protocol (SIP) Overload Control ✨
okay bestie, this is RFC 7339 🦋 and it's all about how SIP servers handle being overloaded. It's a Standards Track document, which means it's an official Internet standard, not just a suggestion 💅. It came out in September 2014 🎀 and its ISSN is 2070-1721. The author list is V. Gurbani (Ed.), V. Hilt, and H. Schulzrinne 🫶. Gurbani and Hilt are from Bell Labs, Alcatel-Lucent, and Schulzrinne is from Columbia University 🌈. The header doesn't list any RFCs it obsoletes or updates, so this one is standing on its own 👑.
Abstract
Overload happens in SIP networks when SIP servers don't have enough resources to handle every SIP message they get 😭. SIP already has a little overload control feature through its 503 (Service Unavailable) response code, but servers are still vulnerable anyway 💀. This document defines how SIP servers behave when they're doing overload control, and it also specifies a loss-based overload scheme for SIP 🔥.
Status of This Memo
This is an Internet Standards Track document 💜.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🙌. For more on Internet Standards, check out Section 2 of RFC 5741 ✨.
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7339 🍓.
Copyright Notice
Copyright (c) 2014 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're in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document 📜. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 💖.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview of Operations ..........................................6
4. Via Header Parameters for Overload Control ......................6
4.1. The "oc" Parameter .........................................6
4.2. The "oc-algo" Parameter ....................................7
4.3. The "oc-validity" Parameter ................................8
4.4. The "oc-seq" Parameter .....................................8
5. General Behavior ................................................9
5.1. Determining Support for Overload Control ..................10
5.2. Creating and Updating the Overload Control Parameters .....10
5.3. Determining the "oc" Parameter Value ......................12
5.4. Processing the Overload Control Parameters ................12
5.5. Using the Overload Control Parameter Values ...............13
5.6. Forwarding the Overload Control Parameters ................14
5.7. Terminating Overload Control ..............................14
5.8. Stabilizing Overload Algorithm Selection ..................15
5.9. Self-Limiting .............................................15
5.10. Responding to an Overload Indication .....................16
5.10.1. Message Prioritization at the Hop before
the Overloaded Server .............................16
5.10.2. Rejecting Requests at an Overloaded Server ........17
5.11. 100 Trying Provisional Response and Overload
Control Parameters .......................................17
6. Example ........................................................18
7. The Loss-Based Overload Control Scheme .........................19
7.1. Special Parameter Values for Loss-Based Overload Control ..19
7.2. Default Algorithm for Loss-Based Overload Control .........20
8. Relationship with Other IETF SIP Load Control Efforts ..........23
9. Syntax .........................................................24
10. Design Considerations .........................................24
10.1. SIP Mechanism ............................................24
10.1.1. SIP Response Header ...............................24
10.1.2. SIP Event Package .................................25
10.2. Backwards Compatibility ..................................26
11. Security Considerations .......................................27
12. IANA Considerations ...........................................29
13. References ....................................................29
13.1. Normative References .....................................29
13.2. Informative References ...................................30
Appendix A. Acknowledgements ......................................31
Appendix B. RFC 5390 Requirements .................................311. Introduction ✨
okay so any network box can get overloaded, and a Session Initiation Protocol (SIP) [RFC3261] server is no exception 💀. It gets into trouble when the number of SIP messages it receives is bigger than the number it can actually process 😭. Overload is a big deal for a whole network of SIP servers 🫠. During overload, the throughput of that network can get seriously wrecked. Even worse, retransmissions of the SIP messages that got dropped can flood the network and use up all its capacity. People call this "congestion collapse" 💔.
Overload is said to happen when a SIP server doesn't have enough resources to process every incoming SIP message ✨. Those resources can include CPU processing capacity, memory, input/output, or disk resources 🧚.
For overload control, this document only covers failure cases where SIP servers can't process every SIP request because they're short on resources 🎯. There are other situations where a SIP server can process incoming requests just fine but still has to reject them, because of failures that have nothing to do with overload 🙈. For example, a Public Switched Telephone Network (PSTN) gateway that runs out of trunks but still has plenty of room to process SIP messages should reject incoming INVITEs with a 488 (Not Acceptable Here) response [RFC4412]. Same vibe for a SIP registrar that has lost its connection to its registration database but can still process SIP requests. It should reject REGISTER requests with a 500 (Server Error) response [RFC3261]. Overload control doesn't apply to these cases 💅, because SIP already has the right response codes for them.
SIP has a limited overload control mechanism through its 503 (Service Unavailable) response code 🌸. The problem is that this mechanism can't stop a SIP server from getting overloaded, and it can't stop congestion collapse either 😬. Using the 503 (Service Unavailable) response code can actually make traffic oscillate and bounce between SIP servers, which makes the overload worse 🙃. You can find a detailed breakdown of the SIP overload problem, the issues with the 503 (Service Unavailable) response code, and the requirements for a SIP overload control mechanism in [RFC5390] 📚.
This document defines the protocol for passing overload info between SIP servers and clients. That way, clients can send less traffic to overloaded servers, which helps avoid congestion collapse and keeps useful throughput up 🚀. Section 4 covers the Via header parameters used for this communication. The general behavior of SIP servers and clients during overload control is in Section 5. Section 7 specifies a loss-based overload control scheme 🦋.
This document specifies the loss-based overload control scheme (Section 7), which is mandatory to implement for this specification 🔥. It also allows other overload control schemes to be supported. To make that work well, the expectations and primitive protocol parameters shared by all classes of overload control schemes are specified in this document 🫶.
2. Terminology ✨
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 described in RFC 2119 [RFC2119] 💖.
In this document, "SIP client" and "SIP server" are used in their generic forms 🌈. So a "SIP client" could mean the client transaction state machine in a SIP proxy, or it could mean a user agent client (UAC). Likewise, a "SIP server" could be a user agent server (UAS) or the server transaction state machine in a proxy 🎀. There are other combos too. For instance, SIP clients and servers could also be part of back-to-back user agents (B2BUAs) 🧚.
No matter the context (proxy, B2BUA, UAS, UAC), "SIP client" applies to any SIP entity that provides overload control to traffic going downstream 🍓. And "SIP server" applies to any SIP entity that's overloaded and wants its upstream neighbor to throttle the incoming traffic 💜.
Unless otherwise specified, every SIP entity described in this document is assumed to support this specification 🙌.
The normative statements in this specification, as they apply to SIP clients and SIP servers, assume that both the SIP clients and SIP servers support this specification 📜. So if only a SIP client supports this specification and not the SIP server, the normative statements about SIP server behavior don't apply to that server, since it doesn't support the spec 🫠.
3. Overview of Operations ✨
This section gives you the overview of how the overload control mechanism works by introducing the overload control parameters 🦋. Section 4 goes deeper into the details and normative behavior for the parameters listed below.
Overload control is performed hop-by-hop, which is why the Via header parameter is such a good fit 🎀. It lets two adjacent SIP entities indicate that they support overload control and swap overload control info [RFC6357]. There are more perks to this choice, which are discussed in Section 10.1.1 ✨. The team also considered an alternative using SIP event packages, and Section 10.1.2 outlines how that option compares 🔍.
This document defines four new parameters for the SIP Via header for overload control 🌸. They give adjacent SIP entities a way to share overload control info. The "oc" parameter is used by a SIP server to indicate a reduction in the number of requests arriving at the server 📉. The "oc-algo" parameter contains a token or a list of tokens that match the classes of overload control algorithms the client supports, and the server picks one algorithm from that list 🧩. The "oc-validity" parameter sets a time limit for how long overload control stays in effect 🕒. The "oc-seq" parameter helps the client put the responses in order 🔢. The next section goes into detail on all of these 💅.
4. Via Header Parameters for Overload Control 🎀
The four Via header parameters get introduced below 💖. More context on how to interpret them under different conditions is in Section 5 🦋.
Ok bestie, that's part 1 of 8 done! 🌈✨
4.1. The "oc" Parameter ✨
Okay so this one is inserted by the SIP client and then updated by the SIP server, like a little tag team 💅
A SIP client MUST add an oc parameter to the topmost Via header it inserts into every SIP request. This is basically the client waving at its downstream neighbors saying "hey, I speak overload control" 🦋 There MUST NOT be a value associated with the parameter, because the server is the one who fills that in 🫶
The downstream server MUST add a value to the oc parameter in the response going upstream to a client that included the oc parameter in the request. Putting a value in there means two things. First, on the very first contact (see Section 5.1), if the server adds a value, it's telling the client that it supports overload control as defined in this document 🌸 Second, if overload control is active, the value tells the client how much control to apply 👑
When a SIP client gets a response with the value in the oc parameter filled in, it MUST reduce the number of requests going downstream to the SIP server that sent the response. The reduction is set by the oc and oc-algo parameters (see Section 5.10 for more on traffic reduction) 💖
4.2. The "oc-algo" Parameter 🎀
This one is also inserted by the SIP client and updated by the SIP server.
A SIP client MUST add an oc-algo parameter to the topmost Via header it inserts into every SIP request, with a default value of loss 🍓
This parameter holds the names of one or more classes of overload control algorithms. A SIP client MUST support the loss-based overload control scheme and MUST insert at least the token loss as one of the oc-algo parameter values. The client MAY also insert other tokens, separated by a comma, if it supports other overload control schemes, like a rate-based scheme [RATE-CONTROL] 🌈 Each item in that comma-separated list stands for a class of overload control algorithms the client supports. If there's more than one class in the list, the client may show its preference by ordering the list from most preferred to least preferred. Still, the client cannot assume the server will pick the most preferred one 🙈
When a downstream SIP server gets a request with multiple overload control algorithms in the oc-algo parameter (optionally sorted by decreasing order of preference), it picks one algorithm from the list. It MUST return that single selected algorithm to the client ✨
Once the SIP server has chosen a mutually agreeable class of overload control algorithms and told the client about it, the selection stays in effect until the server changes the algorithm. The client MUST keep including all the supported algorithms in later requests, and the server MUST respond with the agreed-to algorithm until the server changes it. Very structured, very iconic 👑
The selection SHOULD stay the same for a non-trivial amount of time, so the overload control algorithm has time to settle into its behavior (see Section 5.8) 🦋
The oc-algo parameter doesn't define the exact algorithm used for traffic reduction. The point is to use any algorithm from a specific class that reduces traffic in a similar way. For example, the reference algorithm in Section 7.2 can be used as a loss-based algorithm, or it can be swapped for any other loss-based algorithm that gives equivalent traffic reduction 💅
4.3. The "oc-validity" Parameter ⏳
This parameter MAY be inserted by the SIP server in a response. It MUST NOT be inserted by the SIP client in a request 🧚
This parameter holds a value that marks an interval of time, measured in milliseconds, during which the load reduction given in the oc parameter should be in effect. The default value of the oc-validity parameter is 500 milliseconds. If the client gets a response with the oc and oc-algo parameters suitably filled in but no oc-validity parameter, the SIP client should behave as if it had received oc-validity=500 💜
A value of 0 in the oc-validity parameter is reserved. It means either that the server wants to stop overload control, or that the server supports overload control but isn't asking for any traffic reduction right now (see Section 5.7) 🌸
A non-zero value for the oc-validity parameter MUST only be present together with an oc parameter. A SIP client MUST discard a non-zero oc-validity value if it receives one in a response without the matching oc parameter 🙅♀️
After the value in the oc-validity parameter expires, and until the SIP client gets an updated set of overload control parameters from the SIP server, overload control is not in effect between the client and the downstream SIP server 💀
4.4. The "oc-seq" Parameter 🔢
This parameter MUST be inserted by the SIP server in a response. It MUST NOT be inserted by the SIP client in a request 🫶
This parameter holds an unsigned integer that gives the sequence number for the oc parameter. The sequence number is how you tell apart two oc parameter values that an overload control algorithm generated at two different moments in time. oc parameter values generated at times t and t+1 MUST have an increasing value in the oc-seq parameter. This lets the upstream SIP client sort out responses that arrive out of order 🧩
Note: A timestamp can be used as a value of the oc-seq parameter.
If the value in the oc-seq parameter overflows while the load reduction is in effect, the oc-seq parameter MUST be reset to the current timestamp or an appropriate base value 😭
Note: A client implementation can recognize that an overflow has occurred when it receives anoc-seqparameter whose value is significantly less than several previous values. (Note that anoc-seqparameter whose value does not deviate significantly from the last several previous values is symptomatic of a tardy packet. However, overflow will cause theoc-seqparameter value to be significantly less than the last several values.) If an overflow is detected, then the client should use the overload parameters in the new message, even though the sequence number is lower. The client should also reset any internal state to reflect the overflow so that future messages (following the overflow) will be accepted.
5. General Behavior 🌟
When a SIP client forwards a SIP request, it uses the SIP procedures of [RFC3263] to find the next-hop SIP server. Those procedures take a SIP URI as input, pull out the domain portion of that URI to use as a lookup key, and then query the Domain Name Service (DNS). The DNS gives back an ordered set of one or more IP addresses, each with a port number and transport. That's the "Expected Output" 🗺️
After picking a specific SIP server from the Expected Output, a SIP client checks whether overload controls are currently active with that server. If they are (and the oc-validity period hasn't expired yet), the client applies the relevant algorithm to decide whether to send the SIP request to that server. If overload controls aren't currently active with this server, the client sends the SIP message without invoking any overload control algorithm. That happens when this is the first contact with the server, when the last response from the server had oc-validity=0, or when the time period from the oc-validity parameter has run out ⏰
5.1. Determining Support for Overload Control 🔍
If a client figures out that this is the first contact with a server, the client MUST insert the oc parameter without any value, and it MUST insert the oc-algo parameter with a list of the algorithms it supports. That list MUST include loss, and it MAY include other algorithm names that IANA has approved and that are described in corresponding documents. The client then sends the request to the chosen server 🦋
If a server gets a SIP request containing the oc and oc-algo parameters, the server MUST determine whether it has already selected an overload control algorithm class with this client. If it has, the server SHOULD use that previously selected algorithm class in its response. If the server decides the message is from a new client, or from a client it hasn't heard from in a long time, the server MUST choose one algorithm from the list in the oc-algo parameter. It MUST put the chosen algorithm as the sole parameter value in the oc-algo parameter of the response it sends to the client 💅
Also, if the server isn't currently in an overload condition, it MUST set the value of the oc parameter to 0, and it MAY insert an oc-validity=0 parameter in the response to further qualify the value in the oc parameter. If the server is currently overloaded, it MUST follow the procedures in Section 5.2 🌸
Note: A client that supports the rate-based overload control scheme [RATE-CONTROL] will consideroc=0as a sign not to send any requests downstream at all. So when the server also insertsoc-validity=0, it's saying "I do support overload control, but I'm not in overload mode right now" (see Section 5.7) 🫧
5.2. Creating and Updating the Overload Control Parameters 💖
okay so a SIP server gives overload feedback to its upstream clients by putting a value for the "oc" parameter on the topmost Via header field of a SIP response. That's the Via header the client added before it sent the request to the server 🎀
Since the topmost Via header of a response gets removed by the upstream client after it processes the response, the overload control feedback in "oc" never travels past that upstream SIP client 🫶 So a Via header parameter gives you hop-by-hop semantics for overload control feedback (see [RFC6357]), even if the next-hop neighbor doesn't support this specification. iconic, right? 💅
The "oc" parameter can show up in every response type: provisional, success, and failure responses. (Please see Section 5.11 for special considerations on transporting overload control parameters in a 100 Trying response, bestie.) A SIP server can update "oc" in a response to ask the client to send more or fewer requests to it, or to stop doing overload control altogether ✨
A SIP server that has updated "oc" SHOULD also add an "oc-validity" parameter. This one defines the time in milliseconds during which the overload control feedback in "oc" is valid. The default value of "oc-validity" is 500 (milliseconds) ⏱️
When a SIP server retransmits a response, it SHOULD use the "oc" and "oc-validity" values that match the overload state at the time the retransmitted response was sent. This means those values might be different from the ones used in earlier retransmissions of the same response 🦋 Responses sent over UDP can get delayed in the network and arrive out of order, so the "oc-seq" parameter helps detect a stale "oc" value. it's giving detective energy 🕵️♀️
Implementations that can update the "oc" and "oc-validity" values during retransmissions MUST insert the "oc-seq" parameter. The value of this parameter MUST be a set of numbers drawn from an increasing sequence 🔥
Implementations that can't update "oc" and "oc-validity" during retransmissions, or that don't want to, because they'd have to regenerate the message to be retransmitted, MUST still insert a "oc-seq" parameter in the first response associated with a transaction. They don't have to update the value in later retransmissions though 🌸
The "oc-validity" and "oc-seq" Via header parameters are only defined in SIP responses and MUST NOT be used in SIP requests. Only the upstream neighbor of a SIP server (the entity sending requests to it) really needs these, because the client is the one that can offload traffic by redirecting or rejecting new requests 🧚 If requests get forwarded in both directions between two SIP servers, the roles of upstream and downstream neighbors swap, and responses flow both ways too. So both SIP servers can exchange overload information 💜
This specification gives you a solid overload control mechanism that can protect a SIP server from overload. Now, if a SIP server wants to limit advertisements of its overload control capability for privacy reasons, it might decide to do overload control only for requests received on a secure transport, such as Transport Layer Security (TLS). Indicating support for overload control on a request received over an untrusted link can leak privacy, in the form of the server's capabilities 🙈 To limit what anyone knows about the server's overload control support, a server can adopt a policy of inserting overload control parameters only in requests received over trusted links. That way the parameters are only visible to trusted neighbors 🔐
5.3. Determining the "oc" Parameter Value 🌈
The overloaded server decides the value of "oc" using any useful information it has. The only constraint this document puts on it is that the server control algorithm MUST produce a value for "oc" that the server expects the receiving SIP clients to apply to all downstream SIP requests (both dialogue forming and in-dialogue) sent to this SIP server. Beyond that, how an overloaded server works out the value of "oc" is out of scope for this document 🙌
Note: This stipulation is required so that both the client and server have a common view of which messages the overload control applies to. With this stipulation in place, the client can prioritize messages as discussed in Section 5.10.1.
For example, "oc=10" with the loss-based algorithm means 10% of the total SIP requests (dialogue forming as well as in-dialogue) are subject to reduction at the client. Similarly, "oc=10" with the rate-based algorithm [RATE-CONTROL] means the client should send 10 SIP requests or fewer per second 💖
5.4. Processing the Overload Control Parameters 🎀
A SIP client SHOULD remove the "oc", "oc-validity", and "oc-seq" parameters from all Via headers of a received response, except for the topmost Via header. This stops overload control parameters that a downstream SIP server accidentally or maliciously inserted into Via headers from traveling upstream 🛡️
Overload control applies to unique combinations of IP and port values. A SIP client keeps the overload control values it received (along with the address and port number of the SIP servers they came from) for the duration given in "oc-validity", or for the default duration. Each time a SIP client gets a response with an overload control parameter from a downstream SIP server, it compares the "oc-seq" value from the Via header with the "oc-seq" value stored for that server. If they match, the response doesn't update the overload control parameters for this server, and the client keeps providing overload control as previously negotiated 🤝
If the "oc-seq" value from the Via header is larger than the stored value, the client updates its stored values by copying the new "oc", "oc-algo", and "oc-seq" values from the Via header. Once it does, the client restarts the validity period for the new parameters. Those parameters stay in effect until the validity period expires or they get updated in a new response ⏳
Stored overload control parameters MUST be reset to default values once the validity period has expired (see Section 5.7 for the detailed steps on terminating overload control). Bye-bye old values! 👋✨
5.5. Using the Overload Control Parameter Values 🍓
A SIP client MUST honor overload control values it receives from downstream neighbors. It MUST NOT forward more requests to a SIP server than the current "oc" and "oc-algo" values from that particular downstream server allow 🚦
When forwarding a SIP request, a SIP client uses the SIP procedures of [RFC3263] to determine the next-hop SIP server. Those procedures take a SIP URI as input, pull out the domain portion of that URI to use as a lookup key, and query the DNS for an ordered set of one or more IP addresses. Each IP address in that set comes with a port number and a transport (the Expected Output) 🌐
After the client picks a specific SIP server from the Expected Output, it checks whether it already has overload control parameter values for that server. If the client has a non-expired "oc" value for the chosen server, that server is operating in overload control mode. So the client decides whether it can forward the current request to that SIP server, based on "oc", "oc-algo", and any relevant local policy 💅
Which algorithm decides whether to forward a particular SIP request is a matter of local policy, and it can weigh all kinds of prioritization factors. Still, this local policy SHOULD transmit the same number of SIP requests as the sample algorithm defined by the overload control scheme in use. (See Section 7.2 for the default loss-based overload control algorithm.) 🧮
5.6. Forwarding the Overload Control Parameters 🦋
Overload control is defined hop by hop. So forwarding the contents of the overload control parameters is generally NOT RECOMMENDED, and should only be done if the configuration of the SIP servers permits it 🙅♀️ This means a SIP proxy SHOULD strip the overload control parameters the client inserted before it proxies the request further downstream. Of course, when the proxy acts as a client and proxies the request downstream, it's free to add overload control parameters that are pertinent to itself in the Via header it inserted into the request 💕
5.7. Terminating Overload Control 🌙
A SIP client removes overload control if one of the following events occurs:
- The
"oc-validity"period the client previously received from this server expires (or the default value of 500 ms applies if the server didn't previously specify an"oc-validity"parameter). - The server explicitly tells the client to stop performing overload control using
"oc-validity=0".
A SIP server can decide to terminate overload control by explicitly signaling the client. To do that, the SIP server MUST set the value of "oc-validity" to 0. The SIP server MUST increment the value of "oc-seq", and SHOULD set the value of "oc" to 0 💫
Note: The loss-based overload control scheme (Section 7) can effectively stop overload control by setting the value of"oc"to 0. However, the rate-based scheme [RATE-CONTROL] needs an additional piece of information, in the form of"oc-validity=0".
When the client receives a response with a higher "oc-seq" number than the one it most recently processed, it checks "oc-validity". If that value is 0, the client knows overload control for messages destined to the server is no longer necessary, and the traffic can flow without any reduction 🎉 Furthermore, when "oc-validity" is 0, the client SHOULD disregard the value in "oc" 🌸
5.8. Stabilizing Overload Algorithm Selection ✨
Okay bestie, real life is messy 😭 Servers get rebooted and software gets upgraded, so the overload control algorithm is allowed to change in those situations. BUT frequent changes must be avoided 🙅♀️ Flapping doesn't help the client OR the server, because the chosen algorithm never gets a chance to settle. 💅 When a change is actually wanted, the SIP server just picks a new algorithm from the list in the client's oc-algo parameter and sends it back in a response. Iconic, right? 🦋
The client keeps track of which algorithm goes with each server it sends traffic to. When the server switches algorithms, the client must change its behavior accordingly. 🔄
Once the server picks a specific overload control algorithm for a given client, it SHOULD NOT change that algorithm for at least 3600 seconds (1 hour) 🕐 That window can cover one or more rounds of overload control turning on and then off again, depending on the traffic and the resources at the server. ✨
Note: One way to accomplish this involves the server saving the time of the last algorithm change in a lookup table, indexed by the client's network identifiers. The server only changes the oc-algo parameter when the time since the last change has surpassed 3600 seconds.
5.9. Self-Limiting 🙈
Sometimes a SIP client sends a request and never hears back from the server 😳 RFC 3261 [RFC3261] covers this, and it says:
Note: When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer ..., the condition MUST be treated as a 503 (Service Unavailable) status code.
If timeouts or fatal transport errors keep happening, the SIP client MUST stop sending requests to that server. 🛑 It SHOULD periodically check whether the downstream server is alive, using whatever mechanism it has. Clients should be conservative about this probing (for example, using an exponential back-off), so their liveness checks don't make an overload situation even worse. 🙏 Once a SIP client gets a normal response to a request it sent to the downstream server, it can start sending SIP requests again. 🥳 Of course, it should honor any overload control parameters it receives in the initial response or any later ones. 💖
5.10. Responding to an Overload Indication 🧚
A SIP client can receive overload control feedback saying it needs to send less traffic to its downstream server. 📉 One way to do that is to send some of the requests that would have gone to the overloaded element to a different destination. 🗺️
The client has to make sure that other destination is not overloaded too and can handle the extra load 👀 A client can also buffer requests, hoping the overload clears up quickly so the requests can still go out in time. ⏳ But in lots of cases, the client will have to reject these requests with a "503 (Service Unavailable)" response without the Retry-After header. 💔
5.10.1. Message Prioritization at the Hop before the Overloaded Server 🎀
During an overload, a SIP client has to decide which requests get rejected or redirected, and that choice is mostly up to local policy. 🧠 The client is expected to follow local policy as long as the traffic reduction still matches the overload algorithm in effect at that node. So the normative behavior in the next three paragraphs should be read with the understanding that the SIP client will try to keep local policy intact as much as possible. 💜
A SIP client SHOULD honor the local policy for prioritizing SIP requests, such as policies based on message type (for example, INVITEs versus requests tied to existing sessions). 📞
A SIP client SHOULD honor the local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH) [RFC4412]. Specific (namespace.value) RPH contents may flag high-priority requests that should be preserved as much as possible during overload. The RPH contents can also flag a low-priority request that's allowed to be dropped when things get overloaded. 🫶
A SIP client SHOULD honor the local policy for prioritizing SIP requests about emergency calls, as identified by the SOS URN [RFC5031] that indicates an emergency request. 🚨 This policy makes sure that when a server is overloaded and non-emergency calls outnumber emergency calls arriving at the client, the few emergency calls get preference. 🙌 But if the server is overloaded and most of the calls arriving at the client are emergencies, then no amount of message prioritization can guarantee every emergency call gets delivered, if the client is also going to cut traffic the way the server asked. 😢
A local policy can be expected to combine both the SIP request type and the prioritization markings, and it SHOULD be honored when overload conditions prevail. 👑
5.10.2. Rejecting Requests at an Overloaded Server 🛡️
If the upstream SIP client talking to the overloaded server doesn't support overload control, it'll keep sending requests to that server anyway 😤 So for a non-participating client, the overloaded server has to pay the cost of rejecting some of its requests AND the cost of processing the ones it didn't reject, all the way through. It would be fair for the overloaded server to spend the same amount of processing on that mix of rejecting and processing as it would spend on requests from a participating client. ⚖️ This makes sure SIP clients that don't support this specification don't get an unfair advantage over the ones that do. 💅
A SIP server that is in overload and has started to throttle incoming traffic MUST reject some requests from non-participating clients with a 503 (Service Unavailable) response without the Retry-After header. 🚫
5.11. 100 Trying Provisional Response and Overload Control Parameters 💌
The overload control information a SIP server sends to a client rides along in its responses. 📨 Implementations can put overload control information in any response, but overload control information carried in a 100 Trying response deserves some extra attention 👀
Traditionally, the 100 Trying response has been used in SIP to quench retransmissions. 🤫 In some implementations, the 100 Trying message may not be generated by the transaction user (TU) or consumed by the TU. In those implementations, the 100 Trying response is generated at the transaction layer and sent to the upstream SIP client. On the receiving side, the 100 Trying is consumed at the transaction layer by stopping the retransmission of the corresponding request. 🙃 So an implementation that puts overload control information in the 100 Trying can't assume the upstream SIP client passed that information in the 100 Trying along to its corresponding TU. 😬 That's why implementations that insert overload control information in the 100 Trying MUST re-insert the same (or updated) overload control information in the first non-100 Trying response being sent to the upstream SIP client. 🔁
6. Example 🧚
Let's look at a SIP client, P1, sending requests to another downstream SIP server, P2. 🎬 The snippets below show how the overload control parameters work.
INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;oc;oc-algo="loss,A"
...
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0
...In the messages above, the first line is sent by P1 to P2. It's a SIP request, and because P1 supports overload control, it puts the "oc" parameter in the topmost Via header that it created. 💖 P1 supports two overload control algorithms: "loss" and one called "A".
The second line, a SIP response, shows the topmost Via header that P2 changed according to this specification, sent back to P1. 🌸 P2 also supports overload control and goes with the loss-based scheme, so it sends "loss" back to P1 in the "oc-algo" parameter. It also sets "oc" and "oc-validity" to 0, because it isn't asking for overload control to kick in right now. 🙌
Had P2 not supported overload control, it would have left the "oc" and "oc-algo" parameters unchanged, which lets the client know P2 doesn't support overload control. 🤷♀️
Later on, P2 starts to get overloaded 😰 It sends this SIP message, telling P1 to decrease the messages arriving at P2 by 20% for 0.5 seconds:
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.3;received=192.0.2.111;
oc=20;oc-algo="loss";oc-validity=500;
oc-seq=1282321615.782
...After a while, the overload at P2 calms down 🥹 So P2 changes the parameter values in the response it sends to P1, letting P1 send all messages destined for P2 again.
SIP/2.0 183 Queued
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.4;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
...7. The Loss-Based Overload Control Scheme 👑
With a loss-based approach, a SIP server asks an upstream neighbor to cut the number of requests it would normally forward to this server by a certain percentage. 📊 For example, a SIP server can ask an upstream neighbor to reduce the number of requests that neighbor would normally send by 10%. The upstream neighbor then redirects or rejects 10% of the traffic that was originally headed to that server. 🔀
This section spells out the semantics of the overload control parameters for the loss-based overload control scheme. The general behavior of SIP clients and servers is in Section 5, and it applies to SIP clients and servers that implement loss-based overload control. 📖
7.1. Special Parameter Values for Loss-Based Overload Control 🦋
The loss-based overload control scheme is identified with the token loss. This token shows up in the oc-algo parameter list sent by the SIP client. 🏷️
When a SIP server that has picked the loss-based algorithm enters the overload state, it assigns a value to the oc parameter. This value MUST be in the range of [0, 100], inclusive. 💯 The value tells the client what percentage it should cut the number of requests being forwarded to the overloaded server. The SIP client can use any algorithm it likes, as long as it reduces the traffic sent to the overloaded server by the amount indicated. 🎯
An algorithm like that should honor the message prioritization discussion in Section 5.10.1. ✨ A particular algorithm isn't subject to standardization, but for completeness, a default algorithm for loss-based overload control is given in Section 7.2. 🌈
7.2. Default Algorithm for Loss-Based Overload Control ✨
okay so this section is a default algorithm a SIP client can use to throttle the SIP traffic going downstream by the percentage loss value in the "oc" parameter 💅
The client keeps two categories of requests, bestie. Category one holds the requests that are candidates for reduction. Category two holds the requests that are not subject to reduction, except when every category one message has already been rejected and more reduction is still needed 😭 Check Section 5.10.1 for the directives on putting messages into category two. Everything else goes into category one.
When the client is under overload, it converts the "oc" value into a number it applies to category one requests. Here's a simple example, if "oc=10" and 40% of the requests should be in category one:
10 / 40 * 100 = 25So 25% of the category one requests get reduced, which gives an overall reduction of 10% 🔥 The client uses random discard to hit that 25% reduction in category one. Category two messages just proceed downstream unscathed 🦋 To make the 25% rate happen, the client draws a random number between 1 and 100 for the request it picked from category one. If the random number is less than or equal to the converted "oc" value, the request is not forwarded. Otherwise, it gets forwarded.
Here's a reference algorithm 🧚
cat1 := 80.0 // Category 1 -- Subject to reduction
cat2 := 100.0 - cat1 // Category 2 -- Under normal operations,
// only subject to reduction after category 1 is exhausted.
// Note that the above ratio is simply a reasonable default.
// The actual values will change through periodic sampling
// as the traffic mix changes over time.
while (true) {
// We're modeling message processing as a single work
// queue that contains both incoming and outgoing messages.
sip_msg := get_next_message_from_work_queue()
update_mix(cat1, cat2) // See Note below
switch (sip_msg.type) {
case outbound request:
destination := get_next_hop(sip_msg)
oc_context := get_oc_context(destination)
if (oc_context == null) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop since this
// particular destination is not subject to overload.
}
else {
// Determine if server wants to enter in overload or is in
// overload.
in_oc := extract_in_oc(oc_context)
oc_value := extract_oc(oc_context)
oc_validity := extract_oc_validity(oc_context)
if (in_oc == false or oc_validity is not in effect) {
send_to_network(sip_msg) // Process it normally by sending
// the request to the next hop since this particular
// destination is not subject to overload. Optionally,
// clear the oc context for this server (not shown).
}
else { // Begin performing overload control.
r := random()
drop_msg := false
category := assign_msg_to_category(sip_msg)
pct_to_reduce_cat1 = oc_value / cat1 * 100
if (oc_value <= cat1) { // Reduce all msgs from category 1
if (r <= pct_to_reduce_cat1 && category == cat1) {
drop_msg := true
}
}
else { // oc_value > category 1. Reduce 100% of msgs from
// category 1 and remaining from category 2.
pct_to_reduce_cat2 = (oc_value - cat1) / cat2 * 100
if (category == cat1) {
drop_msg := true
}
else {
if (r <= pct_to_reduce_cat2) {
drop_msg := true;
}
}
}
if (drop_msg == false) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop.
}
else {
// Do not send request downstream; handle it locally by
// generating response (if a proxy) or treating it as
// an error (if a user agent).
}
} // End perform overload control.
}
end case // outbound request
case outbound response:
if (we are in overload) {
add_overload_parameters(sip_msg)
}
send_to_network(sip_msg)
end case // outbound response
case inbound response:
if (sip_msg has oc parameter values) {
create_or_update_oc_context() // For the specific server
// that sent the response, create or update the oc context,
// i.e., extract the values of the oc-related parameters
// and store them for later use.
}
process_msg(sip_msg)
end case // inbound response
case inbound request:
if (we are not in overload) {
process_msg(sip_msg)
}
else { // We are in overload.
if (sip_msg has oc parameters) { // Upstream client supports
process_msg(sip_msg) // oc; only sends important requests.
}
else { // Upstream client does not support oc
if (local_policy(sip_msg) says process message) {
process_msg(sip_msg)
}
else {
send_response(sip_msg, 503)
}
}
}
end case // inbound request
}
}Note: a simple way to sample the traffic mix for category 1 and category 2 is to give each category its own counter. Every 5-10 seconds, read the counters and work out the ratio of category 1 messages to category 2 messages since the last calculation. 📊
Example: say in the last 5 seconds, 500 requests hit the queue. 450 of the 500 were subject to reduction, and 50 of the 500 were classed as not subject to reduction. That makes it cat1 := 90 and cat2 := 10, so a 90/10 mix gets used in the overload calculations 💜
8. Relationship with Other IETF SIP Load Control Efforts ✨
okay so this overload control mechanism is reactive 🙈 Apart from the message prioritization directives in Section 5.10.1, it won't discriminate requests based on user identity, filtering action, or arrival time. If a SIP network needs pro-active overload control, it can upload user-level load control filters, as described in [RFC7200]. Local policy also decides which overload control mechanism takes precedence over the traffic 👑 Say load control filters are installed by signaling neighbors [RFC7200], and the same traffic can also get throttled by this overload control mechanism. Then local policy decides which of those schemes gets priority. How the two schemes interact is out of scope for this document, so that's a whole other story 🫶
9. Syntax 🎀
This spec extends the existing definition of the Via header field parameters from [RFC3261] 💖 Here's the ABNF [RFC5234] syntax:
via-params =/ oc / oc-validity / oc-seq / oc-algo
oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT
oc-validity = "oc-validity" [EQUAL delta-ms]
oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list)
DQUOTE
algo-list = "loss" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39
delta-ms = 1*DIGIT10. Design Considerations 🌸
This section talks through specific design considerations for the mechanism in this document. For the general design considerations for SIP overload control, check [RFC6357] 🧠
10.1. SIP Mechanism 🦋
We need a SIP mechanism to send overload feedback from the receiving SIP entity to the sending SIP entity. There are a bunch of different ways to build one 💅
10.1.1. SIP Response Header 🍓
Overload control info can be sent using a new Via header field parameter for overload control. A SIP server can add this header parameter to the responses it sends upstream, so it can give overload feedback to its upstream neighbors. This approach is giving:
- A Via header parameter is super lightweight and creates very little overhead ✨ It doesn't need extra messages for overload control, and it doesn't pile on traffic or processing in an overload situation, which is the whole point 🙌
- Overload control status can be reported to upstream neighbors pretty often, since it rides along in a SIP response. That makes this work for situations where the overload status needs to change frequently. It also lets you use overload control mechanisms that rely on regular feedback, like window-based overload control 🪟
- With a Via header parameter, overload control status is part of SIP signaling and automatically gets to all the relevant upstream neighbors, meaning the ones currently contributing traffic. A SIP server doesn't have to track and manage the set of current upstream or downstream neighbors it should swap feedback with 🫶
- Overload status isn't sent to inactive senders. That skips sending feedback to senders who aren't contributing traffic. If an inactive sender starts transmitting while the receiver is in overload, it'll get overload feedback in its first response and can adjust how much traffic it forwards 😭
- A SIP server can limit how far the overload control info spreads by only inserting it into responses to known upstream neighbors. A SIP server can also use transport-level authentication (e.g., via TLS) with its upstream neighbors 🔒
10.1.2. SIP Event Package 📮
Okay so, there's another way to send overload info back to a sender: a brand-new event package 🎀 It lets a sending entity subscribe to the overload status of its downstream neighbors, and then it gets NOTIFY requests whenever the overload control status changes. Here's the tea, bestie:
- Overload control info is totally decoupled from SIP signaling 🦋 That means an overload control manager (a separate entity, not the servers themselves) can keep an eye on the load of other servers and send overload control feedback to every SIP server that subscribed to it. Main character energy for the controller ✨
- A receiver can send updates to senders that are currently inactive 💅 Those inactive senders get notified about the overload and can hold off on sending traffic to that neighbor until the overload is resolved. The receiver can also tell all potential senders when they're allowed to send traffic again. BUT, ngl, those notifications add more traffic, so they add to the overall load too 🙈
- A SIP entity has to set up and maintain overload control subscriptions with all of its upstream and downstream neighbors 🧚 A new subscription needs to be set up before or while a request is sent to a new downstream neighbor. Servers can be configured to subscribe at boot time, but that would need extra protection against the avalanche restart problem for overload control 💀 And subscriptions need to be terminated once they aren't needed anymore, which can be done with a timeout mechanism, for example 🍓
- A receiver needs to send NOTIFY messages to all subscribed upstream neighbors in a timely manner whenever the control algorithm needs the control variable to change (like when a SIP server is in an overload condition). That includes both active and inactive neighbors 🫶 These NOTIFYs add to the amount of traffic that needs processing, so, periodt, a priority mechanism needs to be implemented in every server these requests pass through. Otherwise they could get dropped due to overload, and that would be a whole mess 😭
- Overload feedback gets sent to every sender in separate messages, so this mechanism isn't suitable when frequent overload control feedback is needed 🌸
- A SIP server can limit the set of senders that receive overload control information by authenticating subscriptions to this event package 🔥
- This approach requires each proxy to implement user agent functionality (UAS and UAC) to manage the subscriptions 👑
10.2. Backwards Compatibility 🌈
Okay, this part is super important. A new overload control mechanism has to be backwards compatible, so it can slide into a network gradually and still work properly even when only some of the servers support it 💖
Hop-by-hop overload control (see [RFC6357]) is the MVP here 🏆 It doesn't require every SIP entity in a network to support it. It works really well between two adjacent SIP servers as long as both of them support overload control, and it doesn't depend on any other server or user agent. The more SIP servers in a network that support hop-by-hop overload control, the better protected that network is from overload ✨
Now, a SIP server might have multiple upstream neighbors, and only some of them support overload control. If the server just used this overload control mechanism, only the neighbors that support it would reduce their traffic. The others would keep sending at the full rate and still benefit from the throttling done by the servers that support overload control 🙃 In other words, upstream neighbors that don't support overload control would be better off than the ones that do. Not fair, bestie 😤
So a SIP server should follow the behavior outlined in Section 5.10.2 to handle clients that don't support overload control 🫶
11. Security Considerations 🚨
Okay, serious moment, we're going in 🙏 Overload control mechanisms can be abused by an attacker to launch a denial-of-service attack on a SIP entity, if the attacker can pretend that the SIP entity is overloaded. When a forged overload indication gets received by an upstream SIP client, it stops sending traffic to the victim. So the victim ends up under a denial-of-service attack 💀
Let's look at the threat model, here's the diagram:
Pa ------- ------ Pb
\ /
: ------ +-------- P1 ------+------ :
/ L1 L2 \
: ------- ------ :
-----> Downstream (requests)
<----- Upstream (responses)So, requests travel downstream from the left-hand side, through Proxy P1, toward the right-hand side. Responses travel upstream from the right-hand side, through P1, toward the left-hand side. Proxies Pa, Pb, and P1 all support overload control. L1 and L2 are labels for the links connecting P1 to the upstream clients and downstream servers 🧚
If an attacker can modify traffic between Pa and P1 on link L1, they can launch a denial-of-service attack on P1 by making Pa stop sending any traffic to P1 🙅♀️ The attacker does this by modifying the response from P1 to Pa so that Pa's Via header changes to say that all requests destined toward P1 should be dropped. Or, even sneakier, the attacker can just strip any "oc", "oc-validity", and "oc-seq" markings P1 added in a response to Pa. In that case, the attacker forces P1 into overload by denying request quenching at Pa, even though Pa is totally capable of overload control 😭
It's the same vibe on the other side. If an attacker can modify traffic between P1 and Pb on link L2, they can change the Via header associated with P1 in a response from Pb to P1, so that all later requests from P1 toward Pb get dropped 💅 Basically, the attacker is launching a denial-of-service attack on Pb by indicating false overload control. It doesn't matter whether Pb supports overload control or not, because the attack works as long as the attacker can control L2 🙈 And the reverse works too: an attacker can hide a genuine overload condition at Pb by stripping any "oc", "oc-validity", and "oc-seq" markings Pb added in a response to P1. Then the attacker forces P1 to keep sending requests to Pb even during overload, because P1 wouldn't know that Pb supports overload control 🍓
Attacks that indicate false overload control are best mitigated by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that try to suppress genuine overload conditions can be avoided in a similar way, by using TLS on the connection. In general, TCP or WebSockets [RFC6455] together with BCP 38 makes it harder for an attacker to insert or modify messages, but that might still not be enough against an adversary that controls links L1 and L2. TLS gives the best protection against an attacker with access to the network links 🔐
Another way to attack is to send a message containing a high overload feedback value through a proxy that doesn't support this extension. If this feedback gets added to the second Via header (or to all Via headers), it reaches the next upstream proxy. If the attacker can make the recipient believe that the overload status was created by its direct downstream neighbor (and not by the attacker further downstream), the recipient stops sending traffic to the victim 😱 A precondition for this attack is that the victim proxy doesn't support this extension, since it wouldn't pass through overload control feedback otherwise 🙄
A malicious SIP entity could also gain an advantage by pretending to support this specification while never reducing the amount of traffic it forwards to its downstream neighbor 👀 If that downstream neighbor receives traffic from multiple sources that correctly implement overload control, the malicious SIP entity benefits, since all the other sources sending to that downstream neighbor reduce their load. Sneaky, sneaky 😤
Note: The solution to this problem depends on the overload control method. With rate-based, window-based, and other similar overload control algorithms that promise to produce no more than a specified number of requests per unit time, the overloaded server can regulate the traffic arriving to it. However, when using loss-based overload control, such policing isn't always obvious, since the load forwarded depends on the load received by the client. 🧐
To prevent these attacks, servers should monitor client behavior to determine whether clients are complying with overload control policies 👀 If a client isn't conforming to those policies, the server should treat it as a non-supporting client (see Section 5.10.2) 🚫
Finally, a distributed denial-of-service (DDoS) attack could cause an honest server to start signaling an overload condition 😩 This kind of DDoS attack could be launched without controlling the communication links, since it only depends on the attacker injecting a large volume of packets onto those links. If the honest server hit by the DDoS attack has a long "oc-validity" interval, and the attacker can guess that interval, the attacker can keep the server overloaded by synchronizing the DDoS traffic with the validity period. While this kind of attack may be fairly easy to spot, mechanisms for fighting it are outside the scope of this document. And since attackers can invent new variations, the appropriate mechanisms are likely to change over time 🫠
12. IANA Considerations 📋
This specification defines four new Via header parameters, as detailed below in the "Header Field Parameter and Parameter Values" sub-registry, following the registry created by [RFC3968]. The required information is:
Header Field Parameter Name Predefined Values Reference
__________________________________________________________
Via oc Yes [RFC7339]
Via oc-validity Yes [RFC7339]
Via oc-seq Yes [RFC7339]
Via oc-algo Yes [RFC7339]13. References 📚
13.1. Normative References 💜
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [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.
- [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
- [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
- [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References ✨
Okay bestie, these are the "extra reading" references, the ones that are useful but not required to implement the spec. 📚 I'm listing every single one with all its details so nothing gets lost. 💅
[RATE-CONTROL] Noel, E. and P. Williams, "Session Initiation Protocol (SIP) Rate Control", Work in Progress, July 2014. 🌸
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. 🛡️
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. 🚨
[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. 🦋
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. 🧚
[RFC7200] Shen, C., Schulzrinne, H., and A. Koike, "A Session Initiation Protocol (SIP) Load-Control Event Package", RFC 7200, April 2014. ⭐
Appendix A. Acknowledgements 🫶
Okay, the authors wanted to give a massive shoutout to everyone who helped make this happen. 💖 Thank you to Bruno Chatras, Keith Drage, Janet Gunn, Rich Terpstra, Daryl Malas, Eric Noel, R. Parthasarathi, Antoine Roly, Jonathan Rosenberg, Charles Shen, Rahul Srivastava, Padma Valluri, Shaun Bharrat, Paul Kyzivat, and Jeroen Van Bemmel. You all are iconic ✨
Adam Roach and Eric McMurry helped flesh out the different cases for handling SIP messages in the algorithm in Section 7.2. Full main character energy 👑. Janet Gunn also reviewed that algorithm and suggested changes that made the processing simpler for the case where oc_value > cat1. 🔥
Richard Barnes gave invaluable comments during the Area Director review of the document. 🌈
Appendix B. RFC 5390 Requirements 🦋
Okay so this appendix is basically a report card 📝. Table 1 gives a quick summary of how this spec fulfills the requirements of [RFC5390], and then a more detailed breakdown comes after the table so you can see the receipts. 🧾
+-------------+-------------------+
| Requirement | Meets requirement |
+-------------+-------------------+
| REQ 1 | Yes |
| REQ 2 | Yes |
| REQ 3 | Partially |
| REQ 4 | Yes |
| REQ 5 | Partially |
| REQ 6 | Not applicable |
| REQ 7 | Yes |
| REQ 8 | Partially |
| REQ 9 | Yes |
| REQ 10 | Yes |
| REQ 11 | Yes |
| REQ 12 | Yes |
| REQ 13 | Yes |
| REQ 14 | Yes |
| REQ 15 | Yes |
| REQ 16 | Yes |
| REQ 17 | Partially |
| REQ 18 | Yes |
| REQ 19 | Yes |
| REQ 20 | Yes |
| REQ 21 | Yes |
| REQ 22 | Yes |
| REQ 23 | Yes |
+-------------+-------------------+
Table 1: Summary of Meeting Requirements in RFC 5390REQ 1: The overload mechanism shall strive to keep the overall useful throughput of a SIP server at reasonable levels, taking into account the quality-of-service needs of the applications using it, even when the incoming load on the network is way more than the server can handle. Overall throughput under load is the ultimate measure of whether an overload control mechanism is worth it. 📈
Meets REQ 1: Yes. 💜 The overload control mechanism lets an overloaded SIP server keep a reasonable level of throughput as it enters congestion mode, by asking upstream clients to reduce the traffic they send downstream. 🙌
REQ 2: When a single network element fails, goes into overload, or loses processing capacity, the mechanism should strive to limit the impact on other elements in the network. This helps stop a small failure from turning into a widespread outage. 😭
Meets REQ 2: Yes. 💜 When a SIP server enters overload mode, it asks upstream clients to throttle the traffic aimed at it. As a result, the overloaded server also generates proportionally less downstream traffic, which limits the impact on everyone else. 🫶
REQ 3: The mechanism should try to minimize the configuration needed to work. For example, it's better to avoid making someone configure a server's SIP message throughput, since those numbers are hard to figure out. 🤔
Meets REQ 3: Partially. 💜 On the server side, the overload condition is determined by monitoring "S" (see Section 4 of [RFC6357]) and reporting a load feedback "F" as a value of the oc parameter. On the client side, a throttle "T" is applied to requests going downstream based on "F". This specification doesn't prescribe any value for "S", nor a particular value for "F". The oc-algo parameter allows automatic convergence to a particular class of overload control algorithm, and there are suggested default values for the oc-validity parameter. ✨
REQ 4: The mechanism must be able to deal with elements that don't support it, so a network can be a mix of elements that do and don't support it. In other words, the mechanism should not only work in environments where every element supports it. It's reasonable to assume it works better when everyone does, of course. Ideally, overall network throughput should improve incrementally as more elements in the network support the mechanism. 🌱
Meets REQ 4: Yes. 💜 The mechanism is designed to reduce congestion when a pair of communicating entities support it. If a downstream overloaded SIP server doesn't respond to a request in time, a SIP client will try to reduce the traffic headed toward the non-responsive server, as outlined in Section 5.9. 🙈
REQ 5: The mechanism should not assume it will only be deployed in environments with completely trusted elements. It should try to operate as effectively as possible even when other elements are malicious, which includes stopping malicious elements from grabbing more than a fair share of service. 😈
Meets REQ 5: Partially. 💜 Since overload control information is shared between a pair of communicating entities, a confidential and authenticated channel can be used for that communication. However, if no such channel is available, then the security ramifications outlined in Section 11 apply. 🔐
REQ 6: When overload is signaled by a specific message, that message must clearly indicate it's being sent because of overload, as opposed to other non-overload failure conditions. This requirement is meant to avoid some of the problems that came from reusing the 503 response code for multiple purposes. Of course, overload is also signaled by a lack of response to requests. This requirement only applies to explicit overload signals. 🚦
Meets REQ 6: Not applicable. 💜 Overload control information is signaled as part of the Via header and not in a new header. 🎀
REQ 7: The mechanism shall provide a way for an element to throttle the amount of traffic it receives from an upstream element. This throttling shall be graded, so it's not "all or nothing" like the current 503 mechanism. This recognizes that overload isn't a binary state and that there are degrees of overload. 🎚️
Meets REQ 7: Yes. 💜 Please see Sections 5.5 and 5.10. 📖
REQ 8: The mechanism shall ensure that, when a request wasn't processed successfully due to overload (or failure) of a downstream element, the request won't be retried on another element that is also overloaded or whose status is unknown. This requirement derives from REQ 1. 🔁
Meets REQ 8: Partially. 💜 A SIP client that has overload information from multiple downstream servers won't retry the request on another element. However, if a SIP client doesn't know the overload status of a downstream server, it may send the request to that server. 🤷♀️
REQ 9: The fact that a request was rejected by an overloaded element shall not unduly restrict that request's ability to be submitted to and processed by an element that isn't overloaded. This requirement derives from REQ 1. 🌟
Meets REQ 9: Yes. 💜 A SIP client conformant to this specification will send the request to a different element. 🏃♀️
REQ 10: The mechanism should support servers that receive requests from a large number of different upstream elements, where the set of upstream elements can't be enumerated. 🌍
Meets REQ 10: Yes. 💜 There are no constraints on the number of upstream clients. 🥰
REQ 11: The mechanism should support servers that receive requests from a finite set of upstream elements, where the set of upstream elements can be enumerated. 🔢
Meets REQ 11: Yes. 💜 There are no constraints on the number of upstream clients. 💅
REQ 12: The mechanism should work between servers in different domains. 🌐
Meets REQ 12: Yes. 💜 There are no inherent limitations on using overload control between domains. However, interconnection points that engage in overload control between domains will have to populate and maintain the overload control parameters as requests cross domains. 🛂
REQ 13: The mechanism must not dictate a specific algorithm for prioritizing work inside a proxy during overload. It must let a proxy prioritize requests based on any local policy, so certain ones (like a call for emergency services, or a call with a specific value of the Resource-Priority header field [RFC4412]) get preferential treatment, such as not being dropped, getting additional retransmissions, or being processed ahead of others. 🚑
Meets REQ 13: Yes. 💜 Please see Section 5.10. 📖
REQ 14: The mechanism should give clients unambiguous directions on when they should retry a request and when they shouldn't. This especially applies to TCP connection establishment and SIP registrations, to help prevent an avalanche restart. ⏰
Meets REQ 14: Yes. 💜 Section 5.9 provides normative behavior on when to retry a request after repeated timeouts and fatal transport errors from communicating with a non-responsive downstream SIP server. 📜
REQ 15: When a network element fails, is so overloaded that it can't process messages, or can't communicate because of a network failure or partition, it won't be able to explicitly indicate the nature of the failure or its congestion level. The mechanism must still function properly in these cases. 🛠️
Meets REQ 15: Yes. 💜 Section 5.9 provides normative behavior on when to retry a request after repeated timeouts and fatal transport errors from communicating with a non-responsive downstream SIP server. Again, that's the move. 🫶
REQ 16: The mechanism should try to keep the overhead of the overload control messaging as small as possible 🌸
Meets REQ 16: Yes. The overload control messages ride in the topmost Via header, which every SIP element always processes 💅
REQ 17: The overload mechanism must not give malicious attackers a way in, including DoS and DDoS attacks 😭
Meets REQ 17: Partially. Overload control information is shared between two communicating entities, so a confidential and authenticated channel can be used for it 🔐 But if that kind of channel isn't available, then the security ramifications in Section 11 apply, so read that part too, bestie 🫶
REQ 18: The overload mechanism should be clear about whether a load indication applies to a specific IP address, host, or URI, so an upstream element can figure out how loaded the entity is that it's about to send a request to 🎀
Meets REQ 18: Yes. Check out the discussion in Section 5.5 ✨
REQ 19: The overload mechanism spec should give guidance on which message types are worth processing over others during overload, based on SIP-specific considerations 🧚 For example, it may be more beneficial to process a SUBSCRIBE refresh with Expires of zero than one with a non-zero expiration, since the former reduces the overall load on the element. Or to process re-INVITEs over new INVITEs. Genius, honestly 👑
Meets REQ 19: Yes. See Section 5.10 💜
REQ 20: In a mixed environment of elements that do and don't implement the overload mechanism, no disproportionate benefit shall accrue to the users or operators of the elements that don't implement it 🙈
Meets REQ 20: Yes. An element that doesn't implement overload control gets zero extra benefit. No freeloading allowed 💀
REQ 21: The overload mechanism should keep the system stable. When the offered load drops from above the overall capacity of the network to below it, the throughput should settle down and become equal to the offered load 🦋
Meets REQ 21: Yes. The overload control mechanism described in this document ensures the stability of the system 🌈
REQ 22: It must be possible to turn off the reporting of load information toward upstream targets based on who those targets are. This lets a domain administrator who sees the load of their elements as sensitive information keep it locked down 🔒 Of course, in that case there's no expectation that the overload mechanism itself will help prevent overload from that upstream target 😬
Meets REQ 22: Yes. An operator of a SIP server can configure it to only report overload control information for requests received over a confidential channel, for example. Note that this requirement conflicts with REQ 3, since it adds a little bit of extra configuration. ⚠️
REQ 23: It must be possible for the overload mechanism to work when there's a load balancer in front of a farm of proxies 🍓
Meets REQ 23: Yes. Depending on the type of load balancer, this requirement is met. A load balancer fronting a farm of SIP proxies could be SIP-aware or not SIP-aware. If it's SIP-aware, it can make smart decisions about throttling outgoing traffic toward each individual server in the farm, based on the overload control parameters that server returns 🧠 If it's not SIP-aware, there are other strategies for overload control. Section 6 of [RFC6357] documents some of these in more detail (see the discussion related to Figure 3(a) of that document) 📚
Authors' Addresses 🦋
Here are the amazing people behind this spec 🫶
Vijay K. Gurbani (editor)
Bell Labs, Alcatel-Lucent
1960 Lucent Lane, Rm 9C-533
Naperville, IL 60563
USA
EMail: vkg@bell-labs.com
Volker Hilt
Bell Labs, Alcatel-Lucent
Lorenzstrasse 10
70435 Stuttgart
Germany
EMail: volker.hilt@bell-labs.com
Henning Schulzrinne
Columbia University/Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.eduThat's the whole RFC, bestie! 🌈✨💖 Protocol design is literally so iconic.
📦 where this page comes from
- ietf: rfc7339 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms