Subject: [Dime] DOIC Overview of Operation

From: Ben Campbell <[email-masked]>
Date: Mon, 17 Mar 2014 13:34:13 -0500

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.  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.  (Section 4.3)

   A given OLR applies to the Diameter realm and application of the
   Diameter 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.  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.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 21 Mar 2014 08:24:41 -0500

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:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Mar 2014 14:33:52 +0000

Steve,

please find some minor comments inline.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 2:25 PM
To: [email-masked]
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.

Regards,

Steve

Hi,

Thanks!

Ben.

   overloaded node.

   reacting 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

   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

   an entire realm.

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 24 Mar 2014 14:49:35 +0200

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)" <[email-masked]> wrote:

>    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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 08:19:44 -0500

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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Mar 2014 16:16:29 +0000

Hello,

One more comment below for clarification.
It is fine to continue with then on .02 though.
Cheers

   overloaded node.

   reacting nodes.

   an entire realm.

   Diameter, or transport, perspective.

[MCruz] Using the term "adjacent" is kind of misleading, even if you later explained precisely that.

Above paragraph could be replaced by "Reacting and reporting nodes are not necessarily adjacent nodes"

For example, one or more