Diameter Overload Rate Control
Extracted elements (25)
Because the rate algorithm assigns a per-reacting-node maximum rate, the reporting node must maintain per-reacting-node state (current allocation). When new reacting nodes join or existing ones fail, the reporting node must recalculate and redistribute the maximum rate across the new set of reacting nodes.
The loss algorithm is inadequate for rapidly changing traffic because it specifies a percentage reduction rather than an absolute rate. When offered load spikes, a fixed loss percentage still allows traffic to surge far above the reporting node's capacity, requiring a slow feedback loop that can cause wide oscillations across the Diameter network.
The rate algorithm allows a reporting node to specify an absolute maximum request rate (requests per second) per reacting node rather than a loss percentage. This means reacting nodes send exactly the allocated rate regardless of whether offered load is 100 or 1000 requests per second, providing stable and predictable load at the reporting node.
The TAU tolerance parameter controls burst tolerance in the leaky bucket: larger TAU allows more consecutive requests to be forwarded before rejection, improving tolerance to inter-arrival jitter, but increases queuing at the reporting node. TAU = 4*T is recommended as a reasonable compromise; for priority treatment, TAU1 = TAU2/2 and TAU2 = 10*T are suggested defaults.
When many reacting nodes activate overload control simultaneously, their leaky buckets can synchronize, causing 'resonance': batched bursts of requests arriving at the reporting node with poor delay and potential message loss. Randomizing bucket occupancy at activation and whenever the bucket empties (by adding a uniform random offset in [-T/2, +T/2] to the increment) breaks this synchronization without sacrificing long-term rate precision.
The rate abatement algorithm definition is adapted almost verbatim from the SIP Overload Control specification (RFC 7415), with wording changes to align with DOIC and the Diameter protocol. Implementors familiar with SIP rate control will find the algorithm structurally identical.
The rate algorithm MAY be selected by reporting nodes for any of the three DOIC report types: HOST_REPORT, REALM_REPORT (both defined in RFC 7683), and PEER_REPORT (defined in RFC 8581). Future report types are expected to explicitly state whether the rate algorithm is applicable.
A reacting node MUST include the rate specified in the OC-Maximum-Rate AVP in the OC-OLR AVP as an element of the abatement-algorithm-specific portion of reacting-node OCS entries.
A reacting node that supports the rate abatement algorithm MUST indicate rate as the selected abatement algorithm in the reacting-node OCS based on the OC-Feature-Vector AVP or the OC-Peer-Algo AVP in the received OC-Supported-Features AVP.
A reporting node that has selected the rate abatement algorithm MUST indicate the rate requested to be applied by DOIC reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.
Any rate-control algorithm implemented by the reacting node MUST correctly limit the maximum rate of traffic being sent to the reporting node; use of the default leaky bucket algorithm defined in Section 8.3.1 is MAY-level.
DOIC reacting nodes supporting the rate feature MUST indicate support for both the loss and rate algorithms in the OC-Feature-Vector AVP and MAY indicate support for other algorithms.
The reporting node MUST periodically evaluate its overload state and estimate a target Diameter request rate beyond which it would become overloaded, then allocate portions of that rate to each reacting node.
When OC-Maximum-Rate is 0 with a non-zero OC-Validity-Duration, the reacting node should apply abatement treatment to 100% of Diameter requests destined to the overloaded reporting node. When OC-Validity-Duration is 0, the reacting node should stop applying abatement treatment.
When selecting the rate algorithm, a reporting node MUST ensure that a reporting-node OCS entry exists for the target of the Overload report; the target is the Origin-Host (Host report), Origin-Realm (Realm report), or DiameterIdentity of the peer (Peer report).
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.
Priority treatment extends the leaky bucket with two thresholds TAU1 < TAU2: all requests are admitted when X <= TAU1, only higher-priority requests when TAU1 < X <= TAU2, and all requests are rejected when X > TAU2. This generalizes to n priorities with n thresholds.
Reporting-node OCS for the rate algorithm is keyed by the tuple (Application-ID, report type, DiameterIdentity of target reacting node) and stores the allocated maximum rate for that reacting node, unlike the loss algorithm which uses a single percentage for all reacting nodes.
The OC-OLR AVP is extended to include the optional OC-Maximum-Rate AVP. When the rate algorithm is active, this field carries the per-reacting-node traffic cap and replaces (rather than supplements) the OC-Reduction-Percentage AVP.
The OLR_RATE_ALGORITHM feature bit (0x0000000000000004) is carried in the OC-Feature-Vector AVP. When set, it indicates that the DOIC node supports the rate abatement algorithm. Nodes supporting this feature must also support the baseline loss algorithm.
RFC 8582 registers OC-Maximum-Rate as a new Diameter AVP with code 670 (type Unsigned32, V flag MUST NOT be set) in the IANA 'Authentication, Authorization, and Accounting (AAA) Parameters' registry.
RFC 8582 registers the OLR_RATE_ALGORITHM bit value (0x0000000000000004) as a new allocation in the OC-Feature-Vector AVP sub-registry within the IANA AAA Parameters registry.
All security considerations from the base DOIC specification (RFC 7683) apply to the rate abatement mechanism. Additionally, the rate algorithm may handle denial-of-service attacks more effectively than the loss algorithm by imposing an absolute ceiling on incoming request rate rather than a relative percentage reduction.
The default leaky bucket algorithm for rate control maintains counter X, last-cleared-time LCT, and inter-transmission interval T = 1/OC-Maximum-Rate. On each request arrival at time ta: compute Xp = X - (ta - LCT); if Xp <= TAU, transmit and set X = max(0,Xp)+T and LCT = ta; otherwise apply abatement treatment and leave X and LCT unchanged.
The OC-Maximum-Rate AVP has AVP code 670, is of type Unsigned32, and expresses the maximum allowed request rate in requests per second. The V flag MUST NOT be set. A value of zero means no traffic is to be sent.