Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

From: Jouni Korhonen <[email-masked]>
Date: Sun, 2 Mar 2014 12:29:47 +0000

Ulrich,

A couple of observations. In general OK to do rewording this part
but more work is needed with the actual text. See some comments
inline:

On Feb 24, 2014, at 11:44 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

> There has been no discussion of this ticket.
> 
> I propose to replace text in claues 5.5.1 as suggested in the ticket.
> 
> Regards
> Ulrich
> 
> 
> -----Original Message-----
> From: ext dime issue tracker [mailto:[email-masked]] 
> Sent: Tuesday, February 18, 2014 1:35 PM
> To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: [dime] #56: Bad Description of Overload Control State
> 
> #56: Bad Description of Overload Control State
> 
> The description of Overload Control State in clause 5.5.1 is inaccurate,
> incomplete and could be misleading. It does not differentiate between
> Overload Control State in a reacting node versus Overload Control State in
> a reporting node. It also does not describe how Overload Control States
> are maintained.
> 
> It is proposed to replace current text with the following:
> 
> 
> 5.5.1.  Overload Control State (OCS)
> 
>    5.5.1.1   Overload Control States for reacting nodes
> 
>    A reacting node (client) maintains per supported Diameter application
>    a host-type Overload Control State for each Destination-Host towards
>    which it sends host-type requests and a realm-type Overload Control
> State
>    for each Destination-Realm toward which it sends realm-type requests.
>    A host-type Overload Control State may be identified by the pair of
>    Application-Id and Destination-Host; a realm-type Overload Control
> State

Do I understand correctly that you basically propose having a separate
state "object" for each OC-Report-Type? 

>    may be identified by the pair of Application-Id and Destination-Realm.
>    The host-type/realm-type Overload Control State for a given pair of
>    Application and Destination-Host / Destination-Realm could include the
>    information as shown in table 1/table 2.
> 
>    <see attachment>
> 
>    Agents that take the role of a reacting node on behalf of clients MUST
>    maintain Overload Control States per client.

Since we are not going to define the internal structure and implementation 
of the overload control state exactly I am a bit cautious going beyond listing
what goes into the state. Also, having MUSTs need to be weighted very carefully.

>    5.5.1.2   Overload Control States for reporting nodes
> 
>    A reporting node (server) maintains per supported Diameter application
>    an Overload Control State for each Origin-Host from which it receives
>    requests that contain an (explicit or implicit) indication of
>    OLR_DEFAULT_ALGO support.
> 
>    A reporting node (agent that is configured to take the role of a
>    reporting node for a given realm) maintains per supported Diameter
>    application an Overload Control State for each Origin-Host from which
> it
>    receives realm-type requests (of that given realm) that contain an
>    (explicit or implicit) indication of OLR_DEFAULT_ALGO support.
> 
>    A Overload Control State may be identified by the pair of Application-
> Id
>    and Origin-Host.
> 
>    The Overload Control State for a given pair of Application and Origin-
>    Host could include the information as shown in table 3.
>    <see attachment>
> 
>    Note: For nodes that support other features than just OLR_DEFAULT_ALGO
>    the Overload Control State definitions may need to be extended.

Or just state the overload control state need to be flexible enough to
support multiple abatement algorithms in the future?

>    5.5.1.3  Maintaining Overload Control States
> 
>    Reacting nodes create a host-type OCS with OCS-Id = (x,A) when
> receiving
>    an answer message of application x containing an Orig-Host of A and a
>    host-type OC-OLR AVP unless such host-type OCS already exists.
> 
>    Reacting nodes create a realm-type OCS with OCS-Id = (x,A) when
> receiving
>    an answer message of application x containing an Orig-Realm of A and a
>    realm-type OC-OLR AVP unless such realm type OCS already exists.
> 
>    Reacting nodes delete an OCS when it expires (i.e. when current time
>    minus reception time is greater than validity duration).
> 
>    Reacting nodes update the host-type OCS with OCS-Id = (x,A) when
>    receiving an answer message of application x containing an Orig-Host of
>    A and a host-type OC-OLR AVP with a sequence number higher than the
>    stored sequence number.

And what about the abatement algorithm?  Don't we have a dependency here
to Issue #30? I.e. the reacting node would need to take the algorithm
also into account?

- JOuni

> 
>    Reacting nodes update the realm-type OCS with OCS-Id = (x,A) when
>    receiving an answer message of application x containing an Orig-Realm
> of
>    A and a realm-type OC-OLR AVP with a sequence number higher than the
>    stored sequence number.
> 
>    Reporting nodes create an OCS with OCS-Id = (x,A) when receiving a
>    request (indicating support of OLR_DEFAULT_ALGO) of application x
>    containing an Orig-Host of A unless such OCS already exists.
> 
>    Reporting nodes delete an OCS when it expires.
> 
>    Reporting nodes update the OCS with OCS-Id = (x,A) when they detect the
>    need to modify the requested amount of application x traffic reduction
>    generated by A.
> 
> -- 
> -------------------------+-------------------------------------------------
> Reporter:               |      Owner:  draft-docdt-dime-
>  [email-masked]   |  [email-masked]
>     Type:  defect       |     Status:  new
> Priority:  major        |  Milestone:
> Component:  draft-       |    Version:
>  docdt-dime-ovli        |   Keywords:
> Severity:  Active WG    |
>  Document               |
> -------------------------+-------------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/56>
> dime <http://tools.ietf.org/wg/dime/>
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "dime issue tracker" <[email-masked]>
Date: Wed, 26 Mar 2014 09:10:42 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 The following text has been agreed (with "OCS" added in the acronym
 section):

     A reacting node maintains per supported Diameter application
     - a host-type Overload Control State for each Destination-Host towards
       which it sends host-type requests and
     - a realm-type Overload Control State for each Destination-Realm
 towards
       which it sends realm-type requests.

     A host-type Overload Control State may be identified by the pair of
     Application-Id and Destination-Host.
     A realm-type Overload Control State may be identified by the pair of
     Application-Id and Destination-Realm.
     The host-type/realm-type Overload Control State for a given pair of
     Application and Destination-Host / Destination-Realm could include the
     following information:
     - Sequence number (as reveived in OC-OLR)
     - Time of expiry  (deviated from validity duration as received in OC-
 OLR
       and time of reception)
     - Selected Abatement Algorithm (as received in OC-Supported-Features)
     - Algorithm specific input data (as received within OC-OLR, e.g.
       Reduction Percentage for Loss)

     A reporting node maintains per supported Diameter application and per
     supported (and eventually selected) Abatement Algorithm an Overload
     Control State.

     An Overload Control State may be identified by the pair of
 Application-Id
     and supported Abatement Algorithm.

     The Overload Control State for a given pair of Application and
 Abatement
     Algorithm could include the information:
     - Sequence number
     - Validity Duration and Expiry Time
     - Algorithm specific input data (e.g. Reduction Percentage for Loss)

     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id
 ,host-id) when receiving
     an answer message of application app-id containing an Orig-Host of
 host-id and a
     host-type OC-OLR AVP unless such host-type OCS already exists.

     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id
 ,realm-id) when receiving
     an answer message of application app-id containing an Orig-Realm of
 realm-id and a
     realm-type OC-OLR AVP unless such realm type OCS already exists.

     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id
 ,host-id) when
     receiving an answer message of application app-id containing an Orig-
 Host of
     host-id and a host-type OC-OLR AVP with a sequence number higher than
 the
     stored sequence number.

     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-
 id,realm-id) when
     receiving an answer message of application app-id containing an Orig-
 Realm of
     realm-id and a realm-type OC-OLR AVP with a sequence number higher
 than the
     stored sequence number.

     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when
 receiving a
     request of application app-id containing an OC-Supported-Features AVP
     indicating support of the Abatement Algorithm Alg (which the reporting
     node selects) while being overloaded, unless such OCS already exists.

     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
 when they detect the
     need to modify the requested amount of application app-id traffic
 reduction.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  [email-masked]   |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/56#comment:1>
dime <http://tools.ietf.org/wg/dime/>