Re: [Dime] DOIC Overview of Operation

[Jouni Korhonen <[e-mail]>]

Thanks for the text (and additions to it). Looks about good to me.
One clarification inline:


On Mar 21, 2014, at 4:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> wrote:

> Steve,
>  
> please find some minor comments inline.
>  
> Ulrich
>  
> From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
> Sent: Friday, March 21, 2014 2:25 PM
> To: [e-mail]
> Subject: Re: [Dime] DOIC Overview of Operation
>  
> I propose that we close issue 41 with Ben's text into section 3.0.  I also propose that we open a new issue to capture the need to make the rest of section 3 consistent.
> 
> I will do so unless I hear an alternative suggestion soon.
> 
> Regards,
> 
> Steve
> 
> On 3/17/14 1:34 PM, Ben Campbell wrote:
> Hi,
>  
> the dime-ovli currently lacks any sort of high-level overview of operation. As written, it jumps into details without giving the reader a high-level view of how it works. I think that will create confusion for new readers that have not been involved in discussions so far.
>  
> I propose adding the following text to the beginning of section 3. This would be entirely non-normative. I recognize that this would create some redundancies with later subsections. I don't address those here, but we would need to do so when integrating this text if we agree to add it.
>  
> Thanks!
>  
> Ben.
>  
> --------------------------
>  
>    The Diameter Overload Information Conveyance (DOIC) mechanism allows
>    Diameter nodes to request other nodes to perform overload abatement
>    actions, that is, actions to reduce the load offered to the
>    overloaded node.
>  
>    A Diameter node that supports DOIC is known as a "DOIC endpoint".
>    Any Diameter node can act as a DOIC endpoint, including clients,
>    servers, and agents.  DOIC endpoints are further divided into
>    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
>    overload abatement by sending an Overload Report (OLR) to one or more
>    reacting nodes.
>  
>    A reacting node consumes OLRs, and performs whatever actions are
>    needed to fulfill the requests.  A Reporting node may report overload
>    on its own behalf, or on behalf of other (typically upstream) nodes.
>    Likewise, a reacting node may perform overload abatement on its own
>    behalf, or on behalf of other (typically downstream) nodes.
>  
>    A node's role as a DOIC endpoint is independent of its Diameter role.
>    For example, Diameter relay and proxy agents may act as DOIC
>    endpoints, even though they are not endpoints in the Diameter sense.
>    Since Diameter enables bi-directional applications, where Diameter
>    servers can send requests towards Diameter clients, a given Diameter
>    node can simultaneously act as a reporting node and reacting node.
>  
>    Likewise, an relay or proxy agent may act as a reacting node from the
>    perspective of upstream nodes, and a reporting node from the
>    perspective of downstream nodes.
>  
>    DOIC endpoints do not generate new messages to carry DOIC related
>    information.  Rather, they "piggyback" DOIC information over existing
>    Diameter messages by inserting new AVPs into existing Diameter
>    requests and responses.

JiK: This applies to existing applications or new application where
DOIC is just a feature on top of one. Nothing prevents us defining a
DOIC-only application using this spec as the base. This should be
reflected?

> Nodes indicate support for DOIC, and any
>    needed DOIC parameters by inserting an OC_Supported_Features AVP
>    (Section 4.1) into existing requests and responses.  Reporting nodes
>    send OLRs by inserting OC-OLR AVPs[Wiehe, Ulrich (NSN - DE/Munich)]  into existing responses.  (Section 4.3)
>  
>    A given OLR applies to the Diameter [Wiehe, Ulrich (NSN - DE/Munich)] orig-realm and application of the
>    Diameter [Wiehe, Ulrich (NSN - DE/Munich)] response message that carries it.  If a reporting node supports more
>    than one realm and/or application, it reports independently for each
>    combination of realm and application.  Similarly, OC-Feature-Vector
>    AVPs apply to the realm and application of the enclosing message.
>    This implies that a node may support DOIC for one application and/or
>    realm, but not another, and may indicate different DOIC parameters
>    for each application and realm for which it supports DOIC.
>  
>    Reacting nodes perform overload abatement according to an agreed-upon
>    abatement algorithm.  An abatement algorithm defines the meaning of
>    the parameters of an OLR, and the procedures required for overload
>    abatement.  This document specifies a single must-support algorithm,
>    namely the "loss" algorithm [ref?].  Future specifications may
>    introduce new algorithms.
>  
>    Overload conditions may vary in scope.  For example, a single
>    Diameter node may be overloaded, in which case reacting nodes may
>    reasonably attempt to send throttled requests to other destinations
>    or via other agents
> [Wiehe, Ulrich (NSN - DE/Munich)] sending requests to the same destination via other agents does not help and should actually be avoided
> .  On the other hand, an entire Diameter realm may
>    be overloaded, in which case such attempts would do harm.  DOIC OLRs
>    have a concept of "report type" (Section 4.6), where the type defines
>    such behaviors.  Report types are extensible.  This document defines
>    report types for overload of a specific server, and for overload of
>    an entire realm.
>  
>    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
>    that are "adjacent" for DOIC purposes may not be adjacent from a
>    Diameter, or transport, perspective.  For example, one or more
>    Diameter agents that do not support DOIC may exist between a given
>    pair of reporting and reacting nodes, as long as those agents pass
>    unknown AVPs through unmolested.  The report types described in this
>    document can safely pass through non-supporting agents.  This may not
>    be true for report types defined in future specifications.  Documents
>    that introduce new report types MUST describe any limitations on
>    their use across non-supporting agents.
>  
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>  
>  
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime