RFC 8582

Diameter Overload Rate Control

📅 published August 2019, from ietf

Diameter Overload Rate Control 💖

okay bestie, welcome to RFC 8582!! 🎀 this one is a Standards Track doc from the IETF, so it's the real deal. 💅 it was published in August 2019 and the ISSN is 2070-1721. it's written by S. Donovan, Ed. from Oracle and E. Noel from AT&T Labs. 🦋

it doesn't obsolete anything, but it extends the base DOIC solution from RFC 7683. 🧚 so think of this doc as the upgrade pack for DOIC that adds a brand new overload-control abatement algorithm called the "rate" algorithm. ✨

we're gonna walk through the whole thing in 4 parts, so this is just part 1. 🫶 let's go!!

Abstract ✨

ok so the vibe of this spec is that it documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution from RFC 7683. 🌸 this extension adds a new overload-control abatement algorithm, and it lets a DOIC reporting node say "hey, don't send me more than this many Diameter requests per second" to a DOIC reacting node. 💜 it's giving rate limit with main character energy. 👑

Status of This Memo 📜

this is an Internet Standards Track document, which means it's official IETF stuff. 💅 it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. 🌈 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). 🎀

if you want more deets on what Internet Standards are, check out Section 2 of RFC 7841. 🦋 and if you want the current status, errata, or a place to give feedback, the page is https://www.rfc-editor.org/info/rfc8582. 💖

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as they were on the publication date. 📜 please actually read these, bestie, because they describe your rights and restrictions. 🙈 also, any Code Components pulled out of this doc have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License. 💀

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  Interaction with DOIC Report Types  . . . . . . . . . . . . .   5
5.  Capability Announcement . . . . . . . . . . . . . . . . . . .   6
6.  Overload-Report Handling  . . . . . . . . . . . . . . . . . .   7
  6.1.  Reporting-Node OCS  . . . . . . . . . . . . . . . . . . .   7
  6.2.  Reacting-Node OCS . . . . . . . . . . . . . . . . . . . .   7
  6.3.  Reporting-Node Maintenance of OCS . . . . . . . . . . . .   8
  6.4.  Reacting-Node Maintenance of OCS  . . . . . . . . . . . .   8
  6.5.  Reporting-Node Behavior for Rate Abatement Algorithm  . .   9
  6.6.  Reacting-Node Behavior for Rate Abatement Algorithm . . .   9
7.  Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . .   9
  7.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .   9
    7.1.1.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . .  10
  7.2.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  10
    7.2.1.  OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . .  10
  7.3.  Attribute-Value Pair Flag Rules . . . . . . . . . . . . .  11
8.  Rate Abatement Algorithm  . . . . . . . . . . . . . . . . . .  11
  8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  11
  8.2.  Reporting-Node Behavior . . . . . . . . . . . . . . . . .  11
  8.3.  Reacting-Node Behavior  . . . . . . . . . . . . . . . . .  13
    8.3.1.  Default Algorithm for Rate-Based Control  . . . . . .  13
    8.3.2.  Priority Treatment  . . . . . . . . . . . . . . . . .  16
    8.3.3.  Optional Enhancement: Avoidance of Resonance  . . . .  17
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
  9.1.  OC-Supported-Features . . . . . . . . . . . . . . . . . .  19
10. Security Considerations . . . . . . . . . . . . . . . . . . .  19
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
  11.2.  Informative References . . . . . . . . . . . . . . . . .  20
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction 🌷

this doc defines a brand new Diameter overload-control abatement algorithm, called the "rate" algorithm. 🦋

so first, the base Diameter overload spec in [RFC7683] defines the "loss algorithm" as the default Diameter overload loss abatement algorithm. 💅 the loss algorithm lets a reporting node (see Section 3) tell a reacting node (see Section 3) to reduce the amount of traffic it sends to the reporting node, by abating (diverting or throttling) a percentage of requests sent to the server. ✨ it can work, but it doesn't directly handle cases where the rate of incoming service requests changes quickly. 🙈

here's the problem. if the service requests that turn into Diameter transactions suddenly spike, the loss algorithm can't guarantee the load on the server stays under a specific rate level. 💀 it can also be slow to keep reporting nodes stable when the loads are changing really fast. 😭 and honestly? the "loss" algorithm messes up both ways: it throttles too much when offered load dips, and it throttles not enough when offered load spikes. 🌪️

let's do an example, cause examples are everything. 🍓 say a reacting node is handling 100 service requests per second, and every one of those results in one Diameter transaction sent to a reporting node. 💖 if the reporting node is getting close to overload, or already is overloaded, it sends a Diameter Overload report asking for a percentage reduction in traffic, using the loss algorithm. 🫶 for this chat, let's say it asks for a 10% reduction. 🎀 so the reacting node abates (diverts or throttles) ten Diameter transactions a second and sends the other 90 per second to the reporting node. ✨

now imagine the reacting node's service requests spike to 1000 requests per second. 😱 the reacting node keeps honoring that 10% reduction, so it sends 900 Diameter transactions per second and abates the other 100. 💀 that spike is way higher than what the reporting node expects to handle, and it can seriously hurt the reporting node's stability. 😭

the reporting node can, and probably would, send another Overload report asking the reacting node to abate 91% of requests to get back to the 90 transactions per second it wants. 💅 but here's the chaos: once the spike chills out and the reacting node is back to 100 requests per second, that same 91% request means only 9 transactions per second go to the reporting node. 🙃 so now it needs a new Overload report setting the reduction back to 10%. 🔁 this feedback loop can make things worse by causing wild traffic swings on multiple nodes across the Diameter network. 🌊

okay so here's the glow-up. 🌟 one of the perks of a rate-based algorithm over the loss algorithm is that it handles traffic spikes way better. ✨ instead of asking for a percentage cut, the rate approach lets the reporting node specify the maximum number of Diameter requests per second it can receive. 💜 in our example, the reporting node could send a rate-based request capping it at 90 transactions per second. 👑 and the reacting node will send those 90 no matter whether it's getting 100 or 1000 service requests per second. 🦋 slay. 💅

now, a tea spill: with the rate-based algorithm, the reporting node has to figure out how it wants to spread its load across all the reacting nodes sending it traffic. 🫖 for example, say the reporting node gets Diameter traffic from 10 reacting nodes and has a capacity of 100 transactions per second. 🧮 it could set each reacting node's rate to 10 transactions per second. 🎀 that assumes every reacting node has equal performance characteristics, though. 🤷‍♀️ the reporting node could also decide that one high-capacity reacting node sends 55 transactions per second, while the remaining 9 low-capacity reacting nodes each send 5. 🌈

this per-reacting-node control means the reporting node MUST maintain state for each of the reacting nodes. 😤 that state includes the current allocation of Diameter traffic to that reacting node. 📊 and if the number of reacting nodes changes, because new nodes get added, nodes get removed from service, or nodes fail, the reporting node will need to redistribute the maximum Diameter transactions over the new set of reacting nodes. 🔄

this document extends the base Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] to add support for the rate abatement algorithm. 🫶

and this doc borrows a lot from the SIP Overload Control Working Group. 🌸 the definition of the rate abatement algorithm is copied almost word for word from the SIP Overload Control (SOC) document [RFC7415], with changes that make the wording match the DOIC solution and the Diameter protocol. 💖

2. Requirements 📝

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀 these words only count as requirement language when they're in ALL CAPS, so lowercase "may" is just vibes. 🙈

3. Terminology 🧚

Diameter Node 💜 A Diameter Client, Diameter Server, or Diameter Agent [RFC6733]

Diameter Endpoint 🦋 A Diameter Client or Diameter Server [RFC6733]

DOIC Node 🌸 A Diameter node that supports the DOIC solution defined in [RFC7683]

Reporting Node 📢 A DOIC node that sends an Overload report in a Diameter answer message

Reacting Node 🫶 A DOIC node that receives and acts on a DOIC Overload report

4. Interaction with DOIC Report Types 🗂️

as of the publication of this specification, there are three DOIC report types: 🔢

HOST_REPORT 0:
   Overload of a specific Diameter application at a specific Diameter
   node as defined in [RFC7683]

REALM_REPORT 1:
   Overload of a specific Diameter application at a specific Diameter
   realm as defined in [RFC7683]

PEER_REPORT 2:
   Overload of a specific Diameter peer as defined in [RFC8581]

the rate algorithm MAY be selected by reporting nodes for any of these report types. 💖 so reporting nodes are allowed to pick it for whichever report type they want. 🎀

it is expected that all report types defined in the future will indicate whether or not the rate algorithm can be used with that report type. 🔮 future report types are gonna have to say whether rate is allowed, so no guessing, periodt. 💅

part 1 is done, bestie! 🎉 more parts are coming, so stay tuned. 🫶🌈

5. Capability Announcement ✨

Okay so this document defines the rate abatement algorithm, which we're calling "rate" from here on 💖. A DOIC node shows that it supports rate with a new value in the OC-Feature-Vector attribute-value pair (AVP). Section 7.1.1 has the details, and the general rules come from [RFC7683] 🦋.

Every node that supports DOIC is required to support the loss algorithm, so DOIC nodes that support rate get both loss and rate abatement. It's giving double coverage 💅.

DOIC reacting nodes that support rate MUST indicate support for both the loss and rate algorithms in the OC-Feature-Vector AVP. They MAY also indicate support for other algorithms 🌸.

As [RFC7683] explains, a DOIC reporting node that supports rate picks one abatement algorithm and puts it in the OC-Feature-Vector AVP and the OC-Peer-Algo AVP of the answer message it sends to the DOIC reacting nodes ✨.

A reporting node can pick one algorithm for Host and Realm reports and a different one for peer reports. Mix and match, iykyk 🌈.

For Host or Realm reports, the chosen algorithm appears in the OC-Feature-Vector AVP inside the OC-Supported-Features AVP. This goes in answer messages for transactions where the request had an OC-Supported-Features AVP. The procedures are from [RFC7683] 🎀.

For Peer reports, the chosen algorithm appears in the OC-Peer-Algo AVP inside the OC-Supported-Features AVP. Same deal: it goes in answer messages for transactions where the request had an OC-Supported-Features AVP. The procedures for this one are from [RFC8581] 🫶.

6. Overload-Report Handling 👑

This section covers any changes to how [RFC7683] handles Overload reports when the rate abatement algorithm is in use 🔥.

6.1. Reporting-Node OCS 🍓

A reporting node that uses the rate abatement algorithm SHOULD maintain reporting-node Overload Control State (OCS) for each reacting node it sends a rate Overload Report (OLR) to.

Note: This is different from [RFC7683], where a reporting node sends one loss percentage to all reacting nodes. Plot twist 🙈

A reporting node SHOULD maintain OCS entries when it uses the rate abatement algorithm. Keep one per supported Diameter application, per targeted reacting node, and per report type 💜.

A rate OCS entry is identified by the tuple of Application-ID, report type, and DiameterIdentity of the target of the rate OLR 🦋.

The rate OCS entry SHOULD include the rate allocated to the reacting node 💖.

A reporting node that has selected the rate abatement algorithm MUST indicate the rate it wants DOIC reacting nodes to apply. It does this in the OC-Maximum-Rate AVP inside the OC-OLR AVP 👑.

Everything else in the OCS from [RFC7683] and [RFC8581] also applies to the reporting node's OCS when the rate abatement algorithm is used ✨.

6.2. Reacting-Node OCS 🧚

A reacting node that supports the rate abatement algorithm MUST indicate rate as the selected abatement algorithm in its reacting-node OCS. It figures this out from the OC-Feature-Vector AVP or the OC-Peer-Algo AVP in the received OC-Supported-Features AVP 💅.

A reacting node that supports the rate abatement algorithm MUST include the rate from the OC-Maximum-Rate AVP inside the OC-OLR AVP as an element of the abatement-algorithm-specific portion of its reacting-node OCS entries 🌈.

Everything else in the OCS from [RFC7683] and [RFC8581] also applies to the reporting node's OCS when the rate abatement algorithm is used. (Yes, the original says "reporting nodes OCS" here, and it's still the same idea, bestie 🫶.)

6.3. Reporting-Node Maintenance of OCS 🌸

A reporting node that has selected the rate abatement algorithm and enters an overload condition MUST indicate rate as the abatement algorithm. It MUST also indicate the selected rate in the resulting reporting-node OCS entries 🔥.

When the rate algorithm gets selected in the response to a request that contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP showing support for the rate feature, the reporting node MUST make sure a reporting-node OCS entry exists for the target of the Overload report. The target is defined like this 🎀:

o For Host reports, the target is the DiameterIdentity contained in the Origin-Host AVP received in the request.

o For Realm reports, the target is the DiameterIdentity contained in the Origin-Realm AVP received in the request.

o For Peer reports, the target is the DiameterIdentity of the Diameter peer from which the request was received.

A reporting node can get a capability announcement from a new reacting node, meaning one it has no OCS entry for. When that happens, the reporting node that chose the rate algorithm for that reacting node may need to recalculate the rate for all reacting nodes. Any changed rate values get communicated in the next OLR sent to each reacting node 🦋.

6.4. Reacting-Node Maintenance of OCS 💜

When a reacting node receives an answer message saying the reporting node has selected the rate algorithm, it MUST indicate the rate abatement algorithm in the reacting-node OCS entry for that reporting node 💖.

A reacting node that receives an Overload report for the rate abatement algorithm MUST save the rate it got in the OC-Maximum-Rate AVP inside the OC-OLR AVP, in the reacting-node OCS entry 👑.

6.5. Reporting-Node Behavior for Rate Abatement Algorithm ⭐

When the reporting node is in an overload condition with rate selected as the overload abatement algorithm, and it handles a request that contained an OC-Supported-Features AVP showing support for the rate abatement algorithm, it SHOULD include an OC-OLR AVP for the rate algorithm. It uses the parameters stored in the reporting-node OCS for the target of the Overload report 🌈.

Note: The reporting node can also send Overload reports with the rate algorithm indicated even when it isn't overloaded. That could be a strategy to proactively avoid getting overloaded. Whether or not to do so is up to local policy 🧚

When sending an Overload report for the rate algorithm, the OC-Maximum-Rate AVP MUST be included in the OC-OLR AVP, and the OC-Reduction-Percentage AVP MUST NOT be included 🙈.

6.6. Reacting-Node Behavior for Rate Abatement Algorithm 🦋

When a reacting node decides whether abatement treatment should apply to a request going to a reporting node that selected the rate abatement algorithm, it can use the algorithm in Section 8 🫶.

Other algorithms for controlling the rate MAY be implemented by the reacting node. Any algorithm implemented MUST correctly limit the maximum rate of traffic sent to the reporting node 🔥.

Once the reacting node decides that a particular Diameter request gets abatement treatment, the throttling and diversion procedures from [RFC7683] and [RFC8581] apply 💅.

7. Rate Abatement Algorithm AVPs 🎀

7.1. OC-Supported-Features AVP 🍓

The rate algorithm doesn't add any new AVPs to the OC-Supported-Features AVP 🌸.

The rate algorithm does add a new feature bit, carried in the OC-Feature-Vector AVP ✨.

7.1.1. OC-Feature-Vector AVP 👑

This extension adds the following capability to the OC-Feature-Vector AVP 💖.

OLR_RATE_ALGORITHM (0x0000000000000004)

This bit is assigned to the rate abatement algorithm. When the overload-control endpoint sets this flag, it means the DOIC node supports the rate abatement algorithm 🦋.

7.2. OC-OLR AVP 🧚

This extension defines the OC-Maximum-Rate AVP as an optional part of the OC-OLR AVP 🌈.

   OC-OLR ::= < AVP Header: 623 >
              < OC-Sequence-Number >
              < OC-Report-Type >
              [ OC-Reduction-Percentage ]
              [ OC-Validity-Duration ]
              [ SourceID ]
              [ OC-Maximum-Rate ]
            * [ AVP ]

This extension doesn't change any of the other AVPs in the OC-OLR AVP 💅.

This extension doesn't define new Overload report types. The existing HOST_REPORT and REALM_REPORT types from [RFC7683] apply to the rate control algorithm. The PEER_REPORT type from [RFC8581] also applies to it 🫶.

7.2.1. OC-Maximum-Rate AVP ⭐

The OC-Maximum-Rate AVP (AVP code 670) is of type Unsigned32. It describes the maximum rate the sender is asked to send traffic at, measured in requests per second 🔥.

A value of zero means no traffic is to be sent 🙈.

7.3. Attribute-Value Pair Flag Rules 💜

                                                             +---------+
                                                             |AVP flag |
                                                             |rules    |
                                                             +----+----+
                            AVP   Section                    |    |MUST|
    Attribute Name          Code  Defined  Value Type        |MUST| NOT|
   +---------------------------------------------------------+----+----+
   |OC-Maximum-Rate         670    7.2.1   Unsigned32        |    | V  |
   +---------------------------------------------------------+----+----+

8. Rate Abatement Algorithm 🌈

This section is pulled from [RFC7415] with a few small changes so it fits the Diameter protocol 💖.

8.1. Overview 🧚

The reporting node is the one protected by the overload control algorithm defined here. The reacting node is the one that abates traffic towards the server 🦋.

Following the procedures in [RFC7683], the reacting node and reporting node signal their support for rate-based overload control 🫶.

Then, periodically, the reporting node uses internal measurements (for example, CPU utilization or queuing delay) to evaluate its overload state. It also estimates a target maximum Diameter request rate, in number of requests per second. This is different from the target percent reduction used by loss-based abatement ✨.

When it's in an overloaded state, the reporting node uses the OC-OLR AVP to tell reacting nodes about its overload state and the target Diameter request rate 👑.

When a reacting node receives the Overload report with a target maximum Diameter request rate, it applies overload abatement to new Diameter requests going towards the reporting node 💅.

8.2. Reporting-Node Behavior

okay so the actual algorithm a reporting node uses to figure out its overload state and guess a target max Diameter request rate? that's beyond this doc's scope, bestie 💅

BUT the reporting node MUST periodically check its overload state and estimate a target Diameter request rate, the point past which it would become overloaded 🔥. It also has to hand out a slice of that target rate to each of its reacting nodes. It may give every reacting node the same rate, or it may set different rates for different ones ✨.

The max rate the reporting node sets for a reacting node covers the entire stream of Diameter requests 🌊. Abatement might only hit some of them, though, since the reacting node could use priority to pick which requests get abated 🎀.

When setting that max rate for one reacting node, the reporting node may need to think about workload, like CPU load per request, for the mix of message types that node sends 🧮. The reacting node may also prioritize certain message types while it's under overload restriction, so that mix can look different from normal. That means the CPU load might end up higher or lower than usual 💀.

Note that the OC-Maximum-Rate AVP value (in request messages per second) gives a loose upper bound on the traffic the reacting node sends to the reporting node 🦋.

Basically, when one overloaded reporting node is controlling several reacting nodes, some of them might get requests below the target rate at any given moment while others get more than that 🙈. But the overall request rate hitting the overloaded reporting node will converge toward the target Diameter request rate, or drop even lower 🌈.

Once the reporting node detects overload and decides to invoke overload controls, it follows the specifications in [RFC7683] to tell its reacting nodes the target maximum Diameter request rate it allocated to them, and to let them know rate abatement is in effect ✨.

The reporting node uses the OC-Maximum-Rate AVP defined in this specification to send a target maximum Diameter request rate to each of its clients 💜.

8.3. Reacting-Node Behavior

8.3.1. Default Algorithm for Rate-Based Control

A reference algorithm is shown below 🧚.

Note that use of "//" below indicates a comment.

No priority case:

// T: inter-transmission interval, set to 1 / OC-Maximum-Rate // TAU: tolerance parameter // ta: arrival time of the most recent arrival // LCT: arrival time of last Diameter request that // was sent to the server // (initialized to the first arrival time) // X: current value of the leaky bucket counter (initialized to // TAU0)

// After most recent arrival, calculate auxiliary variable Xp Xp = X - (ta - LCT);

if (Xp <= TAU) { // Transmit Diameter request // Update X and LCT X = max (0, Xp) + T; LCT = ta; } else { // Reject Diameter request // Do not update X and LCT }

When deciding whether to send a particular message, the reacting node can use any algorithm that caps the message rate at the OC-Maximum-Rate AVP value, measured in messages per second. To keep things simple, we define T = 1/[OC-Maximum-Rate] as the target inter-Diameter request interval 🎯. The algorithm may be strictly deterministic or probabilistic. It may or may not include a tolerance factor so it can handle short bursts, as long as the long-term rate stays below 1/T.

The algorithm may also have priority handling built in 🎀.

If the algorithm needs extra parameters besides T (which is 1/OC-Maximum-Rate), the reacting node can set them on its own, or they can be negotiated separately between the reacting node and the reporting node.

Either way, how that coordination works is outside the scope of this document 🙃. The two default algorithms here, one with priority provisions and one without, are just examples and not the only option.

To apply abatement treatment to new Diameter requests at the rate in the OC-Maximum-Rate AVP value that the reporting node sent to its reacting nodes, the reacting node MAY use the proposed default rate-based algorithm. It can also use any other equivalent algorithm that forwards messages within the upper bound of 1/T messages per second 💖.

The default leaky bucket algorithm here is based on Appendix A.2 of [ITU-T-I.371] 📚. It lets reacting nodes send Diameter requests at the rate in the OC-Maximum-Rate value, using a tolerance parameter TAU that is preferably configurable ⚙️.

Picture the leaky bucket as a bucket with finite capacity. Its real-valued content drains out at a steady rate of 1 unit per time unit, and it goes up by the increment T every time a Diameter request is forwarded 🪣. T is the inverse of the rate in the OC-Maximum-Rate AVP value, so T = 1 / OC-Maximum-Rate 🧮.

Note that when the OC-Maximum-Rate value is 0 and the OC-Validity-Duration is non-zero, the reacting node should apply abatement treatment to 100% of Diameter requests headed to the overloaded reporting node 🚫. But when OC-Validity-Duration is 0, the reacting node should stop applying abatement treatment ✅.

When a new Diameter request arrives, if the bucket's content is less than or equal to the limit value TAU, the request gets forwarded to the server. Otherwise, abatement treatment is applied to it 🫣.

Note that the capacity of the bucket (the upper bound of the counter) is (T + TAU) 🪣✨.

The tolerance parameter TAU decides how closely the long-term admitted rate matches an ideal control. That ideal would admit every Diameter request when arrival rates are below 1/T, then admit requests at exactly 1/T when arrival rates go above 1/T 🎯. Specifically, when mean arrival rates are close to 1/T, TAU sets how much the inter-arrival time can wander away from T. The bigger TAU is, the more it tolerates deviations from the inter-departure interval T 🦋.

That deviation affects how bursty the admitted rate is, meaning how many Diameter requests in a row get forwarded to the reporting node. Burst size is proportional to TAU divided by the difference between 1/T and the arrival rate 💥.

If reacting nodes have some knowledge about the reporting node and other traffic sources (for example, through operator pre-provisioning), it can be a good idea to pick a TAU value based on how many reacting nodes will be sending requests to the reporting node 🧠.

Reporting nodes with a huge number of reacting nodes, each sending a fairly small arrival rate, will generally benefit from a smaller TAU. That helps limit queuing, and therefore response times, at the reporting node when all the reacting nodes suddenly surge at once 🌊. On the flip side, a reporting node with a smaller number of reacting nodes, each with a proportionally bigger arrival rate, will benefit from a larger TAU 🎀.

Once the control has been activated, when the k-th new Diameter request arrives at time ta(k), the bucket content gets provisionally updated to:

X' = X - (ta(k) - LCT)

Here X is the leaky bucket counter's value after the last forwarded Diameter request arrived, and LCT is the time that last Diameter request was forwarded 🕰️.

If X' is less than or equal to the limit value TAU, the new Diameter request is forwarded. The leaky bucket counter X is set to X' (or to 0 if X' is negative) plus the increment T, and LCT is set to the current time ta(k) ✅. If X' is greater than the limit value TAU, abatement treatment is applied to the new Diameter request, and the values of X and LCT stay the same 🙅‍♀️.

When the first response from the reporting node arrives and indicates control activation (OC-Validity-Duration>0), LCT is set to the activation time. The leaky bucket counter is then initialized to the parameter TAU0, which is preferably configurable and is 0 or larger but less than or equal to TAU 🌱.

TAU can be any positive real number and isn't necessarily bounded by T 🔢.

TAU=4*T is a reasonable compromise between burst size and abatement rate adaptation at low offered rates 💅.

Note that specifying a value for TAU, and any communication or coordination between servers, is beyond the scope of this document 🙈.

8.3.2. Priority Treatment 💖

okay so here's the reference algorithm, bestie 🎀 the priority case looks like this:

Priority case:

  // T: inter-transmission interval, set to 1 / OC-Maximum-Rate
  // TAU1: tolerance parameter of no priority Diameter requests
  // TAU2: tolerance parameter of priority Diameter requests
  // ta: arrival time of the most recent arrival
  // LCT: arrival time of last Diameter request that
  //      was sent to the server
  //      (initialized to the first arrival time)
  // X: current value of the leaky bucket counter (initialized to
  //    TAU0)

  // After most recent arrival, calculate auxiliary variable Xp
  Xp = X - (ta - LCT);

 if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived &&
  Xp <= TAU2 && Xp > TAU1) {
    // Transmit Diameter request
    // Update X and LCT
    X = max (0, Xp) + T;
    LCT = ta;
  } else {
    // Apply abatement treatment to Diameter request
    // Do not update X and LCT
  }

the reacting node is in charge of applying message priority 🔥 it has to keep track of two groups of requests: request candidates for reduction, and requests that are not subject to reduction. the exception is extenuating circumstances, which only kick in when there aren't any messages in the first group that can be reduced 😭

so the leaky bucket we already looked at gets a priority upgrade ✨ it uses two thresholds for Diameter requests in the set of request candidates for reduction. with two priorities, we need two thresholds, TAU1 < TAU2:

  • All new requests would be admitted when the leaky bucket counter is at or below TAU1.
  • Only higher priority requests would be admitted when the leaky bucket counter is between TAU1 and TAU2.
  • All requests would be rejected when the bucket counter is above TAU2.

this can be generalized to n priorities using n thresholds for n>2. literally so smart 👑

with a priority scheme that relies on two tolerance parameters (TAU2 influences the priority traffic, and TAU1 influences the non-priority traffic), you always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2). setting both tolerance parameters to the same value is equivalent to having no priority 🌸 TAU1 influences the admitted rate the same way TAU does when no priority is set, and the bigger the difference between TAU1 and TAU2, the closer the control gets to strict priority queuing. it's giving precision 💅

TAU1 and TAU2 can assume any positive real number value and are not necessarily bounded by T.

reasonable values for TAU0, TAU1, and TAU2 are:

  • TAU0 = 0,
  • TAU1 = 1/2 * TAU2, and
  • TAU2 = 10 * T.

note that specifying values for TAU1 and TAU2, plus any communication or coordination between servers, is beyond the scope of this document 🦋

8.3.3. Optional Enhancement: Avoidance of Resonance 🧚

okay this part is lowkey dramatic 😭 as the number of reacting-node sources of traffic goes up and the throughput of the reporting node goes down, the maximum rate each reacting node admits has to decrease, so the value of T gets bigger. under some circumstances, like if traffic shows up super fast and at the same time from lots of sources, the occupancies of each bucket can sync up. that means the admissions from each source land close together in time and get batched, creating very "peaky" arrivals at the reporting node. this causes control instability, plus very poor delays and even lost messages 💀 the term for this is "resonance" [Erramilli].

if the network topology is such that resonance can happen, a simple way to avoid it is to randomize the bucket occupancy at two good points: when control is activated, and whenever the bucket empties. here's how 💖

after updating the leaky bucket value to X', generate a value u like this:

  • if X' > 0, then u=0
  • else, if X' <= 0, then let u be set to a random value uniformly distributed between -1/2 and +1/2

then, (only) if the arrival is admitted, increase the bucket content by an amount T + uT. that means it's just T if the bucket hadn't emptied, or it lands between T/2 and 3T/2 if it had 🎀

this randomization should also happen when control is activated. so instead of just initializing the leaky bucket counter to TAU0, you initialize it to TAU0 + uT, where u is uniformly distributed as above. activation happens as a result of a response to a request the reacting node sent, so the second term can be read as the bucket increment following that admission 🌈

this method has the following characteristics, periodt:

  • If TAU0 is chosen to be equal to TAU and all sources activate control at the same time due to an extremely high request rate, then the time until the first request admitted by each reacting node would be uniformly distributed over [0,T];
  • The maximum occupancy is TAU + (3/2)T, rather than TAU + T without randomization;
  • For the special case of "classic gapping", where TAU=0, the minimum time between admissions is uniformly distributed over [T/2, 3T/2], and the mean time between admissions is the same, i.e., T+1/R where R is the request arrival rate;
  • At high load, randomization rarely occurs. Therefore, there is no loss of precision of the admitted rate, even though the randomized "phasing" of the buckets remains 🦋

9. IANA Considerations 📝

IANA has registered the following values in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry:

   One new AVP code is defined in Section 7.2.1.

   One new OC-Feature-Vector AVP value is defined in Section 7.1.1.

9.1. OC-Supported-Features ✨

as indicated in Section 7.1.1, a new allocation has been made for the OC-Feature-Vector AVP 💅

10. Security Considerations 🚨

this section is serious, bestie. read it all 😭

the rate abatement mechanism is an extension to the base Diameter Overload mechanism. as such, all of the security considerations outlined in [RFC7683] apply to the rate abatement mechanism.

in addition, the rate algorithm could be used to handle denial-of-service (DoS) attacks more effectively than the loss algorithm 👑

11. References 📚

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, https://www.rfc-editor.org/info/rfc6733.

[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. Morand, "Diameter Overload Indication Conveyance", RFC 7683, DOI 10.17487/RFC7683, October 2015, https://www.rfc-editor.org/info/rfc7683.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8581] Donovan, S., "Diameter Agent Overload and the Peer Overload Report", RFC 8581, DOI 10.17487/RFC8581, August 2019, https://www.rfc-editor.org/info/rfc8581.

11.2. Informative References

[Erramilli] Erramilli, A. and L. Forys, "Traffic Synchronization Effects In Teletraffic Systems", 1991.

[ITU-T-I.371] ITU-T, "Traffic control and congestion control in B-ISDN", ITU-T Recommendation I.371, March 2004.

[RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol (SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415, February 2015, https://www.rfc-editor.org/info/rfc7415.

Acknowledgements 🫶

the authors would like to thank Lionel Morand for his contributions to this document 💜

Authors' Addresses 🎀

Steve Donovan (editor) Oracle 7460 Warren Parkway, Suite 300 Frisco, Texas 75034 United States of America

Email: srdonovan@usdonovans.com

Eric Noel AT&T Labs 200s Laurel Avenue Middletown, NJ 07747 United States of America

Email: ecnoel@research.att.com

that's the whole RFC, bestie 🌈✨

📦 where this page comes from