idnits 2.17.1 draft-ietf-dime-ovli-04.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 == Line 509 has weird spacing: '...rotocol stan...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. -- The document date (October 27, 2014) is 3469 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) == Unused Reference: 'RFC5905' is defined on line 1505, but no explicit reference was found in the text == Unused Reference: 'RFC5729' is defined on line 1528, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-ietf-dime-e2e-sec-req-00 -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. 3 Internet-Draft Broadcom 4 Intended status: Standards Track S. Donovan, Ed. 5 Expires: April 30, 2015 B. Campbell 6 Oracle 7 L. Morand 8 Orange Labs 9 October 27, 2014 11 Diameter Overload Indication Conveyance 12 draft-ietf-dime-ovli-04.txt 14 Abstract 16 This specification documents a Diameter Overload Control (DOC) base 17 solution and the dissemination of the overload report information. 19 Requirements 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 30, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7 63 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 8 64 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 65 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 66 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 67 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 69 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 70 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 71 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13 72 4.2. Overload Report Processing . . . . . . . . . . . . . . . 14 73 4.2.1. Overload Control State . . . . . . . . . . . . . . . 14 74 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 18 75 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 18 76 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20 77 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21 78 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 79 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 22 80 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 81 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 82 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 83 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24 84 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 85 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25 86 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 87 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 88 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 89 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 90 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 93 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 95 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 96 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 97 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 98 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 102 11.2. Informative References . . . . . . . . . . . . . . . . . 32 103 Appendix A. Issues left for future specifications . . . . . . . 33 104 A.1. Additional traffic abatement algorithms . . . . . . . . . 33 105 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 106 A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 33 107 Appendix B. Deployment Considerations . . . . . . . . . . . . . 34 108 Appendix C. Requirements Conformance Analysis . . . . . . . . . 34 109 Appendix D. Considerations for Applications Integrating the DOIC 110 Solution . . . . . . . . . . . . . . . . . . . . . . 34 111 D.1. Application Classification . . . . . . . . . . . . . . . 34 112 D.2. Application Type Overload Implications . . . . . . . . . 35 113 D.3. Request Transaction Classification . . . . . . . . . . . 36 114 D.4. Request Type Overload Implications . . . . . . . . . . . 37 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 117 1. Introduction 119 This specification defines a base solution for Diameter Overload 120 Control (DOC), referred to as Diameter Overload Indication Conveyance 121 (DOIC). The requirements for the solution are described and 122 discussed in the corresponding design requirements document 123 [RFC7068]. Note that the overload control solution defined in this 124 specification does not address all the requirements listed in 125 [RFC7068]. A number of overload control related features are left 126 for the future specifications. See Appendix A for a list of 127 extensions that are currently being considered. See Appendix C for 128 an analysis of the conformance to the requirements specified in 129 [RFC7068]. 131 The solution defined in this specification addresses Diameter 132 overload control between Diameter nodes that support the DOIC 133 solution. Furthermore, the solution which is designed to apply to 134 existing and future Diameter applications, requires no changes to the 135 Diameter base protocol [RFC6733] and is deployable in environments 136 where some Diameter nodes do not implement the Diameter overload 137 control solution defined in this specification. 139 2. Terminology and Abbreviations 141 Abatement 142 Reaction to receipt of an overload report resulting in a reduction 143 in traffic sent to the reporting node. Abatement actions include 144 diversion and throttling. 146 Abatement Algorithm 148 An mechanism requested by reporting nodes and used by reacting 149 nodes to reduce the amount of traffic sent during an occurrence of 150 overload control. 152 Diversion 154 Abatement of traffic sent to a reporting node by a reacting node 155 in response to receipt of an overload report. The abatement is 156 achieved by diverting traffic from the reporting node to another 157 Diameter node that is able to process the request. 159 Host-Routed Request 161 The set of requests that a reacting node knows will be served by a 162 particular host, either due to the presence of a Destination-Host 163 AVP, or by some other local knowledge on the part of the reacting 164 node. 166 Overload Control State (OCS) 168 Reporting and reacting node internally maintained state describing 169 occurrences of overload control. 171 Overload Report (OLR) 173 Information sent by a reporting node indicating the start, 174 continuation or end of an occurrence of overload control. 176 Reacting Node 178 A Diameter node that acts upon an overload report. 180 Realm-Routed Request 182 The set of requests that a reacting node does not know the host 183 that will service the request. 185 Reporting Node 187 A Diameter node that generates an overload report. (This may or 188 may not be the overloaded node.) 190 Throttling 192 Throttling is the reduction of the number of requests sent to an 193 entity. Throttling can include a Diameter Client or Diameter 194 Server dropping requests, or a Diameter Agent rejecting requests 195 with appropriate error responses. In extreme cases reporting 196 nodes can also throttle requests when the requested reductions in 197 traffic does not sufficiently address the overload scenario. 199 3. Solution Overview 201 The Diameter Overload Information Conveyance (DOIC) solution allows 202 Diameter nodes to request other nodes to perform overload abatement 203 actions, that is, actions to reduce the load offered to the 204 overloaded node or realm. 206 A Diameter node that supports DOIC is known as a "DOIC node". Any 207 Diameter node can act as a DOIC node, including clients, servers, and 208 agents. DOIC nodes are further divided into "Reporting Nodes" and 209 "Reacting Nodes." A reporting node requests overload abatement by 210 sending an Overload Report (OLR) to one or more reacting nodes. 212 A reacting node acts upon OLRs, and performs whatever actions are 213 needed to fulfil the abatement requests included in the OLRs. A 214 Reporting node may report overload on its own behalf, or on behalf of 215 other (typically upstream) nodes. Likewise, a reacting node may 216 perform overload abatement on its own behalf, or on behalf of other 217 (typically downstream) nodes. 219 A node's role as a DOIC node is independent of its Diameter role. 220 For example, Diameter Relay and Proxy Agents may act as DOIC nodes, 221 even though they are not endpoints in the Diameter sense. Since 222 Diameter enables bi-directional applications, where Diameter Servers 223 can send requests towards Diameter Clients, a given Diameter node can 224 simultaneously act as a reporting node and a reacting node. 226 Likewise, a relay or proxy agent may act as a reacting node from the 227 perspective of upstream nodes, and a reporting node from the 228 perspective of downstream nodes. 230 DOIC nodes do not generate new messages to carry DOIC related 231 information. Rather, they "piggyback" DOIC information over existing 232 Diameter messages by inserting new AVPs into existing Diameter 233 requests and responses. Nodes indicate support for DOIC, and any 234 needed DOIC parameters by inserting an OC_Supported_Features AVP 235 (Section 6.2) into existing requests and responses. Reporting nodes 236 send OLRs by inserting OC-OLR AVPs (Section 6.3). 238 A given OLR applies to the Diameter realm and application of the 239 Diameter message that carries it. If a reporting node supports more 240 than one realm and/or application, it reports independently for each 241 combination of realm and application. Similarly, the OC-Supported- 242 Features AVP applies to the realm and application of the enclosing 243 message. This implies that a node may support DOIC for one 244 application and/or realm, but not another, and may indicate different 245 DOIC parameters for each application and realm for which it supports 246 DOIC. 248 Reacting nodes perform overload abatement according to an agreed-upon 249 abatement algorithm. An abatement algorithm defines the meaning of 250 the parameters of an OLR and the procedures required for overload 251 abatement. This document specifies a single must-support algorithm, 252 namely the "loss" algorithm (Section 5). Future specifications may 253 introduce new algorithms. 255 Overload conditions may vary in scope. For example, a single 256 Diameter node may be overloaded, in which case reacting nodes may 257 reasonably attempt to send requests to other destinations or via 258 other agents. On the other hand, an entire Diameter realm may be 259 overloaded, in which case such attempts would do harm. DOIC OLRs 260 have a concept of "report type" (Section 6.6), where the type defines 261 such behaviors. Report types are extensible. This document defines 262 report types for overload of a specific server, and for overload of 263 an entire realm. 265 A report of type host is sent to indicate the overload of a specific 266 server for the application-id indicated in the transaction. When 267 receiving an OLR of type host, a reacting node applies overload 268 abatement to what is referred to in this document as host-routed 269 requests. This is the set of requests that the reacting node knows 270 will be served by a particular host, either due to the presence of a 271 Destination-Host AVP, or by some other local knowledge on the part of 272 the reacting node. The reacting node applies overload abatement on 273 those host-routed requests which the reacting node knows will be 274 served by the server that matches the Origin-Host AVP of the received 275 message that contained the received OLR of type host. 277 A report type of realm is sent to indicate the overload of all 278 servers in a realm for the application-id. When receiving an OLR of 279 type realm, a reacting node applies overload abatement to what is 280 referred to in this document as realm-routed requests. This is the 281 set of requests that are not host-routed as defined in the previous 282 paragraph. 284 While a reporting node sends OLRs to "adjacent" reacting nodes, nodes 285 that are "adjacent" for DOIC purposes may not be adjacent from a 286 Diameter, or transport, perspective. For example, one or more 287 Diameter agents that do not support DOIC may exist between a given 288 pair of reporting and reacting nodes, as long as those agents pass 289 unknown AVPs through unchanged. The report types described in this 290 document can safely pass through non-supporting agents. This may not 291 be true for report types defined in future specifications. Documents 292 that introduce new report types MUST describe any limitations on 293 their use across non-supporting agents. 295 3.1. Piggybacking Principle 297 The overload control AVPs defined in this specification have been 298 designed to be piggybacked on top of existing application messages. 299 This is made possible by adding overload control top-level AVPs, the 300 OC-OLR AVP and the OC-Supported-Features AVP, as optional AVPs into 301 existing commands when the corresponding Command Code Format (CCF) 302 specification allows adding new optional AVPs (see Section 1.3.4 of 303 [RFC6733]). 305 Reacting nodes indicate support for DOIC by including the OC- 306 Supported-Features AVP in all request messages originated or relayed 307 by the reacting node. 309 Reporting nodes indicate support for DOIC by including the OC- 310 Supported-Features AVP in all answer messages originated or relayed 311 by the reporting node. Reporting nodes also include overload reports 312 using the OC-OLR AVP in answer messages. 314 Note: There is no new Diameter application defined to carry 315 overload related AVPs. The DOIC AVPs are carried in existing 316 Diameter application messages. 318 Note that the overload control solution does not have fixed server 319 and client roles. The DOIC node role is determined based on the 320 message type: whether the message is a request (i.e. sent by a 321 "reacting node") or an answer (i.e. send by a "reporting node"). 322 Therefore, in a typical "client-server" deployment, the Diameter 323 Client MAY report its overload condition to the Diameter Server for 324 any Diameter Server initiated message exchange. An example of such 325 is the Diameter Server requesting a re-authentication from a Diameter 326 Client. 328 3.2. DOIC Capability Announcement 330 The DOIC solution supports the ability for Diameter nodes to 331 determine if other nodes in the path of a request support the 332 solution. This capability is referred to as DOIC Capability 333 Announcement (DCA) and is separate from Diameter Capability Exchange. 335 The DCA solution uses the OC-Supported-Features AVPs to indicate the 336 Diameter overload features supported. 338 The first node in the path of a Diameter request that supports the 339 DOIC solution inserts the OC-Supported-Feature AVP in the request 340 message. This includes an indication that it supports the loss 341 overload abatement algorithm defined in this specification (see 342 Section 5). This ensures that there is at least one commonly 343 supported overload abatement algorithm between the reporting node and 344 the reacting nodes in the path of the request. 346 DOIC must support deployments where Diameter Clients and/or 347 Diameter Servers do not support the DOIC solution. In this 348 scenario, it is assumed that Diameter Agents that support the DOIC 349 solution will handle overload abatement for the non supporting 350 Diameter nodes. In this case the DOIC agent will insert the OC- 351 Supporting-Features AVP in requests that do not already contain 352 one, telling the reporting node that there is a DOIC node that 353 will handle overload abatement. 355 The reporting node inserts the OC-Supported-Feature AVP in all answer 356 messages to requests that contained the OC-Supported-Feature AVP. 357 The contents of the reporting node's OC-Supported-Feature AVP 358 indicate the set of Diameter overload features supported by the 359 reporting node with one exception. 361 The reporting node only includes an indication of support for one 362 overload abatement algorithm. This is the algorithm that the 363 reporting node intends to use should it enter an overload condition 364 or requests to use while it actually is in an overload condition. 365 Reacting nodes can use the indicated overload abatement algorithm to 366 prepare for possible overload reports and must use the indicated 367 overload abatement algorithm if traffic reduction is actually 368 requested. 370 Note that the loss algorithm defined in this document is a 371 stateless abatement algorithm. As a result it does not require 372 any actions by reacting nodes prior to the receipt of an overload 373 report. Stateful abatement algorithms that base the abatement 374 logic on a history of request messages sent might require reacting 375 nodes to maintain state to ensure that overload reports can be 376 properly handled. 378 The individual features supported by the DOIC nodes are indicated in 379 the OC-Feature-Vector AVP. Any semantics associated with the 380 features will be defined in extension specifications that introduce 381 the features. 383 The DCA mechanism must also support the scenario where the set of 384 features supported by the sender of a request and by agents in the 385 path of a request differ. In this case, the agent updates the OC- 386 Supported-Feature AVP to reflect the mixture of the two sets of 387 supported features. 389 The logic to determine the content of the modified OC-Supported- 390 Feature AVP is out-of-scope for this specification and is left to 391 implementation decisions. Care must be taken not to introduce 392 interoperability issues for downstream or upstream DOIC nodes. 394 3.3. DOIC Overload Condition Reporting 396 As with DOIC Capability Announcement, Overload Condition Reporting 397 uses new AVPs (Section 6.3) to indicate an overload condition. 399 The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP 400 includes the type of report, a sequence number, the length of time 401 that the report is valid and abatement algorithm specific AVPs. 403 Two types of overload reports are defined in this document, host 404 reports and realm reports. 406 A report of type host is sent to indicate the overload of a specific 407 Diameter node for the application-id indicated in the transaction. 408 When receiving an OLR of type host, a reacting node applies overload 409 abatement to what is referred to in this document as host-routed 410 requests. This is the set of requests that the reacting node knows 411 will be served by a particular host, either due to the presence of a 412 Destination-Host AVP, or by some other local knowledge on the part of 413 the reacting node. The reacting node applies overload abatement on 414 those host-routed requests which the reacting node knows will be 415 served by the server that matches the Origin-Host AVP of the received 416 message that contained the received OLR of type host. 418 Realm reports apply to realm-routed requests for a specific realm as 419 indicated in the Destination-Realm AVP. 421 Reporting nodes are responsible for determining the need for a 422 reduction of traffic. The method for making this determination is 423 implementation specific and depend on the type of overload report 424 being generated. A host report, for instance, will generally be 425 generated by tracking utilization of resources required by the host 426 to handle transactions for the Diameter application. A realm report 427 will generally impact the traffic sent to multiple hosts and, as 428 such, will typically require tracking the capacity of the servers 429 able to handle realm-routed requests for the application. 431 Once a reporting node determines the need for a reduction in traffic, 432 it uses the DOIC defined AVPs to report on the condition. These AVPs 433 are included in answer messages sent or relayed by the reporting 434 node. The reporting node indicates the overload abatement algorithm 435 that is to be used to handle the traffic reduction in the OC- 436 Supported-Features AVP. The OC-OLR AVP is used to communicate 437 information about the requested reduction. 439 Reacting nodes, upon receipt of an overload report, are responsible 440 for applying the abatement algorithm to traffic impacted by the 441 overload report. The method used for that abatement is dependent on 442 the abatement algorithm. The loss abatement algorithm is defined in 443 this document (Section 5). Other abatement algorithms can be defined 444 in extensions to the DOIC solutions. 446 As the conditions that lead to the generation of the overload report 447 change the reporting node can send new overload reports requesting 448 greater reduction if the condition gets worse or less reduction if 449 the condition improves. The reporting node sends an overload report 450 with a duration of zero to indicate that the overload condition has 451 ended and use of the abatement algorithm is no longer needed. 453 The reacting node also determines when the overload report expires 454 based on the OC-Validity-Duration AVP in the overload report and 455 stops applying the abatement algorithm when the report expires. 457 3.4. DOIC Extensibility 459 The DOIC solution is designed to be extensible. This extensibility 460 is based on existing Diameter based extensibility mechanisms. 462 There are multiple categories of extensions that are expected. This 463 includes the definition of new overload abatement algorithms, the 464 definition of new report types and new definitions of the scope of 465 messages impacted by an overload report. 467 The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes 468 to communicate supported features. The specific features supported 469 by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC 470 extensions must define new values for the OC-Feature-Vector AVP. 472 DOIC extensions also have the ability to add new AVPs to the OC- 473 Supported-Features AVP, if additional information about the new 474 feature is required. 476 Reporting nodes use the OC-OLR AVP to communicate overload 477 occurrences. This AVP can also be extended to add new AVPs allowing 478 a reporting nodes to communicate additional information about 479 handling an overload condition. 481 If necessary, new extensions can also define new top-level AVPs. It 482 is, however, recommended that DOIC extensions use the OC-Supported- 483 Features and OC-OLR to carry all DOIC related AVPs. 485 3.5. Simplified Example Architecture 487 Figure 1 illustrates the simplified architecture for Diameter 488 overload information conveyance. 490 Realm X Same or other Realms 491 <--------------------------------------> <----------------------> 493 +--^-----+ : (optional) : 494 |Diameter| : : 495 |Server A|--+ .--. : +---^----+ : .--. 496 +--------+ | _( `. : |Diameter| : _( `. +---^----+ 497 +--( )--:-| Agent |-:--( )--|Diameter| 498 +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | 499 |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ 500 |Server B| : : 501 +---^----+ : : 503 End-to-end Overload Indication 504 1) <-----------------------------------------------> 505 Diameter Application Y 507 Overload Indication A Overload Indication A' 508 2) <----------------------> <----------------------> 509 standard base protocol standard base protocol 511 Figure 1: Simplified architecture choices for overload indication 512 delivery 514 In Figure 1, the Diameter overload indication can be conveyed (1) 515 end-to-end between servers and clients or (2) between servers and 516 Diameter agent inside the realm and then between the Diameter agent 517 and the clients. 519 4. Solution Procedures 521 This section outlines the normative behavior associated with the DOIC 522 solution. 524 4.1. Capability Announcement 526 This section defines DOIC Capability Announcement (DCA) behavior. 528 4.1.1. Reacting Node Behavior 530 A reacting node MUST include the OC-Supported-Features AVP in all 531 request messages. 533 A reacting node MAY include the OC-Feature-Vector AVP with an 534 indication of the loss algorithm. A reacting node MUST include the 535 OC-Feature-Vector AVP to indicate support for abatement algorithms in 536 addition to the loss algorithm. 538 A reacting node SHOULD indicate support for all other DOIC features 539 it supports. 541 Not all DOIC features will necessarily apply to all transactions. 542 For instance, there may be a future extension that only applies to 543 session based applications. A reacting node that supports this 544 extension can choose to not include it for non session based 545 applications. 547 An OC-Supported-Features AVP in answer messages indicates there is a 548 reporting node for the transaction. The reacting node MAY take 549 action based on the features indicated in the OC-Feature-Vector AVP. 551 Note that the loss abatement algorithm is the only feature 552 described in this document and it does not require action to be 553 taken when there is an active overload report. This behavior is 554 described in Section 4.2 and Section 5. 556 4.1.2. Reporting Node Behavior 558 Upon receipt of a request message, a reporting node determines if 559 there is a reacting node for the transaction based on the presence of 560 the OC-Supported-Features AVP. 562 If the request message contains an OC-Supported-Features AVP then the 563 reporting node MUST include the OC-Supported-Features AVP in the 564 answer message for that transaction. 566 The reporting node MUST NOT include the OC-Supported-Features AVP, 567 OC-OLR AVP or any other overload control AVPs defined in extension 568 drafts in response messages for transactions where the request 569 message does not include the OC-Supported-Features AVP. Lack of the 570 OC-Supported-Features AVP in the request message indicates that there 571 is no reacting node for the transaction. 573 Based on the content of the OC-Supported-Features AVP in the request 574 message, the reporting node knows what overload control functionality 575 is supported by the reacting node. The reporting node then acts 576 accordingly for the subsequent answer messages it initiates. 578 The reporting node MUST indicate support for one and only one 579 abatement algorithm in the OC-Feature-Vector AVP. The abatement 580 algorithm included MUST be from the set of abatement algorithms 581 contained in the request message's OC-Supported-Features AVP. The 582 abatement algorithm included MUST indicate the abatement algorithm 583 the reporting node wants the reacting node to use when the reporting 584 node enters an overload condition. 586 For an ongoing overload state, a reacting node MUST keep the 587 algorithm that was selected by the reporting node in further requests 588 towards the reporting node. The reporting node SHOULD NOT change the 589 selected algorithm during a period of time that it is in an overload 590 condition and, as a result, is sending OC-OLR AVPs in answer 591 messages. 593 The reporting node SHOULD indicate support for other DOIC features 594 defined in extension drafts that it supports and that apply to the 595 transaction. 597 Note that not all DOIC features will apply to all Diameter 598 applications or deployment scenarios. The features included in 599 the OC-Feature-Vector AVP are based on local reporting node 600 policy. 602 4.1.3. Agent Behavior 604 Diameter agents that support DOIC MUST ensure that all messages have 605 the OC-Supporting-Features AVP. If a message handled by the DOIC 606 agent does not include the OC-Supported-Features AVP then the DOIC 607 agent inserts the AVP. If the message already has the AVP then the 608 agent either leaves it unchanged in the relayed message or modifies 609 it to reflect a mixed set of DOIC features. 611 An agent MAY modify the OC-Supported-Features AVP carried in answer 612 messages. 614 For instance, if the agent supports a superset of the features 615 reported by the reacting node then the agent might choose, based 616 on local policy, to advertise that superset of features to the 617 reporting node. 619 If the agent modifies the OC-Supported-Features AVP sent to the 620 reporting node then it might also need to modify the OC-Supported- 621 Features AVP sent to a reacting node in the subsequent answer 622 message, as it cannot send an indication of support for features 623 that are not supported by the reacting node. 625 Editor's note: There is an open issue on the wording around agent 626 behavior in this case that needs to be resolved prior to finishing 627 this document. 629 4.2. Overload Report Processing 631 4.2.1. Overload Control State 633 Both reacting and reporting nodes maintain Overload Control State 634 (OCS) for active overload conditions. 636 4.2.1.1. Overload Control State for Reacting Nodes 638 A reacting node SHOULD maintain the following OCS per supported 639 Diameter application: 641 o A host-type OCS entry for each Destination-Host to which it sends 642 host-type requests and 644 o A realm-type OCS entry for each Destination-Realm to which it 645 sends realm-type requests. 647 A host-type OCS entry is identified by the pair of Application-Id and 648 Host-Id. 650 A realm-type OCS entry is identified by the pair of Application-Id 651 and Realm-Id. 653 The host-type and realm-type OCS entries MAY include the following 654 information (the actual information stored is an implementation 655 decision): 657 o Sequence number (as received in OC-OLR) 658 o Time of expiry (derived from OC-Validity-Duration AVP received in 659 the OC-OLR AVP and time of reception of the message carrying OC- 660 OLR AVP) 662 o Selected Abatement Algorithm (as received in OC-Supported-Features 663 AVP) 665 o Abatement Algorithm specific input data (as received within the 666 OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss 667 abatement algorithm) 669 4.2.1.2. Overload Control State for Reporting Nodes 671 A reporting node SHOULD maintain OCS entries per supported Diameter 672 application, per supported (and eventually selected) Abatement 673 Algorithm and per report-type. 675 An OCS entry is identified by the pair of Application-Id and 676 Abatement Algorithm. 678 The OCS entry for a given pair of Application and Abatement Algorithm 679 MAY include the information (the actual information stored is an 680 implementation decision): 682 o Report type 684 o Sequence number 686 o Validity Duration 688 o Expiration Time 690 o Algorithm specific input data (for example, the Reduction 691 Percentage for the Loss Abatement Algorithm) 693 4.2.1.3. Reacting Node Maintenance of Overload Control State 695 When a reacting node receives an OC-OLR AVP, it MUST determine if it 696 is for an existing or new overload condition. 698 For the remainder of this section the term OLR referres to the 699 combination of the contents of the received OC-OLR AVP and the 700 abatement algorithm indicated in the received OC-Supported- 701 Features AVP. 703 The OLR is for an existing overload condition if the reacting node 704 has an OCS that matches the received OLR. 706 For a host report-type this means it matches the app-id and host-id 707 in an existing host OCS entry. 709 For a realm report-type this means it matches the app-id and realm-id 710 in an existing realm OCS entry. 712 If the OLR is for an existing overload condition then it MUST 713 determine if the OLR is a retransmission or an update to the existing 714 OLR. 716 If the sequence number for the received OLR is greater than the 717 sequence number stored in the matching OCS entry then the reacting 718 node MUST update the matching OCS entry. 720 If the sequence number for the received OLR is less than or equal to 721 the sequence number in the matching OCS entry then the reacting node 722 MUST silently ignore the received OLR. The matching OCS MUST NOT be 723 updated in this case. 725 If the received OLR is for a new overload condition then the reacting 726 node MUST generate a new OCS entry for the overload condition. 728 For a host report-type this means it creates on OCS entry with the 729 app-id of the application-id in the received message and host-id of 730 the Origin-Host in the received message. 732 Note: This solution assumes that the Origin-Host AVP in the answer 733 message included by the reporting node is not changed along the 734 path to the reacting node. 736 For a realm report-type this means it creates on OCS entry with the 737 app-id of the application-id in the received message and realm-id of 738 the Origin-Realm in the received message. 740 If the received OLR contains a validity duration of zero ("0") then 741 the reacting node MUST update the OCS entry as being expired. 743 Note that it is not necessarily appropriate to delete the OCS 744 entry, as there is recommended behavior that the reacting node 745 slowly returns to full traffic when ending an overload abatement 746 period. 748 The reacting node does not delete an OCS when receiving an answer 749 message that does not contain an OC-OLR AVP (i.e. absence of OLR 750 means "no change"). 752 4.2.1.4. Reporting Node Maintenance of Overload Control State 754 A reporting node SHOULD create a new OCS entry when entering an 755 overload condition. 757 If the reporting node knows through absence of the OC-Supported- 758 Features AVP in received messages that there are no reacting nodes 759 supporting DOIC then the reporting node can choose to not create 760 OCS entries. 762 When generating a new OCS entry the sequence number MAY be set to any 763 value if there is no unexpired overload report for previous overload 764 conditions sent to any reacting node for the same application and 765 report-type. 767 When generating sequence numbers for new overload conditions, the new 768 sequence number MUST be greater than any sequence number in an active 769 (unexpired) overload report previously sent by the reporting node. 770 This property MUST hold over a reboot of the reporting node. 772 The reporting node MUST update an OCS entry when it needs to adjust 773 the validity duration of the overload condition at reacting nodes. 775 For instance, if the reporting node wishes to instruct reacting 776 nodes to continue overload abatement for a longer period of time 777 that originally communicated. This also applies if the reporting 778 node wishes to shorten the period of time that overload abatement 779 is to continue. 781 A reporting node MUST NOT update the abatement algorithm in an active 782 OCS entry. 784 A reporting node MUST update an OCS entry when it wishes to adjust 785 any abatement algorithm specific parameters, including the reduction 786 percentage used for the Loss abatement algorithm. 788 For instance, if the reporting node wishes to change the reduction 789 percentage either higher, if the overload condition has worsened, 790 or lower, if the overload condition has improved, then the 791 reporting node would update the appropriate OCS entry. 793 The reporting node MUST update the sequence number associated with 794 the OCS entry anytime the contents of the OCS entry are changed. 795 This will result in a new sequence number being sent to reacting 796 nodes, instructing the reacting nodes to process the OC-OLR AVP. 798 A reporting node SHOULD update an OCS entry with a validity duration 799 of zero ("0") when the overload condition ends. 801 If the reporting node knows that the OCS entries in the reacting 802 nodes are near expiration then the reporting node can decide to 803 delete the OCS entry. 805 The reporting node MUST keep an OCS entry with a validity duration of 806 zero ("0") for a period of time long enough to ensure that any non- 807 expired reacting node's OCS entry created as a result of the overload 808 condition in the reporting node is deleted. 810 4.2.2. Reacting Node Behavior 812 When a reacting node sends a request it MUST determine if that 813 request matches an active OCS. 815 If the request matches and active OCS then the reacting node MUST 816 apply abatement treatment on the request. The abatement treatment 817 applied depends on the abatement algorithm stored in the OCS. 819 For the Loss abatement algorithm defined in this specification, see 820 Section 5 for the abatement logic applied. 822 If the abatement treatment results in throttling of the request and 823 if the reacting node is an agent then the agent MUST send an 824 appropriate error as defined in section Section 7. 826 In the case that the OCS entry validity duration expires or has a 827 validity duration of zero ("0"), meaning that it the reporting node 828 has explicitly signaled the end of the overload condition then 829 abatement associated with the overload abatement MUST be ended in a 830 controlled fashion. 832 4.2.3. Reporting Node Behavior 834 The operation on the reporting node is straight forward. 836 If there is an active OCS entry then the reporting node SHOULD 837 include the OC-OLR AVP in all answer messages to requests that 838 contain the OC-Supported-Features AVP and that match the active OCS 839 entry. 841 A request matches if the application-id in the request matches the 842 application-id in any active OCS entry and if the report-type in 843 the OCS entry matches a report-type supported by the reporting 844 node as indicated in the OC-Supported-Features AVP. 846 The contents of the OC-OLR AVP MUST contain all information necessary 847 for the abatement algorithm indicated in the OC-Supported-Features 848 AVP that is also included in the answer message. 850 A reporting node MAY choose to not resend an overload report to a 851 reacting node if it can guarantee that this overload report is 852 already active in the reacting node. 854 Note - In some cases (e.g. when there are one or more agents in 855 the path between reporting and reacting nodes, or when overload 856 reports are discarded by reacting nodes) the reporting node may 857 not be able to guarantee that the reacting node has received the 858 report. 860 A reporting node MUST NOT send overload reports of a type that has 861 not been advertised as supported by the reacting node. 863 Note that a reacting node advertises support for the host and 864 realm report types by including the OC-Supported-Features AVP in 865 the request. Support for other report types must be explicitly 866 indicated by new feature bits in the OC-Feature-Vector AVP. 868 A reporting node MAY rely on the OC-Validity-Duration AVP values for 869 the implicit overload control state cleanup on the reacting node. 870 However, it is RECOMMENDED that the reporting node always explicitly 871 indicates the end of a overload condition. 873 The reporting node SHOULD indicate the end of an overload occurrence 874 by sending a new OLR with OC-Validity-Duration set to a value of zero 875 ("0"). The reporting node SHOULD ensure that all reacting nodes 876 receive the updated overload report. 878 All OLRs sent have an expiration time calculated by adding the 879 validity-duration contained in the OLR to the time the message was 880 sent. Transit time for the OLR can be safely ignored. The 881 reporting node can ensure that all reacting nodes have received 882 the OLR by continuing to send it in answer messages until the 883 expiration time for all OLRs sent for that overload condition have 884 expired. 886 When a reporting node sends an OLR, it effectively delegates any 887 necessary throttling to downstream nodes. Therefore, the reporting 888 node SHOULD NOT apply throttling to the set of messages to which the 889 OLR applies. That is, the same candidate set of messages SHOULD NOT 890 be throttled multiple times. 892 However, when the reporting node sends and OLR downstream, it MAY 893 still be responsible to apply other abatement methods such as 894 diversion. The reporting node might also need to throttle requests 895 for reasons other then overload. For example, an agent or server 896 might have a configured rate limit for each client, and throttle 897 requests that exceed that limit, even if such requests had already 898 been candidates for throttling by downstream nodes. 900 This document assumes that there is a single source for realm-reports 901 for a given realm, or that if multiple nodes can send realm reports, 902 that each such node has full knowledge of the overload state of the 903 entire realm. A reacting node cannot distinguish between receiving 904 realm-reports from a single node, or from multiple nodes. 906 Editor's Note: There is not yet consensus on the above two 907 paragraphs. Two alternatives are under consideration -- 908 synchronization of sequence numbers and attribution of reports. 909 If no consensus is reached then it will be left to be addressed as 910 an extension. 912 4.3. Protocol Extensibility 914 The overload control solution can be extended, e.g. with new traffic 915 abatement algorithms, new report types or other new functionality. 917 When defining a new extension a new feature bit MUST be defined for 918 the OC-Feature-Vector. This feature bit is used to communicate 919 support for the new feature. 921 The extension MAY define new AVPs for use in DOIC Capability 922 Announcement and for use in DOIC Overload reporting. These new AVPs 923 SHOULD be defined to be extensions to the OC-Supported-Features and 924 OC-OLR AVPs defined in this document. 926 It should be noted that [RFC6733] defined Grouped AVP extension 927 mechanisms apply. This allows, for example, defining a new feature 928 that is mandatory to be understood even when piggybacked on an 929 existing application. 931 The handling of feature bits in the OC-Feature-Vector AVP that are 932 not associated with overload abatement algorithms MUST be specified 933 by the extensions that define the features. 935 When defining new report type values, the corresponding specification 936 MUST define the semantics of the new report types and how they affect 937 the OC-OLR AVP handling. The specification MUST also reserve a 938 corresponding new feature bit in the OC-Feature-Vector AVP. 940 The OC-OLR AVP can be expanded with optional sub-AVPs only if a 941 legacy DOIC implementation can safely ignore them without breaking 942 backward compatibility for the given OC-Report-Type AVP value. If 943 the new sub-AVPs imply new semantics for handling the indicated 944 report type, then a new OC-Report-Type AVP value MUST be defined. 946 New features (feature bits in the OC-Feature-Vector AVP) and report 947 types (in the OC-Report-Type AVP) MUST be registered with IANA. As 948 with any Diameter specification, new AVPs MUST also be registered 949 with IANA. See Section 8 for the required procedures. 951 5. Loss Algorithm 953 This section documents the Diameter overload loss abatement 954 algorithm. 956 5.1. Overview 958 The DOIC specification supports the ability for multiple overload 959 abatement algorithms to be specified. The abatement algorithm used 960 for any instance of overload is determined by the Diameter Overload 961 Capability Announcement process documented in Section 4.1. 963 The loss algorithm described in this section is the default algorithm 964 that must be supported by all Diameter nodes that support DOIC. 966 The loss algorithm is designed to be a straightforward and stateless 967 overload abatement algorithm. It is used by reporting nodes to 968 request a percentage reduction in the amount of traffic sent. The 969 traffic impacted by the requested reduction depends on the type of 970 overload report. 972 Reporting nodes use a strategy of applying abatement logic to the 973 requested percentage of request messages sent (or handled in the case 974 of agents) by the reacting node that are impacted by the overload 975 report. 977 From a conceptual level, the logic at the reacting node could be 978 outlined as follows. 980 1. An overload report is received and the associated overload state 981 is either saved or updated (if required) by the reacting node. 983 2. A new Diameter request is generated by the application running on 984 the reacting node. 986 3. The reacting node determines that an active overload report 987 applies to the request, as indicated by the corresponding OCS 988 entry. 990 4. The reacting node determines if abatement should be applied to 991 the request. One approach that could be taken for each request 992 is to select a random number between 1 and 100. If the random 993 number is less than the indicated reduction percentage then the 994 request is given abatement treatment, otherwise the request is 995 given normal routing treatment. 997 5.2. Reporting Node Behavior 999 The method a reporting nodes uses to determine the amount of traffic 1000 reduction required to address an overload condition is an 1001 implementation decision. 1003 When a reporting node that has selected the loss abatement algorithm 1004 determines the need to request a traffic reduction it includes an OC- 1005 OLR AVP in response messages as described in Section 4.2.3. 1007 The reporting node MUST indicate a percentage reduction in the OC- 1008 Reduction-Percentage AVP. 1010 The reporting node MAY change the reduction percentage in subsequent 1011 overload reports. When doing so the reporting node must conform to 1012 overload report handing specified in Section 4.2.3. 1014 When the reporting node determines it no longer needs a reduction in 1015 traffic the reporting node SHOULD send an overload report indicating 1016 the overload report is no longer valid, as specified in 1017 Section 4.2.3. 1019 5.3. Reacting Node Behavior 1021 The method a reacting node uses to determine which request messages 1022 are given abatement treatment is an implementation decision. 1024 When receiving an OC-OLR in an answer message where the algorithm 1025 indicated in the OC-Supported-Features AVP is the loss algorithm, the 1026 reacting node MUST apply abatement treatment to the requested 1027 percentage of request messages sent. 1029 Note: the loss algorithm is a stateless algorithm. As a result, 1030 the reacting node does not guarantee that there will be an 1031 absolute reduction in traffic sent. Rather, it guarantees that 1032 the requested percentage of new requests will be given abatement 1033 treatment. 1035 When applying overload abatement treatment for the load abatement 1036 algorithm, the reacting node MUST abate, either by throttling or 1037 diversion, the requested percentage of requests that would have 1038 otherwise been sent to the reporting host or realm. 1040 If reacting node comes out of the 100 percent traffic reduction as a 1041 result of the overload report timing out, the following concerns are 1042 RECOMMENDED to be applied. The reacting node sending the traffic 1043 should be conservative and, for example, first send "probe" messages 1044 to learn the overload condition of the overloaded node before 1045 converging to any traffic amount/rate decided by the sender. Similar 1046 concerns apply in all cases when the overload report times out unless 1047 the previous overload report stated 0 percent reduction. 1049 If the reacting node does not receive an OLR in messages sent to the 1050 formerly overloaded node then the reacting node SHOULD slowly 1051 increase the rate of traffic sent to the overloaded node. 1053 It is suggested that the reacting node decrease the amount of traffic 1054 given abatement treatment by 20% each second until the reduction is 1055 completely removed and no traffic is given abatement treatment. 1057 The goal of this behavior is to reduce the probability of overload 1058 condition thrashing where an immediate transition from 100% 1059 reduction to 0% reduction results in the reporting node moving 1060 quickly back into an overload condition. 1062 6. Attribute Value Pairs 1064 This section describes the encoding and semantics of the Diameter 1065 Overload Indication Attribute Value Pairs (AVPs) defined in this 1066 document. 1068 A new application specification can incorporate the overload control 1069 mechanism specified in this document by making it mandatory to 1070 implement for the application and referencing this specification 1071 normatively. It is the responsibility of the Diameter application 1072 designers to define how overload control mechanisms works on that 1073 application. 1075 6.1. OC-Supported-Features AVP 1077 The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and 1078 serves two purposes. First, it announces a node's support for the 1079 DOIC solution in general. Second, it contains the description of the 1080 supported DOIC features of the sending node. The OC-Supported- 1081 Features AVP MUST be included in every Diameter request message a 1082 DOIC supporting node sends. 1084 OC-Supported-Features ::= < AVP Header: TBD1 > 1085 [ OC-Feature-Vector ] 1086 * [ AVP ] 1088 The OC-Feature-Vector sub-AVP is used to announce the DOIC features 1089 supported by the DOIC node, in the form of a flag bits field in which 1090 each bit announces one feature or capability supported by the node 1091 (see Section 6.2). The absence of the OC-Feature-Vector AVP 1092 indicates that only the default traffic abatement algorithm described 1093 in this specification is supported. 1095 6.2. OC-Feature-Vector AVP 1097 The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and 1098 contains a 64 bit flags field of announced capabilities of a DOIC 1099 node. The value of zero (0) is reserved. 1101 The following capabilities are defined in this document: 1103 OLR_DEFAULT_ALGO (0x0000000000000001) 1105 When this flag is set by the DOIC node it means that the default 1106 traffic abatement (loss) algorithm is supported. 1108 6.3. OC-OLR AVP 1110 The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the 1111 information necessary to convey an overload report on an overload 1112 condition at the reporting node. The OC-OLR AVP does not explicitly 1113 contain all information needed by the reacting node to decide whether 1114 a subsequent request must undergo a throttling process with the 1115 received reduction percentage. The value of the OC-Report-Type AVP 1116 within the OC-OLR AVP indicates which implicit information is 1117 relevant for this decision (see Section 6.6). The application the 1118 OC-OLR AVP applies to is the same as the Application-Id found in the 1119 Diameter message header. The host or realm the OC-OLR AVP concerns 1120 is determined from the Origin-Host AVP and/or Origin-Realm AVP found 1121 in the encapsulating Diameter command. The OC-OLR AVP is intended to 1122 be sent only by a reporting node. 1124 OC-OLR ::= < AVP Header: TBD2 > 1125 < OC-Sequence-Number > 1126 < OC-Report-Type > 1127 [ OC-Reduction-Percentage ] 1128 [ OC-Validity-Duration ] 1129 * [ AVP ] 1131 Note that if a Diameter command were to contain multiple OC-OLR AVPs 1132 they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs 1133 with unknown values SHOULD be silently discarded by reacting nodes 1134 and the event SHOULD be logged. 1136 6.4. OC-Sequence-Number AVP 1138 The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. 1139 Its usage in the context of overload control is described in 1140 Section 4.2. 1142 From the functionality point of view, the OC-Sequence-Number AVP MUST 1143 be used as a non-volatile increasing counter for a sequence of 1144 overload reports between two DOIC nodes for the same overload 1145 occurrence. The sequence number is only required to be unique 1146 between two DOIC nodes. Sequence numbers are treated in a uni- 1147 directional manner, i.e. two sequence numbers on each direction 1148 between two DOIC nodes are not related or correlated. 1150 6.5. OC-Validity-Duration AVP 1152 The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 1153 and indicates in milliseconds the validity time of the overload 1154 report. The number of milliseconds is measured after reception of 1155 the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. 1156 The default value for the OC-Validity-Duration AVP is 5000 (i.e., 5 1157 seconds). When the OC-Validity-Duration AVP is not present in the 1158 OC-OLR AVP, the default value applies. Validity duration with values 1159 above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration 1160 values are treated as if the OC-Validity-Duration AVP were not 1161 present and result in the default value being used. 1163 Editor's note: There is an open discussion on whether to have an 1164 upper limit on the OC-Validity-Duration value, beyond that which can 1165 be indicated by an Unsigned32. 1167 A timeout of the overload report has specific concerns that need to 1168 be taken into account by the DOIC node acting on the earlier received 1169 overload report(s). Section 6.7 discusses the impacts of timeout in 1170 the scope of the traffic abatement algorithms. 1172 6.6. OC-Report-Type AVP 1174 The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The 1175 value of the AVP describes what the overload report concerns. The 1176 following values are initially defined: 1178 0 A host report. The overload treatment should apply to requests 1179 for which all of the following conditions are true: 1181 Either the Destination-Host AVP is present in the request and its 1182 value matches the value of the Origin-Host AVP of the received 1183 message that contained the OC-OLR AVP; or the Destination-Host is 1184 not present in the request but the value of the peer identity 1185 associated with the connection used to send the request matches 1186 the value of the Origin-Host AVP of the received message that 1187 contained the OC-OLR AVP. 1189 The value of the Destination-Realm AVP in the request matches the 1190 value of the Origin-Realm AVP of the received message that 1191 contained the OC-OLR AVP. 1193 The value of the Application-ID in the Diameter Header of the 1194 request matches the value of the Application-ID of the Diameter 1195 Header of the received message that contained the OC-OLR AVP. 1197 1 A realm report. The overload treatment should apply to requests 1198 for which all of the following conditions are true: 1200 The Destination-Host AVP is absent in the requestand the value of 1201 the peer identity associated with the connection used to send the 1202 request does not match a server that could serve the request. 1204 The value of the Destination-Realm AVP in the request matches the 1205 value of the Origin-Realm AVP of the received message that 1206 contained the OC-OLR AVP. 1208 The value of the Application-ID in the Diameter Header of the 1209 request matches the value of the Application-ID of the Diameter 1210 Header of the received message that contained the OC-OLR AVP. 1212 The OC-Report-Type AVP is envisioned to be useful for situations 1213 where a reacting node needs to apply different overload treatments 1214 for different overload contexts. For example, the reacting node(s) 1215 might need to throttle differently requests sent to a specific server 1216 (identified by the Destination-Host AVP in the request) and requests 1217 that can be handled by any server in a realm. 1219 6.7. OC-Reduction-Percentage AVP 1221 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 1222 and describes the percentage of the traffic that the sender is 1223 requested to reduce, compared to what it otherwise would send. The 1224 OC-Reduction-Percentage AVP applies to the default (loss) algorithm 1225 specified in this specification. However, the AVP can be reused for 1226 future abatement algorithms, if its semantics fit into the new 1227 algorithm. 1229 The value of the Reduction-Percentage AVP is between zero (0) and one 1230 hundred (100). Values greater than 100 are ignored. The value of 1231 100 means that all traffic is to be throttled, i.e. the reporting 1232 node is under a severe load and ceases to process any new messages. 1233 The value of 0 means that the reporting node is in a stable state and 1234 has no need for the reacting node to apply any traffic abatement. 1235 The default value of the OC-Reduction-Percentage AVP is 0. When the 1236 OC-Reduction-Percentage AVP is not present in the overload report, 1237 the default value applies. 1239 6.8. Attribute Value Pair flag rules 1241 +---------+ 1242 |AVP flag | 1243 |rules | 1244 +----+----+ 1245 AVP Section | |MUST| 1246 Attribute Name Code Defined Value Type |MUST| NOT| 1247 +--------------------------------------------------+----+----+ 1248 |OC-Supported-Features TBD1 x.x Grouped | | V | 1249 +--------------------------------------------------+----+----+ 1250 |OC-OLR TBD2 x.x Grouped | | V | 1251 +--------------------------------------------------+----+----+ 1252 |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | 1253 +--------------------------------------------------+----+----+ 1254 |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | 1255 +--------------------------------------------------+----+----+ 1256 |OC-Report-Type TBD5 x.x Enumerated | | V | 1257 +--------------------------------------------------+----+----+ 1258 |OC-Reduction | | | 1259 | -Percentage TBD8 x.x Unsigned32 | | V | 1260 +--------------------------------------------------+----+----+ 1261 |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | 1262 +--------------------------------------------------+----+----+ 1264 As described in the Diameter base protocol [RFC6733], the M-bit 1265 setting for a given AVP is relevant to an application and each 1266 command within that application that includes the AVP. 1268 The Diameter overload control AVPs SHOULD always be sent with the 1269 M-bit cleared when used within existing Diameter applications to 1270 avoid backward compatibility issues. Otherwise, when reused in newly 1271 defined Diameter applications, the DOC related AVPs SHOULD have the 1272 M-bit set. 1274 7. Error Response Codes 1276 When a DOIC node rejects a Diameter request due to overload, the DOIC 1277 node MUST select an appropriate error response code. This 1278 determination is made based on the probability of the request 1279 succeeding if retried on a different path. 1281 A reporting node rejecting a Diameter request due to an overload 1282 condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can 1283 assume that the same request may succeed on a different path. 1285 If a reporting node knows or assumes that the same request will not 1286 succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response 1287 SHOULD be used. Retrying would consume valuable resources during an 1288 occurrence of overload. 1290 For instance, if the request arrived at the reporting node without 1291 a Destination-Host AVP then the reporting node might determine 1292 that there is an alternative Diameter node that could successfully 1293 process the request and that retrying the transaction would not 1294 negatively impact the reporting node. DIAMETER_TOO_BUSY would be 1295 sent in this case. 1297 For instance, if the request arrived at the reporting node with a 1298 Destination-Host AVP populated with its own Diameter identity then 1299 the reporting node can assume that retrying the request would 1300 result in it coming to the same reporting node. 1301 DIAMETER_UNABLE_TO_COMPLY would be sent in this case. 1303 A second example is when an agent that supports the DOIC solution 1304 is performing the role of a reacting node for a non supporting 1305 client. Requests that are rejected as a result of DOIC throttling 1306 by the agent in this scenario would generally be rejected with a 1307 DIAMETER_UNABLE_TO_COMPLY response code. 1309 8. IANA Considerations 1311 8.1. AVP codes 1313 New AVPs defined by this specification are listed in Section 6. All 1314 AVP codes allocated from the 'Authentication, Authorization, and 1315 Accounting (AAA) Parameters' AVP Codes registry. 1317 8.2. New registries 1319 Two new registries are needed under the 'Authentication, 1320 Authorization, and Accounting (AAA) Parameters' registry. 1322 Section 6.2 defines a new "Overload Control Feature Vector" registry 1323 including the initial assignments. New values can be added into the 1324 registry using the Specification Required policy [RFC5226]. See 1325 Section 6.2 for the initial assignment in the registry. 1327 Section 6.6 defines a new "Overload Report Type" registry with its 1328 initial assignments. New types can be added using the Specification 1329 Required policy [RFC5226]. 1331 9. Security Considerations 1333 This mechanism gives Diameter nodes the ability to request that 1334 downstream nodes send fewer Diameter requests. Nodes do this by 1335 exchanging overload reports that directly affect this reduction. 1336 This exchange is potentially subject to multiple methods of attack, 1337 and has the potential to be used as a Denial-of-Service (DoS) attack 1338 vector. 1340 Overload reports may contain information about the topology and 1341 current status of a Diameter network. This information is 1342 potentially sensitive. Network operators may wish to control 1343 disclosure of overload reports to unauthorized parties to avoid its 1344 use for competitive intelligence or to target attacks. 1346 Diameter does not include features to provide end-to-end 1347 authentication, integrity protection, or confidentiality. This may 1348 cause complications when sending overload reports between non- 1349 adjacent nodes. 1351 9.1. Potential Threat Modes 1353 The Diameter protocol involves transactions in the form of requests 1354 and answers exchanged between clients and servers. These clients and 1355 servers may be peers, that is,they may share a direct transport (e.g. 1356 TCP or SCTP) connection, or the messages may traverse one or more 1357 intermediaries, known as Diameter Agents. Diameter nodes use TLS, 1358 DTLS, or IPSec to authenticate peers, and to provide confidentiality 1359 and integrity protection of traffic between peers. Nodes can make 1360 authorization decisions based on the peer identities authenticated at 1361 the transport layer. 1363 When agents are involved, this presents an effectively hop-by-hop 1364 trust model. That is, a Diameter client or server can authorize an 1365 agent for certain actions, but it must trust that agent to make 1366 appropriate authorization decisions about its peers, and so on. 1368 Since confidentiality and integrity protection occurs at the 1369 transport layer. Agents can read, and perhaps modify, any part of a 1370 Diameter message, including an overload report. 1372 There are several ways an attacker might attempt to exploit the 1373 overload control mechanism. An unauthorized third party might inject 1374 an overload report into the network. If this third party is upstream 1375 of an agent, and that agent fails to apply proper authorization 1376 policies, downstream nodes may mistakenly trust the report. This 1377 attack is at least partially mitigated by the assumption that nodes 1378 include overload reports in Diameter answers but not in requests. 1379 This requires an attacker to have knowledge of the original request 1380 in order to construct a response. Therefore, implementations SHOULD 1381 validate that an answer containing an overload report is a properly 1382 constructed response to a pending request prior to acting on the 1383 overload report. 1385 A similar attack involves an otherwise authorized Diameter node that 1386 sends an inappropriate overload report. For example, a server for 1387 the realm "example.com" might send an overload report indicating that 1388 a competitor's realm "example.net" is overloaded. If other nodes act 1389 on the report, they may falsely believe that "example.net" is 1390 overloaded, effectively reducing that realm's capacity. Therefore, 1391 it's critical that nodes validate that an overload report received 1392 from a peer actually falls within that peer's responsibility before 1393 acting on the report or forwarding the report to other peers. For 1394 example, an overload report from a peer that applies to a realm not 1395 handled by that peer is suspect. 1397 An attacker might use the information in an overload report to assist 1398 in certain attacks. For example, an attacker could use information 1399 about current overload conditions to time a DoS attack for maximum 1400 effect, or use subsequent overload reports as a feedback mechanism to 1401 learn the results of a previous or ongoing attack. 1403 9.2. Denial of Service Attacks 1405 Diameter overload reports can cause a node to cease sending some or 1406 all Diameter requests for an extended period. This makes them a 1407 tempting vector for DoS tacks. Furthermore, since Diameter is almost 1408 always used in support of other protocols, a DoS attack on Diameter 1409 is likely to impact those protocols as well. Therefore, Diameter 1410 nodes MUST NOT honor or forward overload reports from unauthorized or 1411 otherwise untrusted sources. 1413 9.3. Non-Compliant Nodes 1415 When a Diameter node sends an overload report, it cannot assume that 1416 all nodes will comply. A non-compliant node might continue to send 1417 requests with no reduction in load. Requirement 28 [RFC7068] 1418 indicates that the overload control solution cannot assume that all 1419 Diameter nodes in a network are necessarily trusted, and that 1420 malicious nodes not be allowed to take advantage of the overload 1421 control mechanism to get more than their fair share of service. 1423 In the absence of an overload control mechanism, Diameter nodes need 1424 to implement strategies to protect themselves from floods of 1425 requests, and to make sure that a disproportionate load from one 1426 source does not prevent other sources from receiving service. For 1427 example, a Diameter server might reject a certain percentage of 1428 requests from sources that exceed certain limits. Overload control 1429 can be thought of as an optimization for such strategies, where 1430 downstream nodes never send the excess requests in the first place. 1431 However, the presence of an overload control mechanism does not 1432 remove the need for these other protection strategies. 1434 9.4. End-to End-Security Issues 1436 The lack of end-to-end security features makes it far more difficult 1437 to establish trust in overload reports that originate from non- 1438 adjacent nodes. Any agents in the message path may insert or modify 1439 overload reports. Nodes must trust that their adjacent peers perform 1440 proper checks on overload reports from their peers, and so on, 1441 creating a transitive-trust requirement extending for potentially 1442 long chains of nodes. Network operators must determine if this 1443 transitive trust requirement is acceptable for their deployments. 1444 Nodes supporting Diameter overload control MUST give operators the 1445 ability to select which peers are trusted to deliver overload 1446 reports, and whether they are trusted to forward overload reports 1447 from non-adjacent nodes. 1449 The lack of end-to-end confidentiality protection means that any 1450 Diameter agent in the path of an overload report can view the 1451 contents of that report. In addition to the requirement to select 1452 which peers are trusted to send overload reports, operators MUST be 1453 able to select which peers are authorized to receive reports. A node 1454 MUST not send an overload report to a peer not authorized to receive 1455 it. Furthermore, an agent MUST remove any overload reports that 1456 might have been inserted by other nodes before forwarding a Diameter 1457 message to a peer that is not authorized to receive overload reports. 1459 At the time of this writing, the DIME working group is studying 1460 requirements for adding end-to-end security 1461 [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, 1462 when they become available, might make it easier to establish trust 1463 in non-adjacent nodes for overload control purposes. Readers should 1464 be reminded, however, that the overload control mechanism encourages 1465 Diameter agents to modify AVPs in, or insert additional AVPs into, 1466 existing messages that are originated by other nodes. If end-to-end 1467 security is enabled, there is a risk that such modification could 1468 violate integrity protection. The details of using any future 1469 Diameter end-to-end security mechanism with overload control will 1470 require careful consideration, and are beyond the scope of this 1471 document. 1473 10. Contributors 1475 The following people contributed substantial ideas, feedback, and 1476 discussion to this document: 1478 o Eric McMurry 1480 o Hannes Tschofenig 1482 o Ulrich Wiehe 1484 o Jean-Jacques Trottin 1486 o Maria Cruz Bartolome 1488 o Martin Dolly 1490 o Nirav Salot 1492 o Susan Shishufeng 1494 11. References 1496 11.1. Normative References 1498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1499 Requirement Levels", BCP 14, RFC 2119, March 1997. 1501 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1502 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1503 May 2008. 1505 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1506 Time Protocol Version 4: Protocol and Algorithms 1507 Specification", RFC 5905, June 2010. 1509 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1510 "Diameter Base Protocol", RFC 6733, October 2012. 1512 11.2. Informative References 1514 [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. 1516 [I-D.ietf-dime-e2e-sec-req] 1517 Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, 1518 "Diameter AVP Level Security: Scenarios and Requirements", 1519 draft-ietf-dime-e2e-sec-req-00 (work in progress), 1520 September 2013. 1522 [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. 1524 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 1525 Loughney, "Diameter Credit-Control Application", RFC 4006, 1526 August 2005. 1528 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, 1529 "Clarifications on the Routing of Diameter Requests Based 1530 on the Username and the Realm", RFC 5729, December 2009. 1532 [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control 1533 Requirements", RFC 7068, November 2013. 1535 [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. 1537 Appendix A. Issues left for future specifications 1539 The base solution for the overload control does not cover all 1540 possible use cases. A number of solution aspects were intentionally 1541 left for future specification and protocol work. 1543 A.1. Additional traffic abatement algorithms 1545 This specification describes only means for a simple loss based 1546 algorithm. Future algorithms can be added using the designed 1547 solution extension mechanism. The new algorithms need to be 1548 registered with IANA. See Sections 6.1 and 8 for the required IANA 1549 steps. 1551 A.2. Agent Overload 1553 This specification focuses on Diameter endpoint (server or client) 1554 overload. A separate extension will be required to outline the 1555 handling of the case of agent overload. 1557 A.3. New Error Diagnostic AVP 1559 The proposal was made to add a new Error Diagnostic AVP to supplement 1560 the error responces to be able to indicate that overload was the 1561 reason for the rejection of the message. 1563 Appendix B. Deployment Considerations 1565 Non supporting agents 1567 Due to the way that realm-routed requests are handled in Diameter 1568 networks, with the server selection for the request done by an 1569 agent, it is recommended that deployments enable all agents that 1570 do server selection to support the DOIC solution prior to enabling 1571 the DOIC solution in the Diameter network. 1573 Topology hiding interactions 1575 There exist proxies that implement what is referred to as Topology 1576 Hiding. This can include cases where the agent modifies the 1577 Origin-Host in answer messages. The behavior of the DOIC solution 1578 is not well understood when this happens. As such, the DOIC 1579 solution does not address this scenario. 1581 Appendix C. Requirements Conformance Analysis 1583 This section contains the result of an analysis of the DOIC solutions 1584 conformance to the requirements defined in [RFC7068]. 1586 To be completed. 1588 Appendix D. Considerations for Applications Integrating the DOIC 1589 Solution 1591 This section outlines considerations to be taken into account when 1592 integrating the DOIC solution into Diameter applications. 1594 D.1. Application Classification 1596 The following is a classification of Diameter applications and 1597 request types. This discussion is meant to document factors that 1598 play into decisions made by the Diameter identity responsible for 1599 handling overload reports. 1601 Section 8.1 of [RFC6733] defines two state machines that imply two 1602 types of applications, session-less and session-based applications. 1603 The primary difference between these types of applications is the 1604 lifetime of Session-Ids. 1606 For session-based applications, the Session-Id is used to tie 1607 multiple requests into a single session. 1609 The Credit-Control application defined in [RFC4006] is an example of 1610 a Diameter session-based application. 1612 In session-less applications, the lifetime of the Session-Id is a 1613 single Diameter transaction, i.e. the session is implicitly 1614 terminated after a single Diameter transaction and a new Session-Id 1615 is generated for each Diameter request. 1617 For the purposes of this discussion, session-less applications are 1618 further divided into two types of applications: 1620 Stateless applications: 1622 Requests within a stateless application have no relationship to 1623 each other. The 3GPP defined S13 application is an example of a 1624 stateless application [S13], where only a Diameter command is 1625 defined between a client and a server and no state is maintained 1626 between two consecutive transactions. 1628 Pseudo-session applications: 1630 Applications that do not rely on the Session-Id AVP for 1631 correlation of application messages related to the same session 1632 but use other session-related information in the Diameter requests 1633 for this purpose. The 3GPP defined Cx application [Cx] is an 1634 example of a pseudo-session application. 1636 The handling of overload reports must take the type of application 1637 into consideration, as discussed in Appendix D.2. 1639 D.2. Application Type Overload Implications 1641 This section discusses considerations for mitigating overload 1642 reported by a Diameter entity. This discussion focuses on the type 1643 of application. Appendix D.3 discusses considerations for handling 1644 various request types when the target server is known to be in an 1645 overloaded state. 1647 These discussions assume that the strategy for mitigating the 1648 reported overload is to reduce the overall workload sent to the 1649 overloaded entity. The concept of applying overload treatment to 1650 requests targeted for an overloaded Diameter entity is inherent to 1651 this discussion. The method used to reduce offered load is not 1652 specified here but could include routing requests to another Diameter 1653 entity known to be able to handle them, or it could mean rejecting 1654 certain requests. For a Diameter agent, rejecting requests will 1655 usually mean generating appropriate Diameter error responses. For a 1656 Diameter client, rejecting requests will depend upon the application. 1657 For example, it could mean giving an indication to the entity 1658 requesting the Diameter service that the network is busy and to try 1659 again later. 1661 Stateless applications: 1663 By definition there is no relationship between individual requests 1664 in a stateless application. As a result, when a request is sent 1665 or relayed to an overloaded Diameter entity - either a Diameter 1666 Server or a Diameter Agent - the sending or relaying entity can 1667 choose to apply the overload treatment to any request targeted for 1668 the overloaded entity. 1670 Pseudo-session applications: 1672 For pseudo-session applications, there is an implied ordering of 1673 requests. As a result, decisions about which requests towards an 1674 overloaded entity to reject could take the command code of the 1675 request into consideration. This generally means that 1676 transactions later in the sequence of transactions should be given 1677 more favorable treatment than messages earlier in the sequence. 1678 This is because more work has already been done by the Diameter 1679 network for those transactions that occur later in the sequence. 1680 Rejecting them could result in increasing the load on the network 1681 as the transactions earlier in the sequence might also need to be 1682 repeated. 1684 Session-based applications: 1686 Overload handling for session-based applications must take into 1687 consideration the work load associated with setting up and 1688 maintaining a session. As such, the entity sending requests 1689 towards an overloaded Diameter entity for a session-based 1690 application might tend to reject new session requests prior to 1691 rejecting intra-session requests. In addition, session ending 1692 requests might be given a lower probability of being rejected as 1693 rejecting session ending requests could result in session status 1694 being out of sync between the Diameter clients and servers. 1695 Application designers that would decide to reject mid-session 1696 requests will need to consider whether the rejection invalidates 1697 the session and any resulting session clean-up procedures. 1699 D.3. Request Transaction Classification 1701 Independent Request: 1703 An independent request is not correlated to any other requests 1704 and, as such, the lifetime of the session-id is constrained to an 1705 individual transaction. 1707 Session-Initiating Request: 1709 A session-initiating request is the initial message that 1710 establishes a Diameter session. The ACR message defined in 1711 [RFC6733] is an example of a session-initiating request. 1713 Correlated Session-Initiating Request: 1715 There are cases when multiple session-initiated requests must be 1716 correlated and managed by the same Diameter server. It is notably 1717 the case in the 3GPP PCC architecture [PCC], where multiple 1718 apparently independent Diameter application sessions are actually 1719 correlated and must be handled by the same Diameter server. 1721 Intra-Session Request: 1723 An intra session request is a request that uses the same Session- 1724 Id than the one used in a previous request. An intra session 1725 request generally needs to be delivered to the server that handled 1726 the session creating request for the session. The STR message 1727 defined in [RFC6733] is an example of an intra-session requests. 1729 Pseudo-Session Requests: 1731 Pseudo-session requests are independent requests and do not use 1732 the same Session-Id but are correlated by other session-related 1733 information contained in the request. There exists Diameter 1734 applications that define an expected ordering of transactions. 1735 This sequencing of independent transactions results in a pseudo 1736 session. The AIR, MAR and SAR requests in the 3GPP defined Cx 1737 [Cx] application are examples of pseudo-session requests. 1739 D.4. Request Type Overload Implications 1741 The request classes identified in Appendix D.3 have implications on 1742 decisions about which requests should be throttled first. The 1743 following list of request treatment regarding throttling is provided 1744 as guidelines for application designers when implementing the 1745 Diameter overload control mechanism described in this document. The 1746 exact behavior regarding throttling is a matter of local policy, 1747 unless specifically defined for the application. 1749 Independent requests: 1751 Independent requests can generally be given equal treatment when 1752 making throttling decisions, unless otherwise indicated by 1753 application requirements or local policy. 1755 Session-initiating requests: 1757 Session-initiating requests often represent more work than 1758 independent or intra-session requests. Moreover, session- 1759 initiating requests are typically followed by other session- 1760 related requests. Since the main objective of the overload 1761 control is to reduce the total number of requests sent to the 1762 overloaded entity, throttling decisions might favor allowing 1763 intra-session requests over session-initiating requests. In the 1764 absence of local policies or application specific requirements to 1765 the contrary, Individual session-initiating requests can be given 1766 equal treatment when making throttling decisions. 1768 Correlated session-initiating requests: 1770 A Request that results in a new binding, where the binding is used 1771 for routing of subsequent session-initiating requests to the same 1772 server, represents more work load than other requests. As such, 1773 these requests might be throttled more frequently than other 1774 request types. 1776 Pseudo-session requests: 1778 Throttling decisions for pseudo-session requests can take into 1779 consideration where individual requests fit into the overall 1780 sequence of requests within the pseudo session. Requests that are 1781 earlier in the sequence might be throttled more aggressively than 1782 requests that occur later in the sequence. 1784 Intra-session requests: 1786 There are two types of intra-sessions requests, requests that 1787 terminate a session and the remainder of intra-session requests. 1788 Implementors and operators may choose to throttle session- 1789 terminating requests less aggressively in order to gracefully 1790 terminate sessions, allow clean-up of the related resources (e.g. 1791 session state) and avoid the need for additional intra-session 1792 requests. Favoring session-termination requests may reduce the 1793 session management impact on the overloaded entity. The default 1794 handling of other intra-session requests might be to treat them 1795 equally when making throttling decisions. There might also be 1796 application level considerations whether some request types are 1797 favored over others. 1799 Authors' Addresses 1800 Jouni Korhonen (editor) 1801 Broadcom 1802 Porkkalankatu 24 1803 Helsinki FIN-00180 1804 Finland 1806 Email: jouni.nospam@gmail.com 1808 Steve Donovan (editor) 1809 Oracle 1810 7460 Warren Parkway 1811 Frisco, Texas 75034 1812 United States 1814 Email: srdonovan@usdonovans.com 1816 Ben Campbell 1817 Oracle 1818 7460 Warren Parkway 1819 Frisco, Texas 75034 1820 United States 1822 Email: ben@nostrum.com 1824 Lionel Morand 1825 Orange Labs 1826 38/40 rue du General Leclerc 1827 Issy-Les-Moulineaux Cedex 9 92794 1828 France 1830 Phone: +33145296257 1831 Email: lionel.morand@orange.com