< draft-ietf-dime-doic-rate-control-10.txt | draft-ietf-dime-doic-rate-control-11.txt > | |||
---|---|---|---|---|
Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. | 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: April 6, 2019 AT&T Labs | Expires: August 15, 2019 AT&T Labs | |||
October 3, 2018 | February 11, 2019 | |||
Diameter Overload Rate Control | Diameter Overload Rate Control | |||
draft-ietf-dime-doic-rate-control-10 | 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) [RFC7683] base solution. This extension | |||
adds a new overload control abatement algorithm. This abatement | adds a new overload control abatement algorithm. This abatement | |||
algorithm allows for a DOIC reporting node to specify a maximum rate | algorithm allows for a DOIC reporting node to specify a maximum rate | |||
at which a DOIC reacting node sends Diameter requests to the DOIC | at which a DOIC reacting node sends Diameter requests to the DOIC | |||
reporting node. | reporting node. | |||
skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 April 6, 2019. | This Internet-Draft will expire on August 15, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 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 | |||
skipping to change at page 2, line 39 ¶ | skipping to change at page 2, line 39 ¶ | |||
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 . . . 8 | 5.4. Reacting Node Maintenance of Overload Control State . . . 8 | |||
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 . . . 9 | 5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 9 | |||
6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9 | 6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9 | |||
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9 | 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-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10 | 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 | 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
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 for Rate-based Control . . . . . . 12 | 7.3.1. Default Algorithm for Rate-based Control . . . . . . 12 | |||
7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 15 | 7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 15 | |||
7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17 | 7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17 | |||
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18 | 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18 | |||
8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
8.2. New Registries . . . . . . . . . . . . . . . . . . . . . 18 | 8.2. OC-Supported-Features . . . . . . . . . . . . . . . . . . 18 | |||
8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 18 | 8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 19 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 19 | 11.2. Informative References . . . . . . . . . . . . . . . . . 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 abatement algorithm. The | |||
loss algorithm allows a reporting node (see Section 2) to instruct a | loss algorithm allows a reporting node (see Section 2) to instruct a | |||
reacting node (see Section 2) to reduce the amount of traffic sent to | reacting node (see Section 2) to reduce the amount of traffic sent to | |||
the reporting node by abating (diverting or throttling) a percentage | the reporting node by abating (diverting or throttling) a percentage | |||
of requests sent to the server. While this can effectively decrease | of requests sent to the server. While this can effectively decrease | |||
the load handled by the server, it does not directly address cases | the load handled by the server, it does not directly address cases | |||
where the rate of arrival of service requests changes quickly. For | where the rate of arrival of service requests changes quickly. For | |||
instance, if the service requests that result in Diameter | instance, if the service requests that result in Diameter | |||
transactions increase quickly then the loss algorithm cannot | transactions increase quickly then the loss algorithm cannot | |||
guarantee the load presented to the server remains below a specific | guarantee the load presented to the server remains below a specific | |||
rate level. The loss algorithm can be slow to ensure the stability | rate level. The loss algorithm can be slow to ensure the stability | |||
of reporting nodes when subjected to rapidly changing loads. The | of reporting nodes when subjected to rapidly-changing loads. The | |||
"loss" algorithm errs both in throttling too much when there is a dip | "loss" algorithm errs both in throttling too much when there is a dip | |||
in offered load, and throttling not enough when there is a spike in | in offered load, and throttling not enough when there is a spike in | |||
offered load. | 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 | |||
skipping to change at page 4, line 16 ¶ | skipping to change at page 4, line 16 ¶ | |||
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 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%. This control | report setting the reduction percentage back to 10%. This control | |||
feedback loop has the potential to make the situation worse by | feedback loop has the potential to make the situation worse by | |||
causing wide fluctuations in traffic on multiple nodes in the | causing wide fluctuations in traffic on multiple nodes in the | |||
Diameter network. | 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 it's 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 node | 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. | based overload 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. Terminology | |||
skipping to change at page 6, line 15 ¶ | skipping to change at page 6, line 15 ¶ | |||
4. Capability Announcement | 4. 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 | AVP, as described in Section 6.1.1, per the rules defined in | |||
[RFC7683]. | [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-based 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. | ||||
As defined in [RFC7683], a DOIC reporting node supporting the rate | As defined in [RFC7683], a DOIC reporting node supporting the rate | |||
feature MUST select a single abatement algorithm in the OC-Feature- | feature selects a single abatement algorithm in the OC-Feature-Vector | |||
Vector AVP and OC-Peer-Algo AVP in the answer message sent to the | AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC | |||
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 OC-Feature-Vector AVP sent as part of the OC-Supported- | the OC-Feature-Vector AVP sent as part of the OC-Supported- | |||
Features AVP included in answer messages for transaction where the | Features AVP included in answer messages for transaction where the | |||
request contained an OC-Supported-Features AVP. This is per the | request contained an OC-Supported-Features AVP. This is per the | |||
procedures defined in [RFC7683]. | procedures defined in [RFC7683]. | |||
skipping to change at page 7, line 6 ¶ | skipping to change at page 7, line 6 ¶ | |||
[RFC7683] for handling of overload reports when the rate overload | [RFC7683] for handling of overload reports when the rate overload | |||
abatement algorithm is used. | 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 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 | This is different from the behavior defined in [RFC7683] where a | |||
single loss percentage sent to all reacting nodes. | reporting node sends a single loss percentage 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, 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. | note. | |||
skipping to change at page 7, line 35 ¶ | skipping to change at page 7, line 36 ¶ | |||
5.2. Reacting Node Overload Control State | 5.2. Reacting Node Overload Control State | |||
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 | |||
[I-D.ietf-dime-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 and MUST indicate the selected rate in the | |||
A reporting node that has selected the rate abatement algorithm and | ||||
enters an overload condition MUST indicate the selected rate in the | ||||
resulting reporting node OCS entries. | resulting 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. | |||
skipping to change at page 8, line 48 ¶ | skipping to change at page 8, line 44 ¶ | |||
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 abatement | Supported-Features AVP that indicated support for the rate abatement | |||
algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate | algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate | |||
algorithm using the parameters stored in the reporting node OCS for | algorithm using the parameters stored in the reporting node OCS for | |||
the target of the overload report. | 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 when the reporting node | reports with the rate algorithm indicated even when the reporting | |||
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 to | |||
do so is up to local policy. | 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 OC- | |||
Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC- | Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC- | |||
Reduction-Percentage AVP MUST NOT be included. | Reduction-Percentage AVP MUST NOT be 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 MAY use the algorithm | overload abatement algorithm, the reacting node can choose to use the | |||
detailed in Section 7. | algorithm detailed in Section 7. | |||
Other algorithms for controlling the rate MAY be implemented by | Other algorithms for controlling the rate MAY be implemented by the | |||
the reacting node. Any algorithm implemented MUST result in the | reacting node. Any algorithm implemented MUST correctly limit the | |||
correct 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. | [I-D.ietf-dime-agent-overload] apply. | |||
6. Rate Abatement Algorithm AVPs | 6. Rate Abatement Algorithm AVPs | |||
6.1. OC-Supported-Features AVP | 6.1. OC-Supported-Features AVP | |||
skipping to change at page 10, line 43 ¶ | skipping to change at page 10, line 43 ¶ | |||
+---------+ | +---------+ | |||
|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 TBD1 6.2 Unsigned32 | | V | | |||
+---------------------------------------------------------+----+----+ | +---------------------------------------------------------+----+----+ | |||
7. Rate Based Abatement Algorithm | 7. Rate-Based 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 | 7.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. | |||
skipping to change at page 11, line 25 ¶ | skipping to change at page 11, line 25 ¶ | |||
(e.g. CPU utilization or queuing delay) to evaluate its overload | (e.g. CPU utilization or queuing delay) to evaluate its overload | |||
state and estimate a target maximum Diameter request rate in number | state and estimate a target maximum Diameter request rate in number | |||
of requests per second (as opposed to target percent reduction in the | of requests per second (as opposed to target percent reduction in the | |||
case of loss-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 maximum Diameter | Upon receiving the overload report with a target maximum Diameter | |||
request rate, each reacting node applies abatement treatment 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 | 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 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 | |||
skipping to change at page 12, line 8 ¶ | skipping to change at page 12, line 8 ¶ | |||
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 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 an upper bound on the traffic | second) for the rate algorithm provides a loose upper bound on the | |||
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 others above that target rate. But the resulting | |||
request rate presented to the overloaded reporting node will converge | request rate presented to the overloaded reporting node will converge | |||
towards the target Diameter request rate or a lower rate. | 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] | |||
skipping to change at page 12, line 34 ¶ | skipping to change at page 12, line 34 ¶ | |||
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 | 7.3. Reacting Node Behavior | |||
7.3.1. Default Algorithm for Rate-based Control | 7.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. | ||||
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 | |||
// TAU0) | // TAU0) | |||
skipping to change at page 16, line 18 ¶ | skipping to change at page 16, line 18 ¶ | |||
// 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 | |||
// 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 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 | |||
} | } | |||
skipping to change at page 18, line 43 ¶ | skipping to change at page 18, line 43 ¶ | |||
'phasing' of the buckets remains. | 'phasing' of the buckets remains. | |||
8. IANA Consideration | 8. IANA Consideration | |||
8.1. AVP Codes | 8.1. AVP Codes | |||
New AVPs defined by this specification are listed in Section 6. All | New AVPs defined by this specification are listed in Section 6. All | |||
AVP codes are allocated from the 'Authentication, Authorization, and | AVP codes are allocated from the 'Authentication, Authorization, and | |||
Accounting (AAA) Parameters' AVP Codes registry. | Accounting (AAA) Parameters' AVP Codes registry. | |||
8.2. New Registries | 8.2. OC-Supported-Features | |||
There are no new IANA registries introduced by this document. | As indicated in Section 6.1.1, a new allocation is required in the | |||
OC-Feature-Vector AVP. | ||||
8.3. New DOIC report types | 8.3. New DOIC report types | |||
All DOIC report types defined in the future MUST indicate whether or | All DOIC report types defined in the future MUST indicate whether or | |||
not the rate algorithm can be used with that report type. | not the rate algorithm can be used with that report type. | |||
9. Security Considerations | 9. Security Considerations | |||
The rate overload abatement mechanism is an extension to the base | The rate overload abatement mechanism is an extension to the base | |||
Diameter overload mechanism. As such, all of the security | Diameter overload mechanism. As such, all of the security | |||
considerations outlined in [RFC7683] apply to the rate overload | considerations outlined in [RFC7683] apply to the rate overload | |||
abatement mechanism. | abatement mechanism. | |||
In addition, the rate algorithm could be used to handle DoS attacks | ||||
more effectively than the loss algorithm. | ||||
10. Acknowledgements | 10. Acknowledgements | |||
Lionel Morand for his contributions to the document. | ||||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-dime-agent-overload] | [I-D.ietf-dime-agent-overload] | |||
Donovan, S., "Diameter Agent Overload", draft-ietf-dime- | Donovan, S., "Diameter Agent Overload", draft-ietf-dime- | |||
agent-overload-00 (work in progress), December 2014. | 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, | |||
End of changes. 32 change blocks. | ||||
41 lines changed or deleted | 48 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/ |