Subject: [Dime] Load mechanism proposal

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Aug 2015 15:59:05 -0500

All,

Based on the discussion during the DIME meeting in Prague I have updated 
the Solution Overview and Theory of Operation sections of the Load 
draft.  I have included those two sections below.

These sections reflect the agreement that we would support two types of 
load reports, one for end-points (clients or servers) that travel 
end-to-end and one for agents that are processed peer-to-peer.

If there is agreement with the approach taken below then I will add the 
normative behavior and AVP sections to the draft.

Regards,

Steve

5.  Solution Overview

    The mechanism defined here for the conveyance of load information is
    similar in some says to the mechanism defined for DOIC and is
    different in other ways.

    As with DOIC, load information is conveyed by piggy-backing the load
    AVPs on existing Diameter applications.

    There are two primary differences.  First, there is no capability
    negotiation process for load.  The sender of the load information is
    sending it with the expectation that any supporting nodes will use it
    when making routing decisions.  If there are no nodes that support
    the load extension then the load information is ignored.

    The second big difference between DOIC and Load is visibility of the
    DOIC or Load information within a Diameter network.  DOIC information
    is sent end-to-end resulting in the ability of all nodes in the path
    of the answer message that carries the OC-OLR AVP to act on the
    information.  The DOIC overload reports much remain in the message
    all the way from the reporting node to the node that is the target
    for the answer message.

    For the Load mechanism there are two types of load reports.

    The first is the load of the end-point sending the answering the
    message.  This load report is carried end-to-end to enable any node
    that make server selection decisions to use the load status of the
    sending end-point as part of the server selection decision.

    The second type of load report is a peer report.  This report is used
    by Diameter nodes as part of the logic to select the next hop
    Diameter node.

    Because load reports can traverse Diameter nodes that do not support
    the load mechanism, it is necessary to include the identity of the
    node to which the load report applies as part of the load report.
    This allows for a Diameter node to verify that the load report
    applies to its peer or if it should be ignored.

       Editor's note: The source-id is really only needed in peer load
       reports.  The identity of the sender of an end-point report can be
       determined using the Origin-Host AVP in the answer message.  As
       such, the source-id could be made optional for end-point load
       reports.

Campbell, et al.         Expires January 2, 2016                [Page 6]

Internet-Draft              Abbreviated Title                  July 2015

    The load report includes the relative load of the sending node.  This
    relative load is specified in a manner consistent with that defined
    for DNS SRV [RFC2782].

    The method for calculating the load value included in the load report
    is left as an implementation decision.

    The frequency for sending of load reports is also left as an
    implementation decision.  The sending node might choose to send load
    reports in all messages or it might choose to only send load reports
    when the load value has changed by some implementation specific
    value.  The important consideration is that all nodes needing the
    load information have a sufficiently accurate view of the nodes load.

5.1.  Theory of Operation

    This section outlines how the Diameter load mechanism is expected to
    work.

    For this discussion, assume the following Diameter network
    configuration:

            ---A1---A3----S[1], S[2]...S[p]
           /   | \ /
          C    |  x
           \   | / \
            ---A2---A4----S[p+1], S[p+2] ...S[n]

                     Figure 1: Example Diameter Network

    Also assume that the request for a Diameter transaction takes the
    following path:

          C     A1     A4     S[n]
          |      |      |      |
          |----->|----->|----->|
          xxR     xxR    xxR

                       Figure 2: Request Message Path

    When sending the answer message, an end-point node that supports the
    Diameter Load mechanism includes it's own load information in the
    answer message.  Because it is a Diameter end-point it includes an
    end-point load report.

Campbell, et al.         Expires January 2, 2016                [Page 7]

Internet-Draft              Abbreviated Title                  July 2015

          C     A1     A4     S[n]
          |      |      |      |
          |      |      |<-----|
          |      |       xxA(Load type:ep, source:S[n])
          |      |      |      |

                     Figure 3: Answer Message from S[n]

    If Agent A4 supports the Load mechanism then it will verify that the
    load information received was from its peer.  This is achieved by
    matching the identity included in the load information with the
    identity of the peer node from which the answer message was received.

       Note: If A4 does not support the load mechanism then it will relay
       the answer message without doing any processing on the load
       information.  In this case the load AVPs will be relayed without
       change.

    If the identity included in the load information AVPs matches the
    identity of the peer from which the load information is received then
    Agent A4 stores the load information for S[n] in its routing tables.

    Because the load report is an end-point load report, A4 leaves the
    load report in the message it relays.

    A4 then calculates its own load information and inserts load
    information AVPs in the message before sending the message to A1:

          C     A1     A4     S[n]
          |      |      |      |
          |      |<-----|      |
          |       xxA(Load type:peer, source:A4)
          |       xxA(Load type:ep, source:S[n])
          |      |      |      |

                      Figure 4: Answer Message from A4

    If A1 supports the Load mechanism then it processes each of the Load
    reports it receives separately.

    For the peer load report, A1 first determines if the source of the
    report indicated in the load report matches the DiameterID of the
    Diameter node from which the request was received.  If the identities
    do not match then the peer load report is discarded.  If the
    identities match then A1 saves the load information in its routing

Campbell, et al.         Expires January 2, 2016                [Page 8]

Internet-Draft              Abbreviated Title                  July 2015

    tables for routing of subsequent request messages.  In both cases A1
    strips the peer load report from the message.

    For the end-point load report, A1's actions depend on whether A1 is
    responsible for doing server selection.  If not then A1 ignores the
    end-poind load report.  If A1 is responsible for doing server
    selection then it stores the load information for S[n] in its routing
    tables for the handling of subsequent request messages.  In both
    cases A1 leaves the end-point report in the message.

    A1 then calculates its own load information and inserts load
    information AVPs in the message before sending the message to A1:

          C     A1     A4     S[n]
          |      |      |      |
          |<-----|      |      |
           xxA(Load type:peer, source:A1)
           xxA(Load type:ep, source:S[n])

                      Figure 5: Answer Message from A1

    As with A1, C processes each load report separately.

    For the peer load report, C follows the same procedure for
    determining if the Load report was received from the peer from which
    the report was sent and, when finding it does, stores the load
    information for use when making future routing decisions.

    For the end-point load report, C saves the load information only if
    it is responsible for doing server selection.

    The Load information received by all nodes is then used for routing
    of subsequent request messages.