idnits 2.17.1 draft-ietf-dime-doic-rate-control-11.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC7683], [RFC8174]), 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 (February 11, 2019) is 1901 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) -- Looks like a reference, but probably isn't: '0' on line 802 == Missing Reference: 'T' is mentioned on line 802, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-dime-agent-overload-00 Summary: 1 error (**), 0 flaws (~~), 3 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: August 15, 2019 AT&T Labs 6 February 11, 2019 8 Diameter Overload Rate Control 9 draft-ietf-dime-doic-rate-control-11 11 Abstract 13 This specification documents an extension to the Diameter Overload 14 Indication Conveyance (DOIC) [RFC7683] base solution. This extension 15 adds a new overload control abatement algorithm. This abatement 16 algorithm allows for a DOIC reporting node to specify a maximum rate 17 at which a DOIC reacting node sends Diameter requests to the DOIC 18 reporting node. 20 Requirements 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 24 "OPTIONAL" in this document are to be interpreted as described in BCP 25 14 [RFC2119] [RFC8174] when, and only when, they appear in all 26 capitals, as shown here. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 15, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Interaction with DOIC Report Types . . . . . . . . . . . . . 5 65 4. Capability Announcement . . . . . . . . . . . . . . . . . . . 6 66 5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6 67 5.1. Reporting Node Overload Control State . . . . . . . . . . 6 68 5.2. Reacting Node Overload Control State . . . . . . . . . . 7 69 5.3. Reporting Node Maintenance of Overload Control State . . 7 70 5.4. Reacting Node Maintenance of Overload Control State . . . 8 71 5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8 72 5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 9 73 6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9 74 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9 75 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9 76 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10 78 6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 10 79 7. Rate-Based Abatement Algorithm . . . . . . . . . . . . . . . 10 80 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11 82 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 83 7.3.1. Default Algorithm for Rate-based Control . . . . . . 12 84 7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 15 85 7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17 86 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18 87 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 88 8.2. OC-Supported-Features . . . . . . . . . . . . . . . . . . 18 89 8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 19 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 11.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 This document defines a new Diameter overload control abatement 100 algorithm, the "rate" algorithm. 102 The base Diameter overload specification [RFC7683] defines the "loss" 103 algorithm as the default Diameter overload abatement algorithm. The 104 loss algorithm allows a reporting node (see Section 2) to instruct a 105 reacting node (see Section 2) to reduce the amount of traffic sent to 106 the reporting node by abating (diverting or throttling) a percentage 107 of requests sent to the server. While this can effectively decrease 108 the load handled by the server, it does not directly address cases 109 where the rate of arrival of service requests changes quickly. For 110 instance, if the service requests that result in Diameter 111 transactions increase quickly then the loss algorithm cannot 112 guarantee the load presented to the server remains below a specific 113 rate level. The loss algorithm can be slow to ensure the stability 114 of reporting nodes when subjected to rapidly-changing loads. The 115 "loss" algorithm errs both in throttling too much when there is a dip 116 in offered load, and throttling not enough when there is a spike in 117 offered load. 119 Consider the case where a reacting node is handling 100 service 120 requests per second, where each of these service requests results in 121 one Diameter transaction being sent to a reporting node. If the 122 reporting node is approaching an overload state, or is already in an 123 overload state, it will send a Diameter overload report requesting a 124 percentage reduction in traffic sent when the loss algorithm is used 125 as Diameter overload abatement algorithm. Assume for this discussion 126 that the reporting node requests a 10% reduction. The reacting node 127 will then abate (diverting or throttling) ten Diameter transactions a 128 second, sending the remaining 90 transactions per second to the 129 reporting node. 131 Now assume that the reacting node's service requests spikes to 1000 132 requests per second. The reacting node will continue to honor the 133 reporting node's request for a 10% reduction in traffic. This 134 results, in this example, in the reacting node sending 900 Diameter 135 transactions per second, abating the remaining 100 transactions per 136 second. This spike in traffic is significantly higher than the 137 reporting node is expecting to handle and can result in negative 138 impacts to the stability of the reporting node. 140 The reporting node can, and likely would, send another overload 141 report requesting that the reacting node abate 91% of requests to get 142 back to the desired 90 transactions per second. However, once the 143 spike has abated and the reacting node handled service requests 144 returns to 100 per second, this will result in just 9 transactions 145 per second being sent to the reporting node, requiring a new overload 146 report setting the reduction percentage back to 10%. This control 147 feedback loop has the potential to make the situation worse by 148 causing wide fluctuations in traffic on multiple nodes in the 149 Diameter network. 151 One of the benefits of a rate-based algorithm over the loss algorithm 152 is that it better handles spikes in traffic. Instead of sending a 153 request to reduce traffic by a percentage, the rate approach allows 154 the reporting node to specify the maximum number of Diameter requests 155 per second that can be sent to the reporting node. For instance, in 156 this example, the reporting node could send a rate-based request 157 specifying the maximum transactions per second to be 90. The 158 reacting node will send the 90 regardless of whether it is receiving 159 100 or 1000 service requests per second. 161 It should be noted that one of the implications of the rate-based 162 algorithm is that the reporting node needs to determine how it wants 163 to distribute its load over the set of reacting nodes from which it 164 is receiving traffic. For instance, if the reporting node is 165 receiving Diameter traffic from 10 reacting nodes and has a capacity 166 of 100 transactions per second then the reporting node could choose 167 to set the rate for each of the reacting nodes to 10 transactions per 168 second. This, of course, is assuming that each of the reacting nodes 169 has equal performance characteristics. The reporting node could also 170 choose to have a high capacity reacting node send 55 transactions per 171 second and the remaining 9 low capacity reacting nodes send 5 172 transactions per second. The ability of the reporting node to 173 specify the amount of traffic on a per-reacting-node basis implies 174 that the reporting node must maintain state for each of the reacting 175 nodes. This state includes the current allocation of Diameter 176 traffic to that reacting node. If the number of reacting nodes 177 changes, either because new nodes are added, nodes are removed from 178 service or nodes fail, then the reporting node will need to 179 redistribute the maximum Diameter transactions over the new set of 180 reacting nodes. 182 This document extends the base Diameter Overload Indication 183 Conveyance (DOIC) solution [RFC7683] to add support for the rate- 184 based overload abatement algorithm. 186 This document draws heavily on work in the SIP Overload Control 187 working group. The definition of the rate abatement algorithm is 188 copied almost verbatim from the SIP Overload Control (SOC) document 189 [RFC7415], with changes focused on making the wording consistent with 190 the DOIC solution and the Diameter protocol. 192 2. Terminology 194 Diameter Node 196 A Diameter Client, Diameter Server, or Diameter Agent. [RFC6733] 198 Diameter Endpoint 200 A Diameter Client or Diameter Server. [RFC6733] 202 DOIC Node 204 A Diameter Node that supports the DOIC solution defined in 205 [RFC7683]. 207 Reporting Node 209 A DOIC Node that sends a DOIC overload report. 211 Reacting Node 213 A DOIC Node that receives and acts on a DOIC overload report. 215 3. Interaction with DOIC Report Types 217 As of the publication of this specification, there are two DOIC 218 report types defined with the specification of a third in progress: 220 HOST_REPORT 0 Overload of a specific Diameter Application at a 221 specific Diameter Node as defined in [RFC7683] 223 REALM_REPORT 1 Overload of a specific Diameter Application at a 224 specific Diameter Realm as defined in [RFC7683] 226 PEER_REPORT 2 Overload of a specific Diameter peer as defined in 227 [I-D.ietf-dime-agent-overload] 229 The rate algorithm MAY be selected by reporting nodes for any of 230 these report types. 232 It is expected that all report types defined in the future will 233 indicate whether or not the rate algorithm can be used with that 234 report type. 236 4. Capability Announcement 238 This document defines the rate abatement algorithm (referred to as 239 rate in this document) feature. Support for the rate feature by a 240 DOIC node will be indicated by a new value of the OC-Feature-Vector 241 AVP, as described in Section 6.1.1, per the rules defined in 242 [RFC7683]. 244 Since all nodes that support DOIC are required to support the loss 245 algorithm, DOIC nodes supporting the rate feature will support both 246 the loss and rate-based abatement algorithms. 248 DOIC reacting nodes supporting the rate feature MUST indicate support 249 for both the loss and rate algorithms in the OC-Feature-Vector AVP 250 and MAY indicate support for other algorithms. 252 As defined in [RFC7683], a DOIC reporting node supporting the rate 253 feature selects a single abatement algorithm in the OC-Feature-Vector 254 AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC 255 reacting nodes. 257 A reporting node can select one abatement algorithm to apply to host 258 and realm reports and a different algorithm to apply to peer reports. 260 For host or realm reports the selected algorithm is reflected in 261 the OC-Feature-Vector AVP sent as part of the OC-Supported- 262 Features AVP included in answer messages for transaction where the 263 request contained an OC-Supported-Features AVP. This is per the 264 procedures defined in [RFC7683]. 266 For peer reports the selected algorithm is reflected in the OC- 267 Peer-Algo AVP sent as part of the OC-Supported-Features AVP 268 included answer messages for transactions where the request 269 contained an OC-Supported-Features AVP. This is per the 270 procedures defined in [I-D.ietf-dime-agent-overload]. 272 5. Overload Report Handling 274 This section describes any changes to the behavior defined in 275 [RFC7683] for handling of overload reports when the rate overload 276 abatement algorithm is used. 278 5.1. Reporting Node Overload Control State 280 A reporting node that uses the rate abatement algorithm SHOULD 281 maintain reporting node Overload Control State (OCS) for each 282 reacting node to which it sends a rate Overload Report (OLR). 284 This is different from the behavior defined in [RFC7683] where a 285 reporting node sends a single loss percentage to all reacting 286 nodes. 288 A reporting node SHOULD maintain OCS entries when using the rate 289 abatement algorithm per supported Diameter application, per targeted 290 reacting node and per report type. 292 A rate OCS entry is identified by the tuple of Application-Id, report 293 type and DiameterIdentity of the target of the rate OLR. 295 The rate OCS entry SHOULD include the rate allocated to the reacting 296 note. 298 A reporting node that has selected the rate overload abatement 299 algorithm MUST indicate the rate requested to be applied by DOIC 300 reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP. 302 All other elements for the OCS defined in [RFC7683] and 303 [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS 304 when using the rate abatement algorithm. 306 5.2. Reacting Node Overload Control State 308 A reacting node that supports the rate abatement algorithm MUST 309 indicate rate as the selected abatement algorithm in the reacting 310 node OCS based on the OC-Feature-Vector AVP or the OC-Peer-Algo AVP 311 in the received OC-Supported-Features AVP. 313 A reacting node that supports the rate abatement algorithm MUST 314 include the rate specified in the OC-Maximum-Rate AVP included in the 315 OC-OLR AVP as an element of the abatement-algorithm-specific portion 316 of reacting node OCS entries. 318 All other elements for the OCS defined in [RFC7683] and 319 [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS 320 when using the rate abatement algorithm. 322 5.3. Reporting Node Maintenance of Overload Control State 324 A reporting node that has selected the rate overload abatement 325 algorithm and enters an overload condition MUST indicate rate as the 326 abatement algorithm and MUST indicate the selected rate in the 327 resulting reporting node OCS entries. 329 When selecting the rate algorithm in the response to a request that 330 contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP 331 indicating support for the rate feature, a reporting node MUST ensure 332 that a reporting node OCS entry exists for the target of the overload 333 report. The target is defined as follows: 335 o For Host reports, the target is the DiameterIdentity contained in 336 the Origin-Host AVP received in the request. 338 o For Realm reports, the target is the DiameterIdentity contained in 339 the Origin-Realm AVP received in the request. 341 o For Peer reports, the target is the DiameterIdentity of the 342 Diameter Peer from which the request was received. 344 A reporting node that receives a capability announcement from a new 345 reacting node, meaning a reacting node for which it does not have an 346 OCS entry, and the reporting node chooses the rate algorithm for that 347 reacting node may need to recalculate the rate to be allocated to all 348 reacting nodes. Any changed rate values will be communicated in the 349 next OLR sent to each reacting node. 351 5.4. Reacting Node Maintenance of Overload Control State 353 When receiving an answer message indicating that the reporting node 354 has selected the rate algorithm, a reacting node MUST indicate the 355 rate abatement algorithm in the reacting node OCS entry for the 356 reporting node. 358 A reacting node receiving an overload report for the rate abatement 359 algorithm MUST save the rate received in the OC-Maximum-Rate AVP 360 contained in the OC-OLR AVP in the reacting node OCS entry. 362 5.5. Reporting Node Behavior for Rate Abatement Algorithm 364 When in an overload condition with rate selected as the overload 365 abatement algorithm and when handling a request that contained an OC- 366 Supported-Features AVP that indicated support for the rate abatement 367 algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate 368 algorithm using the parameters stored in the reporting node OCS for 369 the target of the overload report. 371 Note: It is also possible for the reporting node to send overload 372 reports with the rate algorithm indicated even when the reporting 373 node is not in an overloaded state. This could be a strategy to 374 proactively avoid entering into an overloaded state. Whether to 375 do so is up to local policy. 377 When sending an overload report for the rate algorithm, the OC- 378 Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC- 379 Reduction-Percentage AVP MUST NOT be included. 381 5.6. Reacting Node Behavior for Rate Abatement Algorithm 383 When determining if abatement treatment should be applied to a 384 request being sent to a reporting node that has selected the rate 385 overload abatement algorithm, the reacting node can choose to use the 386 algorithm detailed in Section 7. 388 Other algorithms for controlling the rate MAY be implemented by the 389 reacting node. Any algorithm implemented MUST correctly limit the 390 maximum rate of traffic being sent to the reporting node. 392 Once a determination is made by the reacting node that an individual 393 Diameter request is to be subjected to abatement treatment then the 394 procedures for throttling and diversion defined in [RFC7683] and 395 [I-D.ietf-dime-agent-overload] apply. 397 6. Rate Abatement Algorithm AVPs 399 6.1. OC-Supported-Features AVP 401 The rate algorithm does not add any new AVPs to the OC-Supported- 402 Features AVP. 404 The rate algorithm does add a new feature bit to be carried in the 405 OC-Feature-Vector AVP. 407 6.1.1. OC-Feature-Vector AVP 409 This extension adds the following capability to the OC-Feature-Vector 410 AVP. 412 OLR_RATE_ALGORITHM (bit 2) 414 Bit 2 is assigned to the rate overload abatement algorithm. When 415 this flag is set by the overload control endpoint it indicates 416 that the DOIC Node supports the rate overload abatement algorithm. 418 6.2. OC-OLR AVP 420 This extension defines the OC-Maximum-Rate AVP to be an optional part 421 of the OC-OLR AVP. 423 OC-OLR ::= < AVP Header: TBD2 > 424 < OC-Sequence-Number > 425 < OC-Report-Type > 426 [ OC-Reduction-Percentage ] 427 [ OC-Validity-Duration ] 428 [ SourceID ] 429 [ OC-Maximum-Rate ] 430 * [ AVP ] 432 This extension makes no changes to the other AVPs that are part of 433 the OC-OLR AVP. 435 This extension does not define new overload report types. The 436 existing report types of host and realm defined in [RFC7683] apply to 437 the rate control algorithm. The peer report type defined in 438 [I-D.ietf-dime-agent-overload] also applies to the rate control 439 algorithm. 441 6.2.1. OC-Maximum-Rate AVP 443 The OC-Maximum-Rate AVP (AVP code TBD1) is of type Unsigned32 and 444 describes the maximum rate that the sender is requested to send 445 traffic. This is specified in terms of requests per second. 447 A value of zero indicates that no traffic is to be sent. 449 6.3. Attribute Value Pair Flag Rules 451 +---------+ 452 |AVP flag | 453 |rules | 454 +----+----+ 455 AVP Section | |MUST| 456 Attribute Name Code Defined Value Type |MUST| NOT| 457 +---------------------------------------------------------+----+----+ 458 |OC-Maximum-Rate TBD1 6.2 Unsigned32 | | V | 459 +---------------------------------------------------------+----+----+ 461 7. Rate-Based Abatement Algorithm 463 This section is pulled from [RFC7415], with minor changes needed to 464 make it apply to the Diameter protocol. 466 7.1. Overview 468 The reporting node is the one protected by the overload control 469 algorithm defined here. The reacting node is the one that abates 470 traffic towards the server. 472 Following the procedures defined in [RFC7683], the reacting node and 473 reporting node signal their support for rate-based overload control. 475 Then periodically, the reporting node relies on internal measurements 476 (e.g. CPU utilization or queuing delay) to evaluate its overload 477 state and estimate a target maximum Diameter request rate in number 478 of requests per second (as opposed to target percent reduction in the 479 case of loss-based abatement). 481 When in an overloaded state, the reporting node uses the OC-OLR AVP 482 to inform reacting nodes of its overload state and of the target 483 Diameter request rate. 485 Upon receiving the overload report with a target maximum Diameter 486 request rate, each reacting node applies overload abatement for new 487 Diameter requests towards the reporting node. 489 7.2. Reporting Node Behavior 491 The actual algorithm used by the reporting node to determine its 492 overload state and estimate a target maximum Diameter request rate is 493 beyond the scope of this document. 495 However, the reporting node MUST periodically evaluate its overload 496 state and estimate a target Diameter request rate beyond which it 497 would become overloaded. The reporting node must allocate a portion 498 of the target Diameter request rate to each of its reacting nodes. 499 The reporting node may set the same rate for every reacting node, or 500 may set different rates for different reacting node. 502 The maximum rate determined by the reporting node for a reacting node 503 applies to the entire stream of Diameter requests, even though 504 abatement may only affect a particular subset of the requests, since 505 the reacting node might apply priority as part of its decision of 506 which requests to abate. 508 When setting the maximum rate for a particular reacting node, the 509 reporting node may need take into account the workload (e.g. CPU 510 load per request) of the distribution of message types from that 511 reacting node. Furthermore, because the reacting node may prioritize 512 the specific types of messages it sends while under overload 513 restriction, this distribution of message types may be different from 514 the message distribution for that reacting node under non-overload 515 conditions (e.g., either higher or lower CPU load). 517 Note that the value of OC-Maximum-Rate AVP (in request messages per 518 second) for the rate algorithm provides a loose upper bound on the 519 traffic sent by the reacting node to the reporting node. 521 In other words, when multiple reacting nodes are being controlled by 522 an overloaded reporting node, at any given time, some reporting nodes 523 may receive requests at a rate below its target maximum Diameter 524 request rate while others above that target rate. But the resulting 525 request rate presented to the overloaded reporting node will converge 526 towards the target Diameter request rate or a lower rate. 528 Upon detection of overload, and the determination to invoke overload 529 controls, the reporting node follows the specifications in [RFC7683] 530 to notify its clients of the allocated target maximum Diameter 531 request rate and to notify them that the rate overload abatement is 532 in effect. 534 The reporting node uses the OC-Maximum-Rate AVP defined in this 535 specification to communicate a target maximum Diameter request rate 536 to each of its clients. 538 7.3. Reacting Node Behavior 540 7.3.1. Default Algorithm for Rate-based Control 542 A reference algorithm is shown below. 544 Note that use of // below inidcates a comment. 546 No priority case: 548 // T: inter-transmission interval, set to 1 / OC-Maximum-Rate 549 // TAU: tolerance parameter 550 // ta: arrival time of the most recent arrival 551 // LCT: arrival time of last Diameter request that 552 // was sent to the server 553 // (initialized to the first arrival time) 554 // X: current value of the leaky bucket counter (initialized to 555 // TAU0) 557 // After most recent arrival, calculate auxiliary variable Xp 558 Xp = X - (ta - LCT); 560 if (Xp <= TAU) { 561 // Transmit Diameter request 562 // Update X and LCT 563 X = max (0, Xp) + T; 564 LCT = ta; 565 } else { 566 // Reject Diameter request 567 // Do not update X and LCT 568 } 570 In determining whether or not to transmit a specific message, the 571 reacting node can use any algorithm that limits the message rate to 572 the OC-Maximum-Rate AVP value in units of messages per second. For 573 ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target 574 inter-Diameter request interval. It may be strictly deterministic, 575 or it may be probabilistic. It may, or may not, have a tolerance 576 factor, to allow for short bursts, as long as the long term rate 577 remains below 1/T. 579 The algorithm may have provisions for prioritizing traffic. 581 If the algorithm requires other parameters (in addition to "T", which 582 is 1/OC-Maximum-Rate), they may be set autonomously by the reacting 583 node, or they may be negotiated independently between reacting node 584 and reporting node. 586 In either case, the coordination is out of scope for this document. 587 The default algorithms presented here (one with and one without 588 provisions for prioritizing traffic) are only examples. 590 To apply abatement treatment to new Diameter requests at the rate 591 specified in the OC-Maximum-Rate AVP value sent by the reporting node 592 to its reacting nodes, the reacting node MAY use the proposed default 593 algorithm for rate-based control or any other equivalent algorithm 594 that forward messages in conformance with the upper bound of 1/T 595 messages per second. 597 The default Leaky Bucket algorithm presented here is based on [ITU-T 598 Rec. I.371] Appendix A.2. The algorithm makes it possible for 599 reacting nodes to deliver Diameter requests at a rate specified in 600 the OC-Maximum-Rate value with tolerance parameter TAU (preferably 601 configurable). 603 Conceptually, the Leaky Bucket algorithm can be viewed as a finite 604 capacity bucket whose real-valued content drains out at a continuous 605 rate of 1 unit of content per time unit and whose content increases 606 by the increment T for each forwarded Diameter request. T is 607 computed as the inverse of the rate specified in the OC-Maximum-Rate 608 AVP value, namely T = 1 / OC-Maximum-Rate. 610 Note that when the OC-Maximum-Rate value is 0 with a non-zero OC- 611 Validity-Duration, then the reacting node should apply abatement 612 treatment to 100% of Diameter requests destined to the overloaded 613 reporting node. However, when the OC-Validity-Duration value is 0, 614 the reacting node should stop applying abatement treatment. 616 If, at a new Diameter request arrival, the content of the bucket is 617 less than or equal to the limit value TAU, then the Diameter request 618 is forwarded to the server; otherwise, the abatement treatment is 619 applied to the Diameter request. 621 Note that the capacity of the bucket (the upper bound of the counter) 622 is (T + TAU). 624 The tolerance parameter TAU determines how close the long-term 625 admitted rate is to an ideal control that would admit all Diameter 626 requests for arrival rates less than 1/T and then admit Diameter 627 requests precisely at the rate of 1/T for arrival rates above 1/T. 628 In particular at mean arrival rates close to 1/T, it determines the 629 tolerance to deviation of the inter-arrival time from T (the larger 630 TAU the more tolerance to deviations from the inter-departure 631 interval T). 633 This deviation from the inter-departure interval influences the 634 admitted rate burstyness, or the number of consecutive Diameter 635 requests forwarded to the reporting node (burst size proportional to 636 TAU over the difference between 1/T and the arrival rate). 638 In situations where reacting nodes are configured with some knowledge 639 about the reporting node and other traffic sources (e.g., operator 640 pre-provisioning), it can be beneficial to choose a value of TAU 641 based on how many reacting nodes will be sending requests to the 642 reporting node. 644 Reporting nodes with a very large number of reacting nodes, each with 645 a relatively small arrival rate, will generally benefit from a 646 smaller value for TAU in order to limit queuing (and hence response 647 times) at the reporting node when subjected to a sudden surge of 648 traffic from all reacting nodes. Conversely, a reporting node with a 649 relatively small number of reacting nodes, each with proportionally 650 larger arrival rate, will benefit from a larger value of TAU. 652 Once the control has been activated, at the arrival time of the k-th 653 new Diameter request, ta(k), the content of the bucket is 654 provisionally updated to the value 656 X' = X - (ta(k) - LCT) 658 where X is the value of the leaky bucket counter after arrival of the 659 last forwarded Diameter request, and LCT is the time at which the 660 last Diameter request was forwarded. 662 If X' is less than or equal to the limit value TAU, then the new 663 Diameter request is forwarded and the leaky bucket counter X is set 664 to X' (or to 0 if X' is negative) plus the increment T, and LCT is 665 set to the current time ta(k). If X' is greater than the limit value 666 TAU, then the abatement treatment is applied to the new Diameter 667 request and the values of X and LCT are unchanged. 669 When the first response from the reporting node has been received 670 indicating control activation (OC-Validity-Duration>0), LCT is set to 671 the time of activation, and the leaky bucket counter is initialized 672 to the parameter TAU0 (preferably configurable) which is 0 or larger 673 but less than or equal to TAU. 675 TAU can assume any positive real number value and is not necessarily 676 bounded by T. 678 TAU=4*T is a reasonable compromise between burst size and abatement 679 rate adaptation at low offered rate. 681 Note that specification of a value for TAU, and any communication or 682 coordination between servers, is beyond the scope of this document. 684 7.3.2. Priority Treatment 686 A reference algorithm is shown below. 688 Priority case: 690 // T: inter-transmission interval, set to 1 / OC-Maximum-Rate 691 // TAU1: tolerance parameter of no priority Diameter requests 692 // TAU2: tolerance parameter of priority Diameter requests 693 // ta: arrival time of the most recent arrival 694 // LCT: arrival time of last Diameter request that 695 // was sent to the server 696 // (initialized to the first arrival time) 697 // X: current value of the leaky bucket counter (initialized to 698 // TAU0) 700 // After most recent arrival, calculate auxiliary variable Xp 701 Xp = X - (ta - LCT); 703 if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived && 704 Xp <= TAU2 && Xp > TAU1) { 705 // Transmit Diameter request 706 // Update X and LCT 707 X = max (0, Xp) + T; 708 LCT = ta; 709 } else { 710 // Apply abatement treatment to Diameter request 711 // Do not update X and LCT 712 } 714 The reacting node is responsible for applying message priority and 715 for maintaining two categories of requests: Request candidates for 716 reduction, requests not subject to reduction (except under 717 extenuating circumstances when there aren't any messages in the first 718 category that can be reduced). 720 Accordingly, the proposed Leaky bucket implementation is modified to 721 support priority using two thresholds for Diameter requests in the 722 set of request candidates for reduction. With two priorities, the 723 proposed Leaky bucket requires two thresholds TAU1 < TAU2: 725 o All new requests would be admitted when the leaky bucket counter 726 is at or below TAU1, 728 o Only higher priority requests would be admitted when the leaky 729 bucket counter is between TAU1 and TAU2, 731 o All requests would be rejected when the bucket counter is above 732 TAU2. 734 This can be generalized to n priorities using n thresholds for n>2. 736 With a priority scheme that relies on two tolerance parameters (TAU2 737 influences the priority traffic, TAU1 influences the non-priority 738 traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2). 739 Setting both tolerance parameters to the same value is equivalent to 740 having no priority. TAU1 influences the admitted rate the same way 741 as TAU does when no priority is set. And the larger the difference 742 between TAU1 and TAU2, the closer the control is to strict priority 743 queuing. 745 TAU1 and TAU2 can assume any positive real number value and is not 746 necessarily bounded by T. 748 Reasonable values for TAU0, TAU1 & TAU2 are: 750 o TAU0 = 0, 752 o TAU1 = 1/2 * TAU2, and 754 o TAU2 = 10 * T. 756 Note that specification of a value for TAU1 and TAU2, and any 757 communication or coordination between servers, is beyond the scope of 758 this document. 760 7.3.3. Optional Enhancement: Avoidance of Resonance 762 As the number of reacting node sources of traffic increases and the 763 throughput of the reporting node decreases, the maximum rate admitted 764 by each reacting node needs to decrease, and therefore the value of T 765 becomes larger. Under some circumstances, e.g. if the traffic arises 766 very quickly simultaneously at many sources, the occupancies of each 767 bucket can become synchronized, resulting in the admissions from each 768 source being close in time and batched or very 'peaky' arrivals at 769 the reporting node, which not only gives rise to control instability, 770 but also very poor delays and even lost messages. An appropriate 771 term for this is 'resonance' [Erramilli]. 773 If the network topology is such that resonance can occur, then a 774 simple way to avoid resonance is to randomize the bucket occupancy at 775 two appropriate points -- at the activation of control and whenever 776 the bucket empties -- as described below. 778 After updating the value of the leaky bucket to X', generate a value 779 u as follows: 781 if X' > 0, then u=0 783 else if X' <= 0, then let u be set to a random value uniformly 784 distributed between -1/2 and +1/2 785 Then (only) if the arrival is admitted, increase the bucket content 786 by an amount T + uT, which will therefore be just T if the bucket 787 hadn't emptied, or lie between T/2 and 3T/2 if it had. 789 This randomization should also be done when control is activated, 790 i.e. instead of simply initializing the leaky bucket counter to TAU0, 791 initialize it to TAU0 + uT, where u is uniformly distributed as 792 above. Since activation would have been a result of response to a 793 request sent by the reacting node, the second term in this expression 794 can be interpreted as being the bucket increment following that 795 admission. 797 This method has the following characteristics: 799 o If TAU0 is chosen to be equal to TAU and all sources activate 800 control at the same time due to an extremely high request rate, 801 then the time until the first request admitted by each reacting 802 node would be uniformly distributed over [0,T]; 804 o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without 805 randomization; 807 o For the special case of 'classic gapping' where TAU=0, then the 808 minimum time between admissions is uniformly distributed over 809 [T/2, 3T/2], and the mean time between admissions is the same, 810 i.e. T+1/R where R is the request arrival rate. 812 o At high load randomization rarely occurs, so there is no loss of 813 precision of the admitted rate, even though the randomized 814 'phasing' of the buckets remains. 816 8. IANA Consideration 818 8.1. AVP Codes 820 New AVPs defined by this specification are listed in Section 6. All 821 AVP codes are allocated from the 'Authentication, Authorization, and 822 Accounting (AAA) Parameters' AVP Codes registry. 824 8.2. OC-Supported-Features 826 As indicated in Section 6.1.1, a new allocation is required in the 827 OC-Feature-Vector AVP. 829 8.3. New DOIC report types 831 All DOIC report types defined in the future MUST indicate whether or 832 not the rate algorithm can be used with that report type. 834 9. Security Considerations 836 The rate overload abatement mechanism is an extension to the base 837 Diameter overload mechanism. As such, all of the security 838 considerations outlined in [RFC7683] apply to the rate overload 839 abatement mechanism. 841 In addition, the rate algorithm could be used to handle DoS attacks 842 more effectively than the loss algorithm. 844 10. Acknowledgements 846 Lionel Morand for his contributions to the document. 848 11. References 850 11.1. Normative References 852 [I-D.ietf-dime-agent-overload] 853 Donovan, S., "Diameter Agent Overload", draft-ietf-dime- 854 agent-overload-00 (work in progress), December 2014. 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, 858 DOI 10.17487/RFC2119, March 1997, 859 . 861 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 862 Ed., "Diameter Base Protocol", RFC 6733, 863 DOI 10.17487/RFC6733, October 2012, 864 . 866 [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. 867 Morand, "Diameter Overload Indication Conveyance", 868 RFC 7683, DOI 10.17487/RFC7683, October 2015, 869 . 871 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 872 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 873 May 2017, . 875 11.2. Informative References 877 [Erramilli] 878 Erramilli, A. and L. Forys, "Traffic Synchronization 879 Effects In Teletraffic Systems", 1991. 881 [RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol 882 (SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415, 883 February 2015, . 885 Authors' Addresses 887 Steve Donovan (editor) 888 Oracle 889 7460 Warren Pkwy # 300 890 Frisco, Texas 75034 891 United States 893 Email: srdonovan@usdonovans.com 895 Eric Noel 896 AT&T Labs 897 200s Laurel Avenue 898 Middletown, NJ 07747 899 United States 901 Email: ecnoel@research.att.com