Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

In-inline

From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
Sent: Wednesday, February 05, 2014 3:30 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

inline
On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).
SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?
<Ulrich>lack of OLR implies lack of sequence number and lack or report type. How would the reacting node check whether this "implicit no overload indication" is in-sequence and whether the realm or the host is not overloaded? I would have thought that lack of OLR is interpreted as no change in the overload</Ulrich>


Other criteria like REQ18 or REQ13 do not seem to matter.
SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.
<Ulrich>the proposal was not "requiring" but "allowing" the reporting node (especially when not overloaded) to check OC-Ongoing-Throttling-Info AVPs. </Ulrich>



For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?
SRD> That is the purpose of the sequence number.  
<Ulrich> however, "checking the sequence number" actually means "processing the OLR"; "not processing the OLR" means "not even checking the sequence number"</Ulrich>




-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of ext Nirav Salot (nsalot)
Sent: Wednesday, February 05, 2014 5:27 AM
To: [e-mail]; [e-mail]
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

I share the same opinion as Lionel.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, February 04, 2014 9:07 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
So the options would be:
1- OC-OLR AVP in every answer
2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.

If there is no other criterion, the option 1 seems the best approach.

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:[e-mail]]
Envoyé : mardi 4 février 2014 09:49
À : MORAND Lionel IMT/OLN
Cc : [e-mail]
Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

 It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
 (TimeStamp) of the OLR according to which the throttling (which was
 survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
 Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
 The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
 The feedback mechanism also allows to address REQ 18 from RFC 7068.
 In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.