idnits 2.17.1 draft-ietf-dime-doic-rate-control-00.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]), 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 (December 17, 2014) is 3390 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: 'DOIC' is mentioned on line 260, but not defined == Missing Reference: 'Erramilli' is mentioned on line 733, but not defined -- Looks like a reference, but probably isn't: '0' on line 763 == Missing Reference: 'T' is mentioned on line 763, but not defined == Unused Reference: 'RFC5226' is defined on line 802, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 806, but no explicit reference was found in the text -- No information found for draft-SOC-overload-rate-control - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.SOC-overload-rate-control' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- No information found for draft-donovan-agent-overload - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) S. Donovan 3 Internet-Draft Oracle 4 Intended status: Standards Track E. Noel 5 Expires: June 20, 2015 AT&T Labs 6 December 17, 2014 8 Diameter Overload Rate Control 9 draft-ietf-dime-doic-rate-control-00.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 sent 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 June 20, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 8 73 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9 74 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2.1. OC-Rate AVP . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 14 83 7.3.3. Optional enhancement: avoidance of resonance . . . . 16 84 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 11.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 This document defines a new Diameter overload control algorithm. 96 The base Diameter overload specification [I-D.ietf-dime-ovli] defines 97 the loss algorithm as the default Diameter overload abatement 98 algorithm. The loss algorithm allows a reporting node to instruct a 99 reacting node to reduce the amount of traffic sent to the reporting 100 node by throttling a percentage of requests sent to the server. 101 While this can effectively decrease the load handled by the server, 102 it does not directly address cases where the rate of arrival of 103 service requests increase quickly. If the service requests that 104 result in Diameter transactions increases quickly then the loss 105 algorithm can be slow to protect the stability of reporting nodes. 107 Consider the case where a reacting node is handling 100 service 108 requests per second, where each of these service requests results in 109 one Diameter transaction being sent to a reacting node. If the 110 reacting node is approaching an overload state, or is already in an 111 overload state, it will send a Diameter overload report requesting a 112 percentage reduction in traffic sent. Assume for this discussion 113 that the reporting node requests a 10% reduction. The reacting node 114 will then throttle ten Diameter transactions a second, sending the 115 remaining 90 transactions per second to the reacting node. 117 Now assume that the reacting node's service requests spikes to 1000 118 requests per second. The reacting node will continue to honor the 119 reporting nodes request to throttle 10% of the traffic. This 120 results, in this example, in the reacting node sending 900 Diameter 121 transactions per second, throttling the remaining 100 transactions 122 per second. This spike in traffic is significantly higher than the 123 reporting node is expecting to handle and can result in negative 124 impacts to the stability of the reporting node. 126 The reporting node can, and likely would, send another overload 127 report requesting that the reacting node throttle 91% of requests to 128 get back to the desired 90 transactions per second. However, once 129 the spike has abated and the reacting node handled service requests 130 returns to 100 per second, this will result in just 9 transactions 131 per second being sent to the reporting node, requiring a new overload 132 report setting the reduction percentage back to 10%. 134 One of the benefits of a rate based algorithm is that it better 135 handles spikes in traffic. Instead of sending a request to throttle 136 a percentage of the traffic, the rate approach allows the reporting 137 node to specify the maximum number of Diameter requests per second 138 that can be sent to the reporting node. For instance, in this 139 example, the reporting node could send a rate based request 140 specifying the maximum transactions per second to be 90. The 141 reacting noce will send the 90 regardless of whether it is receiving 142 100 or 1000 service requests per second. 144 This document extends the base DOIC solution [I-D.ietf-dime-ovli] to 145 add support for the rate based overload abatement algorithm. 147 This document draws heavily on work in the RIA SIP Overload Control 148 working group. The definitions of the rate abatement algorithmm is 149 copied almost verbatim from the SOC document 150 [I-D.SOC-overload-rate-control], with changes focused on making the 151 wording consistent with the DOIC solution and the Diameter protocol. 153 Editor's Note: Need to verify that the latest text from the SOC 154 document is currently being used. 156 2. Terminology and Abbreviations 158 Diameter Node 160 A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 161 Diameter Agent. 163 Diameter Endpoint 165 An RFC6733 Diameter Client and RFC6733 Diameter Server. 167 DOIC Node 169 A Diameter Node that supports the DOIC solution defined in 170 [I-D.ietf-dime-ovli]. 172 Reporting Node 174 A DOIC Node that sends a DOIC overload report. 176 Reacting Node 178 A DOIC Node that receives and acts on a DOIC overload report. 180 3. Interaction with DOIC report types 182 As of the publication of this specification there are two DOIC report 183 types defined with the specification of a third in progress: 185 1. Host - Overload of a specific Diameter Application at a specific 186 Diameter Node as defined in [I-D.ietf-dime-ovli]. 188 2. Realm - Overlaod of a specific Diameter Application at a specific 189 Diameter Realm as defined in [I-D.ietf-dime-ovli]. 191 3. Peer - Overload of a specific Diameter peer as defined in 192 [I-D.donovan-agent-overload]. 194 The rate algorithm MAY be selected by reporting nodes for any of 195 these report types. 197 It is expected that all report types defined in the future will 198 indicate whether or not the rate algorithm can be used with that 199 report type. 201 4. Capability Announcement 203 Editors Note: This section depends upon the completion of the base 204 Diameter Overload specification. As such, it cannot be complete 205 until the data model and extension mechanism are finalized in the 206 base DOC specification. Details for any new AVPs or modifications to 207 existing AVPs will be finalized in a future version of the draft 208 after the base DOC specification has stabilized. 210 This extension defines the rate abatement algorithm (referred to as 211 rate in this document) feature. Support for the rate feature will be 212 reflected by use of a new value, as defined in Section 6.1.1, in the 213 OC-Feature-Vector AVP per the rules defined in [I-D.ietf-dime-ovli]. 215 Note that Diameter nodes that support the rate feature will, by 216 definition, support both the loss and rate based abatement 217 algorithms. DOIC reacting nodes SHOULD indicate support for both the 218 loss and rate algorithms in the OC-Feature-Vector AVP. 220 There may be local policy reasons that cause a DOIC node that 221 supports the rate to not include it in the OC-Feature-Vector. All 222 reacting nodes, however, must continue to include loss in the OC- 223 Feature-Vector in order to remain compliant with 224 [I-D.ietf-dime-ovli]. 226 A reporting nodes MUST select either the rate or the loss algorithm 227 when receiving a request that contains an OC-Supported-Features AVP. 229 A reporting node MAY select one abatement algorithm to apply to host 230 and realm reports and a different algorithm to apply to peer reports. 232 For host or realm reports the selected algorithm MUST be reflected in 233 the OC-Feature-Vector AVP sent as part of the OC-Selected-Features 234 AVP included in answer messages for transaction where the request 235 contained an OC-Supported-Features AVP. This is per the precedures 236 defined in [I-D.ietf-dime-ovli]. 238 For peer reports the selected algorithm MUST be reflected in the OC- 239 Peer-Abatement-Algorithm AVP sent as part of the OC-Supported- 240 Features AVP included answer messages for transaction where the 241 request contained an OC-Supported-Features AVP. This is per the 242 procedures defined in [I-D.donovan-agent-overload]. 244 Editor's Node: The peer report specification is still under 245 development and, as such, the above paragraph is subject to 246 change. 248 5. Overload Report Handling 250 This section describes any changes to the behavior defined in 251 [I-D.ietf-dime-ovli] for handling of overload reports when the rate 252 overload abatement algorithm is used. 254 5.1. Reporting Node Overload Control State 256 A reporting node that uses the rate abatement algorithm SHOULD 257 maintain reporting node OCS for each reacting node to which it sends 258 a rate OLR. 260 This is different from the behavior defines in [DOIC] where there 261 is a single loss percentage sent to all 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 peer-id of the target of the rate OLR. 270 A reporting node that supports the rate abatement algorithm MUST be 271 able to include rate as the selected abatement algorithm in the 272 reporting node OCS. 274 A reporting node that supports the rate abatement algorithm MUST be 275 able to include the specified rate in the abatement algoritm specific 276 portion of the reporting node OCS. 278 All other elements for the OCS defined in [I-D.ietf-dime-ovli] and 279 [I-D.donovan-agent-overload] also apply to the reporting nodes OCS 280 when using the rate abatement algorithm. 282 5.2. Reacting Node Overload Control State 284 A reacting node that supports the rate abatement algorithm MUST be 285 able to include rate as the selected abatement algorithm in the 286 reacting node OCS. 288 A reacting node that supports the rate abatement algorithm MUST be 289 able to include the rate specified in the OC-Rate AVP included in the 290 OC-OLR AVP as an element of the abatement algoritm specific portion 291 of reacting node OCS entries. 293 All other elements for the OCS defined in [I-D.ietf-dime-ovli] and 294 [I-D.donovan-agent-overload] also apply to the reporting nodes OCS 295 when using the rate abatement algorithm. 297 5.3. Reporting Node Maintenance of Overload Control State 299 A reporting node that has selected the rate overload abatement 300 algorithm and enters an overload condition MUST indicate rate as the 301 abatement algorithm in the resulting reporting node OCS entries. 303 A reporting node that has selected the rate abatement algorithm and 304 enters an overload condition MUST indicate the selected rate in the 305 resulting reporting node OCS entries. 307 When responding to a request that contained an OC-Supporting-Features 308 AVP with an OC-Feature-Vector AVP indicating support for the rate 309 feature, a reporting node MUST ensure that a reporting node OCS entry 310 exists for the target of the overload report. The target is defined 311 as follows: 313 o For Host reports the target is the DiameterID contained in the 314 Origin-Host AVP received in the request. 316 o For Realm reports the target is the DiameterID contained in the 317 Origin-Realm AVP received in the request. 319 o For Peer reports the target is the Diameter ID of the Diameter 320 Peer from which the request was received. 322 5.4. Reacting Node Maintenance of Overload Control State 324 A reacting node receiving an overload report for the rate abatement 325 algorithm MUST save the rate received in the OC-Rate AVP contained in 326 the OC-OLR AVP in the reacting node OCS entry. 328 5.5. Reporting Node Behavior for Rate Abatement Algorithm 330 When in an overload condition with rate selected as the overload 331 abatement algorithm and when handling a request that contained an OC- 332 Supported-Features AVP that indicated support for the rate featre, a 333 reporting node SHOULD include an OC-OLR AVP for the rate algorithm 334 using the parameters stored in the reporting node OCS for the target 335 of the overload report. 337 Editor's Note: The above is a pretty complicated way of saying 338 that the reporting node should include an OC-OLR in the 339 appropriate answer messages. The basic requirement isn't rate 340 feature specific but rather that in all cases the reporting node 341 generates an OC-OLR according to the parameters of the appropriate 342 OCS entry. This wording probably can be improved based on the 343 generic behavior definition. 345 When sending an overload report for the Rate algorithm, the OC-Rate 346 AVP is included and the OC-Reduction-Percentage AVP is not included. 348 5.6. Reacting Node Behavior for Rate Abatement Algorithm 350 When determining if abatement treatment should be applied to a 351 request being sent to a reporting node that has selected the rate 352 overload abatement algorithm, the reacting node MUST use the the 353 algorithm detailed in Section 6 to make the determination. 355 Once a determination is made by the reacting node that an individual 356 Diameter request is to be subjected to abatement treatment then the 357 procedures for throttling and diversion defined in 358 [I-D.ietf-dime-ovli] and [I-D.donovan-agent-overload] apply. 360 6. Rate Abatement Algorithm AVPs 362 Editors Note: This section depends upon the completion of the base 363 DOIC specification. As such, it cannot be complete until the data 364 model and extension mechanism are finalized. Details for any new 365 AVPs or modifications to existing AVPs will be finalized in a future 366 version of the draft after the base DOC specification has stabilized. 368 6.1. OC-Supported-Features AVP 370 The rate algorithm does not add any AVPs to the OC-Supported-Features 371 AVP. 373 The rate algorithm does add a new feature bit to be carried in the 374 OC-Feature-Vector AVP. 376 6.1.1. OC-Feature-Vector AVP 378 This extension adds the following capabilities to the OC-Feature- 379 Vector AVP. 381 OLR_RATE_ALGORITHM (0x0000000000000004) 383 When this flag is set by the overload control endpoint it 384 indicates that the DOIC Node supports the rate overload control 385 algorithm. 387 6.2. OC-OLR AVP 389 This extension defines the OC-Rate AVP to be an optional part of the 390 OC-OLR AVP. 392 OC-OLR ::= < AVP Header: TBD2 > 393 < OC-Sequence-Number > 394 < OC-Report-Type > 395 [ OC-Reduction-Percentage ] 396 [ OC-Validity-Duration ] 397 [ OC-Source-ID ] 398 [ OC-Abatement-Algorithm ] 399 [ OC-Rate ] 400 * [ AVP ] 402 This extension makes no changes to the other AVPs that are part of 403 the OC-OLR AVP. 405 This extension does not define new overload report types. The 406 existing report types of host and realm defined in 407 [I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer 408 report time defined in [I-D.donovan-agent-overload] also applies to 409 the rate control algorithm. 411 6.2.1. OC-Rate AVP 413 The OC-Rate AVP (AVP code TBD8) is type of Unsigned32 and describes 414 the maximum rate that that the sender is requested to send traffic. 415 This is specified in terms of requests per second. 417 Editor's note: Do we need to specify a maximum value? 419 A value of zero indicates that no traffic is to be sent. 421 6.3. Attribute Value Pair flag rules 423 +---------+ 424 |AVP flag | 425 |rules | 426 +----+----+ 427 AVP Section | |MUST| 428 Attribute Name Code Defined Value Type |MUST| NOT| 429 +--------------------------------------------------------+----+----+ 430 |OC-Rate TBD1 x.x Unsigned64 | | V | 431 +--------------------------------------------------------+----+----+ 433 7. Rate Based Abatement Algorithm 435 Editor's Note: Need to scrub this section to use the reporting node 436 and reacting node terminology and remove the server and client terms 437 use for the SOC description. 439 This section is pulled from [I-D.SOC-overload-rate-control], with 440 minor changes needed to make it apply to the Diameter protocol. 442 7.1. Overview 444 The server is the one protected by the overload control algorithm 445 defined here. This is also referred to as the reporting node. The 446 client is the one that throttles traffic towards the server. This is 447 also referred to as the reacting node. 449 Following the procedures defined in [draft-ietf-dime-doic], the 450 server and clients signal one another support for rate-based overload 451 control. 453 Editor's Note: Need to scrub this section to use the reporting node 454 and reacting node terminology and remove the server and client terms. 456 Then periodically, the server relies on internal measurements (e.g. 457 CPU utilization, queueing delay...) to evaluate its overload state 458 and estimate a target Diameter request rate in number of requests per 459 second (as opposed to target percent reduction in the case of loss- 460 based abatement). 462 When in an overloaded state, the reporting node uses the OC-OLR AVP 463 to inform reacting nodes of its overload state and of the target 464 Diameter request rate. 466 Upon receiving the overload report with a target Diameter request 467 rate, each reacting node throttles new Diameter requests towards the 468 reporting node. 470 7.2. Reporting Node Behavior 472 The actual algorithm used by the reporting node to determine its 473 overload state and estimate a target Diameter request rate is beyond 474 the scope of this document. 476 However, the reporting node MUST periodically evaluate its overload 477 state and estimate a target Diameter request rate beyond which it 478 would become overloaded. The server must allocate a portion of the 479 target Diameter request rate to each of its reacting nodes. The 480 server may set the same rate for every reacting node, or may set 481 different rates for different reacting node. 483 The max rate determined by the reporting node for a reacting node 484 applies to the entire stream of Diameter requests, even though 485 throttling may only affect a particular subset of the requests, since 486 the reacting node might can apply priority as part of its decision of 487 which requests to throttle. 489 When setting the maximum rate for a particular reacting node, the 490 reporting node may need take into account the workload (e.g. cpu load 491 per request) of the distribution of message types from that reacting 492 node. Furthermore, because the reacting node may prioritize the 493 specific types of messages it sends while under overload restriction, 494 this distribution of message types may be different from the message 495 distribution for that reacting node under non-overload conditions 496 (e.g., either higher or lower cpu load). 498 Note that the AVP for the rate algorithm is an upper bound (in 499 request messages per second) on the traffic sent by the reacting node 500 to the reporting node. The reacting node may send traffic at a rate 501 significantly lower than the upper bound, for a variety of reasons. 503 In other words, when multiple reacting nodes are being controlled by 504 an overloaded reporting node, at any given time some reacting nodes 505 may receive requests at a rate below its target Diameter request rate 506 while others above that target rate. But the resulting request rate 507 presented to the overloaded reporting node will converge towards the 508 target Diameter request rate. 510 Upon detection of overload, and the determination to invoke overload 511 controls, the reporting node MUST follow the specifications in 512 [draft-ietf-dime-ovli] to notify its clients of the allocated target 513 Diameter request rate. 515 The reporting node MUST use the OC-Maximum-Rate AVP defined in this 516 specification to communicate a target Diameter request rate to each 517 of its clients. 519 7.3. Reacting Node Behavior 521 7.3.1. Default algorithm 523 In determining whether or not to transmit a specific message, the 524 reacting node may use any algorithm that limits the message rate to 525 1/T messages per second. It may be strictly deterministic, or it may 526 be probabilistic. It may, or may not, have a tolerance factor, to 527 allow for short bursts, as long as the long term rate remains below 528 1/T. The algorithm may have provisions for prioritizing traffic. 530 If the algorithm requires other parameters (in addition to "T", which 531 is 1/OC-Maximum-Rate), they may be set autonomously by the client, or 532 they may be negotiated independently between client and server. 534 In either case, the coordination is out of scope for this document. 535 The default algorithms presented here (one without provisions for 536 prioritizing traffic, one with) are only examples. Other algorithms 537 that forward messages in conformance with the upper bound of 1/T 538 messages per second may be used. 540 To throttle new Diameter requests at the rate specified in the OC- 541 Maximum-Rate AVP value sent by the reporting node to its reacting 542 nodes, the reacting node MAY use the proposed default algorithm for 543 rate-based control or any other equivalent algorithm. 545 The default Leaky Bucket algorithm presented here is based on [ITU-T 546 Rec. I.371] Appendix A.2. The algorithm makes it possible for 547 clients to deliver Diameter requests at a rate specified in the OC- 548 Maximum-Rate value with tolerance parameter TAU (preferably 549 configurable). 551 Conceptually, the Leaky Bucket algorithm can be viewed as a finite 552 capacity bucket whose real-valued content drains out at a continuous 553 rate of 1 unit of content per time unit and whose content increases 554 by the increment T for each forwarded Diameter request. T is 555 computed as the inverse of the rate specified in the OC-Maximum-Rate 556 AVP value, namely T = 1 / OC-Maximum-Rate. 558 Note that when the OC-Maximum-Rate value is 0 with a non-zero OC- 559 Validity-Duration, then the reacting node should reject 100% of 560 Diameter requests destined to the overloaded reporting node. 561 However, when the OC-Validity-Duration value is 0, the client should 562 stop throttling. 564 If, at a new Diameter request arrival, the content of the bucket is 565 less than or equal to the limit value TAU, then the Diameter request 566 is forwarded to the server; otherwise, the Diameter request is 567 rejected. 569 Note that the capacity of the bucket (the upper bound of the counter) 570 is (T + TAU). 572 The tolerance parameter TAU determines how close the long-term 573 admitted rate is to an ideal control that would admit all Diameter 574 requests for arrival rates less than 1/T and then admit Diameter 575 requests precisely at the rate of 1/T for arrival rates above 1/T. 576 In particular at mean arrival rates close to 1/T, it determines the 577 tolerance to deviation of the inter-arrival time from T (the larger 578 TAU the more tolerance to deviations from the inter-departure 579 interval T). 581 This deviation from the inter-departure interval influences the 582 admitted rate burstyness, or the number of consecutive Diameter 583 requests forwarded to the reporting node (burst size proportional to 584 TAU over the difference between 1/T and the arrival rate). 586 Reporting nodes with a very large number of clients, each with a 587 relatively small arrival rate, will generally benefit from a smaller 588 value for TAU in order to limit queuing (and hence response times) at 589 the reporting node when subjected to a sudden surge of traffic from 590 all reacting nodes. Conversely, a reporting node with a relatively 591 small number of reacting nodes, each with proportionally larger 592 arrival rate, will benefit from a larger value of TAU. 594 Once the control has been activated, at the arrival time of the k-th 595 new Diameter request, ta(k), the content of the bucket is 596 provisionally updated to the value 598 X' = X - (ta(k) - LCT) 600 where X is the value of the leaky bucket counter after arrival of the 601 last forwarded Diameter request, and LCT is the time at which the 602 last Diameter request was forwarded. 604 If X' is less than or equal to the limit value TAU, then the new 605 Diameter request is forwarded and the leaky bucket counter X is set 606 to X' (or to 0 if X' is negative) plus the increment T, and LCT is 607 set to the current time ta(k). If X' is greater than the limit value 608 TAU, then the new Diameter request is rejected and the values of X 609 and LCT are unchanged. 611 When the first response from the reporting node has been received 612 indicating control activation (OC-Validity-Duration>0), LCT is set to 613 the time of activation, and the leaky bucket counter is initialized 614 to the parameter TAU0 (preferably configurable) which is 0 or larger 615 but less than or equal to TAU. 617 TAU can assume any positive real number value and is not necessarily 618 bounded by T. 620 TAU=4*T is a reasonable compromise between burst size and throttled 621 rate adaptation at low offered rate. 623 Note that specification of a value for TAU, and any communication or 624 coordination between servers, is beyond the scope of this document. 626 A reference algorithm is shown below. 628 No priority case: 630 // T: inter-transmission interval, set to 1 / OC-Maximum-Rate 631 // TAU: tolerance parameter 632 // ta: arrival time of the most recent arrival 633 // LCT: arrival time of last SIP request that was sent to the server 634 // (initialized to the first arrival time) 635 // X: current value of the leaky bucket counter (initialized to 636 // TAU0) 638 // After most recent arrival, calculate auxiliary variable Xp 639 Xp = X - (ta - LCT); 641 if (Xp <= TAU) { 642 // Transmit SIP request 643 // Update X and LCT 644 X = max (0, Xp) + T; 645 LCT = ta; 646 } else { 647 // Reject SIP request 648 // Do not update X and LCT 649 } 651 7.3.2. Priority treatment 653 The reacting node is responsible for applying message priority and 654 for maintaining two categories of requests: Request candidates for 655 reduction, requests not subject to reduction (except under 656 extenuating circumstances when there aren't any messages in the first 657 category that can be reduced). 659 Accordingly, the proposed Leaky bucket implementation is modified to 660 support priority using two thresholds for Diameter requests in the 661 set of request candidates for reduction. With two priorities, the 662 proposed Leaky bucket requires two thresholds TAU1 < TAU2: 664 o All new requests would be admitted when the leaky bucket counter 665 is at or below TAU1, 667 o Only higher priority requests would be admitted when the leaky 668 bucket counter is between TAU1 and TAU2, 670 o All requests would be rejected when the bucket counter is above 671 TAU2. 673 This can be generalized to n priorities using n thresholds for n>2 in 674 the obvious way. 676 With a priority scheme that relies on two tolerance parameters (TAU2 677 influences the priority traffic, TAU1 influences the non-priority 678 traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2). 679 Setting both tolerance parameters to the same value is equivalent to 680 having no priority. TAU1 influences the admitted rate the same way 681 as TAU does when no priority is set. And the larger the difference 682 between TAU1 and TAU2, the closer the control is to strict priority 683 queueing. 685 TAU1 and TAU2 can assume any positive real number value and is not 686 necessarily bounded by T. 688 Reasonable values for TAU0, TAU1 & TAU2 are: TAU0 = 0, TAU1 = 1/2 * 689 TAU2 and TAU2 = 10 * T. 691 Note that specification of a value for TAU1 and TAU2, and any 692 communication or coordination between servers, is beyond the scope of 693 this document. 695 A reference algorithm is shown below. 697 Priority case: 699 // T: inter-transmission interval, set to 1 / OC-Maximum-Rate 700 // TAU1: tolerance parameter of no priority SIP requests 701 // TAU2: tolerance parameter of priority SIP requests 702 // ta: arrival time of the most recent arrival 703 // LCT: arrival time of last SIP request that was sent to the server 704 // (initialized to the first arrival time) 705 // X: current value of the leaky bucket counter (initialized to 706 // TAU0) 708 // After most recent arrival, calculate auxiliary variable Xp 709 Xp = X - (ta - LCT); 711 if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived && 712 Xp <= TAU2 && Xp > TAU1) { 713 // Transmit SIP request 714 // Update X and LCT 715 X = max (0, Xp) + T; 716 LCT = ta; 717 } else { 718 // Reject SIP request 719 // Do not update X and LCT 720 } 722 7.3.3. Optional enhancement: avoidance of resonance 724 As the number of reacting node sources of traffic increases and the 725 throughput of the reporting node decreases, the maximum rate admitted 726 by each reacting node needs to decrease, and therefore the value of T 727 becomes larger. Under some circumstances, e.g. if the traffic arises 728 very quickly simultaneously at many sources, the occupancies of each 729 bucket can become synchronized, resulting in the admissions from each 730 source being close in time and batched or very 'peaky' arrivals at 731 the reporting node, which not only gives rise to control instability, 732 but also very poor delays and even lost messages. An appropriate 733 term for this is 'resonance' [Erramilli]. 735 If the network topology is such that this can occur, then a simple 736 way to avoid this is to randomize the bucket occupancy at two 737 appropriate points: At the activation of control, and whenever the 738 bucket empties, as follows. 740 After updating the value of the leaky bucket to X', generate a value 741 u as follows: 743 if X' > 0, then u=0 745 else if X' <= 0 then uniformly distributed between -1/2 and +1/2 746 Then (only) if the arrival is admitted, increase the bucket by an 747 amount T + uT, which will therefore be just T if the bucket hadn't 748 emptied, or lie between T/2 and 3T/2 if it had. 750 This randomization should also be done when control is activated, 751 i.e. instead of simply initializing the leaky bucket counter to TAU0, 752 initialize it to TAU0 + uT, where u is uniformly distributed as 753 above. Since activation would have been a result of response to a 754 request sent by the reacting node, the second term in this expression 755 can be interpreted as being the bucket increment following that 756 admission. 758 This method has the following characteristics: 760 o If TAU0 is chosen to be equal to TAU and all sources were to 761 activate control at the same time due to an extremely high request 762 rate, then the time until the first request admitted by each 763 client would be uniformly distributed over [0,T]; 765 o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without 766 randomization; 768 o For the special case of 'classic gapping' where TAU=0, then the 769 minimum time between admissions is uniformly distributed over 770 [T/2, 3T/2], and the mean time between admissions is the same, 771 i.e. T+1/R where R is the request arrival rate; 773 o At high load randomization rarely occurs, so there is no loss of 774 precision of the admitted rate, even though the randomized 775 'phasing' of the buckets remains. 777 8. IANA Consideration 779 TBD 781 9. Security Considerations 783 Agent overload is an extension to the based Diameter overload 784 mechanism. As such, all of the security considerations outlined in 785 [I-D.ietf-dime-ovli] apply to the agent overload scenarios. 787 10. Acknowledgements 789 11. References 790 11.1. Normative References 792 [I-D.SOC-overload-rate-control] 793 Noel, E., "SIP Overload Rate Control", February 2014. 795 [I-D.ietf-dime-ovli] 796 Korhonen, J., "Diameter Overload Indication Conveyance", 797 October 2013. 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 803 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 804 May 2008. 806 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 807 "Diameter Base Protocol", RFC 6733, October 2012. 809 11.2. Informative References 811 [I-D.donovan-agent-overload] 812 Donovan, S., "Diameter Agent Overload", February 2014. 814 Authors' Addresses 816 Steve Donovan 817 Oracle 818 17210 Campbell Road 819 Dallas, Texas 75254 820 United States 822 Email: srdonovan@usdonovans.com 824 Eric Noel 825 AT&T Labs 826 200s Laurel Avenue 827 Middletown, NJ 07747 828 United States 830 Email: ecnoel@research.att.com