Re: [Dime] OVLI: OC-Validity-Duration

On Dec 16, 2013, at 3:34 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:

> Ben,
> 
> But does a reporting node need to send a Validity-Duration AVP in each message if this is just going to be used for clean-up purposes? Even more if we think it could be a pre-configured default value?

I think it is a pre-configured value at the reporting node. But it still needs to be communicated to the receiving node. (You really _don't_ want to have to configure it for both, and keep the configuration in sync between them.)

This is exactly like how the Expires header works for SIP.

> 
> /MCruz
> 
> 
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com] 
> Sent: lunes, 16 de diciembre de 2013 22:00
> To: Maria Cruz Bartolome
> Cc: Jouni Korhonen; dime@ietf.org
> Subject: Re: [Dime] OVLI: OC-Validity-Duration
> 
> 
> On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:
> 
>> Jouni,
>> 
>> I think the best way to manage "something unpredictable" is not to provide an estimation (on an unpredictable event) from the server.
>> If you really think that scheduled cleanups are helpful, this could always be considered in the client, with a default value, that does not need to be sent from the reporting node.
> 
> The point is not for the reporting node to predict how long it's likely to be overloaded, it's to make sure things get cleaned up if some _other_ unpredictable event occurs. The idea is to set a time out so that, if the reacting node doesn't see an update in some period of time, it can discard the state. Otherwise, it could assume the overload condition to last forever. It's up to the implementation, but typically you choose your validity times to balance how long you are willing to let an expired report "hang" vs how many "update" messages you are willing to tolerate. I think it will be typical that servers choose a fixed timeout value (possibly configured) for all reports.
> 
> Soft state like this is a well known protocol design pattern used in many IETF protocols. The idea is that, if some failure occurs so that the recipient fails to get an update, the problem eventually expires, and heals itself.
> 
>> 
>> Regards
>> /MCrzu
>> 
>> -----Original Message-----
>> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>> Sent: jueves, 12 de diciembre de 2013 9:39
>> To: Maria Cruz Bartolome
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>> 
>> Hi,
>> 
>> I kind of like scheduled cleanups.. just to make sure there is no
>> stuff left hanging around when something unpredictable happens in
>> the network system.
>> 
>> Again, I would say this is a wrong place to "optimize".
>> 
>> 
>> - Jouni
>> 
>> On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:
>> 
>>> Dear all,
>>> 
>>> I would like to reconsider the real need for the OC-Validity-Duration AVP to be included into overload report.
>>> Overload mechanism is being design with a principle in mind: as soon as reporting node determines a reacting node overload behavior should change, reporting node sends a fresh overload report to this reacting node.
>>> Therefore, latest overload report received will be always applicable until a new report is received, and then I do not see the value, but just complexity, of including a Duration in the report.
>>> 
>>> Let me know your views.
>>> Best regards
>>> /MCruz
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime