<?xml  version="1.0"  encoding="US-ASCII"?>
<!DOCTYPE  rfc SYSTEM  "rfc2629.dtd"  [  <!ENTITY
rfc6733 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">  <!ENTITY
rfc5390 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5390.xml"> <!ENTITY
rfc2782 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">  <!ENTITY
draft-ietf-dime-overload-reqs                              PUBLIC                              ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-overload-reqs.xml"> <!ENTITY
draft-roach-dime-overload-ctrl                              PUBLIC                              ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.roach-dime-overload-ctrl.xml"> <!ENTITY
draft-korhonen-dime-ovl                              PUBLIC                              ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.korhonen-dime-ovl.xml">
  ]>
<?xml-stylesheet  type='text/xsl'   href='rfc2629.xslt'  ?>
<?rfc   toc="yes"?>
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<?rfc  sortrefs="no"  ?>
<?rfc  symrefs="yes"  ?>
<rfc  category="std" ipr="trust200902">
  <front>
    <title>Diameter Overload Data Analysis</title>
    <author fullname="Ben Campbell" initials="B." surname="Campbell">
      <organization>Tekelec</organization>
      <address>
        <postal>
          <street>17210 Campbell Rd.</street>
          <street>Suite 250</street>
          <city>Dallas</city>
          <region>TX</region>
          <code>75252</code>
          <country>US</country>
        </postal>
        <email>ben@nostrum.com</email>
      </address>
    </author>
    <author initials='H.' surname='Tschofenig' fullname='Hannes Tschofenig'>
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <email>Hannes.Tschofenig@nsn.com</email>
      </address>
    </author>
    <author initials='J.' surname='Korhonen' fullname='Jouni Korhonen'>
      <organization>Renesas Mobile</organization>
      <address>
        <postal>
          <street>Porkkalankatu 24</street>
          <city>Helsinki</city>
          <code>FIN-00180</code>
          <country>Finland</country>
        </postal>
        <email>jouni.nospam@gmail.com</email>
      </address>
    </author>
    <author fullname="Adam Roach" initials="A. B." surname="Roach">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street></street>
          <city>Dallas</city>
          <region>TX</region>
        </postal>
        <email>adam@nostrum.com</email>
      </address>
    </author>
    <date month="February" year="2013"/>
    <area>Operations</area>
    <abstract>
      <t>
       When a Diameter server or agent becomes overloaded, it needs to be able
       to gracefully reduce its load, typically by informing clients to reduce
       sending traffic for some period of time. Multiple mechanisms have been
       proposed for transporting overload and load information. While these
       proposals differ in many ways, they share similar data requirements.
       This document analyzes the data requirements of each proposal with a
       view towards proposing a common set of of Diameter Attribute-Value
       Pairs (AVPs).
      </t>
    </abstract>
  </front>
  <middle>
    <section  anchor = "intro" title="Introduction">
      <t>
       When a <xref target = "RFC6733">Diameter</xref> server or agent becomes
       overloaded, it needs to be able to gracefully reduce its load,
       typically by informing clients to reduce sending traffic for some
       period of time. The Diameter Overload Control
       <xref target="I-D.ietf-dime-overload-reqs">Requirements</xref> describe
       requirements for overflow control mechanisms.
      </t>
      <t>
       At the time of this writing, there have been two proposals for Diameter
       overload control mechanisms.
       <xref target="I-D.roach-dime-overload-ctrl">"A Mechanism for Diameter
       Overload Control" (MDOC)</xref> defines a mechanism that piggybacks
       overload and load state information over existing Diameter messages.
       <xref target="I-D.korhonen-dime-ovl">"The Diameter Overload Control
       Application" (DOCA)</xref> defines a mechanism that uses a new and
       distinct Diameter application to communicate similar information. While
       there are significant differences between the two proposals, they carry
       similar information. Each proposal includes its own set of Diameter
       AVPs.
      </t>
      <t>
       This document is intended as a framework for discussing the data
       requirements of the two proposals. It includes an analysis of the
       differences and similarities of their respective data elements, with a
       view towards rationalizing the AVPs from the two proposals.
      </t>
      <t>
       <list>
         <t>
          The authors expect that a follow-on effort will eventually specify a
          common data model for reporting Diameter overload information.
         </t>
       </list>
      </t>
      <t>
       This document assumes that Diameter nodes exchange overload control
       information via Diameter, rather than via some out-of-band channel.
       This document does not address the specific difference of either
       mechanism proposal, except where they impact the AVP definitions.
      </t>
    </section>
    <section title="Documentation Conventions">
      <t>
       This document uses terms defined in <xref target="RFC6733" /> and
       <xref target="I-D.ietf-dime-overload-reqs"/>.
      </t>
    </section>
    <section anchor="data-usage" title="Overload Control Data Usage">
      <t>
       A Diameter overload control mechanism based on the overload control
       <xref target="I-D.ietf-dime-overload-reqs">requirements</xref> involves
       the exchange of information between two or more Diameter nodes. The
       exchanged information serves three distinct purposes:
      </t>
      <t>
       <list style="hanging">
         <t hangText="Negotiation:">
          Diameter nodes need to negotiate support for the overload control
          mechanism in general. Nodes that support overload control need to
          advertise the overload control scopes they can support. Finally,
          they need to select an overload control algorithm.
         </t>
         <t hangText="Communication of Overload State:">
          Nodes need to report that an overload condition is in effect, to
          what degree they are overloaded, and the scope of the overload
          condition. We refer to such a communication as an "Overload Report".
         </t>
         <t hangText="Communication of Load:">
          Nodes need to communicate their current load status, even when not
          in an overloaded state.
         </t>
       </list>
      </t>
      <t>
       Overload Control information may be communicated between adjacent
       Diameter nodes, or it may cross one or more intervening nodes. Overload
       Control information can be communicated in either direction; that is, a
       downstream node can indicate overload to an upstream node, or
       vice-versa.
      </t>
      <t>
       <list>
         <t>
          Open Issue: There is an ongoing discussion about whether the
          overload control mechanism should be strictly hop-by-hop, or whether
          it should support communication between non-adjacent nodes. The
          results of this discussion may have implications for overload
          control data elements.
         </t>
       </list>
      </t>
    </section>
    <section anchor="diffs" title="Mechanism Differences that Affect Data Structures">
      <t>
       While a thorough comparison of the two proposed mechanisms is out of
       scope for this document, there are a few differences that directly
       impact the choice of data elements.
      </t>
      <section title="Non-Adjacent Nodes">
        <t>
         MDOC only supports hop-by-hop communication of overload information.
         DOCA allows for the possibility of communication between non-adjacent
         nodes. For hop-by-hop communication, the originator of an overload
         report is always the directly connected node. If non-adjacent
         communication is to be allowed, the data model needs a way to express
         the identity of the originating node.
        </t>
      </section>
      <section title="Stateless Negotiation">
        <t>
         Both MDOC and DOCA allow overload control parameters to be negotiated
         at the beginning of a connection, and persist for the duration of the
         connection. DOCA also allows a "stateless" mode, where the parameters
         do not persist between overload reports. This requires the sender of
         an overload report to restate any relevant parameters for each
         report. Thus, the DOCA overload report format includes the ability to
         express all such parameters at any time, not just during negotiation.
        </t>
        <t>
         Note that stateless negotiation does not mean that no state may ever
         be saved. Nodes may use implementation-specific methods of
         remembering certain parameters, or out-of-band configuration methods
         to do the same.
        </t>
      </section>
      <section title="Overload Scopes">
        <t>
         As described in <xref target="I-D.ietf-dime-overload-reqs"/>, it's
         possible for a Diameter node to experience overload that impacts some
         subset of potential traffic. For example, a Diameter agent might
         route traffic to different servers based on realm. If the server for
         one realm experienced an outage or overload condition, the agent
         report that it is overloaded for that realm, but can process traffic
         for other realms normally. We use the term "overload scope", or
         simply "scope", to refer to the set of potential messages affected by
         an overload report.
        </t>
        <t>
         MDOC includes a richer (and therefore more complex) concept of
         overload scopes. A node may include multiple scopes in an overload
         report. Each scope entry indicates both the type of scope, and the
         value of the scope, where the value is interpreted according to the
         type.
        </t>
        <t>
         DOCA also allows a node to include multiple scopes in a report. But
         DOCA's current set of scope types only affect the interpretation of
         the originating node identity. Therefore the DOCA scope entries do
         not include a value.
        </t>
      </section>
      <section title="Hard or Soft Overload State">
        <t>
         MDOC assumes that overload information is soft state. That is, it
         expires if not refreshed within a stated interval. DOCA also treats
         most overload information as soft state, but there are situations
         where it may be treated as hard-state. For example, if the OC-Level
         is set to "Hold", the expiration time is not honored.
        </t>
      </section>
    </section>
    <section title="Naming Conventions">
      <t>
       MDOC and DOCA use somewhat different naming conventions for their
       respective AVPs. DOCA prefixes each AVP name with "OC". (for example,
       "OC-Scope"). MDOC prefixes AVPs that can appear in the root of messages
       with "Overload", and leaves those that occur inside an overload related
       grouped AVP to be identified by context. (For example, "Overload Info"
       and "Supported Scopes"). The working group should consider picking one
       approach or the other.
      </t>
    </section>
    <section title="Data Element Comparison">
      <section title="Data Elements for Connection Establishment and Negotiation">
        <t>
         The following sections describe data elements used for initial
         negotiation.
        </t>
        <section anchor="scope-neg" title="Supported Scope Selection">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Scope : Bitmap of scopes supported by the sender.
              Currently defined values are "Host scope", "Realm Scope", "Only
              origin realm", "Application Information", "Node Utilization
              Information", and "Application Priorities".
             </t>
             <t>
              MDOC: Supported-Scopes : Bitmap of scopes supported by the
              sender. Currently defined values are "Destination-Realm",
              "Application-ID", "Destination-Host", "Host", "Connection",
              "Session-Group", and "Session".
             </t>
           </list>
          </t>
          <t>
           DOCA uses OC-Scope both to declare supported scopes, and to list
           the scopes associated with a particular overload report. MDOC uses
           separate dedicated AVPs for the two purposes. DOCA overloads
           OC-Scope to include indicators that load information and priority
           information may be included.
          </t>
        </section>
        <section anchor="algo-neg" title="Algorithm Selection">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Algorithm : Bitmap of supported algorithms. Currently
              defined values are "Drop", "Throttle", and "Prioritize".
              Multiple values allowed.
             </t>
             <t>
              MDOC: Overload-Algorithm: Enumeration of supported algorithms.
              Multiple instances allowed in negotiation. Currently, there is
              one algorithm described, namely "loss".
             </t>
           </list>
          </t>
          <t>
           Both mechanisms support algorithm extensibility. MDOC only allows
           Overload-Algorithm to occur in a CER or CEA message, and negotiates
           a single algorithm for the duration of the connection. DOCA allows
           the algorithm to be selected at report time. (Open Issue: what does
           it mean to indicate multiple algorithms in a congestion report?)
          </t>
        </section>
        <section title="Application Selection">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Applications: Indications of the applications that are
              of interest.
             </t>
             <t>
              MDOC: MDOC assumes that overload reports can apply to any and
              all applications, and does not negotiate the list upfront. The
              "application" scope is used to select one or more applications
              on a per-report basis.
             </t>
           </list>
          </t>
          <t>
           Open Issue: Are there use cases for the up front negotiation of
           applications of interest?
          </t>
        </section>
        <section title="Frequency of Reports">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Tocl: Indicates how frequent reports shall be sent.
             </t>
             <t>
              MDOC: N/A
             </t>
           </list>
          </t>
          <t>
           Since MDOC piggybacks overload reports in existing messages, the
           rate of overload reports is the same as the overall message rate.
           This may have advantage of giving more rapid and precise feedback
           as load increases.
          </t>
          <t>
           Open Issue: We need further discussion about the appropriate
           rate(s) for overload reporting, regardless of which mechanism may
           be selected.
          </t>
        </section>
        <section title="Grouping">
          <t>
           <list style="symbols">
             <t>
              DOCA: n/a - negotiation AVPs included at message root.
             </t>
             <t>
              MDOC: Load-Info: Grouped AVP acting as a container for the other
              AVPs used for negotiation.
             </t>
           </list>
          </t>
        </section>
      </section>
      <section title="Data Elements for Overload and Load reporting">
        <section title="Scope of Report">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Scope (See <xref target="scope-neg"/>)
             </t>
             <t>
              MDOC: Load-Info-Scope: Octet-String giving the scope of the
              overload report. The string contains a type indicator and a
              value. One or more instances required.
             </t>
           </list>
          </t>
          <t>
           MDOC has a richer and more complex concept of scopes. Multiple
           scopes can be combined for a given overload report. Allowable scope
           combinations are described in
           <xref target="I-D.roach-dime-overload-ctrl"/>.
          </t>
        </section>
        <section title="Overload Severity">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Level: OctetString(1): Values 1-6 define discreet
              overload levels of increasing severity, with 1 meaning no
              overload condition, and 6 meaning clients should switch to a
              different server.
             </t>
             <t>
              DOCA: OC-Sending-Rate: Float32: Used when the "throttle"
              algorithm is in effect to indicate the maximum desired Diameter
              message rate.
             </t>
             <t>
              MDOC: Overload-Metric (Unsigned32): A numeric representation of
              load. The meaning is up to the interpretation of the selected
              algorithm, with the exception that a value of zero always means
              that no overload abatement is in effect. For the "Loss"
              algorithm, Overload Metric is a numeric value in the range of
              zero through 100, indicating the percentage of traffic reduction
              requested.
             </t>
           </list>
          </t>
          <t>
           The Overload-Metric AVP used by MDOC is more general than OC-Level,
           in that it's interpretation is left to the algorithm. The meaning
           of the OC-Level values appear to be fixed regardless of algorithm
           choice. the OC-Level meanings could be used in MDOC by defining a
           new algorithm that interpreted Overload-Metric values 1-6 in the
           same way as defined for OC-Level.
          </t>
          <t>
           Since MDOC does not define an algorithm similar to "throttle", it
           has no built in analog to OC-Sending-Rate. However, since MDOC
           allows algorithm extensibility, one could define a similar
           algorithm, and if necessary, add an extension AVP to state
           sending-rate.
          </t>
        </section>
        <section title="Report Algorithm">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Algorithm (See <xref target="algo-neg"/>)
             </t>
             <t>
              MDOC: The overload control algorithm is set during negotiation,
              and doesn't change for the duration of the connection.
             </t>
           </list>
          </t>
          <t>
           Open Issue: DOCA's reuse of the OC-Algorithm AVP seems to allow
           more than one algorithm to be assigned to a single overload report.
           It's not clear what that would mean.
          </t>
        </section>
        <section title="Report Expiration">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Best-Before: (Time) Time of report expiration.
             </t>
             <t>
              MDOC: Period-Of-Validity (Unsigned32)- Number of seconds until
              expiration.
             </t>
           </list>
          </t>
          <t>
           DOCA defines expiration to be a point in time. MDOC uses a
           duration, i.e. number of seconds until expiration. The DOCA
           approach seems to require clock synchronization.
          </t>
          <t>
           DOCA contains an open issue about whether to allow reports to
           expire vs. requiring explicit signaling.
          </t>
        </section>
        <section title="Current Load">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Utilization: Indicates the overall load situation as a
              value between 0 and 100.
             </t>
             <t>
              MDOC: Load: The load situation in terms of 0 - 65535.
             </t>
           </list>
          </t>
          <t>
           Current load indicates the existing load on an otherwise
           non-overloaded node. MDOC's range of 0-65535 was selected to
           harmonize with the <xref target="RFC2782">DNS service location
           (SRV)</xref> record's "Weight" field.
          </t>
        </section>
        <section title="Applications covered by a Report">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Applications: Indications what applications are of
              interest for load reporting.
             </t>
             <t>
              MDOC does not use a separate AVP for this purpose. Rather, one
              or more applications can be indicated using the application
              scope type.
             </t>
           </list>
          </t>
        </section>
        <section title="Report Action">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Action: Indicates the start, interim, and end of an
              overload period.
             </t>
             <t>
              MDOC: MDOC does not have a separate AVP to indicate the start
              and stop of an overload condition. Rather, a report with a
              non-zero Overload-Metric value starts the condition, and a
              report with a zero value, or the expiration of the
              Period-of-Validity value, indicate an end. Subsequent reports
              with non-zero Overload-Metric values serve the same purpose as a
              DOCA report with an OC-Action value of "interim".
             </t>
           </list>
          </t>
          <t>
           Open Issue: Is OC-Action redundant? DOCA also has the ability to
           express a non-overload condition in OC-Level, so an approach
           similar to that of MDOC should be workable.
          </t>
        </section>
        <section title="Priority">
          <t>
           <list style="symbols">
             <t>
              DOCA: OC-Priority: Unsigned32: When used in an OC-Information
              AVP, sets the relative priority of applications listed in
              OC-Applications. As specified, may also be used to set the
              priority of a given Diameter message. [Open Issue: Is
              OC-Priority only in effect when the "Prioritize" algorithm is in
              effect?]
             </t>
             <t>
              MDOC: N/A
             </t>
           </list>
          </t>
          <t>
           MDOC does not have an explicit priority data element. Relative
           priority between applications can be managed using the
           "Application" scope. This is not exactly the same as stating
           inter-application priority explicitly, but it may be possible to
           accomplish similar behavior.
          </t>
        </section>
        <section title="Session Groups">
          <t>
           <list style="symbols">
             <t>
              DOCA: N/A
             </t>
             <t>
              MDOC: Session-Group: UTF8String: Session-Group allows a node to
              assign a session to a named group. Overload Reports can refer to
              all sessions in a group using the Session-Group AVP.
             </t>
           </list>
          </t>
          <t>
           A common application for Session-Group is when a Diameter agent
           load balances Diameter sessions across a set of servers. If the
           agent assigns all of the sessions assigned to a particular server
           to a group, and that server later becomes overloaded, the agent can
           send one overload report that applies to all sessions in the group,
           but does not apply to sessions assigned to other, non-overloaded,
           servers.
          </t>
          <t>
           DOCA may be able to do something similar using by using the
           OC-Origin AVP to identify the overloaded server. However, the
           server-group approach can work even if the Diameter agent performs
           topology hiding.
          </t>
        </section>
      </section>
      <section title="Result Codes">
        <t>
         DOCA defines the following Diameter result codes:
         <list style="symbols">
           <t>
            DIAMETER_NO_COMMON_SCOPE (Permanent Failure): The Diameter peers
            are unable to negotiate one or more scopes in common.
           </t>
           <t>
            DIAMETER_NO_COMMON_ALGORITHM (Permanent Failure): The Diameter
            peers are unable to negotiate one or more algorithms in common.
           </t>
           <t>
            DIAMETER_TOCL_TOO_SMALL (Permanent Failure): The peer included an
            OC-TOCL AVP with an unacceptably low value.
           </t>
           <t>
            DIAMETER_TOCL_TOO_BIG (Permanent Failure): The peer included an
            OC-TOCL AVP with an unacceptably high value.
           </t>
           <t>
            DIAMETER_RATE_TOO_BIG (Permanent Failure): The peer included an
            OC-SENDING-RATE AVP with an unacceptably high value.
           </t>
         </list>
        </t>
        <t>
         A failure to negotiate Overload Control support does not cause a
         connection failure in MDOC. Instead, overload control is just not
         invoked on the connection.
        </t>
        <t>
         MDOC defines the following result codes:
         <list style="symbols">
           <t>
            DIAMETER_PEER_IN_OVERLOAD (Transient Failure): When a Diameter
            node drops a request due to overload, it responds with this result
            code. This is primarily used when the peer does not support
            overload control, and therefore fails to reduce load as it would
            be expected to do so if it supported overload control.
           </t>
         </list>
        </t>
        <t>
         DIAMETER_PEER_IN_OVERLOAD may be of value to both mechanisms. The
         <xref target="I-D.ietf-dime-overload-reqs">Overload Control
         Requirements</xref> argues that the result codes in the Diameter base
         protocol are insufficient for reporting failures due to congestion.
        </t>
      </section>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations">
      <t>
       This draft makes no requests of IANA. The authors expect that a
       follow-on effort will specify a common set of Overload Control
       AVPs.This may introduce additional IANA considerations.
      </t>
    </section>
    <section title="Security Considerations">
      <t>
       This document compares the data elements used by
       <xref target="I-D.korhonen-dime-ovl">"DOCA</xref> and
       <xref target="I-D.roach-dime-overload-ctrl">MDOC</xref>. It introduces
       no security considerations beyond those in the respective documents.
      </t>
      <t>
       The authors expect that a follow-on effort will specify a common set of
       Overload Control AVPs. This may introduce additional security
       considerations.
      </t>
      <t>
       The authors made no attempt to analyze the security considerations in
       the DOCA and MDOC specifications for completeness.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    &rfc6733;
    &draft-ietf-dime-overload-reqs;
	&draft-roach-dime-overload-ctrl;
	&draft-korhonen-dime-ovl;
    </references>
    <references title="Informative References">
	&rfc2782;
</references>
    <section title="Contributors">
      <t>
       Eric McMurry made significant contributions to the analysis in this
       draft.
      </t>
    </section>
  </back>
</rfc>
