Re: [Dime] issue #56 proposed conclusion

Hi Ulrich Steve

>From the Ulrich use case about deletion of OCS, which is for me valid,  I understand that the reporting node has to ensure that all its clients received its updated  OLR with validity time 0,  so with the hope this does not create  an "OCS status" per client. Steve statement applies when there is a per client handling of  the OLR in the reporting node (this is another discussion point). The fact to globally handle the clients has also some consequences even if there is an interest for it.

Best regards.

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mardi 25 mars 2014 10:08
À : ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] issue #56 proposed conclusion

Steve,

please see inline.

Ulrich
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 8:05 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] issue #56 proposed conclusion

Ulrich,

I have a few comments inline (towards the end of your proposal).

Steve
On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Dear all,

I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

Ulrich

-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich)

Sent: Thursday, March 20, 2014 2:08 PM

To: dime@ietf.org<mailto:dime@ietf.org>

Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State

Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:

    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    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)

    5.5.1.2   Overload Control States for reporting nodes

    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)

    5.5.1.3  Maintaining Overload Control States

    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 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 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.
SRD> I would think the reporting node would create the OCS when it determines it needs a reduction, independent when it receives requests from various reacting nodes.
<Ulrich> when not receiving requests, there is no need for reduction; the need of reduction is determined when a request is received.
Furthermore: If the reporting node determines that it needs a reduction independently from a received request, which Algorithm would it select? </Ulrich>

    Reporting nodes delete an OCS when it expires.
SRD> Or when it explicitly sends an OLR with validity duration of zero.
<Ulrich> no. Let me give an example:
Server S has an OCS identified by the pair (Application x, Loss) with the content: Sequence number =5, duration= 30 sec/expiry time= 9:45:59, percentage =10%.
At 9:45:30 Client C1 sends an application x request to S and gets back an OLR indicating 10% for 30 sec.
At 9.45:57 Client C2 send an application x request to S and gets back an OLR indicating 10% for 30sec.
At 9:45:58 S decides that it is no longer overloaded. It therefore updates the OCS to contain: sequence number=6, duration = 0sec/expiry time= 9:46:30, percentage =0%.
At 9:45:59 C1 sends an application x request to S and gets back the explicit OLR with validity duration of zero. S must not delet the OCS at this time.
At 9:46:01 C2 sends an application x request to S and (because the OCS was not deleted in the previous step) gets back the explicit OLR with validity duration of zero. If the OCS was deleted in the previous step C2 would continue throttling until 9:46:27.</Ulrich>

    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.

Ulrich

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime