draft-ietf-dime-doic-rate-control-00.txt   draft-ietf-dime-doic-rate-control-01.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track E. Noel Intended status: Standards Track E. Noel
Expires: June 20, 2015 AT&T Labs Expires: September 7, 2015 AT&T Labs
December 17, 2014 March 6, 2015
Diameter Overload Rate Control Diameter Overload Rate Control
draft-ietf-dime-doic-rate-control-00.txt draft-ietf-dime-doic-rate-control-01.txt
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) base solution. This extension adds a Indication Conveyance (DOIC) base solution. This extension adds a
new overload control abatement algorithm. This abatement algorithm new overload control abatement algorithm. This abatement algorithm
allows for a DOIC reporting node to specify a maximum rate at which a allows for a DOIC reporting node to specify a maximum rate at which a
DOIC reacting node sends Diameter requests sent to the DOIC reporting DOIC reacting node sends Diameter requests to the DOIC reporting
node. node.
Requirements Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 20, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Interaction with DOIC report types . . . . . . . . . . . . . 4 3. Interaction with DOIC report types . . . . . . . . . . . . . 5
4. Capability Announcement . . . . . . . . . . . . . . . . . . . 5 4. Capability Announcement . . . . . . . . . . . . . . . . . . . 5
5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6 5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6
5.1. Reporting Node Overload Control State . . . . . . . . . . 6 5.1. Reporting Node Overload Control State . . . . . . . . . . 6
5.2. Reacting Node Overload Control State . . . . . . . . . . 7 5.2. Reacting Node Overload Control State . . . . . . . . . . 7
5.3. Reporting Node Maintenance of Overload Control State . . 7 5.3. Reporting Node Maintenance of Overload Control State . . 7
5.4. Reacting Node Maintenance of Overload Control State . . . 7 5.4. Reacting Node Maintenance of Overload Control State . . . 7
5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8 5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8
5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 8 5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 8
6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 8 6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 8
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 8 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9
6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. OC-Rate AVP . . . . . . . . . . . . . . . . . . . . . 9 6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10
6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 10 6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 10
7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 10 7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 10
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11
7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12
7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 12 7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 12
7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 14 7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 15
7.3.3. Optional enhancement: avoidance of resonance . . . . 16 7.3.3. Optional enhancement: avoidance of resonance . . . . 17
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines a new Diameter overload control algorithm. This document defines a new Diameter overload control abatement
algorithm.
The base Diameter overload specification [I-D.ietf-dime-ovli] defines The base Diameter overload specification [I-D.ietf-dime-ovli] defines
the loss algorithm as the default Diameter overload abatement the loss algorithm as the default Diameter overload abatement
algorithm. The loss algorithm allows a reporting node to instruct a algorithm. The loss algorithm allows a reporting node to instruct a
reacting node to reduce the amount of traffic sent to the reporting reacting node to reduce the amount of traffic sent to the reporting
node by throttling a percentage of requests sent to the server. node by abating (diverting or throttling) a percentage of requests
While this can effectively decrease the load handled by the server, sent to the server. While this can effectively decrease the load
it does not directly address cases where the rate of arrival of handled by the server, it does not directly address cases where the
service requests increase quickly. If the service requests that rate of arrival of service requests increase quickly. If the service
result in Diameter transactions increases quickly then the loss requests that result in Diameter transactions increases quickly then
algorithm can be slow to protect the stability of reporting nodes. the loss algorithm cannot guarantee the load presented to the server
remains below a specific rate level. The loss algorithm can be slow
to protect the stability of reporting nodes when subject with rapidly
changing loads.
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 reacting node. If the one Diameter transaction being sent to a reacting node. If the
reacting node is approaching an overload state, or is already in an reacting 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. Assume for this discussion percentage reduction in traffic sent. Assume for this discussion
that the reporting node requests a 10% reduction. The reacting node that the reporting node requests a 10% reduction. The reacting node
will then throttle ten Diameter transactions a second, sending the will then abate (diverting or throttling) ten Diameter transactions a
remaining 90 transactions per second to the reacting node. second, sending the remaining 90 transactions per second to the
reacting node.
Now assume that the reacting node's service requests spikes to 1000 Now assume that the reacting node's service requests spikes 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 nodes request to throttle 10% of the traffic. This reporting nodes 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, throttling the remaining 100 transactions transactions per second, abating the remaining 100 transactions per
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 throttle 91% of requests to report requesting that the reacting node abate 91% of requests to get
get back to the desired 90 transactions per second. However, once back to the desired 90 transactions per second. However, once the
the spike has abated and the reacting node handled service requests spike has abated and the reacting node handled service requests
returns to 100 per second, this will result in just 9 transactions returns to 100 per second, this will result in just 9 transactions
per second being sent to the reporting node, requiring a new overload per second being sent to the reporting node, requiring a new overload
report setting the reduction percentage back to 10%. report setting the reduction percentage back to 10%. This control
feedback loop has the potential to make the situation worse.
One of the benefits of a rate based algorithm is that it better One of the benefits of a rate based algorithm is that it better
handles spikes in traffic. Instead of sending a request to throttle handles spikes in traffic. Instead of sending a request to reduce
a percentage of the traffic, the rate approach allows the reporting traffic by a percentage, the rate approach allows the reporting node
node to specify the maximum number of Diameter requests per second to specify the maximum number of Diameter requests per second that
that can be sent to the reporting node. For instance, in this can be sent to the reporting node. For instance, in this example,
example, the reporting node could send a rate based request the reporting node could send a rate based request specifying the
specifying the maximum transactions per second to be 90. The maximum transactions per second to be 90. The reacting node will
reacting noce will send the 90 regardless of whether it is receiving send the 90 regardless of whether it is receiving 100 or 1000 service
100 or 1000 service requests per second. requests per second.
This document extends the base DOIC solution [I-D.ietf-dime-ovli] to This document extends the base DOIC solution [I-D.ietf-dime-ovli] to
add support for the rate based overload abatement algorithm. add support for the rate based overload abatement algorithm.
This document draws heavily on work in the RIA SIP Overload Control This document draws heavily on work in the RIA SIP Overload Control
working group. The definitions of the rate abatement algorithmm is working group. The definition of the rate abatement algorithm is
copied almost verbatim from the SOC document copied almost verbatim from the SOC document [RFC7415], with changes
[I-D.SOC-overload-rate-control], with changes focused on making the focused on making the wording consistent with the DOIC solution and
wording consistent with the DOIC solution and the Diameter protocol. the Diameter protocol.
Editor's Note: Need to verify that the latest text from the SOC Editor's Note: Need to verify that the latest text from the SOC
document is currently being used. document is currently being used.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diameter Node Diameter Node
A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733
Diameter Agent. Diameter Agent.
Diameter Endpoint Diameter Endpoint
An RFC6733 Diameter Client and RFC6733 Diameter Server. An RFC6733 Diameter Client or RFC6733 Diameter Server.
DOIC Node DOIC Node
A Diameter Node that supports the DOIC solution defined in A Diameter Node that supports the DOIC solution defined in
[I-D.ietf-dime-ovli]. [I-D.ietf-dime-ovli].
Reporting Node Reporting Node
A DOIC Node that sends a DOIC overload report. A DOIC Node that sends a DOIC overload report.
skipping to change at page 5, line 5 skipping to change at page 5, line 13
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 3. Interaction with DOIC report types
As of the publication of this specification there are two DOIC report As of the publication of this specification there are two DOIC report
types defined with the specification of a third in progress: types defined with the specification of a third in progress:
1. Host - Overload of a specific Diameter Application at a specific 1. Host - Overload of a specific Diameter Application at a specific
Diameter Node as defined in [I-D.ietf-dime-ovli]. Diameter Node as defined in [I-D.ietf-dime-ovli].
2. Realm - Overlaod of a specific Diameter Application at a specific 2. Realm - Overload of a specific Diameter Application at a specific
Diameter Realm as defined in [I-D.ietf-dime-ovli]. Diameter Realm as defined in [I-D.ietf-dime-ovli].
3. Peer - Overload of a specific Diameter peer as defined in 3. Peer - Overload of a specific Diameter peer as defined in
[I-D.donovan-agent-overload]. [I-D.ietf-dime-agent-overload].
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.
Editor's note: It needs to be validated that use of the rate
algorithm applies to the host and realm 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 4. Capability Announcement
Editors Note: This section depends upon the completion of the base
Diameter Overload specification. As such, it cannot be complete
until the data model and extension mechanism are finalized in the
base DOC specification. Details for any new AVPs or modifications to
existing AVPs will be finalized in a future version of the draft
after the base DOC specification has stabilized.
This extension defines the rate abatement algorithm (referred to as This extension defines the rate abatement algorithm (referred to as
rate in this document) feature. Support for the rate feature will be rate in this document) feature. Support for the rate feature will be
reflected by use of a new value, as defined in Section 6.1.1, in the reflected by use of a new value, as defined in Section 6.1.1, in the
OC-Feature-Vector AVP per the rules defined in [I-D.ietf-dime-ovli]. OC-Feature-Vector AVP per the rules defined in [I-D.ietf-dime-ovli].
Note that Diameter nodes that support the rate feature will, by Note that Diameter nodes that support the rate feature will, by
definition, support both the loss and rate based abatement definition, support both the loss and rate based abatement
algorithms. DOIC reacting nodes SHOULD indicate support for both the algorithms. DOIC reacting nodes SHOULD indicate support for both the
loss and rate algorithms in the OC-Feature-Vector AVP. loss and rate algorithms in the OC-Feature-Vector AVP.
There may be local policy reasons that cause a DOIC node that There may be local policy reasons that cause a DOIC node that
supports the rate to not include it in the OC-Feature-Vector. All supports the rate abatement algorithm to not include it in the OC-
reacting nodes, however, must continue to include loss in the OC- Feature-Vector. All reacting nodes, however, must continue to
Feature-Vector in order to remain compliant with include loss in the OC-Feature-Vector in order to remain compliant
[I-D.ietf-dime-ovli]. with [I-D.ietf-dime-ovli].
A reporting nodes MUST select either the rate or the loss algorithm
when receiving a request that contains an OC-Supported-Features AVP.
A reporting node MAY select one abatement algorithm to apply to host A reporting node MAY 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 MUST be reflected in For host or realm reports the selected algorithm is reflected in
the OC-Feature-Vector AVP sent as part of the OC-Selected-Features the OC-Feature-Vector AVP sent as part of the OC-Selected-Features
AVP included in answer messages for transaction where the request AVP included in answer messages for transaction where the request
contained an OC-Supported-Features AVP. This is per the precedures contained an OC-Supported-Features AVP. This is per the
defined in [I-D.ietf-dime-ovli]. procedures defined in [I-D.ietf-dime-ovli].
For peer reports the selected algorithm MUST be reflected in the OC- For peer reports the selected algorithm is reflected in the OC-
Peer-Abatement-Algorithm AVP sent as part of the OC-Supported- Peer-Algo AVP sent as part of the OC-Supported-Features AVP
Features AVP included answer messages for transaction where the included answer messages for transaction 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 defined in [I-D.donovan-agent-overload]. procedures defined in [I-D.ietf-dime-agent-overload].
Editor's Node: The peer report specification is still under Editor's Node: The peer report specification is still under
development and, as such, the above paragraph is subject to development and, as such, the above paragraph is subject to
change. change.
5. Overload Report Handling 5. Overload Report Handling
This section describes any changes to the behavior defined in This section describes any changes to the behavior defined in
[I-D.ietf-dime-ovli] for handling of overload reports when the rate [I-D.ietf-dime-ovli] for handling of overload reports when the rate
overload abatement algorithm is used. overload abatement algorithm is used.
5.1. Reporting Node Overload Control State 5.1. Reporting Node Overload Control State
A reporting node that uses the rate abatement algorithm SHOULD A reporting node that uses the rate abatement algorithm SHOULD
maintain reporting node OCS for each reacting node to which it sends maintain reporting node OCS for each reacting node to which it sends
a rate OLR. a rate OLR.
This is different from the behavior defines in [DOIC] where there This is different from the behavior defines in
is a single loss percentage sent to all reacting nodes. [I-D.ietf-dime-ovli] where a single loss percentage sent to all
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, A rate OCS entry is identified by the tuple of Application-Id,
report-type and peer-id of the target of the rate OLR. report-type and DiameterID of the target of the rate OLR.
A reporting node that supports the rate abatement algorithm MUST be
able to include rate as the selected abatement algorithm in the
reporting node OCS.
A reporting node that supports the rate abatement algorithm MUST be A reporting node that supports the rate abatement algorithm MUST be
able to include the specified rate in the abatement algoritm specific able to include the specified rate in the abatement algorithm
portion of the reporting node OCS. specific portion of the reporting node rate OCS.
All other elements for the OCS defined in [I-D.ietf-dime-ovli] and All other elements for the OCS defined in [I-D.ietf-dime-ovli] and
[I-D.donovan-agent-overload] also apply to the reporting nodes OCS [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
when using the rate abatement algorithm. when using the rate abatement algorithm.
5.2. Reacting Node Overload Control State 5.2. Reacting Node Overload Control State
A reacting node that supports the rate abatement algorithm MUST be A reacting node that supports the rate abatement algorithm MUST be
able to include rate as the selected abatement algorithm in the able to include rate as the selected abatement algorithm in the
reacting node OCS. reacting node OCS.
A reacting node that supports the rate abatement algorithm MUST be A reacting node that supports the rate abatement algorithm MUST be
able to include the rate specified in the OC-Rate AVP included in the able to include the rate specified in the OC-Maximum-Rate AVP
OC-OLR AVP as an element of the abatement algoritm specific portion included in the OC-OLR AVP as an element of the abatement algorithm
of reacting node OCS entries. specific portion of reacting node OCS entries.
All other elements for the OCS defined in [I-D.ietf-dime-ovli] and All other elements for the OCS defined in [I-D.ietf-dime-ovli] and
[I-D.donovan-agent-overload] also apply to the reporting nodes OCS [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
when using the rate abatement algorithm. when using the rate abatement algorithm.
5.3. Reporting Node Maintenance of Overload Control State 5.3. Reporting Node Maintenance of Overload Control State
A reporting node that has selected the rate overload abatement A reporting node that has selected the rate overload abatement
algorithm and enters an overload condition MUST indicate rate as the algorithm and enters an overload condition MUST indicate rate as the
abatement algorithm in the resulting reporting node OCS entries. abatement algorithm in the resulting reporting node OCS entries.
A reporting node that has selected the rate abatement algorithm and A reporting node that has selected the rate abatement algorithm and
enters an overload condition MUST indicate the selected rate in the enters an overload condition MUST indicate the selected rate in the
resulting reporting node OCS entries. resulting reporting node OCS entries.
When responding to a request that contained an OC-Supporting-Features When selecting the rate algorithm in the response to a request that
AVP with an OC-Feature-Vector AVP indicating support for the rate contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP
feature, a reporting node MUST ensure that a reporting node OCS entry indicating support for the rate feature, a reporting node MUST ensure
exists for the target of the overload report. The target is defined that a reporting node OCS entry exists for the target of the overload
as follows: report. The target is defined as follows:
o For Host reports the target is the DiameterID contained in the o For Host reports the target is the DiameterID contained in the
Origin-Host AVP received in the request. Origin-Host AVP received in the request.
o For Realm reports the target is the DiameterID contained in the o For Realm reports the target is the DiameterID contained in the
Origin-Realm AVP received in the request. Origin-Realm AVP received in the request.
o For Peer reports the target is the Diameter ID of the Diameter o For Peer reports the target is the DiameterID of the Diameter Peer
Peer from which the request was received. from which the request was received.
5.4. Reacting Node Maintenance of Overload Control State 5.4. Reacting Node Maintenance of Overload Control State
When receiving an answer message indicating that the reacting node
has selected the rate algorithm, a reaction 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 A reacting node receiving an overload report for the rate abatement
algorithm MUST save the rate received in the OC-Rate AVP contained in algorithm MUST save the rate received in the OC-Maximum-Rate AVP
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 5.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 OC-
Supported-Features AVP that indicated support for the rate featre, a Supported-Features AVP that indicated support for the rate abatement
reporting node SHOULD include an OC-OLR AVP for the rate algorithm algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate
using the parameters stored in the reporting node OCS for the target algorithm using the parameters stored in the reporting node OCS for
of the overload report. the target of the overload report.
Editor's Note: The above is a pretty complicated way of saying Editor's Note: The above is a pretty complicated way of saying
that the reporting node should include an OC-OLR in the that the reporting node should include an OC-OLR in the
appropriate answer messages. The basic requirement isn't rate appropriate answer messages. The basic requirement isn't rate
feature specific but rather that in all cases the reporting node feature specific but rather that in all cases the reporting node
generates an OC-OLR according to the parameters of the appropriate generates an OC-OLR according to the parameters of the appropriate
OCS entry. This wording probably can be improved based on the OCS entry. This wording probably can be improved based on the
generic behavior definition. generic behavior definition.
When sending an overload report for the Rate algorithm, the OC-Rate When sending an overload report for the Rate algorithm, the OC-
AVP is included and the OC-Reduction-Percentage AVP is not included. Maximum-Rate AVP is included and the OC-Reduction-Percentage AVP is
not included.
5.6. Reacting Node Behavior for Rate Abatement Algorithm 5.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 MUST use the the overload abatement algorithm, the reacting node MAY use the algorithm
algorithm detailed in Section 6 to make the determination. detailed in Section 6.
Note: Other algorithms for controlling the rate can be implemented
by the reacting node as long as they result in the correct 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 procedures for throttling and diversion defined in
[I-D.ietf-dime-ovli] and [I-D.donovan-agent-overload] apply. [I-D.ietf-dime-ovli] and [I-D.ietf-dime-agent-overload] apply.
6. Rate Abatement Algorithm AVPs 6. Rate Abatement Algorithm AVPs
Editors Note: This section depends upon the completion of the base Editors Note: This section depends upon the completion of the base
DOIC specification. As such, it cannot be complete until the data DOIC specification. As such, it cannot be complete until the data
model and extension mechanism are finalized. Details for any new model and extension mechanism are finalized. Details for any new
AVPs or modifications to existing AVPs will be finalized in a future AVPs or modifications to existing AVPs will be finalized in a future
version of the draft after the base DOC specification has stabilized. version of the draft after the base DOC specification has stabilized.
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
skipping to change at page 9, line 18 skipping to change at page 9, line 26
Vector AVP. Vector AVP.
OLR_RATE_ALGORITHM (0x0000000000000004) OLR_RATE_ALGORITHM (0x0000000000000004)
When this flag is set by the overload control endpoint it When this flag is set by the overload control endpoint it
indicates that the DOIC Node supports the rate overload control indicates that the DOIC Node supports the rate overload control
algorithm. algorithm.
6.2. OC-OLR AVP 6.2. OC-OLR AVP
This extension defines the OC-Rate AVP to be an optional part of the This extension defines the OC-Maximum-Rate AVP to be an optional part
OC-OLR AVP. of the OC-OLR AVP.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
[ OC-Source-ID ] [ OC-Source-ID ]
[ OC-Abatement-Algorithm ] [ OC-Abatement-Algorithm ]
[ OC-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 existing report types of host and realm defined in
[I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer [I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer
report time defined in [I-D.donovan-agent-overload] also applies to report type defined in [I-D.ietf-dime-agent-overload] also applies to
the rate control algorithm. the rate control algorithm.
6.2.1. OC-Rate AVP 6.2.1. OC-Maximum-Rate AVP
The OC-Rate AVP (AVP code TBD8) is type of Unsigned32 and describes The OC-Maximum-Rate AVP (AVP code TBD1) is type of Unsigned32 and
the maximum rate that that the sender is requested to send traffic. describes the maximum rate that that the sender is requested to send
This is specified in terms of requests per second. traffic. This is specified in terms of requests per second.
Editor's note: Do we need to specify a maximum value? Editor's note: Do we need to specify a maximum value?
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 6.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-Rate TBD1 x.x Unsigned64 | | V | |OC-Maximum-Rate TBD1 x.x Unsigned64 | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. Rate Based Abatement Algorithm 7. Rate Based Abatement Algorithm
Editor's Note: Need to scrub this section to use the reporting node This section is pulled from [RFC7415], with minor changes needed to
and reacting node terminology and remove the server and client terms make it apply to the Diameter protocol.
use for the SOC description.
This section is pulled from [I-D.SOC-overload-rate-control], with
minor changes needed to make it apply to the Diameter protocol.
7.1. Overview 7.1. Overview
The server is the one protected by the overload control algorithm The reporting node is the one protected by the overload control
defined here. This is also referred to as the reporting node. The algorithm defined here. The reacting node is the one that abates
client is the one that throttles traffic towards the server. This is traffic towards the server.
also referred to as the reacting node.
Following the procedures defined in [draft-ietf-dime-doic], the Following the procedures defined in [draft-ietf-dime-doic], the
server and clients signal one another support for rate-based overload reacting node and reporting node signal one another support for rate-
control. based overload control.
Editor's Note: Need to scrub this section to use the reporting node
and reacting node terminology and remove the server and client terms.
Then periodically, the server relies on internal measurements (e.g. Then periodically, the reporting node relies on internal measurements
CPU utilization, queueing delay...) to evaluate its overload state (e.g. CPU utilization or queuing delay) to evaluate its overload
and estimate a target Diameter request rate in number of requests per state and estimate a target maximum Diameter request rate in number
second (as opposed to target percent reduction in the case of loss- of requests per second (as opposed to target percent reduction in the
based abatement). 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 Diameter request Upon receiving the overload report with a target maximum Diameter
rate, each reacting node throttles new Diameter requests towards the request rate, each reacting node applies abatement treatment for new
reporting node. Diameter requests towards the reporting node.
7.2. Reporting Node Behavior 7.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 Diameter request rate is beyond overload state and estimate a target maximum Diameter request rate is
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 server must allocate a portion of the would become overloaded. The reporting node must allocate a portion
target Diameter request rate to each of its reacting nodes. The of the target Diameter request rate to each of its reacting nodes.
server may set the same rate for every reacting node, or may set The reporting node may set the same rate for every reacting node, or
different rates for different reacting node. may set different rates for different reacting node.
The max 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
throttling 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 can apply priority as part of its decision of the reacting node might apply priority as part of its decision of
which requests to throttle. 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 load reporting node may need take into account the workload (e.g. cpu load
per request) of the distribution of message types from that reacting per request) of the distribution of message types from that reacting
node. Furthermore, because the reacting node may prioritize the node. Furthermore, because the reacting node may prioritize the
specific types of messages it sends while under overload restriction, specific types of messages it sends while under overload restriction,
this distribution of message types may be different from the message this distribution of message types may be different from the message
distribution for that reacting node under non-overload conditions distribution for that reacting node under non-overload conditions
(e.g., either higher or lower cpu load). (e.g., either higher or lower cpu load).
Note that the AVP for the rate algorithm is an upper bound (in Note that the AVP for the rate algorithm is an upper bound (in
request messages per second) on the traffic sent by the reacting node request messages per second) on the traffic sent by the reacting node
to the reporting node. The reacting node may send traffic at a rate to the reporting node. The reacting node may send traffic at a rate
significantly lower than the upper bound, for a variety of reasons. significantly lower than the upper bound, for a variety of reasons.
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 reacting nodes an overloaded reporting node, at any given time some reacting nodes
may receive requests at a rate below its target Diameter request rate may receive requests at a rate below its target maximum Diameter
while others above that target rate. But the resulting request rate request rate while others above that target rate. But the resulting
presented to the overloaded reporting node will converge towards the request rate presented to the overloaded reporting node will converge
target Diameter request rate. towards the target Diameter request 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 MUST follow the specifications in controls, the reporting node MUST follow the specifications in
[draft-ietf-dime-ovli] to notify its clients of the allocated target [draft-ietf-dime-ovli] to notify its clients of the allocated target
Diameter request rate. maximum Diameter request rate and to notify them that the rate
overload abatement is in effect.
The reporting node MUST use the OC-Maximum-Rate AVP defined in this The reporting node MUST use the OC-Maximum-Rate AVP defined in this
specification to communicate a target Diameter request rate to each specification to communicate a target maximum Diameter request rate
of its clients. to each of its clients.
7.3. Reacting Node Behavior 7.3. Reacting Node Behavior
7.3.1. Default algorithm 7.3.1. Default algorithm
In determining whether or not to transmit a specific message, the In determining whether or not to transmit a specific message, the
reacting node may use any algorithm that limits the message rate to reacting node can use any algorithm that limits the message rate to
1/T messages per second. It may be strictly deterministic, or it may the OC-Maximum-Rate AVP value in units of messages per second. For
be probabilistic. It may, or may not, have a tolerance factor, to ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target
allow for short bursts, as long as the long term rate remains below inter-Diameter request interval. It may be strictly deterministic,
1/T. The algorithm may have provisions for prioritizing traffic. 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 If the algorithm requires other parameters (in addition to "T", which
is 1/OC-Maximum-Rate), they may be set autonomously by the client, or is 1/OC-Maximum-Rate), they may be set autonomously by the reacting
they may be negotiated independently between client and server. node, or they may be negotiated independently between reacting node
and reporting node.
In either case, the coordination is out of scope for this document. In either case, the coordination is out of scope for this document.
The default algorithms presented here (one without provisions for The default algorithms presented here (one with and one without
prioritizing traffic, one with) are only examples. Other algorithms provisions for prioritizing traffic) are only examples.
that forward messages in conformance with the upper bound of 1/T
messages per second may be used.
To throttle new Diameter requests at the rate specified in the OC- To apply abatement treatment to new Diameter requests at the rate
Maximum-Rate AVP value sent by the reporting node to its reacting specified in the OC-Maximum-Rate AVP value sent by the reporting node
nodes, the reacting node MAY use the proposed default algorithm for to its reacting nodes, the reacting node MAY use the proposed default
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
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 [ITU-T
Rec. I.371] Appendix A.2. The algorithm makes it possible for Rec. I.371] Appendix A.2. The algorithm makes it possible for
clients to deliver Diameter requests at a rate specified in the OC- reacting nodes to deliver Diameter requests at a rate specified in
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 OC-
Validity-Duration, then the reacting node should reject 100% of Validity-Duration, then the reacting node should apply abatement
Diameter requests destined to the overloaded reporting node. treatment to 100% of Diameter requests destined to the overloaded
However, when the OC-Validity-Duration value is 0, the client should reporting node. However, when the OC-Validity-Duration value is 0,
stop throttling. 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 Diameter request is is forwarded to the server; otherwise, the abatement treatment is
rejected. 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 burstyness, 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).
Reporting nodes with a very large number of clients, each with a In situations where reacting nodes are configured with some knowledge
relatively small arrival rate, will generally benefit from a smaller about the reporting node (e.g., operator pre-provisioning), it can be
value for TAU in order to limit queuing (and hence response times) at beneficial to choose a value of TAU based on how many reacting nodes
the reporting node when subjected to a sudden surge of traffic from will be sending requests to the reporting node.
all reacting nodes. Conversely, a reporting node with a relatively
small number of reacting nodes, each with proportionally larger Reporting nodes with a very large number of reacting nodes, each with
arrival rate, will benefit from a larger value of TAU. 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 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 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
skipping to change at page 13, line 49 skipping to change at page 14, line 14
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 new Diameter request is rejected and the values of X TAU, then the abatement treatment is applied to the new Diameter
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 throttled 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.
A reference algorithm is shown below. A reference algorithm is shown below.
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
skipping to change at page 15, line 29 skipping to change at page 16, line 9
This can be generalized to n priorities using n thresholds for n>2 in This can be generalized to n priorities using n thresholds for n>2 in
the obvious way. the obvious way.
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, 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
queueing. 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: TAU0 = 0, TAU1 = 1/2 * Reasonable values for TAU0, TAU1 & TAU2 are:
TAU2 and TAU2 = 10 * T.
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 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.
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 SIP requests // TAU1: tolerance parameter of no priority Diameter requests
// TAU2: tolerance parameter of priority SIP 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 SIP request that was sent to the server // LCT: arrival time of last Diameter request that 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
// TAU0) // TAU0)
// After most recent arrival, calculate auxiliary variable Xp // After most recent arrival, calculate auxiliary variable Xp
Xp = X - (ta - LCT); Xp = X - (ta - LCT);
if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived && if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived &&
Xp <= TAU2 && Xp > TAU1) { Xp <= TAU2 && Xp > TAU1) {
// Transmit SIP 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 {
// Reject SIP request // Apply abatement treatment to Diameter request
// Do not update X and LCT // Do not update X and LCT
} }
7.3.3. Optional enhancement: avoidance of resonance 7.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 arises
very quickly simultaneously at many sources, the occupancies of each very quickly simultaneously at many sources, the occupancies of each
bucket can become synchronized, resulting in the admissions from each bucket can become synchronized, resulting in the admissions from each
source being close in time and batched or very 'peaky' arrivals at source being close in time and batched or very 'peaky' arrivals at
the reporting node, which not only gives rise to control instability, the reporting node, which not only gives rise to control instability,
but also very poor delays and even lost messages. An appropriate but also very poor delays and even lost messages. An appropriate
term for this is 'resonance' [Erramilli]. term for this is 'resonance' [Erramilli].
If the network topology is such that this can occur, then a simple If the network topology is such that resonance can occur, then a
way to avoid this is to randomize the bucket occupancy at two simple way to avoid resonance is to randomize the bucket occupancy at
appropriate points: At the activation of control, and whenever the two appropriate points -- at the activation of control and whenever
bucket empties, as follows. 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 uniformly distributed between -1/2 and +1/2 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 by an Then (only) if the arrival is admitted, increase the bucket by an
amount T + uT, which will therefore be just T if the bucket hadn't 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. 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 TAU0,
initialize it to TAU0 + uT, where u is uniformly distributed as 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 response to a
request sent by the reacting node, the second term in this expression request sent by the reacting node, the second term in this expression
can be interpreted as being the bucket increment following that can be interpreted as being the bucket increment following that
admission. 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 were to o If TAU0 is chosen to be equal to TAU and all sources activate
activate control at the same time due to an extremely high request control at the same time due to an extremely high request rate,
rate, then the time until the first request admitted by each then the time until the first request admitted by each reacting
client 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 o At high load randomization rarely occurs, so there is no loss of
precision of the admitted rate, even though the randomized precision of the admitted rate, even though the randomized
'phasing' of the buckets remains. 'phasing' of the buckets remains.
8. IANA Consideration 8. IANA Consideration
TBD TBD
9. Security Considerations 9. Security Considerations
Agent overload is an extension to the based Diameter overload Agent overload is an extension to the based Diameter overload
mechanism. As such, all of the security considerations outlined in mechanism. As such, all of the security considerations outlined in
[I-D.ietf-dime-ovli] apply to the agent overload scenarios. [I-D.ietf-dime-ovli] apply to the agent overload scenarios.
10. Acknowledgements 10. Acknowledgements
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.SOC-overload-rate-control] [I-D.ietf-dime-agent-overload]
Noel, E., "SIP Overload Rate Control", February 2014. Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
agent-overload-00 (work in progress), December 2014.
[I-D.ietf-dime-ovli] [I-D.ietf-dime-ovli]
Korhonen, J., "Diameter Overload Indication Conveyance", Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
October 2013. "Diameter Overload Indication Conveyance", draft-ietf-
dime-ovli-08 (work in progress), February 2015.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "Diameter Base Protocol", RFC 6733, October 2012.
11.2. Informative References 11.2. Informative References
[I-D.donovan-agent-overload] [RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol
Donovan, S., "Diameter Agent Overload", February 2014. (SIP) Rate Control", RFC 7415, February 2015.
Authors' Addresses Authors' Addresses
Steve Donovan Steve Donovan (editor)
Oracle Oracle
17210 Campbell Road 17210 Campbell Road
Dallas, Texas 75254 Dallas, Texas 75254
United States United States
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
Eric Noel Eric Noel
AT&T Labs AT&T Labs
200s Laurel Avenue 200s Laurel Avenue
 End of changes. 85 change blocks. 
239 lines changed or deleted 255 lines changed or added

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