Re: [Dime] DOIC Overview of Operation

[Steve Donovan <[e-mail]>]

Jouni,
Ulrich,

Given that this is a non normative section and that we can continue to
update the document after -02 is publiched, I'm updating the document
with Ben's text as is for now.  I propose we address your comments as
part of the -02 draft review. 

Regards,

Steve

On 3/24/14 7:49 AM, Jouni Korhonen wrote:
> 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
>