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

[Jouni Korhonen <[e-mail]>]

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)" <[e-mail]> 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:[e-mail]] 
> Sent: Tuesday, February 18, 2014 1:35 PM
> To: [e-mail]; Wiehe, Ulrich (NSN - DE/Munich)
> Cc: [e-mail]
> 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-
>  [e-mail]   |  [e-mail]
>     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime