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

From: "dime issue tracker" <[email-masked]>
Date: Tue, 18 Feb 2014 12:35:12 -0000

#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-
  [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/>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Feb 2014 11:44:11 +0000

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

    <see attachment>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 16:22:53 +0000

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:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:44
To: [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

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

 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.

    which it sends host-type requests and a realm-type Overload Control  State
    Application-Id and Destination-Host; a realm-type Overload Control  State

    <see attachment>

    application an Overload Control State for each Origin-Host from which  it

    A Overload Control State may be identified by the pair of Application-  Id
    and Origin-Host.

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

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

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 10:45:29 -0600

Ulrich,

See inline.

Steve

>     A reacting node (client) maintains per supported Diameter application
SRD> Why qualify with client.  It applies to all reacting nodes.
>     which it sends host-type requests and a realm-type Overload Control
SRD> ...and... (add the word and here)
>     information as shown in table 1/table 2.
SRD> Reception time and validity duration could be replaced with
"expiration time"
>     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.
>     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.
>     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 Overload Control State may be identified by the pair of Application-
SRD> I don't see this as a must.  It could be identified by just
Application-ID.
>     Host could include the information as shown in table 3.
SRD> Expiration time should be sufficient.
>     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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 09:03:44 +0000

Hi MCruz,

thank you for your comments.

I agree that there are dependencies withh issue#35.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 5:23 PM
To: [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

Ulrich,

Best regards
/MCruz

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

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

    <see attachment>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 09:00:40 +0000

Steve,

Please see inline.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 5:45 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

Ulrich,

See inline.

Steve

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

SRD> Why qualify with client.  It applies to all reacting nodes.
<Ulrich> I agree to remove "(client)"</Ulrich>

    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)
<Ulrich> I do not agree </Ulrich>

    <see attachment>
SRD> Reception time and validity duration could be replaced with "expiration time"
<Ulrich> I agree </Ulrich>

    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.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>

    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.
<Ulrich> the agent case is described below (agent that is configured to take the role of a reporting node for a given realm) and there are differences </Ulrich> 

    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.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>

    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.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>

    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.
<Ulrich> no, you need to store the validity duration since this will be sent in OLRs</Ulrich>

    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?
<Ulrich> ok </Ulrich>

  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.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>

    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.
<Ulrich> there are dependencies with #31 and #35: once a single OLR with validity duration of zero is sent you should not delete the OCS as there may be other agents (issue #31) or even other clients (issue #35) that did not get the "end of overload indication"</Ulrich>