draft-ietf-dime-doic-rate-control-11.txt   rfc8582.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. Internet Engineering Task Force (IETF) S. Donovan, Ed.
Internet-Draft Oracle Request for Comments: 8582 Oracle
Intended status: Standards Track E. Noel Category: Standards Track E. Noel
Expires: August 15, 2019 AT&T Labs ISSN: 2070-1721 AT&T Labs
February 11, 2019 August 2019
Diameter Overload Rate Control Diameter Overload Rate Control
draft-ietf-dime-doic-rate-control-11
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. This extension Indication Conveyance (DOIC) base solution, which is defined in RFC
adds a new overload control abatement algorithm. This abatement 7683. This extension adds a new overload-control abatement
algorithm allows for a DOIC reporting node to specify a maximum rate algorithm. This abatement algorithm allows for a DOIC reporting node
at which a DOIC reacting node sends Diameter requests to the DOIC to specify a maximum rate at which a DOIC reacting node sends
reporting node. Diameter requests to the DOIC reporting node.
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 15, 2019. 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Interaction with DOIC Report Types . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Capability Announcement . . . . . . . . . . . . . . . . . . . 6 4. Interaction with DOIC Report Types . . . . . . . . . . . . . 5
5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6 5. Capability Announcement . . . . . . . . . . . . . . . . . . . 6
5.1. Reporting Node Overload Control State . . . . . . . . . . 6 6. Overload-Report Handling . . . . . . . . . . . . . . . . . . 7
5.2. Reacting Node Overload Control State . . . . . . . . . . 7 6.1. Reporting-Node OCS . . . . . . . . . . . . . . . . . . . 7
5.3. Reporting Node Maintenance of Overload Control State . . 7 6.2. Reacting-Node OCS . . . . . . . . . . . . . . . . . . . . 7
5.4. Reacting Node Maintenance of Overload Control State . . . 8 6.3. Reporting-Node Maintenance of OCS . . . . . . . . . . . . 8
5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8 6.4. Reacting-Node Maintenance of OCS . . . . . . . . . . . . 8
5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 9 6.5. Reporting-Node Behavior for Rate Abatement Algorithm . . 9
6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9 6.6. Reacting-Node Behavior for Rate Abatement Algorithm . . . 9
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9 7. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9
6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9 7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9 7.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 10
6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10 7.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 10 7.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10
7. Rate-Based Abatement Algorithm . . . . . . . . . . . . . . . 10 7.3. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 11
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Rate Abatement Algorithm . . . . . . . . . . . . . . . . . . 11
7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 8.2. Reporting-Node Behavior . . . . . . . . . . . . . . . . . 11
7.3.1. Default Algorithm for Rate-based Control . . . . . . 12 8.3. Reacting-Node Behavior . . . . . . . . . . . . . . . . . 13
7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 15 8.3.1. Default Algorithm for Rate-Based Control . . . . . . 13
7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17 8.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 16
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18 8.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17
8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.2. OC-Supported-Features . . . . . . . . . . . . . . . . . . 18 9.1. OC-Supported-Features . . . . . . . . . . . . . . . . . . 19
8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document defines a new Diameter overload control abatement This document defines a new Diameter overload-control abatement
algorithm, the "rate" algorithm. algorithm, the "rate" algorithm.
The base Diameter overload specification [RFC7683] defines the "loss" The base Diameter overload specification [RFC7683] defines the "loss
algorithm as the default Diameter overload abatement algorithm. The algorithm" as the default Diameter overload loss abatement algorithm.
loss algorithm allows a reporting node (see Section 2) to instruct a The loss algorithm allows a reporting node (see Section 3) to
reacting node (see Section 2) to reduce the amount of traffic sent to instruct a reacting node (see Section 3) to reduce the amount of
the reporting node by abating (diverting or throttling) a percentage traffic sent to the reporting node by abating (diverting or
of requests sent to the server. While this can effectively decrease throttling) a percentage of requests sent to the server. While this
the load handled by the server, it does not directly address cases can effectively decrease the load handled by the server, it does not
where the rate of arrival of service requests changes quickly. For directly address cases where the rate of arrival of service requests
instance, if the service requests that result in Diameter changes quickly. For instance, if the service requests that result
transactions increase quickly then the loss algorithm cannot in Diameter transactions increase quickly, then the loss algorithm
guarantee the load presented to the server remains below a specific cannot guarantee the load presented to the server remains below a
rate level. The loss algorithm can be slow to ensure the stability specific rate level. The loss algorithm can be slow to ensure the
of reporting nodes when subjected to rapidly-changing loads. The stability of reporting nodes when subjected to rapidly-changing
"loss" algorithm errs both in throttling too much when there is a dip loads. The "loss" algorithm errs both in throttling too much when
in offered load, and throttling not enough when there is a spike in there is a dip in offered load, and throttling not enough when there
offered load. is a spike in offered load.
Consider the case where a reacting node is handling 100 service Consider the case where a reacting node is handling 100 service
requests per second, where each of these service requests results in requests per second, where each of these service requests results in
one Diameter transaction being sent to a reporting node. If the one Diameter transaction being sent to a reporting node. If the
reporting node is approaching an overload state, or is already in an reporting node is approaching an overload state, or is already in an
overload state, it will send a Diameter overload report requesting a overload state, it will send a Diameter Overload report requesting a
percentage reduction in traffic sent when the loss algorithm is used percentage reduction in traffic sent when the loss algorithm is used
as Diameter overload abatement algorithm. Assume for this discussion as a Diameter overload abatement algorithm. Assume for this
that the reporting node requests a 10% reduction. The reacting node discussion that the reporting node requests a 10% reduction. The
will then abate (diverting or throttling) ten Diameter transactions a reacting node will then abate (diverting or throttling) ten Diameter
second, sending the remaining 90 transactions per second to the transactions a second, sending the remaining 90 transactions per
reporting node. second to the reporting node.
Now assume that the reacting node's service requests spikes to 1000 Now assume that the reacting node's service requests spike to 1000
requests per second. The reacting node will continue to honor the requests per second. The reacting node will continue to honor the
reporting node's request for a 10% reduction in traffic. This reporting node's request for a 10% reduction in traffic. This
results, in this example, in the reacting node sending 900 Diameter results, in this example, in the reacting node sending 900 Diameter
transactions per second, abating the remaining 100 transactions per transactions per second, abating the remaining 100 transactions per
second. This spike in traffic is significantly higher than the second. This spike in traffic is significantly higher than the
reporting node is expecting to handle and can result in negative reporting node is expecting to handle and can result in negative
impacts to the stability of the reporting node. impacts to the stability of the reporting node.
The reporting node can, and likely would, send another overload The reporting node can, and likely would, send another Overload
report requesting that the reacting node abate 91% of requests to get report requesting that the reacting node abate 91% of requests to get
back to the desired 90 transactions per second. However, once the back to the desired 90 transactions per second. However, once the
spike has abated and the reacting node handled service requests spike has abated and the rate at which the reacting node handles
returns to 100 per second, this will result in just 9 transactions requests has returned to 100 per second, this will result in just 9
per second being sent to the reporting node, requiring a new overload transactions per second being sent to the reporting node, requiring a
report setting the reduction percentage back to 10%. This control new Overload report setting the reduction percentage back to 10%.
feedback loop has the potential to make the situation worse by This control feedback loop has the potential to make the situation
causing wide fluctuations in traffic on multiple nodes in the worse by causing wide fluctuations in traffic on multiple nodes in
Diameter network. the Diameter network.
One of the benefits of a rate-based algorithm over the loss algorithm 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 is that it better handles spikes in traffic. Instead of sending a
request to reduce traffic by a percentage, the rate approach allows request to reduce traffic by a percentage, the rate approach allows
the reporting node to specify the maximum number of Diameter requests the reporting node to specify the maximum number of Diameter requests
per second that can be sent to the reporting node. For instance, in per second that can be sent to the reporting node. For instance, in
this example, the reporting node could send a rate-based request this example, the reporting node could send a rate-based request
specifying the maximum transactions per second to be 90. The specifying the maximum transactions per second to be 90. The
reacting node will send the 90 regardless of whether it is receiving reacting node will send the 90 regardless of whether it is receiving
100 or 1000 service requests per second. 100 or 1000 service requests per second.
It should be noted that one of the implications of the rate-based 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 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 to distribute its load over the set of reacting nodes from which it
is receiving traffic. For instance, if the reporting node is is receiving traffic. For instance, if the reporting node is
receiving Diameter traffic from 10 reacting nodes and has a capacity receiving Diameter traffic from 10 reacting nodes and has a capacity
of 100 transactions per second then the reporting node could choose 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 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 second. This, of course, is assuming that each of the reacting nodes
has equal performance characteristics. The reporting node could also has equal performance characteristics. The reporting node could also
choose to have a high capacity reacting node send 55 transactions per choose to have a high-capacity reacting node send 55 transactions per
second and the remaining 9 low capacity reacting nodes send 5 second and the remaining 9 low-capacity reacting nodes send 5
transactions per second. The ability of the reporting node to transactions per second. The ability of the reporting node to
specify the amount of traffic on a per-reacting-node basis implies specify the amount of traffic on a per-reacting-node basis implies
that the reporting node must maintain state for each of the reacting that the reporting node must maintain state for each of the reacting
nodes. This state includes the current allocation of Diameter nodes. This state includes the current allocation of Diameter
traffic to that reacting node. If the number of reacting nodes traffic to that reacting node. If the number of reacting nodes
changes, either because new nodes are added, nodes are removed from changes, either because new nodes are added, nodes are removed from
service or nodes fail, then the reporting node will need to service, or nodes fail, then the reporting node will need to
redistribute the maximum Diameter transactions over the new set of redistribute the maximum Diameter transactions over the new set of
reacting nodes. reacting nodes.
This document extends the base Diameter Overload Indication This document extends the base Diameter Overload Indication
Conveyance (DOIC) solution [RFC7683] to add support for the rate- Conveyance (DOIC) solution [RFC7683] to add support for the rate
based overload abatement algorithm. abatement algorithm.
This document draws heavily on work in the SIP Overload Control This document draws heavily on work in the SIP Overload Control
working group. The definition of the rate abatement algorithm is Working Group. The definition of the rate abatement algorithm is
copied almost verbatim from the SIP Overload Control (SOC) document copied almost verbatim from the SIP Overload Control (SOC) document
[RFC7415], with changes focused on making the wording consistent with [RFC7415], with changes focused on making the wording consistent with
the DOIC solution and the Diameter protocol. the DOIC solution and the Diameter protocol.
2. Terminology 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 Diameter Node
A Diameter Client, Diameter Server, or Diameter Agent. [RFC6733] A Diameter Client, Diameter Server, or Diameter Agent [RFC6733]
Diameter Endpoint Diameter Endpoint
A Diameter Client or Diameter Server. [RFC6733] A Diameter Client or Diameter Server [RFC6733]
DOIC Node DOIC Node
A Diameter Node that supports the DOIC solution defined in A Diameter node that supports the DOIC solution defined in
[RFC7683]. [RFC7683]
Reporting Node Reporting Node
A DOIC Node that sends a DOIC overload report. A DOIC node that sends an Overload report in a Diameter answer
message
Reacting Node Reacting Node
A DOIC Node that receives and acts on a DOIC overload report. A DOIC node that receives and acts on a DOIC Overload report
3. Interaction with DOIC Report Types 4. Interaction with DOIC Report Types
As of the publication of this specification, there are two DOIC As of the publication of this specification, there are three DOIC
report types defined with the specification of a third in progress: report types:
HOST_REPORT 0 Overload of a specific Diameter Application at a HOST_REPORT 0:
specific Diameter Node as defined in [RFC7683] 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 REALM_REPORT 1:
specific Diameter Realm as defined in [RFC7683] 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 PEER_REPORT 2:
[I-D.ietf-dime-agent-overload] Overload of a specific Diameter peer as defined in [RFC8581]
The rate algorithm MAY be selected by reporting nodes for any of The rate algorithm MAY be selected by reporting nodes for any of
these report types. these report types.
It is expected that all report types defined in the future will It is expected that all report types defined in the future will
indicate whether or not the rate algorithm can be used with that indicate whether or not the rate algorithm can be used with that
report type. report type.
4. Capability Announcement 5. Capability Announcement
This document defines the rate abatement algorithm (referred to as This document defines the rate abatement algorithm (referred to as
rate in this document) feature. Support for the rate feature by a "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 DOIC node will be indicated by a new value of the OC-Feature-Vector
AVP, as described in Section 6.1.1, per the rules defined in attribute-value pair (AVP), as described in Section 7.1.1, per the
[RFC7683]. rules defined in [RFC7683].
Since all nodes that support DOIC are required to support the loss Since all nodes that support DOIC are required to support the loss
algorithm, DOIC nodes supporting the rate feature will support both algorithm, DOIC nodes supporting the rate feature will support both
the loss and rate-based abatement algorithms. the loss and rate abatement algorithms.
DOIC reacting nodes supporting the rate feature MUST indicate support DOIC reacting nodes supporting the rate feature MUST indicate support
for both the loss and rate algorithms in the OC-Feature-Vector AVP for both the loss and rate algorithms in the OC-Feature-Vector AVP
and MAY indicate support for other algorithms. and MAY indicate support for other algorithms.
As defined in [RFC7683], a DOIC reporting node supporting the rate As defined in [RFC7683], a DOIC reporting node supporting the rate
feature selects a single abatement algorithm in the OC-Feature-Vector 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 AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC
reacting nodes. reacting nodes.
A reporting node can select one abatement algorithm to apply to host A reporting node can select one abatement algorithm to apply to Host
and realm reports and a different algorithm to apply to peer reports. and Realm reports, and a different algorithm to apply to peer
reports.
For host or realm reports the selected algorithm is reflected in For Host or Realm reports, the selected algorithm is reflected in the
the OC-Feature-Vector AVP sent as part of the OC-Supported- OC-Feature-Vector AVP sent as part of the OC-Supported-Features AVP
Features AVP included in answer messages for transaction where the included in answer messages for transactions where the request
request contained an OC-Supported-Features AVP. This is per the contained an OC-Supported-Features AVP. This is per the procedures
procedures defined in [RFC7683]. defined in [RFC7683].
For peer reports the selected algorithm is reflected in the OC- For Peer reports, the selected algorithm is reflected in the OC-Peer-
Peer-Algo AVP sent as part of the OC-Supported-Features AVP Algo AVP sent as part of the OC-Supported-Features AVP included in
included answer messages for transactions where the request answer messages for transactions where the request contained an
contained an OC-Supported-Features AVP. This is per the OC-Supported-Features AVP. This is per the procedures defined in
procedures defined in [I-D.ietf-dime-agent-overload]. [RFC8581].
5. Overload Report Handling 6. Overload-Report Handling
This section describes any changes to the behavior defined in This section describes any changes to the behavior defined in
[RFC7683] for handling of overload reports when the rate overload [RFC7683] for the handling of Overload reports when the rate
abatement algorithm is used. abatement algorithm is used.
5.1. Reporting Node Overload Control State 6.1. Reporting-Node OCS
A reporting node that uses the rate abatement algorithm SHOULD A reporting node that uses the rate abatement algorithm SHOULD
maintain reporting node Overload Control State (OCS) for each maintain reporting-node Overload Control State (OCS) for each
reacting node to which it sends a rate Overload Report (OLR). reacting node to which it sends a rate Overload Report (OLR).
This is different from the behavior defined in [RFC7683] where a Note: This is different from the behavior defined in [RFC7683]
reporting node sends a single loss percentage to all reacting where a reporting node sends a single loss percentage to all
nodes. reacting nodes.
A reporting node SHOULD maintain OCS entries when using the rate A reporting node SHOULD maintain OCS entries when using the rate
abatement algorithm per supported Diameter application, per targeted abatement algorithm per supported Diameter application, per targeted
reacting node and per report type. reacting node and per report type.
A rate OCS entry is identified by the tuple of Application-Id, report A rate OCS entry is identified by the tuple of Application-ID, report
type and DiameterIdentity of the target of the rate OLR. type, and DiameterIdentity of the target of the rate OLR.
The rate OCS entry SHOULD include the rate allocated to the reacting The rate OCS entry SHOULD include the rate allocated to the reacting
note. node.
A reporting node that has selected the rate overload abatement A reporting node that has selected the rate abatement algorithm MUST
algorithm MUST indicate the rate requested to be applied by DOIC indicate the rate requested to be applied by DOIC reacting nodes in
reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP. the OC-Maximum-Rate AVP included in the OC-OLR AVP.
All other elements for the OCS defined in [RFC7683] and All other elements for the OCS defined in [RFC7683] and [RFC8581]
[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS also apply to the reporting node's OCS when using the rate abatement
when using the rate abatement algorithm. algorithm.
5.2. Reacting Node Overload Control State 6.2. Reacting-Node OCS
A reacting node that supports the rate abatement algorithm MUST A reacting node that supports the rate abatement algorithm MUST
indicate rate as the selected abatement algorithm in the reacting 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 node OCS based on the OC-Feature-Vector AVP or the OC-Peer-Algo AVP
in the received OC-Supported-Features AVP. in the received OC-Supported-Features AVP.
A reacting node that supports the rate abatement algorithm MUST A reacting node that supports the rate abatement algorithm MUST
include the rate specified in the OC-Maximum-Rate AVP included in the 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 OC-OLR AVP as an element of the abatement-algorithm-specific portion
of reacting node OCS entries. of reacting-node OCS entries.
All other elements for the OCS defined in [RFC7683] and All other elements for the OCS defined in [RFC7683] and [RFC8581]
[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS also apply to the reporting nodes OCS when using the rate abatement
when using the rate abatement algorithm. algorithm.
5.3. Reporting Node Maintenance of Overload Control State 6.3. Reporting-Node Maintenance of OCS
A reporting node that has selected the rate overload abatement A reporting node that has selected the rate abatement algorithm and
algorithm and enters an overload condition MUST indicate rate as the enters an overload condition MUST indicate rate as the abatement
abatement algorithm and MUST indicate the selected rate in the algorithm and MUST indicate the selected rate in the resulting
resulting reporting node OCS entries. reporting-node OCS entries.
When selecting the rate algorithm in the response to a request that When selecting the rate algorithm in the response to a request that
contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP
indicating support for the rate feature, a reporting node MUST ensure indicating support for the rate feature, a reporting node MUST ensure
that a reporting node OCS entry exists for the target of the overload that a reporting-node OCS entry exists for the target of the Overload
report. The target is defined as follows: report. The target is defined as follows:
o For Host reports, the target is the DiameterIdentity contained in o For Host reports, the target is the DiameterIdentity contained in
the Origin-Host AVP received in the request. the Origin-Host AVP received in the request.
o For Realm reports, the target is the DiameterIdentity contained in o For Realm reports, the target is the DiameterIdentity contained in
the Origin-Realm AVP received in the request. the Origin-Realm AVP received in the request.
o For Peer reports, the target is the DiameterIdentity of the o For Peer reports, the target is the DiameterIdentity of the
Diameter Peer from which the request was received. Diameter peer from which the request was received.
A reporting node that receives a capability announcement from a new A reporting node that receives a capability announcement from a new
reacting node, meaning a reacting node for which it does not have an reacting node, meaning a reacting node for which it does not have an
OCS entry, and the reporting node chooses the rate algorithm for that OCS entry, and the reporting node that chooses the rate algorithm for
reacting node may need to recalculate the rate to be allocated to all that reacting node may need to recalculate the rate to be allocated
reacting nodes. Any changed rate values will be communicated in the to all reacting nodes. Any changed rate values will be communicated
next OLR sent to each reacting node. in the next OLR sent to each reacting node.
5.4. Reacting Node Maintenance of Overload Control State 6.4. Reacting-Node Maintenance of OCS
When receiving an answer message indicating that the reporting node When receiving an answer message indicating that the reporting node
has selected the rate algorithm, a reacting node MUST indicate the has selected the rate algorithm, a reacting node MUST indicate the
rate abatement algorithm in the reacting node OCS entry for the rate abatement algorithm in the reacting-node OCS entry for the
reporting node. reporting node.
A reacting node receiving an overload report for the rate abatement A reacting node receiving an Overload report for the rate abatement
algorithm MUST save the rate received in the OC-Maximum-Rate AVP algorithm MUST save the rate received in the OC-Maximum-Rate AVP
contained in the OC-OLR AVP in the reacting node OCS entry. contained in the OC-OLR AVP in the reacting-node OCS entry.
5.5. Reporting Node Behavior for Rate Abatement Algorithm 6.5. Reporting-Node Behavior for Rate Abatement Algorithm
When in an overload condition with rate selected as the overload When in an overload condition with rate selected as the overload
abatement algorithm and when handling a request that contained an OC- abatement algorithm and when handling a request that contained an
Supported-Features AVP that indicated support for the rate abatement OC-Supported-Features AVP that indicated support for the rate
algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate abatement algorithm, a reporting node SHOULD include an OC-OLR AVP
algorithm using the parameters stored in the reporting node OCS for for the rate algorithm using the parameters stored in the
the target of the overload report. reporting-node OCS for the target of the Overload report.
Note: It is also possible for the reporting node to send overload Note: It is also possible for the reporting node to send Overload
reports with the rate algorithm indicated even when the reporting reports with the rate algorithm indicated even when the reporting
node is not in an overloaded state. This could be a strategy to node is not in an overloaded state. This could be a strategy to
proactively avoid entering into an overloaded state. Whether to proactively avoid entering into an overloaded state. Whether or
do so is up to local policy. not to do so is up to local policy.
When sending an overload report for the rate algorithm, the OC- When sending an Overload report for the rate algorithm, the
Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC- OC-Maximum-Rate AVP MUST be included in the OC-OLR AVP and the
Reduction-Percentage AVP MUST NOT be included. OC-Reduction-Percentage AVP MUST NOT be included.
5.6. Reacting Node Behavior for Rate Abatement Algorithm 6.6. Reacting-Node Behavior for Rate Abatement Algorithm
When determining if abatement treatment should be applied to a When determining if abatement treatment should be applied to a
request being sent to a reporting node that has selected the rate request being sent to a reporting node that has selected the rate
overload abatement algorithm, the reacting node can choose to use the abatement algorithm, the reacting node can choose to use the
algorithm detailed in Section 7. algorithm detailed in Section 8.
Other algorithms for controlling the rate MAY be implemented by the Other algorithms for controlling the rate MAY be implemented by the
reacting node. Any algorithm implemented MUST correctly limit the reacting node. Any algorithm implemented MUST correctly limit the
maximum rate of traffic being sent to the reporting node. maximum rate of traffic being sent to the reporting node.
Once a determination is made by the reacting node that an individual Once a determination is made by the reacting node that an individual
Diameter request is to be subjected to abatement treatment then the Diameter request is to be subjected to abatement treatment, then the
procedures for throttling and diversion defined in [RFC7683] and procedures for throttling and diversion defined in [RFC7683] and
[I-D.ietf-dime-agent-overload] apply. [RFC8581] apply.
6. Rate Abatement Algorithm AVPs 7. Rate Abatement Algorithm AVPs
6.1. OC-Supported-Features AVP 7.1. OC-Supported-Features AVP
The rate algorithm does not add any new AVPs to the OC-Supported- The rate algorithm does not add any new AVPs to the OC-Supported-
Features AVP. Features AVP.
The rate algorithm does add a new feature bit to be carried in the The rate algorithm does add a new feature bit to be carried in the
OC-Feature-Vector AVP. OC-Feature-Vector AVP.
6.1.1. OC-Feature-Vector AVP 7.1.1. OC-Feature-Vector AVP
This extension adds the following capability to the OC-Feature-Vector This extension adds the following capability to the OC-Feature-Vector
AVP. AVP.
OLR_RATE_ALGORITHM (bit 2) OLR_RATE_ALGORITHM (0x0000000000000004)
Bit 2 is assigned to the rate overload abatement algorithm. When This bit is assigned to the rate abatement algorithm. When this
this flag is set by the overload control endpoint it indicates flag is set by the overload-control endpoint, it indicates that
that the DOIC Node supports the rate overload abatement algorithm. the DOIC node supports the rate abatement algorithm.
6.2. OC-OLR AVP 7.2. OC-OLR AVP
This extension defines the OC-Maximum-Rate AVP to be an optional part This extension defines the OC-Maximum-Rate AVP to be an optional part
of the OC-OLR AVP. of the OC-OLR AVP.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
[ SourceID ] [ SourceID ]
[ OC-Maximum-Rate ] [ OC-Maximum-Rate ]
* [ AVP ] * [ AVP ]
This extension makes no changes to the other AVPs that are part of This extension makes no changes to the other AVPs that are part of
the OC-OLR AVP. the OC-OLR AVP.
This extension does not define new overload report types. The This extension does not define new Overload report types. The
existing report types of host and realm defined in [RFC7683] apply to existing report types of HOST_REPORT and REALM_REPORT defined in
the rate control algorithm. The peer report type defined in [RFC7683] apply to the rate control algorithm. The report type of
[I-D.ietf-dime-agent-overload] also applies to the rate control PEER_REPORT defined in [RFC8581] also applies to the rate control
algorithm. algorithm.
6.2.1. OC-Maximum-Rate AVP 7.2.1. OC-Maximum-Rate AVP
The OC-Maximum-Rate AVP (AVP code TBD1) is of type Unsigned32 and The OC-Maximum-Rate AVP (AVP code 670) is of type Unsigned32 and
describes the maximum rate that the sender is requested to send describes the maximum rate that the sender is requested to send
traffic. This is specified in terms of requests per second. traffic. This is specified in terms of requests per second.
A value of zero indicates that no traffic is to be sent. A value of zero indicates that no traffic is to be sent.
6.3. Attribute Value Pair Flag Rules 7.3. Attribute-Value Pair Flag Rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------------------+----+----+ +---------------------------------------------------------+----+----+
|OC-Maximum-Rate TBD1 6.2 Unsigned32 | | V | |OC-Maximum-Rate 670 7.2.1 Unsigned32 | | V |
+---------------------------------------------------------+----+----+ +---------------------------------------------------------+----+----+
7. Rate-Based Abatement Algorithm 8. Rate Abatement Algorithm
This section is pulled from [RFC7415], with minor changes needed to This section is pulled from [RFC7415] with minor changes needed to
make it apply to the Diameter protocol. make it apply to the Diameter protocol.
7.1. Overview 8.1. Overview
The reporting node is the one protected by the overload control The reporting node is the one protected by the overload control
algorithm defined here. The reacting node is the one that abates algorithm defined here. The reacting node is the one that abates
traffic towards the server. traffic towards the server.
Following the procedures defined in [RFC7683], the reacting node and Following the procedures defined in [RFC7683], the reacting node and
reporting node signal their support for rate-based overload control. reporting node signal their support for rate-based overload control.
Then periodically, the reporting node relies on internal measurements Then, periodically, the reporting node relies on internal
(e.g. CPU utilization or queuing delay) to evaluate its overload measurements (e.g., CPU utilization or queuing delay) to evaluate its
state and estimate a target maximum Diameter request rate in number overload state and estimate a target maximum Diameter request rate in
of requests per second (as opposed to target percent reduction in the number of requests per second (as opposed to target percent reduction
case of loss-based abatement). in the case of loss-based abatement).
When in an overloaded state, the reporting node uses the OC-OLR AVP 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 to inform reacting nodes of its overload state and of the target
Diameter request rate. Diameter request rate.
Upon receiving the overload report with a target maximum Diameter Upon receiving the Overload report with a target maximum Diameter
request rate, each reacting node applies overload abatement for new request rate, each reacting node applies overload abatement for new
Diameter requests towards the reporting node. Diameter requests towards the reporting node.
7.2. Reporting Node Behavior 8.2. Reporting-Node Behavior
The actual algorithm used by the reporting node to determine its The actual algorithm used by the reporting node to determine its
overload state and estimate a target maximum Diameter request rate is overload state and estimate a target maximum Diameter request rate is
beyond the scope of this document. beyond the scope of this document.
However, the reporting node MUST periodically evaluate its overload However, the reporting node MUST periodically evaluate its overload
state and estimate a target Diameter request rate beyond which it state and estimate a target Diameter request rate beyond which it
would become overloaded. The reporting node must allocate a portion would become overloaded. The reporting node must allocate a portion
of the target Diameter request rate to each of its reacting nodes. 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 The reporting node may set the same rate for every reacting node, or
may set different rates for different reacting node. may set different rates for different reacting nodes.
The maximum rate determined by the reporting node for a reacting node The maximum rate determined by the reporting node for a reacting node
applies to the entire stream of Diameter requests, even though applies to the entire stream of Diameter requests, even though
abatement may only affect a particular subset of the requests, since abatement may only affect a particular subset of the requests, since
the reacting node might apply priority as part of its decision of the reacting node might apply priority as part of its decision of
which requests to abate. which requests to abate.
When setting the maximum rate for a particular reacting node, the When setting the maximum rate for a particular reacting node, the
reporting node may need take into account the workload (e.g. CPU reporting node may need to take into account the workload (e.g., CPU
load per request) of the distribution of message types from that load per request) of the distribution of message types from that
reacting node. Furthermore, because the reacting node may prioritize reacting node. Furthermore, because the reacting node may prioritize
the specific types of messages it sends while under overload the specific types of messages it sends while under overload
restriction, this distribution of message types may be different from restriction, this distribution of message types may be different from
the message distribution for that reacting node under non-overload the message distribution for that reacting node under non-overload
conditions (e.g., either higher or lower CPU load). conditions (e.g., either higher or lower CPU load).
Note that the value of OC-Maximum-Rate AVP (in request messages per 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 second) for the rate algorithm provides a loose upper bound on the
traffic sent by the reacting node to the reporting node. traffic sent by the reacting node to the reporting node.
In other words, when multiple reacting nodes are being controlled by In other words, when multiple reacting nodes are being controlled by
an overloaded reporting node, at any given time, some reporting nodes an overloaded reporting node, at any given time, some reporting nodes
may receive requests at a rate below its target maximum Diameter may receive requests at a rate below its target maximum Diameter
request rate while others above that target rate. But the resulting request rate while receiving others above that target rate. But, the
request rate presented to the overloaded reporting node will converge resulting request rate presented to the overloaded reporting node
towards the target Diameter request rate or a lower rate. will converge towards the target Diameter request rate or a lower
rate.
Upon detection of overload, and the determination to invoke overload Upon detection of overload, and the determination to invoke overload
controls, the reporting node follows the specifications in [RFC7683] controls, the reporting node follows the specifications in [RFC7683]
to notify its clients of the allocated target maximum Diameter to notify its reacting nodes of the allocated target maximum Diameter
request rate and to notify them that the rate overload abatement is request rate, and to notify them that the rate abatement is in
in effect. effect.
The reporting node uses the OC-Maximum-Rate AVP defined in this The reporting node uses the OC-Maximum-Rate AVP defined in this
specification to communicate a target maximum Diameter request rate specification to communicate a target maximum Diameter request rate
to each of its clients. to each of its clients.
7.3. Reacting Node Behavior 8.3. Reacting-Node Behavior
7.3.1. Default Algorithm for Rate-based Control 8.3.1. Default Algorithm for Rate-Based Control
A reference algorithm is shown below. A reference algorithm is shown below.
Note that use of // below inidcates a comment. Note that use of "//" below indicates a comment.
No priority case: No priority case:
// T: inter-transmission interval, set to 1 / OC-Maximum-Rate // T: inter-transmission interval, set to 1 / OC-Maximum-Rate
// TAU: tolerance parameter // TAU: tolerance parameter
// ta: arrival time of the most recent arrival // ta: arrival time of the most recent arrival
// LCT: arrival time of last Diameter request that // LCT: arrival time of last Diameter request that
// was sent to the server // was sent to the server
// (initialized to the first arrival time) // (initialized to the first arrival time)
// X: current value of the leaky bucket counter (initialized to // X: current value of the leaky bucket counter (initialized to
skipping to change at page 13, line 32 skipping to change at page 13, line 42
} else { } else {
// Reject Diameter request // Reject Diameter request
// Do not update X and LCT // Do not update X and LCT
} }
In determining whether or not to transmit a specific message, the In determining whether or not to transmit a specific message, the
reacting node can use any algorithm that limits the message rate to 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 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 ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target
inter-Diameter request interval. It may be strictly deterministic, inter-Diameter request interval. It may be strictly deterministic,
or it may be probabilistic. It may, or may not, have a tolerance 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 factor, to allow for short bursts, as long as the long-term rate
remains below 1/T. remains below 1/T.
The algorithm may have provisions for prioritizing traffic. The algorithm may have provisions for prioritizing traffic.
If the algorithm requires other parameters (in addition to "T", which If the algorithm requires other parameters (in addition to "T", which
is 1/OC-Maximum-Rate), they may be set autonomously by the reacting is 1/OC-Maximum-Rate), they may be set autonomously by the reacting
node, or they may be negotiated independently between reacting node node, or they may be negotiated independently between the reacting
and reporting node. node and the reporting node.
In either case, the coordination is out of scope for this document. In either case, the coordination is out of the scope of this
The default algorithms presented here (one with and one without document. The default algorithms presented here (one with and one
provisions for prioritizing traffic) are only examples. without provisions for prioritizing traffic) are only examples.
To apply abatement treatment to new Diameter requests at the rate To apply abatement treatment to new Diameter requests at the rate
specified in the OC-Maximum-Rate AVP value sent by the reporting node 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 to its reacting nodes, the reacting node MAY use the proposed default
algorithm for rate-based control or any other equivalent algorithm algorithm for rate-based control or any other equivalent algorithm
that forward messages in conformance with the upper bound of 1/T that forward messages in conformance with the upper bound of 1/T
messages per second. messages per second.
The default Leaky Bucket algorithm presented here is based on [ITU-T The default leaky bucket algorithm presented here is based on
Rec. I.371] Appendix A.2. The algorithm makes it possible for 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 reacting nodes to deliver Diameter requests at a rate specified in
the OC-Maximum-Rate value with tolerance parameter TAU (preferably the OC-Maximum-Rate value with tolerance parameter TAU (preferably
configurable). configurable).
Conceptually, the Leaky Bucket algorithm can be viewed as a finite Conceptually, the leaky bucket algorithm can be viewed as a finite
capacity bucket whose real-valued content drains out at a continuous capacity bucket whose real-valued content drains out at a continuous
rate of 1 unit of content per time unit and whose content increases rate of 1 unit of content per time unit and whose content increases
by the increment T for each forwarded Diameter request. T is by the increment T for each forwarded Diameter request. T is
computed as the inverse of the rate specified in the OC-Maximum-Rate computed as the inverse of the rate specified in the OC-Maximum-Rate
AVP value, namely T = 1 / 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- Note that when the OC-Maximum-Rate value is 0 with a non-zero
Validity-Duration, then the reacting node should apply abatement OC-Validity-Duration, then the reacting node should apply abatement
treatment to 100% of Diameter requests destined to the overloaded treatment to 100% of Diameter requests destined to the overloaded
reporting node. However, when the OC-Validity-Duration value is 0, reporting node. However, when the OC-Validity-Duration value is 0,
the reacting node should stop applying abatement treatment. the reacting node should stop applying abatement treatment.
If, at a new Diameter request arrival, the content of the bucket is 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 less than or equal to the limit value TAU, then the Diameter request
is forwarded to the server; otherwise, the abatement treatment is is forwarded to the server; otherwise, the abatement treatment is
applied to the Diameter request. applied to the Diameter request.
Note that the capacity of the bucket (the upper bound of the counter) Note that the capacity of the bucket (the upper bound of the counter)
is (T + TAU). is (T + TAU).
The tolerance parameter TAU determines how close the long-term The tolerance parameter TAU determines how close the long-term
admitted rate is to an ideal control that would admit all Diameter 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 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. 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 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 tolerance to deviation of the inter-arrival time from T. (The larger
TAU the more tolerance to deviations from the inter-departure TAU, the more tolerance to deviations from the inter-departure
interval T). interval T.)
This deviation from the inter-departure interval influences the This deviation from the inter-departure interval influences the
admitted rate burstyness, or the number of consecutive Diameter admitted rate burstiness or the number of consecutive Diameter
requests forwarded to the reporting node (burst size proportional to requests forwarded to the reporting node (burst size proportional to
TAU over the difference between 1/T and the arrival rate). TAU over the difference between 1/T and the arrival rate).
In situations where reacting nodes are configured with some knowledge In situations where reacting nodes are configured with some knowledge
about the reporting node and other traffic sources (e.g., operator about the reporting node and other traffic sources (e.g., operator
pre-provisioning), it can be beneficial to choose a value of TAU pre-provisioning), it can be beneficial to choose a value of TAU
based on how many reacting nodes will be sending requests to the based on how many reacting nodes will be sending requests to the
reporting node. reporting node.
Reporting nodes with a very large number of reacting nodes, each with Reporting nodes with a very large number of reacting nodes, each with
a relatively small arrival rate, will generally benefit from a a relatively small arrival rate, will generally benefit from a
smaller value for TAU in order to limit queuing (and hence response smaller value for TAU in order to limit queuing (and hence response
times) at the reporting node when subjected to a sudden surge of times) at the reporting node when subjected to a sudden surge of
traffic from all reacting nodes. Conversely, a reporting node with a traffic from all reacting nodes. Conversely, a reporting node with a
relatively small number of reacting nodes, each with proportionally relatively small number of reacting nodes, each with a proportionally
larger arrival rate, will benefit from a larger value of TAU. 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 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 new Diameter request, ta(k), the content of the bucket is
provisionally updated to the value provisionally updated to the value
X' = X - (ta(k) - LCT) X' = X - (ta(k) - LCT)
where X is the value of the leaky bucket counter after arrival of the 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 forwarded Diameter request, and LCT is the time at which the
last Diameter request was forwarded. last Diameter request was forwarded.
If X' is less than or equal to the limit value TAU, then the new 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 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 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 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 TAU, then the abatement treatment is applied to the new Diameter
request and the values of X and LCT are unchanged. request, and the values of X and LCT are unchanged.
When the first response from the reporting node has been received When the first response from the reporting node has been received,
indicating control activation (OC-Validity-Duration>0), LCT is set to indicating control activation (OC-Validity-Duration>0), LCT is set to
the time of activation, and the leaky bucket counter is initialized the time of activation, and the leaky bucket counter is initialized
to the parameter TAU0 (preferably configurable) which is 0 or larger to the parameter TAU0 (preferably configurable), which is 0 or larger
but less than or equal to TAU. but less than or equal to TAU.
TAU can assume any positive real number value and is not necessarily TAU can assume any positive real number value and is not necessarily
bounded by T. bounded by T.
TAU=4*T is a reasonable compromise between burst size and abatement TAU=4*T is a reasonable compromise between burst size and abatement
rate adaptation at low offered rate. rate adaptation at low offered rate.
Note that specification of a value for TAU, and any communication or Note that specification of a value for TAU, and any communication or
coordination between servers, is beyond the scope of this document. coordination between servers, is beyond the scope of this document.
7.3.2. Priority Treatment 8.3.2. Priority Treatment
A reference algorithm is shown below. A reference algorithm is shown below.
Priority case: Priority case:
// T: inter-transmission interval, set to 1 / OC-Maximum-Rate // T: inter-transmission interval, set to 1 / OC-Maximum-Rate
// TAU1: tolerance parameter of no priority Diameter requests // TAU1: tolerance parameter of no priority Diameter requests
// TAU2: tolerance parameter of priority Diameter requests // TAU2: tolerance parameter of priority Diameter requests
// ta: arrival time of the most recent arrival // ta: arrival time of the most recent arrival
// LCT: arrival time of last Diameter request that // LCT: arrival time of last Diameter request that
skipping to change at page 16, line 30 skipping to change at page 16, line 39
// Transmit Diameter request // Transmit Diameter request
// Update X and LCT // Update X and LCT
X = max (0, Xp) + T; X = max (0, Xp) + T;
LCT = ta; LCT = ta;
} else { } else {
// Apply abatement treatment to Diameter request // Apply abatement treatment to Diameter request
// Do not update X and LCT // Do not update X and LCT
} }
The reacting node is responsible for applying message priority and The reacting node is responsible for applying message priority and
for maintaining two categories of requests: Request candidates for for maintaining two categories of requests: request candidates for
reduction, requests not subject to reduction (except under reduction, and requests not subject to reduction (except under
extenuating circumstances when there aren't any messages in the first extenuating circumstances when there aren't any messages in the first
category that can be reduced). category that can be reduced).
Accordingly, the proposed Leaky bucket implementation is modified to Accordingly, the proposed leaky bucket implementation is modified to
support priority using two thresholds for Diameter requests in the support priority using two thresholds for Diameter requests in the
set of request candidates for reduction. With two priorities, the set of request candidates for reduction. With two priorities, the
proposed Leaky bucket requires two thresholds TAU1 < TAU2: proposed leaky bucket requires two thresholds TAU1 < TAU2:
o All new requests would be admitted when the leaky bucket counter o All new requests would be admitted when the leaky bucket counter
is at or below TAU1, is at or below TAU1.
o Only higher priority requests would be admitted when the leaky o Only higher priority requests would be admitted when the leaky
bucket counter is between TAU1 and TAU2, bucket counter is between TAU1 and TAU2.
o All requests would be rejected when the bucket counter is above o All requests would be rejected when the bucket counter is above
TAU2. TAU2.
This can be generalized to n priorities using n thresholds for n>2. This can be generalized to n priorities using n thresholds for n>2.
With a priority scheme that relies on two tolerance parameters (TAU2 With a priority scheme that relies on two tolerance parameters (TAU2
influences the priority traffic, TAU1 influences the non-priority influences the priority traffic, and TAU1 influences the non-priority
traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2). traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2).
Setting both tolerance parameters to the same value is equivalent to Setting both tolerance parameters to the same value is equivalent to
having no priority. TAU1 influences the admitted rate the same way having no priority. TAU1 influences the admitted rate the same way
as TAU does when no priority is set. And the larger the difference 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 between TAU1 and TAU2, the closer the control is to strict priority
queuing. queuing.
TAU1 and TAU2 can assume any positive real number value and is not TAU1 and TAU2 can assume any positive real number value and is not
necessarily bounded by T. necessarily bounded by T.
Reasonable values for TAU0, TAU1 & TAU2 are: Reasonable values for TAU0, TAU1, and TAU2 are:
o TAU0 = 0, o TAU0 = 0,
o TAU1 = 1/2 * TAU2, and o TAU1 = 1/2 * TAU2, and
o TAU2 = 10 * T. o TAU2 = 10 * T.
Note that specification of a value for TAU1 and TAU2, and any Note that specification of a value for TAU1 and TAU2, and any
communication or coordination between servers, is beyond the scope of communication or coordination between servers, is beyond the scope of
this document. this document.
7.3.3. Optional Enhancement: Avoidance of Resonance 8.3.3. Optional Enhancement: Avoidance of Resonance
As the number of reacting node sources of traffic increases and the As the number of reacting-node sources of traffic increases and the
throughput of the reporting node decreases, the maximum rate admitted throughput of the reporting node decreases, the maximum rate admitted
by each reacting node needs to decrease, and therefore the value of T by each reacting node needs to decrease, and therefore the value of T
becomes larger. Under some circumstances, e.g. if the traffic arises becomes larger. Under some circumstances, e.g., if the traffic
very quickly simultaneously at many sources, the occupancies of each arises very quickly simultaneously at many sources, the occupancies
bucket can become synchronized, resulting in the admissions from each of each bucket can become synchronized, resulting in both the
source being close in time and batched or very 'peaky' arrivals at admissions from each source being close in time and batched, or very
the reporting node, which not only gives rise to control instability, "peaky" arrivals at the reporting node. This gives rise not only to
but also very poor delays and even lost messages. An appropriate control instability, but also very poor delays and even lost
term for this is 'resonance' [Erramilli]. messages. An appropriate term for this is "resonance" [Erramilli].
If the network topology is such that resonance can occur, then a If the network topology is such that resonance can occur, then a
simple way to avoid resonance is to randomize the bucket occupancy at simple way to avoid resonance is to randomize the bucket occupancy at
two appropriate points -- at the activation of control and whenever two appropriate points: at the activation of control, and whenever
the bucket empties -- as described below. the bucket empties, as described below:
After updating the value of the leaky bucket to X', generate a value After updating the value of the leaky bucket to X', generate a value
u as follows: u as follows:
if X' > 0, then u=0 if X' > 0, then u=0
else if X' <= 0, then let u be set to a random value uniformly else, if X' <= 0, then let u be set to a random value uniformly
distributed between -1/2 and +1/2 distributed between -1/2 and +1/2
Then (only) if the arrival is admitted, increase the bucket content
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 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. hadn't emptied, or lie between T/2 and 3T/2 if it had.
This randomization should also be done when control is activated, This randomization should also be done when control is activated,
i.e. instead of simply initializing the leaky bucket counter to TAU0, i.e., instead of simply initializing the leaky bucket counter to
initialize it to TAU0 + uT, where u is uniformly distributed as TAU0, initialize it to TAU0 + uT, where u is uniformly distributed as
above. Since activation would have been a result of response to a above. Since activation would have been a result of the response to
request sent by the reacting node, the second term in this expression a request sent by the reacting node, the second term in this
can be interpreted as being the bucket increment following that expression can be interpreted as being the bucket increment following
admission. that admission.
This method has the following characteristics: This method has the following characteristics:
o If TAU0 is chosen to be equal to TAU and all sources activate 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, control at the same time due to an extremely high request rate,
then the time until the first request admitted by each reacting then the time until the first request admitted by each reacting
node would be uniformly distributed over [0,T]; node would be uniformly distributed over [0,T];
o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without
randomization; randomization;
o For the special case of 'classic gapping' where TAU=0, then the o For the special case of "classic gapping", where TAU=0, then the
minimum time between admissions is uniformly distributed over minimum time between admissions is uniformly distributed over
[T/2, 3T/2], and the mean time between admissions is the same, [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. i.e., T+1/R where R is the request arrival rate.
o At high load randomization rarely occurs, so there is no loss of
precision of the admitted rate, even though the randomized
'phasing' of the buckets remains.
8. IANA Consideration
8.1. AVP Codes
New AVPs defined by this specification are listed in Section 6. All o At high load, randomization rarely occurs. Therefore, there is no
AVP codes are allocated from the 'Authentication, Authorization, and loss of precision of the admitted rate, even though the randomized
Accounting (AAA) Parameters' AVP Codes registry. "phasing" of the buckets remains.
8.2. OC-Supported-Features 9. IANA Considerations
As indicated in Section 6.1.1, a new allocation is required in the IANA has registered the following values in the "Authentication,
OC-Feature-Vector AVP. Authorization, and Accounting (AAA) Parameters" registry:
8.3. New DOIC report types One new AVP code is defined in Section 7.2.1.
All DOIC report types defined in the future MUST indicate whether or One new OC-Feature-Vector AVP value is defined in Section 7.1.1.
not the rate algorithm can be used with that report type.
9. Security Considerations 9.1. OC-Supported-Features
The rate overload abatement mechanism is an extension to the base As indicated in Section 7.1.1, a new allocation has been made for the
Diameter overload mechanism. As such, all of the security OC-Feature-Vector AVP.
considerations outlined in [RFC7683] apply to the rate overload
abatement mechanism.
In addition, the rate algorithm could be used to handle DoS attacks 10. Security Considerations
more effectively than the loss algorithm.
10. Acknowledgements 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.
Lionel Morand for his contributions to the document. In addition, the rate algorithm could be used to handle denial-of-
service (DoS) attacks more effectively than the loss algorithm.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-dime-agent-overload]
Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
agent-overload-00 (work in progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance", Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015, RFC 7683, DOI 10.17487/RFC7683, October 2015,
<https://www.rfc-editor.org/info/rfc7683>. <https://www.rfc-editor.org/info/rfc7683>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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 11.2. Informative References
[Erramilli] [Erramilli]
Erramilli, A. and L. Forys, "Traffic Synchronization Erramilli, A. and L. Forys, "Traffic Synchronization
Effects In Teletraffic Systems", 1991. 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 [RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol
(SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415, (SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415,
February 2015, <https://www.rfc-editor.org/info/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 Authors' Addresses
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
7460 Warren Pkwy # 300 7460 Warren Parkway, Suite 300
Frisco, Texas 75034 Frisco, Texas 75034
United States United States of America
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
Eric Noel Eric Noel
AT&T Labs AT&T Labs
200s Laurel Avenue 200s Laurel Avenue
Middletown, NJ 07747 Middletown, NJ 07747
United States United States of America
Email: ecnoel@research.att.com Email: ecnoel@research.att.com
 End of changes. 141 change blocks. 
310 lines changed or deleted 310 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/