--- 1/draft-ietf-dime-doic-rate-control-08.txt 2018-09-10 14:13:12.107198499 -0700 +++ 2/draft-ietf-dime-doic-rate-control-09.txt 2018-09-10 14:13:12.147199472 -0700 @@ -1,19 +1,19 @@ Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. Internet-Draft Oracle Intended status: Standards Track E. Noel -Expires: September 6, 2018 AT&T Labs - March 5, 2018 +Expires: March 14, 2019 AT&T Labs + September 10, 2018 Diameter Overload Rate Control - draft-ietf-dime-doic-rate-control-08.txt + draft-ietf-dime-doic-rate-control-09.txt Abstract This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution. This extension adds a new overload control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,63 +59,67 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Interaction with DOIC Report Types . . . . . . . . . . . . . 5 4. Capability Announcement . . . . . . . . . . . . . . . . . . . 5 5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6 5.1. Reporting Node Overload Control State . . . . . . . . . . 6 5.2. Reacting Node Overload Control State . . . . . . . . . . 6 5.3. Reporting 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 6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 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.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 9 6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 9 7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 10 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11 7.3.1. Default Algorithm for Rate-based Control . . . . . . 11 7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 14 7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 16 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. New Registries . . . . . . . . . . . . . . . . . . . . . 17 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 17 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This document defines a new Diameter overload control abatement algorithm, the "rate" algorithm. The base Diameter overload specification [RFC7683] defines the "loss" algorithm as the default Diameter overload abatement algorithm. The - loss algorithm allows a reporting node to instruct a reacting node to - reduce the amount of traffic sent to the reporting node by abating - (diverting or throttling) a percentage of requests sent to the - server. While this can effectively decrease the load handled by the - server, it does not directly address cases where the rate of arrival - of service requests increases quickly. If the service requests that - result in Diameter transactions increase quickly then the loss - algorithm cannot guarantee the load presented to the server remains - below a specific rate level. The loss algorithm can be slow to - protect the stability of reporting nodes when subjected with rapidly - changing loads. + 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 + the reporting node by abating (diverting or throttling) a percentage + of requests sent to the server. While this can effectively decrease + the load handled by the server, it does not directly address cases + where the rate of arrival of service requests changes quickly. For + instance, if the service requests that result in Diameter + transactions increase quickly then the loss algorithm cannot + guarantee the load presented to the server remains below a specific + rate level. The loss algorithm can be slow to protect the stability + 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 requests per second, where each of these service requests results in one Diameter transaction being sent to a reporting node. If the reporting node is approaching an overload state, or is already in an overload state, it will send a Diameter overload report requesting a percentage reduction in traffic sent when the loss algorithm is used as Diameter overload abatement algorithm. Assume for this discussion that the reporting node requests a 10% reduction. The reacting node will then abate (diverting or throttling) ten Diameter transactions a @@ -145,39 +149,39 @@ One of the benefits of a rate based algorithm over the loss algorithm is that it better handles spikes in traffic. Instead of sending a request to reduce traffic by a percentage, the rate approach allows the reporting node to specify the maximum number of Diameter requests per second that can be sent to the reporting node. For instance, in this example, the reporting node could send a rate-based request specifying the maximum transactions per second to be 90. The reacting node will send the 90 regardless of whether it is receiving 100 or 1000 service requests per second. - This document extends the base DOIC solution [RFC7683] to add support - for the rate based overload abatement algorithm. + This document extends the base Diameter Overload Indication + 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 working group. The definition of the rate abatement algorithm is - copied almost verbatim from the SOC document [RFC7415], with changes - focused on making the wording consistent with the DOIC solution and - the Diameter protocol. + copied almost verbatim from the SIP Overload Control (SOC) document + [RFC7415], with changes focused on making the wording consistent with + the DOIC solution and the Diameter protocol. 2. Terminology Diameter Node - A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733 - Diameter Agent. + A Diameter Client, Diameter Server, or Diameter Agent. [RFC6733] Diameter Endpoint - An RFC6733 Diameter Client or RFC6733 Diameter Server. + A Diameter Client or Diameter Server. [RFC6733] DOIC Node A Diameter Node that supports the DOIC solution defined in [RFC7683]. Reporting Node A DOIC Node that sends a DOIC overload report. @@ -201,39 +205,39 @@ The rate algorithm MAY be selected by reporting nodes for any of these report types. It is expected that all report types defined in the future will indicate whether or not the rate algorithm can be used with that report type. 4. Capability Announcement - This extension defines the rate abatement algorithm (referred to as - rate in this document) feature. Support of the rate feature by the - DOIC node is announced by a new value of the OC-Feature-Vector AVP, - as described in Section 6.1.1, per the rules defined in [RFC7683]. + This document defines the rate abatement algorithm (referred to as + rate in this document) feature. Support for the rate feature by a + DOIC node will be indicated by a new value of the OC-Feature-Vector + 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 - that support the Diameter overload control mechanism as specified in - [RFC7683], DOIC nodes supporting the rate feature will support both + Since all nodes that support DOIC are required to support the loss + algorithm, DOIC nodes supporting the rate feature will support both the loss and rate based abatement algorithms. DOIC reacting nodes supporting the rate feature MUST indicate support for both the loss and rate algorithms in the OC-Feature-Vector AVP. As defined in [RFC7683], a DOIC reporting node supporting the rate 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 - nodes. + Vector AVP and OC-Peer-Algo AVP in the answer message sent to the + 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. For host or realm reports the selected algorithm is reflected in the OC-Feature-Vector AVP sent as part of the OC-Supported- Features AVP included in answer messages for transaction where the request contained an OC-Supported-Features AVP. This is per the procedures defined in [RFC7683]. For peer reports the selected algorithm is reflected in the OC- Peer-Algo AVP sent as part of the OC-Supported-Features AVP @@ -256,21 +260,24 @@ This is different from the behavior defined in [RFC7683] where a single loss percentage sent to all reacting nodes. A reporting node SHOULD maintain OCS entries when using the rate abatement algorithm per supported Diameter application, per targeted reacting node and per report type. A rate OCS entry is identified by the tuple of Application-Id, report type and DiameterIdentity of the target of the rate OLR. - 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 reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP. All other elements for the OCS defined in [RFC7683] and [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS when using the rate abatement algorithm. 5.2. Reacting Node Overload Control State A reacting node that supports the rate abatement algorithm MUST @@ -325,20 +332,26 @@ 5.5. Reporting Node Behavior for Rate Abatement Algorithm When in an overload condition with rate selected as the overload abatement algorithm and when handling a request that contained an OC- Supported-Features AVP that indicated support for the rate abatement algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate algorithm using the parameters stored in the reporting node OCS for the target of the overload report. + Note: It is also possible for the reporting node to send overload + reports with the rate algorithm indicated 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- Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC- Reduction-Percentage AVP MUST NOT be included. 5.6. Reacting Node Behavior for Rate Abatement Algorithm When determining if abatement treatment should be applied to a request being sent to a reporting node that has selected the rate overload abatement algorithm, the reacting node MAY use the algorithm detailed in Section 7. @@ -364,22 +377,21 @@ 6.1.1. OC-Feature-Vector AVP This extension adds the following capability to the OC-Feature-Vector AVP. OLR_RATE_ALGORITHM (bit 2) Bit 2 is assigned to the rate overload abatement algorithm. When this flag is set by the overload control endpoint it indicates - that the DOIC Node supports the rate overload abatement - algorithm.. + that the DOIC Node supports the rate overload abatement algorithm. 6.2. OC-OLR AVP This extension defines the OC-Maximum-Rate AVP to be an optional part of the OC-OLR AVP. OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] @@ -774,20 +785,25 @@ 8.1. AVP Codes New AVPs defined by this specification are listed in Section 6. All AVP codes are allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry. 8.2. New Registries 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 The rate overload abatement mechanism is an extension to the base Diameter overload mechanism. As such, all of the security considerations outlined in [RFC7683] apply to the rate overload abatement mechanism. 10. Acknowledgements 11. References