Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7683

Diameter Overload Indication Conveyance

Pages: 42
Proposed Standard
Updated by:  8581
Part 2 of 2 – Pages 23 to 42
First   Prev   None

Top   ToC   RFC7683 - Page 23   prevText

6. Loss Algorithm

This section documents the Diameter overload loss abatement algorithm.

6.1. Overview

The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the DOIC Capability Announcement process documented in Section 5.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes request the stateless reduction of the number of requests by an indicated percentage. This percentage reduction is in comparison to the number of messages the node otherwise would send, regardless of how many requests the node might have sent in the past. From a conceptual level, the logic at the reacting node could be outlined as follows. 1. An overload report is received, and the associated OCS is either saved or updated (if required) by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request, as indicated by the corresponding OCS entry. 4. The reacting node determines if overload abatement treatment should be applied to the request. One approach that could be taken for each request is to select a uniformly selected random number between 1 and 100. If the random number is less than or
Top   ToC   RFC7683 - Page 24
       equal to the indicated reduction percentage, then the request is
       given abatement treatment; otherwise, the request is given normal
       routing treatment.

6.2. Reporting Node Behavior

The method a reporting node uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a reduction in traffic, it includes an OC-OLR AVP in answer messages as described in Section 5.2.3. When sending the OC-OLR AVP, the reporting node MUST indicate a percentage reduction in the OC-Reduction-Percentage AVP. The reporting node MAY change the reduction percentage in subsequent overload reports. When doing so, the reporting node must conform to overload report handling specified in Section 5.2.3.

6.3. Reacting Node Behavior

The method a reacting node uses to determine which request messages are given abatement treatment is an implementation decision. When receiving an OC-OLR in an answer message where the algorithm indicated in the OC-Supported-Features AVP is the loss algorithm, the reacting node MUST apply abatement treatment to the requested percentage of request messages sent. Note: The loss algorithm is a stateless algorithm. As a result, the reacting node does not guarantee that there will be an absolute reduction in traffic sent. Rather, it guarantees that the requested percentage of new requests will be given abatement treatment. If the reacting node comes out of the 100% traffic reduction (meaning, it has received an OLR indicating that no traffic should be sent, as a result of the overload report timing out), the reacting node sending the traffic SHOULD be conservative and, for example, first send "probe" messages to learn the overload condition of the overloaded node before converging to any traffic amount/rate decided by the sender. Similar concerns apply in all cases when the overload report times out, unless the previous overload report stated 0% reduction.
Top   ToC   RFC7683 - Page 25
      Note: The goal of this behavior is to reduce the probability of
      overload condition thrashing where an immediate transition from
      100% reduction to 0% reduction results in the reporting node
      moving quickly back into an overload condition.

7. Attribute Value Pairs

This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. Refer to Section 4 of [RFC6733] for more information on AVPs and AVP data types.

7.1. OC-Supported-Features AVP

The OC-Supported-Features AVP (AVP Code 621) is of type Grouped and serves two purposes. First, it announces a node's support for the DOIC solution in general. Second, it contains the description of the supported DOIC features of the sending node. The OC-Supported- Features AVP MUST be included in every Diameter request message a DOIC supporting node sends. OC-Supported-Features ::= < AVP Header: 621 > [ OC-Feature-Vector ] * [ AVP ]

7.2. OC-Feature-Vector AVP

The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and contains a 64-bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. The OC-Feature-Vector sub-AVP is used to announce the DOIC features supported by the DOIC node, in the form of a flag-bits field in which each bit announces one feature or capability supported by the node. The absence of the OC-Feature-Vector AVP in request messages indicates that only the default traffic abatement algorithm described in this specification is supported. The absence of the OC-Feature- Vector AVP in answer messages indicates that the default traffic abatement algorithm described in this specification is selected (while other traffic abatement algorithms may be supported), and no features other than abatement algorithms are supported.
Top   ToC   RFC7683 - Page 26
   The following capability is defined in this document:

   OLR_DEFAULT_ALGO (0x0000000000000001)

      When this flag is set by the a DOIC reacting node, it means that
      the default traffic abatement (loss) algorithm is supported.  When
      this flag is set by a DOIC reporting node, it means that the loss
      algorithm will be used for requested overload abatement.


The OC-OLR AVP (AVP Code 623) is of type Grouped and contains the information necessary to convey an overload report on an overload condition at the reporting node. The application the OC-OLR AVP applies to is identified by the Application-ID found in the Diameter message header. The host or realm the OC-OLR AVP concerns is determined from the Origin-Host AVP and/or Origin-Realm AVP found in the encapsulating Diameter command. The OC-OLR AVP is intended to be sent only by a reporting node. OC-OLR ::= < AVP Header: 623 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ]

7.4. OC-Sequence-Number AVP

The OC-Sequence-Number AVP (AVP Code 624) is of type Unsigned64. Its usage in the context of overload control is described in Section 5.2. From the functionality point of view, the OC-Sequence-Number AVP is used as a nonvolatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. Sequence numbers are treated in a unidirectional manner, i.e., two sequence numbers in each direction between two DOIC nodes are not related or correlated.

7.5. OC-Validity-Duration AVP

The OC-Validity-Duration AVP (AVP Code 625) is of type Unsigned32 and indicates in seconds the validity time of the overload report. The number of seconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 30 seconds. When the OC-Validity- Duration AVP is not present in the OC-OLR AVP, the default value applies. The maximum value for the OC-Validity-Duration AVP is
Top   ToC   RFC7683 - Page 27
   86,400 seconds (24 hours).  If the value received in the OC-Validity-
   Duration is greater than the maximum value, then the default value

7.6. OC-Report-Type AVP

The OC-Report-Type AVP (AVP Code 626) is of type Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: HOST_REPORT 0 The overload report is for a host. Overload abatement treatment applies to host-routed requests. REALM_REPORT 1 The overload report is for a realm. Overload abatement treatment applies to realm-routed requests. The values 2-4294967295 are unassigned.

7.7. OC-Reduction-Percentage AVP

The OC-Reduction-Percentage AVP (AVP Code 627) is of type Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e., the reporting node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement.
Top   ToC   RFC7683 - Page 28

7.8. AVP Flag Rules

+---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features 621 7.1 Grouped | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector 622 7.2 Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-OLR 623 7.3 Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number 624 7.4 Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration 625 7.5 Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type 626 7.6 Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage 627 7.7 Unsigned32 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application.

8. Error Response Codes

When a DOIC node rejects a Diameter request due to overload, the DOIC node MUST select an appropriate error response code. This determination is made based on the probability of the request succeeding if retried on a different path. Note: This only applies for DOIC nodes that are not the originator of the request. A reporting node rejecting a Diameter request due to an overload condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can assume that the same request may succeed on a different path. If a reporting node knows or assumes that the same request will not succeed on a different path, the DIAMETER_UNABLE_TO_COMPLY error response SHOULD be used. Retrying would consume valuable resources during an occurrence of overload.
Top   ToC   RFC7683 - Page 29
      For instance, if the request arrived at the reporting node without
      a Destination-Host AVP, then the reporting node might determine
      that there is an alternative Diameter node that could successfully
      process the request and that retrying the transaction would not
      negatively impact the reporting node.  DIAMETER_TOO_BUSY would be
      sent in this case.

      If the request arrived at the reporting node with a Destination-
      Host AVP populated with its own Diameter identity, then the
      reporting node can assume that retrying the request would result
      in it coming to the same reporting node.
      DIAMETER_UNABLE_TO_COMPLY would be sent in this case.

      A second example is when an agent that supports the DOIC solution
      is performing the role of a reacting node for a non-supporting
      client.  Requests that are rejected as a result of DOIC throttling
      by the agent in this scenario would generally be rejected with a
      DIAMETER_UNABLE_TO_COMPLY response code.

9. IANA Considerations

9.1. AVP Codes

New AVPs defined by this specification are listed in Section 7. All AVP codes are allocated from the "AVP Codes" sub-registry under the "Authentication, Authorization, and Accounting (AAA) Parameters" registry.

9.2. New Registries

Two new registries have been created in the "AVP Specific Values" sub-registry under the "Authentication, Authorization, and Accounting (AAA) Parameters" registry. A new "OC-Feature-Vector AVP Values (code 622)" registry has been created. This registry contains the following: Feature Vector Value Name Feature Vector Value Specification defining the new value See Section 7.2 for the initial Feature Vector Value in the registry. This specification defines the value. New values can be added to the registry using the Specification Required policy [RFC5226].
Top   ToC   RFC7683 - Page 30
   A new "OC-Report-Type AVP Values (code 626)" registry has been
   created.  This registry contains the following:

      Report Type Value Name

      Report Type Value

      Specification defining the new value

   See Section 7.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

10. Security Considerations

DOIC gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly effect this reduction. This exchange is potentially subject to multiple methods of attack and has the potential to be used as a denial-of-service (DoS) attack vector. For instance, a series of injected realm OLRs with a requested reduction percentage of 100% could be used to completely eliminate any traffic from being sent to that realm. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid their use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes.

10.1. Potential Threat Modes

The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g., TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPsec to authenticate peers and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer.
Top   ToC   RFC7683 - Page 31
   When agents are involved, this presents an effectively transitive
   trust model.  That is, a Diameter client or server can authorize an
   agent for certain actions, but it must trust that agent to make
   appropriate authorization decisions about its peers, and so on.
   Since confidentiality and integrity protection occur at the transport
   layer, agents can read, and perhaps modify, any part of a Diameter
   message, including an overload report.

   There are several ways an attacker might attempt to exploit the
   overload control mechanism.  An unauthorized third party might inject
   an overload report into the network.  If this third party is upstream
   of an agent, and that agent fails to apply proper authorization
   policies, downstream nodes may mistakenly trust the report.  This
   attack is at least partially mitigated by the assumption that nodes
   include overload reports in Diameter answers but not in requests.
   This requires an attacker to have knowledge of the original request
   in order to construct an answer.  Such an answer would also need to
   arrive at a Diameter node via a protected transport connection.
   Therefore, implementations MUST validate that an answer containing an
   overload report is a properly constructed response to a pending
   request prior to acting on the overload report, and that the answer
   was received via an appropriate transport connection.

   A similar attack involves a compromised but otherwise authorized node
   that sends an inappropriate overload report.  For example, a server
   for the realm "" might send an overload report indicating
   that a competitor's realm "" is overloaded.  If other
   nodes act on the report, they may falsely believe that ""
   is overloaded, effectively reducing that realm's capacity.
   Therefore, it's critical that nodes validate that an overload report
   received from a peer actually falls within that peer's responsibility
   before acting on the report or forwarding the report to other peers.
   For example, an overload report from a peer that applies to a realm
   not handled by that peer is suspect.  This may require out-of-band,
   non-Diameter agreements and/or mechanisms.

      This attack is partially mitigated by the fact that the
      application, as well as host and realm, for a given OLR is
      determined implicitly by respective AVPs in the enclosing answer.
      If a reporting node modifies any of those AVPs, the enclosing
      transaction will also be affected.

10.2. Denial-of-Service Attacks

Diameter overload reports, especially realm reports, can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS attacks. Furthermore, since Diameter is almost always used in support of other
Top   ToC   RFC7683 - Page 32
   protocols, a DoS attack on Diameter is likely to impact those
   protocols as well.  In the worst case, where the Diameter application
   is being used for access control into an IP network, a coordinated
   DoS attack could result in the blockage of all traffic into that
   network.  Therefore, Diameter nodes MUST NOT honor or forward OLRs
   received from peers that are not trusted to send them.

   An attacker might use the information in an OLR to assist in DoS
   attacks.  For example, an attacker could use information about
   current overload conditions to time an attack for maximum effect, or
   use subsequent overload reports as a feedback mechanism to learn the
   results of a previous or ongoing attack.  Operators need the ability
   to ensure that OLRs are not leaked to untrusted parties.

10.3. Noncompliant Nodes

In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might throttle a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. When a Diameter node sends an overload report, it cannot assume that all nodes will comply, even if they indicate support for DOIC. A noncompliant node might continue to send requests with no reduction in load. Such noncompliance could be done accidentally or maliciously to gain an unfair advantage over compliant nodes. Requirement 28 in [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are trusted. It also requires that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service.

10.4. End-to-End Security Issues

The lack of end-to-end integrity features makes it difficult to establish trust in overload reports received from non-adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive- trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter
Top   ToC   RFC7683 - Page 33
   overload control MUST give operators the ability to select which
   peers are trusted to deliver overload reports and whether they are
   trusted to forward overload reports from non-adjacent nodes.  DOIC
   nodes MUST strip DOIC AVPs from messages received from peers that are
   not trusted for DOIC purposes.

   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.

      A DOIC node cannot always automatically detect that a peer also
      supports DOIC.  For example, a node might have a peer that is a
      non-supporting agent.  If nodes on the other side of that agent
      send OC-Supported-Features AVPs, the agent is likely to forward
      them as unknown AVPs.  Messages received across the non-supporting
      agent may be indistinguishable from messages received across a
      DOIC supporting agent, giving the false impression that the non-
      supporting agent actually supports DOIC.  This complicates the
      transitive-trust nature of DOIC.  Operators need to be careful to
      avoid situations where a non-supporting agent is mistakenly
      trusted to enforce DOIC-related authorization policies.

   It is expected that work on end-to-end Diameter security might make
   it easier to establish trust in non-adjacent nodes for overload
   control purposes.  Readers should be reminded, however, that the
   overload control mechanism allows Diameter Agents to modify AVPs in,
   or insert additional AVPs into, existing messages that are originated
   by other nodes.  If end-to-end security is enabled, there is a risk
   that such modification could violate integrity protection.  The
   details of using any future Diameter end-to-end security mechanism
   with overload control will require careful consideration, and are
   beyond the scope of this document.
Top   ToC   RFC7683 - Page 34

11. References

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <>. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <>.

11.2. Informative References

[Cx] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 12.7.0, September 2015. [PCC] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 12.10.0, September 2015. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005, <>. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, DOI 10.17487/RFC7068, November 2013, <>. [S13] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272 12.8.0, September 2015.
Top   ToC   RFC7683 - Page 35

Appendix A. Issues Left for Future Specifications

The base solution for overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. The following subsections define some of the potential extensions to the DOIC solution.

A.1. Additional Traffic Abatement Algorithms

This specification describes only means for a simple loss-based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 7.2 and 9 for the required IANA steps.

A.2. Agent Overload

This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling of the case of agent overload.

A.3. New Error Diagnostic AVP

This specification indicates the use of existing error messages when nodes reject requests due to overload. There is an expectation that additional error codes or AVPs will be defined in a separate specification to indicate that overload was the reason for the rejection of the message.

Appendix B. Deployment Considerations

Non-supporting Agents Due to the way that realm-routed requests are handled in Diameter networks with the server selection for the request done by an agent, network operators should enable DOIC at agents that perform server selection first. Topology-Hiding Interactions There exist proxies that implement what is referred to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario.
Top   ToC   RFC7683 - Page 36
   Inter-Realm/Administrative Domain Considerations

      There are likely to be special considerations for handling DOIC
      signaling across administrative boundaries.  This includes
      considerations for whether or not information included in the DOIC
      signaling should be sent across those boundaries.  In addition,
      consideration should be taken as to whether or not a reacting node
      in one realm can be trusted to implement the requested overload
      abatement handling for overload reports received from a separately
      administered realm.

Appendix C. Considerations for Applications Integrating the DOIC Solution

This section outlines considerations to be taken into account when integrating the DOIC solution into Diameter applications.

C.1. Application Classification

The following is a classification of Diameter applications and request types. This discussion is meant to document factors that play into decisions made by the Diameter entity responsible for handling overload reports. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e., the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request.
Top   ToC   RFC7683 - Page 37
   For the purposes of this discussion, session-less applications are
   further divided into two types of applications:

   Stateless Applications:

      Requests within a stateless application have no relationship to
      each other.  The 3GPP-defined S13 application is an example of a
      stateless application [S13], where only a Diameter command is
      defined between a client and a server and no state is maintained
      between two consecutive transactions.

   Pseudo-Session Applications:

      Applications that do not rely on the Session-Id AVP for
      correlation of application messages related to the same session
      but use other session-related information in the Diameter requests
      for this purpose.  The 3GPP-defined Cx application [Cx] is an
      example of a pseudo-session application.

   The handling of overload reports must take the type of application
   into consideration, as discussed in Appendix C.2.

C.2. Implications of Application Type Overload

This section discusses considerations for mitigating overload reported by a Diameter entity. This discussion focuses on the type of application. Appendix C.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to this discussion. The method used to reduce offered load is not specified here, but it could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter Agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later.
Top   ToC   RFC7683 - Page 38
   Stateless Applications:

      By definition, there is no relationship between individual
      requests in a stateless application.  As a result, when a request
      is sent or relayed to an overloaded Diameter entity -- either a
      Diameter Server or a Diameter Agent -- the sending or relaying
      entity can choose to apply the overload treatment to any request
      targeted for the overloaded entity.

   Pseudo-session Applications:

      For pseudo-session applications, there is an implied ordering of
      requests.  As a result, decisions about which requests towards an
      overloaded entity to reject could take the command code of the
      request into consideration.  This generally means that
      transactions later in the sequence of transactions should be given
      more favorable treatment than messages earlier in the sequence.
      This is because more work has already been done by the Diameter
      network for those transactions that occur later in the sequence.
      Rejecting them could result in increasing the load on the network
      as the transactions earlier in the sequence might also need to be

   Session-Based Applications:

      Overload handling for session-based applications must take into
      consideration the work load associated with setting up and
      maintaining a session.  As such, the entity sending requests
      towards an overloaded Diameter entity for a session-based
      application might tend to reject new session requests prior to
      rejecting intra-session requests.  In addition, session-ending
      requests might be given a lower probability of being rejected, as
      rejecting session-ending requests could result in session status
      being out of sync between the Diameter clients and servers.
      Application designers that would decide to reject mid-session
      requests will need to consider whether the rejection invalidates
      the session and any resulting session cleanup procedures.

C.3. Request Transaction Classification

Independent Request: An independent request is not correlated to any other requests, and, as such, the lifetime of the Session-Id is constrained to an individual transaction.
Top   ToC   RFC7683 - Page 39
   Session-Initiating Request:

      A session-initiating request is the initial message that
      establishes a Diameter session.  The ACR message defined in
      [RFC6733] is an example of a session-initiating request.

   Correlated Session-Initiating Request:

      There are cases when multiple session-initiated requests must be
      correlated and managed by the same Diameter server.  It is notably
      the case in the 3GPP Policy and Charging Control (PCC)
      architecture [PCC], where multiple apparently independent Diameter
      application sessions are actually correlated and must be handled
      by the same Diameter server.

   Intra-session Request:

      An intra-session request is a request that uses the same Session-
      Id as the one used in a previous request.  An intra-session
      request generally needs to be delivered to the server that handled
      the session-creating request for the session.  The STR message
      defined in [RFC6733] is an example of an intra-session request.

   Pseudo-session Requests:

      Pseudo-session requests are independent requests and do not use
      the same Session-Id but are correlated by other session-related
      information contained in the request.  There exist Diameter
      applications that define an expected ordering of transactions.
      This sequencing of independent transactions results in a pseudo-
      session.  The AIR, MAR, and SAR requests in the 3GPP-defined Cx
      [Cx] application are examples of pseudo-session requests.

C.4. Request Type Overload Implications

The request classes identified in Appendix C.3 have implications on decisions about which requests should be throttled first. The following list of request treatments regarding throttling is provided as guidelines for application designers when implementing the Diameter overload control mechanism described in this document. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent Requests: Independent requests can generally be given equal treatment when making throttling decisions, unless otherwise indicated by application requirements or local policy.
Top   ToC   RFC7683 - Page 40
   Session-Initiating Requests:

      Session-initiating requests often represent more work than
      independent or intra-session requests.  Moreover, session-
      initiating requests are typically followed by other session-
      related requests.  Since the main objective of overload control is
      to reduce the total number of requests sent to the overloaded
      entity, throttling decisions might favor allowing intra-session
      requests over session-initiating requests.  In the absence of
      local policies or application-specific requirements to the
      contrary, individual session-initiating requests can be given
      equal treatment when making throttling decisions.

   Correlated Session-Initiating Requests:

      A request that results in a new binding; where the binding is used
      for routing of subsequent session-initiating requests to the same
      server, it represents more work load than other requests.  As
      such, these requests might be throttled more frequently than other
      request types.

   Pseudo-session Requests:

      Throttling decisions for pseudo-session requests can take into
      consideration where individual requests fit into the overall
      sequence of requests within the pseudo-session.  Requests that are
      earlier in the sequence might be throttled more aggressively than
      requests that occur later in the sequence.

   Intra-session Requests:

      There are two types of intra-sessions requests, requests that
      terminate a session and the remainder of intra-session requests.
      Implementers and operators may choose to throttle session-
      terminating requests less aggressively in order to gracefully
      terminate sessions, allow cleanup of the related resources (e.g.,
      session state), and avoid the need for additional intra-session
      requests.  Favoring session termination requests may reduce the
      session management impact on the overloaded entity.  The default
      handling of other intra-session requests might be to treat them
      equally when making throttling decisions.  There might also be
      application-level considerations whether some request types are
      favored over others.
Top   ToC   RFC7683 - Page 41


The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng
Top   ToC   RFC7683 - Page 42

Authors' Addresses

Jouni Korhonen (editor) Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 United States Email: Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: