draft-ietf-dime-doic-rate-control-08.txt   draft-ietf-dime-doic-rate-control-09.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: September 6, 2018 AT&T Labs Expires: March 14, 2019 AT&T Labs
March 5, 2018 September 10, 2018
Diameter Overload Rate Control Diameter Overload Rate Control
draft-ietf-dime-doic-rate-control-08.txt draft-ietf-dime-doic-rate-control-09.txt
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 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 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 September 6, 2018. This Internet-Draft will expire on March 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Interaction with DOIC Report Types . . . . . . . . . . . . . 5 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 . . . . . . . . . . 6 5.2. Reacting Node Overload Control State . . . . . . . . . . 6
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 . . 7 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 . . . . . . . . . . . . . . . . 8
6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9 6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 9
6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 9 6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 10 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11
7.3.1. Default Algorithm for Rate-based Control . . . . . . 11 7.3.1. Default Algorithm for Rate-based Control . . . . . . 11
7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 14 7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 14
7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 16 7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 16
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17
8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. New Registries . . . . . . . . . . . . . . . . . . . . . 17 8.2. New Registries . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 to instruct a reacting node to loss algorithm allows a reporting node (see Section 2) to instruct a
reduce the amount of traffic sent to the reporting node by abating reacting node (see Section 2) to reduce the amount of traffic sent to
(diverting or throttling) a percentage of requests sent to the the reporting node by abating (diverting or throttling) a percentage
server. While this can effectively decrease the load handled by the of requests sent to the server. While this can effectively decrease
server, it does not directly address cases where the rate of arrival the load handled by the server, it does not directly address cases
of service requests increases quickly. If the service requests that where the rate of arrival of service requests changes quickly. For
result in Diameter transactions increase quickly then the loss instance, if the service requests that result in Diameter
algorithm cannot guarantee the load presented to the server remains transactions increase quickly then the loss algorithm cannot
below a specific rate level. The loss algorithm can be slow to guarantee the load presented to the server remains below a specific
protect the stability of reporting nodes when subjected with rapidly rate level. The loss algorithm can be slow to protect the stability
changing loads. of reporting nodes when subjected with rapidly changing loads. The
"loss" algorithm errs both in throttling TOO MUCH when there is a dip
in offered load, and throttling NOT ENOUGH when there is a spike in
offered load.
Consider the case where a reacting node is handling 100 service Consider the case where a reacting node is handling 100 service
requests per second, where each of these service requests results in requests per second, where each of these service requests results in
one Diameter transaction being sent to a reporting node. If the one Diameter transaction being sent to a reporting node. If the
reporting node is approaching an overload state, or is already in an reporting node is approaching an overload state, or is already in an
overload state, it will send a Diameter overload report requesting a overload state, it will send a Diameter overload report requesting a
percentage reduction in traffic sent when the loss algorithm is used percentage reduction in traffic sent when the loss algorithm is used
as Diameter overload abatement algorithm. Assume for this discussion as Diameter overload abatement algorithm. 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 abate (diverting or throttling) ten Diameter transactions a will then abate (diverting or throttling) ten Diameter transactions a
skipping to change at page 4, line 17 skipping to change at page 4, line 20
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.
This document extends the base DOIC solution [RFC7683] to add support This document extends the base Diameter Overload Indication
for the rate based overload abatement algorithm. Conveyance (DOIC) solution [RFC7683] to add support for the rate
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 SOC document [RFC7415], with changes copied almost verbatim from the SIP Overload Control (SOC) document
focused on making the wording consistent with the DOIC solution and [RFC7415], with changes focused on making the wording consistent with
the Diameter protocol. the DOIC solution and the Diameter protocol.
2. Terminology 2. Terminology
Diameter Node Diameter Node
A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733 A Diameter Client, Diameter Server, or Diameter Agent. [RFC6733]
Diameter Agent.
Diameter Endpoint Diameter Endpoint
An RFC6733 Diameter Client or RFC6733 Diameter Server. A Diameter Client or Diameter Server. [RFC6733]
DOIC Node DOIC Node
A Diameter Node that supports the DOIC solution defined in A Diameter Node that supports the DOIC solution defined in
[RFC7683]. [RFC7683].
Reporting Node Reporting Node
A DOIC Node that sends a DOIC overload report. A DOIC Node that sends a DOIC overload report.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
The rate algorithm MAY be selected by reporting nodes for any of The rate algorithm MAY be selected by reporting nodes for any of
these report types. these report types.
It is expected that all report types defined in the future will It is expected that all report types defined in the future will
indicate whether or not the rate algorithm can be used with that indicate whether or not the rate algorithm can be used with that
report type. report type.
4. Capability Announcement 4. Capability Announcement
This extension defines the rate abatement algorithm (referred to as This document defines the rate abatement algorithm (referred to as
rate in this document) feature. Support of the rate feature by the rate in this document) feature. Support for the rate feature by a
DOIC node is announced by a new value of the OC-Feature-Vector AVP, DOIC node will be indicated by a new value of the OC-Feature-Vector
as described in Section 6.1.1, per the rules defined in [RFC7683]. AVP, as described in Section 6.1.1, per the rules defined in
[RFC7683].
The loss algorithm being the default algorithm supported by all nodes Since all nodes that support DOIC are required to support the loss
that support the Diameter overload control mechanism as specified in algorithm, DOIC nodes supporting the rate feature will support both
[RFC7683], 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.
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 MUST select a single abatement algorithm in the OC-Feature-
Vector AVP and OC-Peer-Algo AVP in the sent to the DOIC reacting Vector AVP and OC-Peer-Algo AVP in the answer message sent to the
nodes. DOIC reacting nodes.
A reporting node MAY 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].
For peer reports the selected algorithm is reflected in the OC- For peer reports the selected algorithm is reflected in the OC-
Peer-Algo AVP sent as part of the OC-Supported-Features AVP Peer-Algo AVP sent as part of the OC-Supported-Features AVP
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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. 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, 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.
A reporting node that has selected the rate overoload abatement The rate OCS entery SHOULD include the rate allocated to each
reacting note.
A reporting node that has selected the rate overload abatement
algorithm MUST indicate the rate requested to be applied by DOIC algorithm MUST indicate the rate requested to be applied by DOIC
reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP. reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.
All other elements for the OCS defined in [RFC7683] and All other elements for the OCS defined in [RFC7683] and
[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.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
skipping to change at page 8, line 8 skipping to change at page 8, line 14
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
reports with the rate algorithm indicated when the reporting node
is not in an overloaded state. This could be a strategy to
proactively avoid entering into an overloaded state. Whether to
do so is up to local policy.
When sending an overload report for the rate algorithm, the OC- When sending an overload report for the rate algorithm, the 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 MAY use the algorithm
detailed in Section 7. detailed in Section 7.
skipping to change at page 8, line 47 skipping to change at page 9, line 14
6.1.1. OC-Feature-Vector AVP 6.1.1. OC-Feature-Vector AVP
This extension adds the following capability to the OC-Feature-Vector This extension adds the following capability to the OC-Feature-Vector
AVP. AVP.
OLR_RATE_ALGORITHM (bit 2) OLR_RATE_ALGORITHM (bit 2)
Bit 2 is assigned to the rate overload abatement algorithm. When Bit 2 is assigned to the rate overload abatement algorithm. When
this flag is set by the overload control endpoint it indicates this flag is set by the overload control endpoint it indicates
that the DOIC Node supports the rate overload abatement that the DOIC Node supports the rate overload abatement algorithm.
algorithm..
6.2. OC-OLR AVP 6.2. OC-OLR AVP
This extension defines the OC-Maximum-Rate AVP to be an optional part This extension defines the OC-Maximum-Rate AVP to be an optional part
of the OC-OLR AVP. of the OC-OLR AVP.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
skipping to change at page 17, line 47 skipping to change at page 17, line 47
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. New Registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
8.3. New DOIC report types
All DOIC report types defined in the future MUST indicate whether or
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.
10. Acknowledgements 10. Acknowledgements
11. References 11. References
 End of changes. 20 change blocks. 
40 lines changed or deleted 57 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/