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

[Steve Donovan <[e-mail]>]

I'm ok with Ben's suggested wording.

Steve

On 3/25/14, 6:16 PM, Ben Campbell wrote:
> 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
>