--- 1/draft-ietf-dime-doic-rate-control-05.txt 2017-03-27 21:13:07.402044635 -0700 +++ 2/draft-ietf-dime-doic-rate-control-06.txt 2017-03-27 21:13:07.438045483 -0700 @@ -1,19 +1,19 @@ Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. Internet-Draft Oracle Intended status: Standards Track E. Noel -Expires: August 20, 2017 AT&T Labs - February 16, 2017 +Expires: September 28, 2017 AT&T Labs + March 27, 2017 Diameter Overload Rate Control - draft-ietf-dime-doic-rate-control-05.txt + draft-ietf-dime-doic-rate-control-06.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,66 +31,66 @@ 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 http://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 August 20, 2017. + This Internet-Draft will expire on September 28, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 - 3. Interaction with DOIC report types . . . . . . . . . . . . . 5 + 3. Interaction with DOIC Report Rypes . . . . . . . . . . . . . 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.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.2. OC-OLR 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.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11 7.3.1. Default Algorithm . . . . . . . . . . . . . . . . . . 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 + 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.2. New Registries . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction This document defines a new Diameter overload control abatement @@ -177,21 +177,21 @@ [RFC7683]. Reporting Node A DOIC Node that sends a DOIC overload report. Reacting Node A DOIC Node that receives and acts on a DOIC overload report. -3. Interaction with DOIC report types +3. Interaction with DOIC Report Rypes As of the publication of this specification there are two DOIC report types defined with the specification of a third in progress: 1. Host - Overload of a specific Diameter Application at a specific Diameter Node as defined in [RFC7683]. 2. Realm - Overload of a specific Diameter Application at a specific Diameter Realm as defined in [RFC7683]. @@ -397,21 +397,21 @@ algorithm. 6.2.1. OC-Maximum-Rate AVP The OC-Maximum-Rate AVP (AVP code TBD1) is of type Unsigned32 and describes the maximum rate that the sender is requested to send traffic. This is specified in terms of requests per second. 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 | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +---------------------------------------------------------+----+----+ |OC-Maximum-Rate TBD1 6.2 Unsigned32 | | V | +---------------------------------------------------------+----+----+ @@ -420,23 +420,23 @@ This section is pulled from [RFC7415], with minor changes needed to make it apply to the Diameter protocol. 7.1. Overview The reporting node is the one protected by the overload control algorithm defined here. The reacting node is the one that abates traffic towards the server. - Following the procedures defined in [draft-ietf-dime-doic], the - reacting node and reporting node signal one another support for rate- - based overload control. + Following the procedures defined in [RFC7683], the reacting node and + reporting node signal one another support for rate-based overload + control. Then periodically, the reporting node relies on internal measurements (e.g. CPU utilization or queuing delay) to evaluate its overload state and estimate a target maximum Diameter request rate in number of requests per second (as opposed to target percent reduction in the case of loss-based abatement). 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 Diameter request rate. @@ -764,27 +764,27 @@ minimum time between admissions is uniformly distributed over [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. o At high load randomization rarely occurs, so there is no loss of precision of the admitted rate, even though the randomized 'phasing' of the buckets remains. 8. IANA Consideration -8.1. AVP codes +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 +8.2. New Registries There are no new IANA registries introduced by this document. 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.