idnits 2.17.1 draft-ietf-dime-doic-rate-control-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2015) is 3339 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Erramilli' is mentioned on line 746, but not defined -- Looks like a reference, but probably isn't: '0' on line 777 == Missing Reference: 'T' is mentioned on line 777, but not defined == Unused Reference: 'RFC5226' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 822, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-dime-agent-overload-00 == Outdated reference: A later version (-10) exists of draft-ietf-dime-ovli-08 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. 3 Internet-Draft Oracle 4 Intended status: Standards Track E. Noel 5 Expires: September 7, 2015 AT&T Labs 6 March 6, 2015 8 Diameter Overload Rate Control 9 draft-ietf-dime-doic-rate-control-01.txt 11 Abstract 13 This specification documents an extension to the Diameter Overload 14 Indication Conveyance (DOIC) base solution. This extension adds a 15 new overload control abatement algorithm. This abatement algorithm 16 allows for a DOIC reporting node to specify a maximum rate at which a 17 DOIC reacting node sends Diameter requests to the DOIC reporting 18 node. 20 Requirements 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 7, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 62 3. Interaction with DOIC report types . . . . . . . . . . . . . 5 63 4. Capability Announcement . . . . . . . . . . . . . . . . . . . 5 64 5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6 65 5.1. Reporting Node Overload Control State . . . . . . . . . . 6 66 5.2. Reacting Node Overload Control State . . . . . . . . . . 7 67 5.3. Reporting Node Maintenance of Overload Control State . . 7 68 5.4. Reacting Node Maintenance of Overload Control State . . . 7 69 5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8 70 5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 8 71 6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 8 72 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9 73 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9 74 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10 76 6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 10 77 7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 10 78 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11 80 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 81 7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 12 82 7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 15 83 7.3.3. Optional enhancement: avoidance of resonance . . . . 17 84 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 11.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 This document defines a new Diameter overload control abatement 95 algorithm. 97 The base Diameter overload specification [I-D.ietf-dime-ovli] defines 98 the loss algorithm as the default Diameter overload abatement 99 algorithm. The loss algorithm allows a reporting node to instruct a 100 reacting node to reduce the amount of traffic sent to the reporting 101 node by abating (diverting or throttling) a percentage of requests 102 sent to the server. While this can effectively decrease the load 103 handled by the server, it does not directly address cases where the 104 rate of arrival of service requests increase quickly. If the service 105 requests that result in Diameter transactions increases quickly then 106 the loss algorithm cannot guarantee the load presented to the server 107 remains below a specific rate level. The loss algorithm can be slow 108 to protect the stability of reporting nodes when subject with rapidly 109 changing loads. 111 Consider the case where a reacting node is handling 100 service 112 requests per second, where each of these service requests results in 113 one Diameter transaction being sent to a reacting node. If the 114 reacting node is approaching an overload state, or is already in an 115 overload state, it will send a Diameter overload report requesting a 116 percentage reduction in traffic sent. Assume for this discussion 117 that the reporting node requests a 10% reduction. The reacting node 118 will then abate (diverting or throttling) ten Diameter transactions a 119 second, sending the remaining 90 transactions per second to the 120 reacting node. 122 Now assume that the reacting node's service requests spikes to 1000 123 requests per second. The reacting node will continue to honor the 124 reporting nodes request for a 10% reduction in traffic. This 125 results, in this example, in the reacting node sending 900 Diameter 126 transactions per second, abating the remaining 100 transactions per 127 second. This spike in traffic is significantly higher than the 128 reporting node is expecting to handle and can result in negative 129 impacts to the stability of the reporting node. 131 The reporting node can, and likely would, send another overload 132 report requesting that the reacting node abate 91% of requests to get 133 back to the desired 90 transactions per second. However, once the 134 spike has abated and the reacting node handled service requests 135 returns to 100 per second, this will result in just 9 transactions 136 per second being sent to the reporting node, requiring a new overload 137 report setting the reduction percentage back to 10%. This control 138 feedback loop has the potential to make the situation worse. 140 One of the benefits of a rate based algorithm is that it better 141 handles spikes in traffic. Instead of sending a request to reduce 142 traffic by a percentage, the rate approach allows the reporting node 143 to specify the maximum number of Diameter requests per second that 144 can be sent to the reporting node. For instance, in this example, 145 the reporting node could send a rate based request specifying the 146 maximum transactions per second to be 90. The reacting node will 147 send the 90 regardless of whether it is receiving 100 or 1000 service 148 requests per second. 150 This document extends the base DOIC solution [I-D.ietf-dime-ovli] to 151 add support for the rate based overload abatement algorithm. 153 This document draws heavily on work in the RIA SIP Overload Control 154 working group. The definition of the rate abatement algorithm is 155 copied almost verbatim from the SOC document [RFC7415], with changes 156 focused on making the wording consistent with the DOIC solution and 157 the Diameter protocol. 159 Editor's Note: Need to verify that the latest text from the SOC 160 document is currently being used. 162 2. Terminology and Abbreviations 164 Diameter Node 166 A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733 167 Diameter Agent. 169 Diameter Endpoint 171 An RFC6733 Diameter Client or RFC6733 Diameter Server. 173 DOIC Node 175 A Diameter Node that supports the DOIC solution defined in 176 [I-D.ietf-dime-ovli]. 178 Reporting Node 180 A DOIC Node that sends a DOIC overload report. 182 Reacting Node 184 A DOIC Node that receives and acts on a DOIC overload report. 186 3. Interaction with DOIC report types 188 As of the publication of this specification there are two DOIC report 189 types defined with the specification of a third in progress: 191 1. Host - Overload of a specific Diameter Application at a specific 192 Diameter Node as defined in [I-D.ietf-dime-ovli]. 194 2. Realm - Overload of a specific Diameter Application at a specific 195 Diameter Realm as defined in [I-D.ietf-dime-ovli]. 197 3. Peer - Overload of a specific Diameter peer as defined in 198 [I-D.ietf-dime-agent-overload]. 200 The rate algorithm MAY be selected by reporting nodes for any of 201 these report types. 203 Editor's note: It needs to be validated that use of the rate 204 algorithm applies to the host and realm report types. 206 It is expected that all report types defined in the future will 207 indicate whether or not the rate algorithm can be used with that 208 report type. 210 4. Capability Announcement 212 This extension defines the rate abatement algorithm (referred to as 213 rate in this document) feature. Support for the rate feature will be 214 reflected by use of a new value, as defined in Section 6.1.1, in the 215 OC-Feature-Vector AVP per the rules defined in [I-D.ietf-dime-ovli]. 217 Note that Diameter nodes that support the rate feature will, by 218 definition, support both the loss and rate based abatement 219 algorithms. DOIC reacting nodes SHOULD indicate support for both the 220 loss and rate algorithms in the OC-Feature-Vector AVP. 222 There may be local policy reasons that cause a DOIC node that 223 supports the rate abatement algorithm to not include it in the OC- 224 Feature-Vector. All reacting nodes, however, must continue to 225 include loss in the OC-Feature-Vector in order to remain compliant 226 with [I-D.ietf-dime-ovli]. 228 A reporting node MAY select one abatement algorithm to apply to host 229 and realm reports and a different algorithm to apply to peer reports. 231 For host or realm reports the selected algorithm is reflected in 232 the OC-Feature-Vector AVP sent as part of the OC-Selected-Features 233 AVP included in answer messages for transaction where the request 234 contained an OC-Supported-Features AVP. This is per the 235 procedures defined in [I-D.ietf-dime-ovli]. 237 For peer reports the selected algorithm is reflected in the OC- 238 Peer-Algo AVP sent as part of the OC-Supported-Features AVP 239 included answer messages for transaction where the request 240 contained an OC-Supported-Features AVP. This is per the 241 procedures defined in [I-D.ietf-dime-agent-overload]. 243 Editor's Node: The peer report specification is still under 244 development and, as such, the above paragraph is subject to 245 change. 247 5. Overload Report Handling 249 This section describes any changes to the behavior defined in 250 [I-D.ietf-dime-ovli] for handling of overload reports when the rate 251 overload abatement algorithm is used. 253 5.1. Reporting Node Overload Control State 255 A reporting node that uses the rate abatement algorithm SHOULD 256 maintain reporting node OCS for each reacting node to which it sends 257 a rate OLR. 259 This is different from the behavior defines in 260 [I-D.ietf-dime-ovli] where a single loss percentage sent to all 261 reacting nodes. 263 A reporting node SHOULD maintain OCS entries when using the rate 264 abatement algorithm per supported Diameter application, per targeted 265 reacting node and per report-type. 267 A rate OCS entry is identified by the tuple of Application-Id, 268 report-type and DiameterID of the target of the rate OLR. 270 A reporting node that supports the rate abatement algorithm MUST be 271 able to include the specified rate in the abatement algorithm 272 specific portion of the reporting node rate OCS. 274 All other elements for the OCS defined in [I-D.ietf-dime-ovli] and 275 [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS 276 when using the rate abatement algorithm. 278 5.2. Reacting Node Overload Control State 280 A reacting node that supports the rate abatement algorithm MUST be 281 able to include rate as the selected abatement algorithm in the 282 reacting node OCS. 284 A reacting node that supports the rate abatement algorithm MUST be 285 able to include the rate specified in the OC-Maximum-Rate AVP 286 included in the OC-OLR AVP as an element of the abatement algorithm 287 specific portion of reacting node OCS entries. 289 All other elements for the OCS defined in [I-D.ietf-dime-ovli] and 290 [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS 291 when using the rate abatement algorithm. 293 5.3. Reporting Node Maintenance of Overload Control State 295 A reporting node that has selected the rate overload abatement 296 algorithm and enters an overload condition MUST indicate rate as the 297 abatement algorithm in the resulting reporting node OCS entries. 299 A reporting node that has selected the rate abatement algorithm and 300 enters an overload condition MUST indicate the selected rate in the 301 resulting reporting node OCS entries. 303 When selecting the rate algorithm in the response to a request that 304 contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP 305 indicating support for the rate feature, a reporting node MUST ensure 306 that a reporting node OCS entry exists for the target of the overload 307 report. The target is defined as follows: 309 o For Host reports the target is the DiameterID contained in the 310 Origin-Host AVP received in the request. 312 o For Realm reports the target is the DiameterID contained in the 313 Origin-Realm AVP received in the request. 315 o For Peer reports the target is the DiameterID of the Diameter Peer 316 from which the request was received. 318 5.4. Reacting Node Maintenance of Overload Control State 320 When receiving an answer message indicating that the reacting node 321 has selected the rate algorithm, a reaction node MUST indicate the 322 rate abatement algorithm in the reacting node OCS entry for the 323 reporting node. 325 A reacting node receiving an overload report for the rate abatement 326 algorithm MUST save the rate received in the OC-Maximum-Rate AVP 327 contained in the OC-OLR AVP in the reacting node OCS entry. 329 5.5. Reporting Node Behavior for Rate Abatement Algorithm 331 When in an overload condition with rate selected as the overload 332 abatement algorithm and when handling a request that contained an OC- 333 Supported-Features AVP that indicated support for the rate abatement 334 algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate 335 algorithm using the parameters stored in the reporting node OCS for 336 the target of the overload report. 338 Editor's Note: The above is a pretty complicated way of saying 339 that the reporting node should include an OC-OLR in the 340 appropriate answer messages. The basic requirement isn't rate 341 feature specific but rather that in all cases the reporting node 342 generates an OC-OLR according to the parameters of the appropriate 343 OCS entry. This wording probably can be improved based on the 344 generic behavior definition. 346 When sending an overload report for the Rate algorithm, the OC- 347 Maximum-Rate AVP is included and the OC-Reduction-Percentage AVP is 348 not included. 350 5.6. Reacting Node Behavior for Rate Abatement Algorithm 352 When determining if abatement treatment should be applied to a 353 request being sent to a reporting node that has selected the rate 354 overload abatement algorithm, the reacting node MAY use the algorithm 355 detailed in Section 6. 357 Note: Other algorithms for controlling the rate can be implemented 358 by the reacting node as long as they result in the correct rate of 359 traffic being sent to the reporting node. 361 Once a determination is made by the reacting node that an individual 362 Diameter request is to be subjected to abatement treatment then the 363 procedures for throttling and diversion defined in 364 [I-D.ietf-dime-ovli] and [I-D.ietf-dime-agent-overload] apply. 366 6. Rate Abatement Algorithm AVPs 368 Editors Note: This section depends upon the completion of the base 369 DOIC specification. As such, it cannot be complete until the data 370 model and extension mechanism are finalized. Details for any new 371 AVPs or modifications to existing AVPs will be finalized in a future 372 version of the draft after the base DOC specification has stabilized. 374 6.1. OC-Supported-Features AVP 376 The rate algorithm does not add any AVPs to the OC-Supported-Features 377 AVP. 379 The rate algorithm does add a new feature bit to be carried in the 380 OC-Feature-Vector AVP. 382 6.1.1. OC-Feature-Vector AVP 384 This extension adds the following capabilities to the OC-Feature- 385 Vector AVP. 387 OLR_RATE_ALGORITHM (0x0000000000000004) 389 When this flag is set by the overload control endpoint it 390 indicates that the DOIC Node supports the rate overload control 391 algorithm. 393 6.2. OC-OLR AVP 395 This extension defines the OC-Maximum-Rate AVP to be an optional part 396 of the OC-OLR AVP. 398 OC-OLR ::= < AVP Header: TBD2 > 399 < OC-Sequence-Number > 400 < OC-Report-Type > 401 [ OC-Reduction-Percentage ] 402 [ OC-Validity-Duration ] 403 [ OC-Source-ID ] 404 [ OC-Abatement-Algorithm ] 405 [ OC-Maximum-Rate ] 406 * [ AVP ] 408 This extension makes no changes to the other AVPs that are part of 409 the OC-OLR AVP. 411 This extension does not define new overload report types. The 412 existing report types of host and realm defined in 413 [I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer 414 report type defined in [I-D.ietf-dime-agent-overload] also applies to 415 the rate control algorithm. 417 6.2.1. OC-Maximum-Rate AVP 419 The OC-Maximum-Rate AVP (AVP code TBD1) is type of Unsigned32 and 420 describes the maximum rate that that the sender is requested to send 421 traffic. This is specified in terms of requests per second. 423 Editor's note: Do we need to specify a maximum value? 425 A value of zero indicates that no traffic is to be sent. 427 6.3. Attribute Value Pair flag rules 429 +---------+ 430 |AVP flag | 431 |rules | 432 +----+----+ 433 AVP Section | |MUST| 434 Attribute Name Code Defined Value Type |MUST| NOT| 435 +--------------------------------------------------------+----+----+ 436 |OC-Maximum-Rate TBD1 x.x Unsigned64 | | V | 437 +--------------------------------------------------------+----+----+ 439 7. Rate Based Abatement Algorithm 441 This section is pulled from [RFC7415], with minor changes needed to 442 make it apply to the Diameter protocol. 444 7.1. Overview 446 The reporting node is the one protected by the overload control 447 algorithm defined here. The reacting node is the one that abates 448 traffic towards the server. 450 Following the procedures defined in [draft-ietf-dime-doic], the 451 reacting node and reporting node signal one another support for rate- 452 based overload control. 454 Then periodically, the reporting node relies on internal measurements 455 (e.g. CPU utilization or queuing delay) to evaluate its overload 456 state and estimate a target maximum Diameter request rate in number 457 of requests per second (as opposed to target percent reduction in the 458 case of loss-based abatement). 460 When in an overloaded state, the reporting node uses the OC-OLR AVP 461 to inform reacting nodes of its overload state and of the target 462 Diameter request rate. 464 Upon receiving the overload report with a target maximum Diameter 465 request rate, each reacting node applies abatement treatment for new 466 Diameter requests towards the reporting node. 468 7.2. Reporting Node Behavior 470 The actual algorithm used by the reporting node to determine its 471 overload state and estimate a target maximum Diameter request rate is 472 beyond the scope of this document. 474 However, the reporting node MUST periodically evaluate its overload 475 state and estimate a target Diameter request rate beyond which it 476 would become overloaded. The reporting node must allocate a portion 477 of the target Diameter request rate to each of its reacting nodes. 478 The reporting node may set the same rate for every reacting node, or 479 may set different rates for different reacting node. 481 The maximum rate determined by the reporting node for a reacting node 482 applies to the entire stream of Diameter requests, even though 483 abatement may only affect a particular subset of the requests, since 484 the reacting node might apply priority as part of its decision of 485 which requests to abate. 487 When setting the maximum rate for a particular reacting node, the 488 reporting node may need take into account the workload (e.g. cpu load 489 per request) of the distribution of message types from that reacting 490 node. Furthermore, because the reacting node may prioritize the 491 specific types of messages it sends while under overload restriction, 492 this distribution of message types may be different from the message 493 distribution for that reacting node under non-overload conditions 494 (e.g., either higher or lower cpu load). 496 Note that the AVP for the rate algorithm is an upper bound (in 497 request messages per second) on the traffic sent by the reacting node 498 to the reporting node. The reacting node may send traffic at a rate 499 significantly lower than the upper bound, for a variety of reasons. 501 In other words, when multiple reacting nodes are being controlled by 502 an overloaded reporting node, at any given time some reacting nodes 503 may receive requests at a rate below its target maximum Diameter 504 request rate while others above that target rate. But the resulting 505 request rate presented to the overloaded reporting node will converge 506 towards the target Diameter request rate. 508 Upon detection of overload, and the determination to invoke overload 509 controls, the reporting node MUST follow the specifications in 510 [draft-ietf-dime-ovli] to notify its clients of the allocated target 511 maximum Diameter request rate and to notify them that the rate 512 overload abatement is in effect. 514 The reporting node MUST use the OC-Maximum-Rate AVP defined in this 515 specification to communicate a target maximum Diameter request rate 516 to each of its clients. 518 7.3. Reacting Node Behavior 520 7.3.1. Default algorithm 522 In determining whether or not to transmit a specific message, the 523 reacting node can use any algorithm that limits the message rate to 524 the OC-Maximum-Rate AVP value in units of messages per second. For 525 ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target 526 inter-Diameter request interval. It may be strictly deterministic, 527 or it may be probabilistic. It may, or may not, have a tolerance 528 factor, to allow for short bursts, as long as the long term rate 529 remains below 1/T. 531 The algorithm may have provisions for prioritizing traffic. 533 If the algorithm requires other parameters (in addition to "T", which 534 is 1/OC-Maximum-Rate), they may be set autonomously by the reacting 535 node, or they may be negotiated independently between reacting node 536 and reporting node. 538 In either case, the coordination is out of scope for this document. 539 The default algorithms presented here (one with and one without 540 provisions for prioritizing traffic) are only examples. 542 To apply abatement treatment to new Diameter requests at the rate 543 specified in the OC-Maximum-Rate AVP value sent by the reporting node 544 to its reacting nodes, the reacting node MAY use the proposed default 545 algorithm for rate-based control or any other equivalent algorithm 546 that forward messages in conformance with the upper bound of 1/T 547 messages per second. 549 The default Leaky Bucket algorithm presented here is based on [ITU-T 550 Rec. I.371] Appendix A.2. The algorithm makes it possible for 551 reacting nodes to deliver Diameter requests at a rate specified in 552 the OC-Maximum-Rate value with tolerance parameter TAU (preferably 553 configurable). 555 Conceptually, the Leaky Bucket algorithm can be viewed as a finite 556 capacity bucket whose real-valued content drains out at a continuous 557 rate of 1 unit of content per time unit and whose content increases 558 by the increment T for each forwarded Diameter request. T is 559 computed as the inverse of the rate specified in the OC-Maximum-Rate 560 AVP value, namely T = 1 / OC-Maximum-Rate. 562 Note that when the OC-Maximum-Rate value is 0 with a non-zero OC- 563 Validity-Duration, then the reacting node should apply abatement 564 treatment to 100% of Diameter requests destined to the overloaded 565 reporting node. However, when the OC-Validity-Duration value is 0, 566 the reacting node should stop applying abatement treatment. 568 If, at a new Diameter request arrival, the content of the bucket is 569 less than or equal to the limit value TAU, then the Diameter request 570 is forwarded to the server; otherwise, the abatement treatment is 571 applied to the Diameter request. 573 Note that the capacity of the bucket (the upper bound of the counter) 574 is (T + TAU). 576 The tolerance parameter TAU determines how close the long-term 577 admitted rate is to an ideal control that would admit all Diameter 578 requests for arrival rates less than 1/T and then admit Diameter 579 requests precisely at the rate of 1/T for arrival rates above 1/T. 580 In particular at mean arrival rates close to 1/T, it determines the 581 tolerance to deviation of the inter-arrival time from T (the larger 582 TAU the more tolerance to deviations from the inter-departure 583 interval T). 585 This deviation from the inter-departure interval influences the 586 admitted rate burstyness, or the number of consecutive Diameter 587 requests forwarded to the reporting node (burst size proportional to 588 TAU over the difference between 1/T and the arrival rate). 590 In situations where reacting nodes are configured with some knowledge 591 about the reporting node (e.g., operator pre-provisioning), it can be 592 beneficial to choose a value of TAU based on how many reacting nodes 593 will be sending requests to the reporting node. 595 Reporting nodes with a very large number of reacting nodes, each with 596 a relatively small arrival rate, will generally benefit from a 597 smaller value for TAU in order to limit queuing (and hence response 598 times) at the reporting node when subjected to a sudden surge of 599 traffic from all reacting nodes. Conversely, a reporting node with a 600 relatively small number of reacting nodes, each with proportionally 601 larger arrival rate, will benefit from a larger value of TAU. 603 Once the control has been activated, at the arrival time of the k-th 604 new Diameter request, ta(k), the content of the bucket is 605 provisionally updated to the value 606 X' = X - (ta(k) - LCT) 608 where X is the value of the leaky bucket counter after arrival of the 609 last forwarded Diameter request, and LCT is the time at which the 610 last Diameter request was forwarded. 612 If X' is less than or equal to the limit value TAU, then the new 613 Diameter request is forwarded and the leaky bucket counter X is set 614 to X' (or to 0 if X' is negative) plus the increment T, and LCT is 615 set to the current time ta(k). If X' is greater than the limit value 616 TAU, then the abatement treatment is applied to the new Diameter 617 request and the values of X and LCT are unchanged. 619 When the first response from the reporting node has been received 620 indicating control activation (OC-Validity-Duration>0), LCT is set to 621 the time of activation, and the leaky bucket counter is initialized 622 to the parameter TAU0 (preferably configurable) which is 0 or larger 623 but less than or equal to TAU. 625 TAU can assume any positive real number value and is not necessarily 626 bounded by T. 628 TAU=4*T is a reasonable compromise between burst size and abatement 629 rate adaptation at low offered rate. 631 Note that specification of a value for TAU, and any communication or 632 coordination between servers, is beyond the scope of this document. 634 A reference algorithm is shown below. 636 No priority case: 638 // T: inter-transmission interval, set to 1 / OC-Maximum-Rate 639 // TAU: tolerance parameter 640 // ta: arrival time of the most recent arrival 641 // LCT: arrival time of last SIP request that was sent to the server 642 // (initialized to the first arrival time) 643 // X: current value of the leaky bucket counter (initialized to 644 // TAU0) 646 // After most recent arrival, calculate auxiliary variable Xp 647 Xp = X - (ta - LCT); 649 if (Xp <= TAU) { 650 // Transmit SIP request 651 // Update X and LCT 652 X = max (0, Xp) + T; 653 LCT = ta; 654 } else { 655 // Reject SIP request 656 // Do not update X and LCT 657 } 659 7.3.2. Priority treatment 661 The reacting node is responsible for applying message priority and 662 for maintaining two categories of requests: Request candidates for 663 reduction, requests not subject to reduction (except under 664 extenuating circumstances when there aren't any messages in the first 665 category that can be reduced). 667 Accordingly, the proposed Leaky bucket implementation is modified to 668 support priority using two thresholds for Diameter requests in the 669 set of request candidates for reduction. With two priorities, the 670 proposed Leaky bucket requires two thresholds TAU1 < TAU2: 672 o All new requests would be admitted when the leaky bucket counter 673 is at or below TAU1, 675 o Only higher priority requests would be admitted when the leaky 676 bucket counter is between TAU1 and TAU2, 678 o All requests would be rejected when the bucket counter is above 679 TAU2. 681 This can be generalized to n priorities using n thresholds for n>2 in 682 the obvious way. 684 With a priority scheme that relies on two tolerance parameters (TAU2 685 influences the priority traffic, TAU1 influences the non-priority 686 traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2). 687 Setting both tolerance parameters to the same value is equivalent to 688 having no priority. TAU1 influences the admitted rate the same way 689 as TAU does when no priority is set. And the larger the difference 690 between TAU1 and TAU2, the closer the control is to strict priority 691 queuing. 693 TAU1 and TAU2 can assume any positive real number value and is not 694 necessarily bounded by T. 696 Reasonable values for TAU0, TAU1 & TAU2 are: 698 o TAU0 = 0, 700 o TAU1 = 1/2 * TAU2, and 702 o TAU2 = 10 * T. 704 Note that specification of a value for TAU1 and TAU2, and any 705 communication or coordination between servers, is beyond the scope of 706 this document. 708 A reference algorithm is shown below. 710 Priority case: 712 // T: inter-transmission interval, set to 1 / OC-Maximum-Rate 713 // TAU1: tolerance parameter of no priority Diameter requests 714 // TAU2: tolerance parameter of priority Diameter requests 715 // ta: arrival time of the most recent arrival 716 // LCT: arrival time of last Diameter request that was sent to the server 717 // (initialized to the first arrival time) 718 // X: current value of the leaky bucket counter (initialized to 719 // TAU0) 721 // After most recent arrival, calculate auxiliary variable Xp 722 Xp = X - (ta - LCT); 724 if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived && 725 Xp <= TAU2 && Xp > TAU1) { 726 // Transmit Diameter request 727 // Update X and LCT 728 X = max (0, Xp) + T; 729 LCT = ta; 730 } else { 731 // Apply abatement treatment to Diameter request 732 // Do not update X and LCT 733 } 735 7.3.3. Optional enhancement: avoidance of resonance 737 As the number of reacting node sources of traffic increases and the 738 throughput of the reporting node decreases, the maximum rate admitted 739 by each reacting node needs to decrease, and therefore the value of T 740 becomes larger. Under some circumstances, e.g. if the traffic arises 741 very quickly simultaneously at many sources, the occupancies of each 742 bucket can become synchronized, resulting in the admissions from each 743 source being close in time and batched or very 'peaky' arrivals at 744 the reporting node, which not only gives rise to control instability, 745 but also very poor delays and even lost messages. An appropriate 746 term for this is 'resonance' [Erramilli]. 748 If the network topology is such that resonance can occur, then a 749 simple way to avoid resonance is to randomize the bucket occupancy at 750 two appropriate points -- at the activation of control and whenever 751 the bucket empties -- as described below. 753 After updating the value of the leaky bucket to X', generate a value 754 u as follows: 756 if X' > 0, then u=0 758 else if X' <= 0, then let u be set to a random value uniformly 759 distributed between -1/2 and +1/2 760 Then (only) if the arrival is admitted, increase the bucket by an 761 amount T + uT, which will therefore be just T if the bucket hadn't 762 emptied, or lie between T/2 and 3T/2 if it had. 764 This randomization should also be done when control is activated, 765 i.e. instead of simply initializing the leaky bucket counter to TAU0, 766 initialize it to TAU0 + uT, where u is uniformly distributed as 767 above. Since activation would have been a result of response to a 768 request sent by the reacting node, the second term in this expression 769 can be interpreted as being the bucket increment following that 770 admission. 772 This method has the following characteristics: 774 o If TAU0 is chosen to be equal to TAU and all sources activate 775 control at the same time due to an extremely high request rate, 776 then the time until the first request admitted by each reacting 777 node would be uniformly distributed over [0,T]; 779 o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without 780 randomization; 782 o For the special case of 'classic gapping' where TAU=0, then the 783 minimum time between admissions is uniformly distributed over 784 [T/2, 3T/2], and the mean time between admissions is the same, 785 i.e. T+1/R where R is the request arrival rate. 787 o At high load randomization rarely occurs, so there is no loss of 788 precision of the admitted rate, even though the randomized 789 'phasing' of the buckets remains. 791 8. IANA Consideration 793 TBD 795 9. Security Considerations 797 Agent overload is an extension to the based Diameter overload 798 mechanism. As such, all of the security considerations outlined in 799 [I-D.ietf-dime-ovli] apply to the agent overload scenarios. 801 10. Acknowledgements 803 11. References 804 11.1. Normative References 806 [I-D.ietf-dime-agent-overload] 807 Donovan, S., "Diameter Agent Overload", draft-ietf-dime- 808 agent-overload-00 (work in progress), December 2014. 810 [I-D.ietf-dime-ovli] 811 Korhonen, J., Donovan, S., Campbell, B., and L. Morand, 812 "Diameter Overload Indication Conveyance", draft-ietf- 813 dime-ovli-08 (work in progress), February 2015. 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 819 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 820 May 2008. 822 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 823 "Diameter Base Protocol", RFC 6733, October 2012. 825 11.2. Informative References 827 [RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol 828 (SIP) Rate Control", RFC 7415, February 2015. 830 Authors' Addresses 832 Steve Donovan (editor) 833 Oracle 834 17210 Campbell Road 835 Dallas, Texas 75254 836 United States 838 Email: srdonovan@usdonovans.com 840 Eric Noel 841 AT&T Labs 842 200s Laurel Avenue 843 Middletown, NJ 07747 844 United States 846 Email: ecnoel@research.att.com