Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given client 

Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 

So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.

Best regards 

JJacques   

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : lundi 24 mars 2014 19:08
À : dime@ietf.org
Objet : Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm.... 

I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques  

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

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

    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.

Ulrich

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime