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

[Maria Cruz Bartolome <[e-mail]>]

Ulrich,

In your proposal you newly define overload control states per client/origin-host.
This is very related to the ongoing discussion in Issue#35. Then, at least I think we need to first conclude on that thread.

A part from that,  we need to take into account that 3GPP requirement on overload mitigation differentiation per client is a server option:
TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementations to decide when and whether overload mitigation differentiation per client is used".

Therefore, it could be better to keep this differentiation per client/origin-host out of chapter 5.5.1.

Best regards
/MCruz



-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:44
To: [e-mail]; [e-mail]
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

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
    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.

    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.

    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.

    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