summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8582.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8582.txt')
-rw-r--r--doc/rfc/rfc8582.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8582.txt b/doc/rfc/rfc8582.txt
new file mode 100644
index 0000000..c4c0681
--- /dev/null
+++ b/doc/rfc/rfc8582.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Donovan, Ed.
+Request for Comments: 8582 Oracle
+Category: Standards Track E. Noel
+ISSN: 2070-1721 AT&T Labs
+ August 2019
+
+
+ Diameter Overload Rate Control
+
+Abstract
+
+ This specification documents an extension to the Diameter Overload
+ Indication Conveyance (DOIC) base solution, which is defined in RFC
+ 7683. This extension adds a new overload-control abatement
+ algorithm. This abatement algorithm allows for a DOIC reporting node
+ to specify a maximum rate at which a DOIC reacting node sends
+ Diameter requests to the DOIC reporting node.
+
+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 has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8582.
+
+Copyright Notice
+
+ 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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Donovan & Noel Standards Track [Page 1]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 2]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+1. Introduction
+
+ This document defines a new Diameter overload-control abatement
+ algorithm, the "rate" algorithm.
+
+ The base Diameter overload specification [RFC7683] defines the "loss
+ algorithm" as the default Diameter overload loss abatement algorithm.
+ The loss algorithm allows a reporting node (see Section 3) to
+ instruct a reacting node (see Section 3) to reduce the amount of
+ traffic sent to the reporting node by abating (diverting or
+ throttling) a percentage of requests sent to the server. While this
+ can effectively decrease the load handled by the server, it does not
+ directly address cases where the rate of arrival of service requests
+ changes quickly. For instance, if the service requests that result
+ in Diameter transactions increase quickly, then the loss algorithm
+ cannot guarantee the load presented to the server remains below a
+ specific rate level. The loss algorithm can be slow to ensure the
+ stability of reporting nodes when subjected to rapidly-changing
+ loads. The "loss" algorithm errs both in throttling too much when
+ there is a dip in offered load, and throttling not enough when there
+ is a spike in offered load.
+
+ Consider the case where a reacting node is handling 100 service
+ requests per second, where each of these service requests results in
+ one Diameter transaction being sent to a reporting node. If the
+ reporting node is approaching an overload state, or is already in an
+ overload state, it will send a Diameter Overload report requesting a
+ percentage reduction in traffic sent when the loss algorithm is used
+ as a Diameter overload abatement algorithm. Assume for this
+ discussion that the reporting node requests a 10% reduction. The
+ reacting node will then abate (diverting or throttling) ten Diameter
+ transactions a second, sending the remaining 90 transactions per
+ second to the reporting node.
+
+ Now assume that the reacting node's service requests spike to 1000
+ requests per second. The reacting node will continue to honor the
+ reporting node's request for a 10% reduction in traffic. This
+ results, in this example, in the reacting node sending 900 Diameter
+ transactions per second, abating the remaining 100 transactions per
+ second. This spike in traffic is significantly higher than the
+ reporting node is expecting to handle and can result in negative
+ impacts to the stability of the reporting node.
+
+ The reporting node can, and likely would, send another Overload
+ report requesting that the reacting node abate 91% of requests to get
+ back to the desired 90 transactions per second. However, once the
+ spike has abated and the rate at which the reacting node handles
+ requests has returned to 100 per second, this will result in just 9
+
+
+
+Donovan & Noel Standards Track [Page 3]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ transactions per second being sent to the reporting node, requiring a
+ new Overload report setting the reduction percentage back to 10%.
+ This control feedback loop has the potential to make the situation
+ worse by causing wide fluctuations in traffic on multiple nodes in
+ the Diameter network.
+
+ One of the benefits of a rate-based algorithm over the loss algorithm
+ is that it better handles spikes in traffic. Instead of sending a
+ request to reduce traffic by a percentage, the rate approach allows
+ the reporting node to specify the maximum number of Diameter requests
+ per second that can be sent to the reporting node. For instance, in
+ this example, the reporting node could send a rate-based request
+ specifying the maximum transactions per second to be 90. The
+ reacting node will send the 90 regardless of whether it is receiving
+ 100 or 1000 service requests per second.
+
+ It should be noted that one of the implications of the rate-based
+ algorithm is that the reporting node needs to determine how it wants
+ to distribute its load over the set of reacting nodes from which it
+ is receiving traffic. For instance, if the reporting node is
+ receiving Diameter traffic from 10 reacting nodes and has a capacity
+ of 100 transactions per second, then the reporting node could choose
+ to set the rate for each of the reacting nodes to 10 transactions per
+ second. This, of course, is assuming that each of the reacting nodes
+ has equal performance characteristics. The reporting node could also
+ choose to have a high-capacity reacting node send 55 transactions per
+ second and the remaining 9 low-capacity reacting nodes send 5
+ transactions per second. The ability of the reporting node to
+ specify the amount of traffic on a per-reacting-node basis implies
+ that the reporting node must maintain state for each of the reacting
+ nodes. This state includes the current allocation of Diameter
+ traffic to that reacting node. If the number of reacting nodes
+ changes, either because new nodes are added, nodes are removed from
+ service, or nodes fail, then 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.
+
+ This document draws heavily on work in the SIP Overload Control
+ Working Group. The definition of the rate abatement algorithm is
+ copied almost verbatim from the SIP Overload Control (SOC) document
+ [RFC7415], with changes focused on making the wording consistent with
+ the DOIC solution and the Diameter protocol.
+
+
+
+
+
+Donovan & Noel Standards Track [Page 4]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+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.
+
+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]
+
+
+
+
+Donovan & Noel Standards Track [Page 5]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ The rate algorithm MAY be selected by reporting nodes for any of
+ these report types.
+
+ 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.
+
+5. Capability Announcement
+
+ This document defines the rate abatement algorithm (referred to as
+ "rate" in this document) feature. Support for the rate feature by a
+ DOIC node will be indicated by a new value of the OC-Feature-Vector
+ attribute-value pair (AVP), as described in Section 7.1.1, per the
+ rules defined in [RFC7683].
+
+ Since all nodes that support DOIC are required to support the loss
+ algorithm, DOIC nodes supporting the rate feature will support both
+ the loss and rate abatement algorithms.
+
+ 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.
+
+ As defined in [RFC7683], a DOIC reporting node supporting the rate
+ feature selects a single abatement algorithm in the OC-Feature-Vector
+ AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC
+ reacting nodes.
+
+ A reporting node can select one abatement algorithm to apply to Host
+ and Realm reports, and a different algorithm to apply to peer
+ reports.
+
+ For Host or Realm reports, the selected algorithm is reflected in the
+ OC-Feature-Vector AVP sent as part of the OC-Supported-Features AVP
+ included in answer messages for transactions where the request
+ contained an OC-Supported-Features AVP. This is per the procedures
+ defined in [RFC7683].
+
+ For Peer reports, the selected algorithm is reflected in the OC-Peer-
+ Algo AVP sent as part of the OC-Supported-Features AVP included in
+ answer messages for transactions where the request contained an
+ OC-Supported-Features AVP. This is per the procedures defined in
+ [RFC8581].
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 6]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+6. Overload-Report Handling
+
+ This section describes any changes to the behavior defined in
+ [RFC7683] for the handling of Overload reports when the rate
+ abatement algorithm is used.
+
+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 to which it sends a rate Overload Report (OLR).
+
+ Note: This is different from the behavior defined in [RFC7683]
+ where a reporting node sends a single loss percentage to all
+ reacting nodes.
+
+ A reporting node SHOULD maintain OCS entries when using the rate
+ abatement algorithm 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 requested to be applied by DOIC reacting nodes in
+ the OC-Maximum-Rate AVP included in the OC-OLR AVP.
+
+ All other elements for the OCS defined in [RFC7683] and [RFC8581]
+ also apply to the reporting node's OCS when using the rate abatement
+ algorithm.
+
+6.2. Reacting-Node OCS
+
+ 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 reacting node that supports the rate abatement algorithm MUST
+ include the rate specified in the OC-Maximum-Rate AVP included in the
+ OC-OLR AVP as an element of the abatement-algorithm-specific portion
+ of reacting-node OCS entries.
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 7]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ All other elements for the OCS defined in [RFC7683] and [RFC8581]
+ also apply to the reporting nodes OCS when using the rate abatement
+ algorithm.
+
+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 and MUST indicate the selected rate in the resulting
+ reporting-node OCS entries.
+
+ When selecting the rate algorithm in the response to a request that
+ contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP
+ indicating support for the rate feature, a reporting node MUST ensure
+ that a reporting-node OCS entry exists for the target of the Overload
+ report. The target is defined as follows:
+
+ 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 that receives a capability announcement from a new
+ reacting node, meaning a reacting node for which it does not have an
+ OCS entry, and the reporting node that chooses the rate algorithm for
+ that reacting node may need to recalculate the rate to be allocated
+ to all reacting nodes. Any changed rate values will be communicated
+ in the next OLR sent to each reacting node.
+
+6.4. Reacting-Node Maintenance of OCS
+
+ When receiving an answer message indicating that the reporting node
+ has selected the rate algorithm, a reacting node MUST indicate the
+ rate abatement algorithm in the reacting-node OCS entry for the
+ reporting node.
+
+ A reacting node receiving an Overload report for the rate abatement
+ algorithm MUST save the rate received in the OC-Maximum-Rate AVP
+ contained in the OC-OLR AVP in the reacting-node OCS entry.
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 8]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+6.5. Reporting-Node Behavior for Rate Abatement Algorithm
+
+ When in an overload condition with rate selected as the overload
+ abatement algorithm and when handling a request that contained an
+ OC-Supported-Features AVP that indicated support for the rate
+ abatement algorithm, a reporting node SHOULD include an OC-OLR AVP
+ for the rate algorithm using the parameters stored in the
+ reporting-node OCS for the target of the Overload report.
+
+ Note: It is also possible for the reporting node to send Overload
+ reports with the rate algorithm indicated even when the reporting
+ node is not in an overloaded state. This could be a strategy to
+ proactively avoid entering into an overloaded state. 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 determining if abatement treatment should be applied to a
+ request being sent to a reporting node that has selected the rate
+ abatement algorithm, the reacting node can choose to use the
+ algorithm detailed 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 being sent to the reporting node.
+
+ Once a determination is made by the reacting node that an individual
+ Diameter request is to be subjected to abatement treatment, then the
+ procedures for throttling and diversion defined in [RFC7683] and
+ [RFC8581] apply.
+
+7. Rate Abatement Algorithm AVPs
+
+7.1. OC-Supported-Features AVP
+
+ The rate algorithm does not add any new AVPs to the OC-Supported-
+ Features AVP.
+
+ The rate algorithm does add a new feature bit to be carried in the
+ OC-Feature-Vector AVP.
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 9]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+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 this
+ flag is set by the overload-control endpoint, it indicates that
+ the DOIC node supports the rate abatement algorithm.
+
+7.2. OC-OLR AVP
+
+ This extension defines the OC-Maximum-Rate AVP to be 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 makes no changes to the other AVPs that are part of
+ the OC-OLR AVP.
+
+ This extension does not define new Overload report types. The
+ existing report types of HOST_REPORT and REALM_REPORT defined in
+ [RFC7683] apply to the rate control algorithm. The report type of
+ PEER_REPORT defined in [RFC8581] also applies to the rate control
+ algorithm.
+
+7.2.1. OC-Maximum-Rate AVP
+
+ The OC-Maximum-Rate AVP (AVP code 670) is of type Unsigned32 and
+ describes the maximum rate that the sender is requested to send
+ traffic. This is specified in terms of requests per second.
+
+ A value of zero indicates that no traffic is to be sent.
+
+
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 10]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+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 minor changes needed to
+ make it apply to 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 defined in [RFC7683], the reacting node and
+ reporting node signal their support for rate-based overload control.
+
+ Then, periodically, the reporting node relies on internal
+ measurements (e.g., CPU utilization or queuing delay) to evaluate its
+ overload state and estimate a target maximum Diameter request rate in
+ number of requests per second (as opposed to target percent reduction
+ in the case of loss-based abatement).
+
+ When in an overloaded state, the reporting node uses the OC-OLR AVP
+ to inform reacting nodes of its overload state and of the target
+ Diameter request rate.
+
+ Upon receiving the Overload report with a target maximum Diameter
+ request rate, each reacting node applies overload abatement for new
+ Diameter requests towards the reporting node.
+
+8.2. Reporting-Node Behavior
+
+ The actual algorithm used by the reporting node to determine its
+ overload state and estimate a target maximum Diameter request rate is
+ beyond the scope of this document.
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 11]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ However, the reporting node MUST periodically evaluate its overload
+ state and estimate a target Diameter request rate beyond which it
+ would become overloaded. The reporting node must allocate a portion
+ of the target Diameter request rate to each of its reacting nodes.
+ The reporting node may set the same rate for every reacting node, or
+ may set different rates for different reacting nodes.
+
+ The maximum rate determined by the reporting node for a reacting node
+ applies to the entire stream of Diameter requests, even though
+ abatement may only affect a particular subset of the requests, since
+ the reacting node might apply priority as part of its decision of
+ which requests to abate.
+
+ When setting the maximum rate for a particular reacting node, the
+ reporting node may need to take into account the workload (e.g., CPU
+ load per request) of the distribution of message types from that
+ reacting node. Furthermore, because the reacting node may prioritize
+ the specific types of messages it sends while under overload
+ restriction, this distribution of message types may be different from
+ the message distribution for that reacting node under non-overload
+ conditions (e.g., either higher or lower CPU load).
+
+ Note that the value of OC-Maximum-Rate AVP (in request messages per
+ second) for the rate algorithm provides a loose upper bound on the
+ traffic sent by the reacting node to the reporting node.
+
+ In other words, when multiple reacting nodes are being controlled by
+ an overloaded reporting node, at any given time, some reporting nodes
+ may receive requests at a rate below its target maximum Diameter
+ request rate while receiving others above that target rate. But, the
+ resulting request rate presented to the overloaded reporting node
+ will converge towards the target Diameter request rate or a lower
+ rate.
+
+ Upon detection of overload, and the determination to invoke overload
+ controls, the reporting node follows the specifications in [RFC7683]
+ to notify its reacting nodes of the allocated target maximum Diameter
+ request rate, and to notify them that the rate abatement is in
+ effect.
+
+ The reporting node uses the OC-Maximum-Rate AVP defined in this
+ specification to communicate a target maximum Diameter request rate
+ to each of its clients.
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 12]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+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
+ }
+
+ In determining whether or not to transmit a specific message, the
+ reacting node can use any algorithm that limits the message rate to
+ the OC-Maximum-Rate AVP value in units of messages per second. For
+ ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target
+ inter-Diameter request interval. It may be strictly deterministic,
+ or it may be probabilistic. It may or may not have a tolerance
+ factor, to allow for short bursts, as long as the long-term rate
+ remains below 1/T.
+
+ The algorithm may have provisions for prioritizing traffic.
+
+ If the algorithm requires other parameters (in addition to "T", which
+ is 1/OC-Maximum-Rate), they may be set autonomously by the reacting
+ node, or they may be negotiated independently between the reacting
+ node and the reporting node.
+
+
+
+
+Donovan & Noel Standards Track [Page 13]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ In either case, the coordination is out of the scope of this
+ document. The default algorithms presented here (one with and one
+ without provisions for prioritizing traffic) are only examples.
+
+ To apply abatement treatment to new Diameter requests at the rate
+ specified in the OC-Maximum-Rate AVP value sent by the reporting node
+ to its reacting nodes, the reacting node MAY use the proposed default
+ algorithm for rate-based control or any other equivalent algorithm
+ that forward messages in conformance with the upper bound of 1/T
+ messages per second.
+
+ The default leaky bucket algorithm presented here is based on
+ Appendix A.2 of [ITU-T-I.371]. The algorithm makes it possible for
+ reacting nodes to deliver Diameter requests at a rate specified in
+ the OC-Maximum-Rate value with tolerance parameter TAU (preferably
+ configurable).
+
+ Conceptually, the leaky bucket algorithm can be viewed as a finite
+ capacity bucket whose real-valued content drains out at a continuous
+ rate of 1 unit of content per time unit and whose content increases
+ by the increment T for each forwarded Diameter request. T is
+ computed as the inverse of the rate specified in the OC-Maximum-Rate
+ AVP value, namely T = 1 / OC-Maximum-Rate.
+
+ Note that when the OC-Maximum-Rate value is 0 with a non-zero
+ OC-Validity-Duration, then the reacting node should apply abatement
+ treatment to 100% of Diameter requests destined to the overloaded
+ reporting node. However, when the OC-Validity-Duration value is 0,
+ the reacting node should stop applying abatement treatment.
+
+ If, at a new Diameter request arrival, the content of the bucket is
+ less than or equal to the limit value TAU, then the Diameter request
+ is forwarded to the server; otherwise, the abatement treatment is
+ applied to the Diameter request.
+
+ Note that the capacity of the bucket (the upper bound of the counter)
+ is (T + TAU).
+
+ The tolerance parameter TAU determines how close the long-term
+ admitted rate is to an ideal control that would admit all Diameter
+ requests for arrival rates less than 1/T and then admit Diameter
+ requests precisely at the rate of 1/T for arrival rates above 1/T.
+ In particular, at mean arrival rates close to 1/T, it determines the
+ tolerance to deviation of the inter-arrival time from T. (The larger
+ TAU, the more tolerance to deviations from the inter-departure
+ interval T.)
+
+
+
+
+
+Donovan & Noel Standards Track [Page 14]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ This deviation from the inter-departure interval influences the
+ admitted rate burstiness or the number of consecutive Diameter
+ requests forwarded to the reporting node (burst size proportional to
+ TAU over the difference between 1/T and the arrival rate).
+
+ In situations where reacting nodes are configured with some knowledge
+ about the reporting node and other traffic sources (e.g., operator
+ pre-provisioning), it can be beneficial to choose a value of TAU
+ based on how many reacting nodes will be sending requests to the
+ reporting node.
+
+ Reporting nodes with a very large number of reacting nodes, each with
+ a relatively small arrival rate, will generally benefit from a
+ smaller value for TAU in order to limit queuing (and hence response
+ times) at the reporting node when subjected to a sudden surge of
+ traffic from all reacting nodes. Conversely, a reporting node with a
+ relatively small number of reacting nodes, each with a proportionally
+ larger arrival rate, will benefit from a larger value of TAU.
+
+ Once the control has been activated, at the arrival time of the k-th
+ new Diameter request, ta(k), the content of the bucket is
+ provisionally updated to the value
+
+ X' = X - (ta(k) - LCT)
+
+ where X is the value of the leaky bucket counter after arrival of the
+ last forwarded Diameter request, and LCT is the time at which the
+ last Diameter request was forwarded.
+
+ If X' is less than or equal to the limit value TAU, then the new
+ Diameter request is forwarded and 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, then the abatement treatment is applied to the new Diameter
+ request, and the values of X and LCT are unchanged.
+
+ When the first response from the reporting node has been received,
+ indicating control activation (OC-Validity-Duration>0), LCT is set to
+ the time of activation, and the leaky bucket counter is initialized
+ to the parameter TAU0 (preferably configurable), which is 0 or larger
+ but less than or equal to TAU.
+
+ TAU can assume any positive real number value and is not necessarily
+ bounded by T.
+
+ TAU=4*T is a reasonable compromise between burst size and abatement
+ rate adaptation at low offered rate.
+
+
+
+
+Donovan & Noel Standards Track [Page 15]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ Note that specification of a value for TAU, and any communication or
+ coordination between servers, is beyond the scope of this document.
+
+8.3.2. Priority Treatment
+
+ A reference algorithm is shown below.
+
+ 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 responsible for applying message priority and
+ for maintaining two categories of requests: request candidates for
+ reduction, and requests not subject to reduction (except under
+ extenuating circumstances when there aren't any messages in the first
+ category that can be reduced).
+
+ Accordingly, the proposed leaky bucket implementation is modified to
+ support priority using two thresholds for Diameter requests in the
+ set of request candidates for reduction. With two priorities, the
+ proposed leaky bucket requires two thresholds TAU1 < TAU2:
+
+ o All new requests would be admitted when the leaky bucket counter
+ is at or below TAU1.
+
+
+
+
+
+Donovan & Noel Standards Track [Page 16]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ o Only higher priority requests would be admitted when the leaky
+ bucket counter is between TAU1 and TAU2.
+
+ o 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.
+
+ With a priority scheme that relies on two tolerance parameters (TAU2
+ influences the priority traffic, and TAU1 influences the non-priority
+ traffic), 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
+ as TAU does when no priority is set, and the larger the difference
+ between TAU1 and TAU2, the closer the control is to strict priority
+ queuing.
+
+ TAU1 and TAU2 can assume any positive real number value and is not
+ necessarily bounded by T.
+
+ Reasonable values for TAU0, TAU1, and TAU2 are:
+
+ o TAU0 = 0,
+
+ o TAU1 = 1/2 * TAU2, and
+
+ o TAU2 = 10 * T.
+
+ Note that specification of a value for TAU1 and TAU2, and any
+ communication or coordination between servers, is beyond the scope of
+ this document.
+
+8.3.3. Optional Enhancement: Avoidance of Resonance
+
+ As the number of reacting-node sources of traffic increases and the
+ throughput of the reporting node decreases, the maximum rate admitted
+ by each reacting node needs to decrease, and therefore the value of T
+ becomes larger. Under some circumstances, e.g., if the traffic
+ arises very quickly simultaneously at many sources, the occupancies
+ of each bucket can become synchronized, resulting in both the
+ admissions from each source being close in time and batched, or very
+ "peaky" arrivals at the reporting node. This gives rise not only to
+ control instability, but also very poor delays and even lost
+ messages. An appropriate term for this is "resonance" [Erramilli].
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 17]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ If the network topology is such that resonance can occur, then a
+ simple way to avoid resonance is to randomize the bucket occupancy at
+ two appropriate points: at the activation of control, and whenever
+ the bucket empties, as described below:
+
+ After updating the value of the leaky bucket to X', generate a value
+ u as follows:
+
+ 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, which will therefore be just T if the bucket
+ hadn't emptied, or lie between T/2 and 3T/2 if it had.
+
+ This randomization should also be done when control is activated,
+ i.e., instead of simply initializing the leaky bucket counter to
+ TAU0, initialize it to TAU0 + uT, where u is uniformly distributed as
+ above. Since activation would have been a result of the response to
+ a request sent by the reacting node, the second term in this
+ expression can be interpreted as being the bucket increment following
+ that admission.
+
+ This method has the following characteristics:
+
+ o 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];
+
+ o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without
+ randomization;
+
+ o For the special case of "classic gapping", where TAU=0, then 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.
+
+ o 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.
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 18]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+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
+
+ 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>.
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 19]
+
+RFC 8582 Diameter Overload Rate Control August 2019
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+Donovan & Noel Standards Track [Page 20]
+