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

[Steve Donovan <[e-mail]>]

Ulrich,

See inline.

Steve

On 2/24/14 5:44 AM, Wiehe, Ulrich (NSN - DE/Munich) 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
SRD> Why qualify with client.  It applies to all reacting nodes.
>     a host-type Overload Control State for each Destination-Host towards
>     which it sends host-type requests and a realm-type Overload Control
>  State
SRD> ...and... (add the word and here)
>     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
>     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>
SRD> Reception time and validity duration could be replaced with
"expiration time"
>
>     Agents that take the role of a reacting node on behalf of clients MUST
>     maintain Overload Control States per client.
SRD> This depends on the resolution of the current discussion of issue
35.  I propose it be modified to "Agents that take the reacting node on
behalf of non-supporting clients must maintain either the global
overload state or per client overload state if requested by the
reporting node.
>
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node (server) maintains per supported Diameter application
SRD> There is no reason to qualify the reporting node as a server.  It
could also be an agent and all of this still applies.
>     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.
SRD> It doesn't need to be per Origin-Host, per the discussion of issue
35.  We should support a global overload state if the reporting node
doesn't which to keep per reacting node state.
>
>     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.
SRD> I don't see this as a must.  It could be identified by just
Application-ID.
>
>     The Overload Control State for a given pair of Application and Origin-
>     Host could include the information as shown in table 3.
>     <see attachment>
SRD> Expiration time should be sufficient.
>
>     Note: For nodes that support other features than just OLR_DEFAULT_ALGO
>     the Overload Control State definitions may need to be extended.
>
>     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.
>
>     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.
SRD> Why would the reporting node create an OCS when it is not
overloaded?  Shouldn't this be modified to say that the reporting nodes
creates an OCS when receiving a request and when in an overloaded state
for the application?  Also, we should not require that the reporting
node keep state for all reacting nodes, it should be able to keep a
single state for all reacting nodes.
>
>     Reporting nodes delete an OCS when it expires.
SRD> or when the reporting node exits the overload state.  This should
be after the reporting node sends an overload report with validity
duration of zero to reacting nodes.
>
>     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.
>