Re: [Dime] Issue#31 status

Ulrich,

Please see inline.

Steve

On 3/25/14 5:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> I think we can easily extend the proposed text for #56 to cover these
> points:
>
>  
>
>  
>
>     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)
>
>     Overload Control States for reporting nodes containing a validity
> duration of 0 sec. should
>
>     not expire before any previously sent (stale) OLR has timed out at
> any reacting node.
>
SRD> I would actually model this differently.  I would have the
following overload state in the reporting node:

- Overload condition status - active or clear (clear meaning that a
previous overload condition has ended)
- Sequence number
- Validity duration to be sent in reports
- Expiration times (time that the state can be removed after the
overload condition clears)
- Application specific data

Then the logic is to send an OLR anytime there is an active overload
condition.  If the status is active then the validity duration is set to
the value in the state object.  If the status is clear then the validity
duration sent is zero.

That said, I'm ok with using your wording in the -02 draft and we can
change it in -03 if needed.
>
>    
>
>     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.
>
>  
>
>     Reacting nodes do not delete an OCS when receiving an answer
> message that does not
>
>     contain an OC-OLR AVP (i.e. absence of OLR means "no change").
>
SRD> Agreed
>
>  
>
>     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.
>
>  
>
>     Reporting nodes delete an OCS when it expires.
>
>  
>
>     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.
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, March 24, 2014 10:06 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#31 status
>
>  
>
> All,
>
> Can someone boil down the various proposed wording for this issue into
> what we want to have in the -02 draft.
>
> Thanks,
>
> Steve
>
> On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     #31: Sending OC-Ongoing-Throttling-Info AVP in request messages
>     that survived a throttling
>
>      
>
>     Dear all,
>
>      
>
>     I did not receive much support for the proposal to define an
>     OC-Ongoing-Throttling-Info AVP in request messages that survived a
>     throttlting.
>
>      
>
>     However, we seem to agree on some principles:
>
>      
>
>     Missing OLR in answer means "no change"; it does not mean "no
>     overload/no throttling requested"
>
>      
>
>     Reporting nodes SHOULD include OLR in every answer that it sends
>     in response to a request message which indicated OLR_DEFAULT_ALGO
>     support unless the reporting node has very good reasons not to do
>     so. Exact wording is not yet agreed.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org <mailto:DiME@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>