Subject: Re: [Dime] issue #56 proposed conclusion

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Mar 2014 17:23:30 +0000

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: [email-masked]
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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Mar 2014 18:07:44 +0000

Hi Ulrich

In 5.5.1.2 you wrote:
    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:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : lundi 24 mars 2014 18:24
À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Objet : Re: [Dime] issue #56 proposed conclusion

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Mar 2014 18:43:23 +0000

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:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : lundi 24 mars 2014 19:08
À : [email-masked]
Objet : Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

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

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 14:04:38 -0500

Ulrich,

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

Steve

>     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. 
>     Reporting nodes delete an OCS when it expires.
SRD> Or when it explicitly sends an OLR with validity duration of zero.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 14:06:44 -0500

Ulrich,

Acronym overlap is unavoidable.  If we add OCS in the abbreviations
section then we should be ok.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Mar 2014 08:07:39 +0000

Hi JJacques,

let me try to give an example:

Client C1 supports algorithms A1 and A2.
Server S supports algorithms A1 and A2.
Client C2 supports only algorithm A1.

C1 sends an application x request indicating support of A1 and A2 to the server S.
Now S selects one single algorithm (in this example A2) and requests some reduction using A2.  S has a OCS identified by the pair (x,A2).

Now client C2 sends an application x request indicating support of A1 to S. 
Again S selects one single algorithm (in this case A1) and requests some reduction using A1. S has an OCS identified by the pair (x,A1).

In summary it is right that S selects one single algorithm out of the set of adveritzed algorithms, but this does not mean that S must only maintain one OCS.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:08 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

-----Message d'origine-----

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Mar 2014 08:24:07 +0000

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
With this (partial) solution of #35 there would not be any impact to my proposal for #56.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Best regards 

JJacques   

-----Message d'origine-----

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

-----Message d'origine-----

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

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

Steve,

please see inline.

Ulrich
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 8:05 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Ulrich,

Steve

Dear all,

Ulrich

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

To: [email-masked]<mailto:[email-masked]>

Dear all,

    following information:

      and time of reception)

    Control State.

    - Sequence number

    stored sequence number.

    stored sequence number.

    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>

Ulrich

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

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

Also fine with me.
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 8:07 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Ulrich,

Acronym overlap is unavoidable.  If we add OCS in the abbreviations section then we should be ok.

Steve

Dear all,

Ulrich

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

Dear all,

    following information:

      and time of reception)

    Control State.

    - Sequence number

    stored sequence number.

    stored sequence number.

Ulrich

DiME mailing list

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 25 Mar 2014 09:24:38 +0000

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:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mardi 25 mars 2014 10:08
À : ext Steve Donovan; [email-masked]
Objet : Re: [Dime] issue #56 proposed conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Dear all,

Ulrich

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

Dear all,

    following information:

      and time of reception)

    Control State.

    - Sequence number

    stored sequence number.

    stored sequence number.

Ulrich

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 07:20:47 -0500

Ulrich,

Please see inline.

Steve

> <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>
>
SRD2> You are correct that the algorithm can't be selected until the 
request arrives.  My point was that there would be state indicating the 
reporting node is overloaded already in place.
> 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: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>
>
SRD> This is a good description of the need to keep the state in the 
server until it times out.  Thanks.
> [email-masked]  <mailto:[email-masked]>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 16:10:20 -0500

JJ,

Ulrich straightened me out on the need to keep the state around until it
expires.  As such, I don't believe there is the need for per reacting
node support in the reporting node.

Regards,

Steve

On 3/25/14 4:24 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> 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:[email-masked]] *De la part de* Wiehe,
> Ulrich (NSN - DE/Munich)
> *Envoyé :* mardi 25 mars 2014 10:08
> *À :* ext Steve Donovan; [email-masked]
> *Objet :* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> Steve,
>
>  
>
> please see inline.
>
>  
>
> Ulrich
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, March 24, 2014 8:05 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> Ulrich,
>
>     To: [email-masked] <mailto:[email-masked]>
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 16:11:31 -0500

All,

I plan to incorporate Ulrich's text in the -02 draft.

Ulrich, can you please copy the proposed text into the issue and close
the ticket.

Thanks,

Steve

On 3/25/14 4:08 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> *Sent:* Monday, March 24, 2014 8:07 PM
> *To:* [email-masked]

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 07:56:06 +0000

Hi Ulrich

I agree with your example: so with an OCS that can be defined per application and algorithm.
Nevertheless a remark, I think this OCS exists only when the algorithm has been selected. I do not see the case of an OCS with a supported but not selected algorithm. I may miss something.

So wording in 5.5.1.2 could be:
	A reporting node maintains per supported Diameter application and per
    selected Abatement Algorithm an Overload
    Control State....
 
This does  not remove my questioning about the per client case: pease see the other mail

Best regards

JJacques

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : mardi 25 mars 2014 09:08
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : RE: issue #56 proposed conclusion

Hi JJacques,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:08 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

-----Message d'origine-----

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 07:58:54 +0000

Hi Ulrich

1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.

So I propose  to evolve your definition
   
A reporting node maintains per supported Diameter application, per
    selected Abatement Algorithm and eventually per client if relevant an Overload
    Control State

Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.

2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    

Best regards 

JJacques 

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : mardi 25 mars 2014 09:24
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : RE: issue #56 proposed conclusion

Hi JJacques

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Best regards 

JJacques   

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

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

-----Message d'origine-----

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Mar 2014 08:26:04 +0000

Hi JJacques,

In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.
This does not mean that we cannot improve text for 03.

Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.
This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.

Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, March 26, 2014 8:59 AM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

   

Best regards 

JJacques 

-----Message d'origine-----

Hi JJacques

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Best regards 

JJacques   

-----Message d'origine-----

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

-----Message d'origine-----

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 08:51:27 +0000

Hi Ulrich

1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?

2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 
Reduction percentage for the realm.

Best regards

JJacques   

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : mercredi 26 mars 2014 09:26
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Objet : RE: issue #56 proposed conclusion

Hi JJacques,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, March 26, 2014 8:59 AM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

   

Best regards 

JJacques 

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked] Objet : RE: issue #56 proposed conclusion

Hi JJacques

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: [email-masked]
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Best regards 

JJacques   

-----Message d'origine-----

Hi Ulrich

In 5.5.1.2 you wrote:

Best regards

JJacques  

-----Message d'origine-----

Dear all,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: [email-masked]
Subject: issue #56 proposed conclusion

Dear all,

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 07:23:02 -0500

JJ,

This text is not normative so a reporting node can create the OCS
anytime it wishes.  It is very much an implementation decision.

The value of this text is that it helps to explain the DOIC mechanism. 

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 07:25:47 -0500

JJ,

Please see inline.

Steve

>     selected Abatement Algorithm and eventually per client if relevant an Overload
SRD> I agree with the per algorithm, but I don't think we need the word
selected.  I also don't think we need the  "... and eventually" part. 
That can be added if and when we have that extension mechanism defined.
> 2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for req…
SRD> I thought OCS per report type was already there.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 07:27:32 -0500

JJ,

I am not in favor of your suggestion.  I won't restate -- its in my
previous email.

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 12:37:41 +0000

Hi Steve

When reading your draft  about Rate control, we have
        The server must allocate a portion of the
   target Diameter request rate to each of its reacting nodes.  The
   server may set the same rate for every reacting node, or may set
   different rates for different reacting node.
I am OK with this statement. For me it implies  the reporting node (server)  to have a n OCS per reacting node if the rates are different .
So  I am a bit surprised you do not take this example  into account in the draft that should be future proof in its wording even if the OCS is not normative, but has a general meaning applicable to various algorithm and not only to the loss algorithm.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 26 mars 2014 13:28
À : [email-masked]
Objet : Re: [Dime] issue #56 proposed conclusion

JJ,

I am not in favor of your suggestion.  I won't restate -- its in my previous email.

Steve

Hi Ulrich

Best regards

JJacques

-----Message d'origine-----

À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]<mailto:[email-masked]>

Hi JJacques,

Best regards

Ulrich

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

Hi Ulrich

    Control State

Best regards

JJacques

-----Message d'origine-----

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]<mailto:[email-masked]> Objet : RE: issue #56 proposed conclusion

Hi JJacques

Best regards

Ulrich

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

Hi Ulrich and all

Best regards

JJacques

-----Message d'origine-----

De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : [email-masked]<mailto:[email-masked]> Objet : Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:

    Control State

Best regards

JJacques

-----Message d'origine-----

De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]> Objet : Re: [Dime] issue #56 proposed conclusion

Dear all,

Ulrich

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

Dear all,

    following information:

      and time of reception)

    Control State.

    - Sequence number

    stored sequence number.

    stored sequence number.

Ulrich

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 07:50:17 -0500

JJ,

There is nothing in the draft that prevents extending the amount of
state saved by a reporting node.

We do probably need to add more on extensibility into the draft and one
of the suggestions for any extension should be to expand on the
discussion of how OCS is impacted by the extension.

Regards,

Steve

On 3/26/14 7:37 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> I am OK with this statement. For me it implies  the reporting node
> (server)  to have a n OCS per reacting node if the rates are different .
>
> So  I am a bit surprised you do not take this example  into account in
> the draft that should be future proof in its wording even if the OCS
> is not normative, but has a general meaning applicable to various
> algorithm and not only to the loss algorithm.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>    
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* mercredi 26 mars 2014 13:28
> *À :* [email-masked]
>     À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked] <mailto:[email-masked]>
>
>     De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked] <mailto:[email-masked]> Objet : RE: issue #56 proposed conclusion
>
>      
>
>     Hi JJacques
>
>      
>
>     De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : [email-masked] <mailto:[email-masked]> Objet : Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     Hi Ulrich
>
>      
>
>     In 5.5.1.2 you wrote:
>
>     De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked] <mailto:[email-masked]> Objet : Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     Dear all,
>
>      
>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 13:07:40 +0000

Steve

A sentence about extensibility of the OSC is for me necessary, not only on  the information it can store but also on the access keys (eg per reacting nodes), otherwise the OCS as currently described for which it should have a large appliance perimeter has already two exceptions, the specific client % reduction percentage  with the loss algorithm and your control rate case.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 26 mars 2014 13:50
À : [email-masked]
Objet : Re: [Dime] issue #56 proposed conclusion

JJ,

There is nothing in the draft that prevents extending the amount of state saved by a reporting node.

We do probably need to add more on extensibility into the draft and one of the suggestions for any extension should be to expand on the discussion of how OCS is impacted by the extension.

Regards,

Steve

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 26 mars 2014 13:28
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] issue #56 proposed conclusion

JJ,

Steve

Hi Ulrich

Best regards

JJacques

-----Message d'origine-----

Hi JJacques,

Best regards

Ulrich

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

Hi Ulrich

    Control State

Best regards

JJacques

-----Message d'origine-----

Hi JJacques

Best regards

Ulrich

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

Hi Ulrich and all

Best regards

JJacques

-----Message d'origine-----

Hi Ulrich

In 5.5.1.2 you wrote:

    Control State

Best regards

JJacques

-----Message d'origine-----

Dear all,

Ulrich

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

Dear all,

    following information:

      and time of reception)

    Control State.

    - Sequence number

    stored sequence number.

    stored sequence number.

Ulrich

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 08:33:24 -0500

JJ,

I agree, we need wording around extensibility.

My concern, however, was that adding wording around client specific
reports might mean we should also put wording around peer reports that
would be used for agent overload.

Is it ok to defer the extensibility wording to be addressed in -03 and
go with Ulrich's suggestion?  I have a good deal of work to do to get
the -02 draft published prior to next weeks CT4 meeting and this would
let me focus there.

Regards,

Steve

On 3/26/14 8:07 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Steve
>
>  
>
> A sentence about extensibility of the OSC is for me necessary, not
> only on  the information it can store but also on the access keys (eg
> per reacting nodes), otherwise the OCS as currently described for
> which it should have a large appliance perimeter has already two
> exceptions, the specific client % reduction percentage  with the loss
> algorithm and your control rate case.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *Envoyé :* mercredi 26 mars 2014 13:50
> *À :* [email-masked]
> We do probably need to add more on extensibility into the draft and
> one of the suggestions for any extension should be to expand on the
>     So  I am a bit surprised you do not take this example  into
>     account in the draft that should be future proof in its wording
>     even if the OCS is not normative, but has a general meaning
>     applicable to various algorithm and not only to the loss algorithm.
>
>      
>
>     Best regards
>
>      
>
>     JJacques
>
>        
>
>      
>
>     *À :* [email-masked] <mailto:[email-masked]>