Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire

[Ben Campbell <[e-mail]>]

I do not agree. While this fixes a related problem of using a zero validity-duration to signal the end of an overload condition, it still implies that one SHOULD NOT let a report "just expire". As I've argued before, I believe there are time when it is just as good, if not better, to let an overload condition expire naturally.

Here's a quote of my argument to that effect from further down the thread:

> I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. 
> 
> And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.

So, here's a different proposal for your first paragraph:

   "When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be achieved by sending an updated overload report (meaning the OLR contains a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so."


On Mar 24, 2014, at 3:38 PM, Steve Donovan <[e-mail]> wrote:

> Here's some proposed wording that will hopefully let us close this issue:
> 
> Regards,
> 
> Steve
> 
> -----
> 
> Section 4.5., paragraph 3 - 
> 
> Current -02 wording:
> 
> As a general guidance for implementations it is RECOMMENDED never to
>    let any overload report to timeout.  Following to this rule, an
>    overload endpoint should explicitly signal the end of overload
>    condition and not rely on the expiration of the validity time of the
>    overload report in the reacting node.  This is achieved by sending an
>    updated overload report (meaning it must contain a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
> 
> Proposed wording:
> 
>    A reporting node SHOULD explicitly signal the end of overload
>    condition in a timely manner.  This is achieved by sending an
>    updated overload report (meaning the OLR contains a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
> 
>   A reacting node MUST invalidate and remove an overload report that
>   expires without an explicit overload report containing an OC-Validity-Duration
>   value set to zero ("0").
> 
> 
> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>> Fine with me.
>> 
>> - Jouni
>> 
>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome 
>> <[e-mail]>
>>  wrote:
>> 
>> 
>>> Ben, Nirav,
>>> 
>>> I follow same argumentation.
>>> Regards
>>> /MCruz
>>> 
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:[e-mail]
>>> ] On Behalf Of Nirav Salot (nsalot)
>>> Sent: martes, 11 de febrero de 2014 11:23
>>> To: Ben Campbell; Jouni Korhonen
>>> Cc: 
>>> [e-mail] list; [e-mail]
>>> 
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>> 
>>> Ben,
>>> 
>>> I resonate with your thinking below.
>>> 
>>> Regards,
>>> Nirav.
>>> 
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:[e-mail]
>>> ] On Behalf Of Ben Campbell
>>> Sent: Monday, February 10, 2014 9:54 PM
>>> To: Jouni Korhonen
>>> Cc: 
>>> [e-mail] list; [e-mail]
>>> 
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>> 
>>> 
>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen 
>>> <[e-mail]>
>>>  wrote:
>>> 
>>> 
>>>> My reasoning for explicit termination was that knowing the 
>>>> implementation folks they will let overload conditions expire unless advised otherwise.
>>>> And having unnecessary stuff hanging around waiting for a cleanup is 
>>>> not a good thing in general. But I am open here for other options..
>>>> 
>>>> 
>>> I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. 
>>> 
>>> And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> 
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>> 
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> 
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>> 
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> 
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> 
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>> 
>> 
>> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime