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

+1

On Mar 26, 2014, at 3:57 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

> 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 <srdonovan@usdonovans.com> 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
>>>> <maria.cruz.bartolome@ericsson.com>
>>>>  wrote:
>>>> 
>>>> 
>>>>> Ben, Nirav,
>>>>> 
>>>>> I follow same argumentation.
>>>>> Regards
>>>>> /MCruz
>>>>> 
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Nirav Salot (nsalot)
>>>>> Sent: martes, 11 de febrero de 2014 11:23
>>>>> To: Ben Campbell; Jouni Korhonen
>>>>> Cc:
>>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>> 
>>>>> 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:dime-bounces@ietf.org
>>>>> ] On Behalf Of Ben Campbell
>>>>> Sent: Monday, February 10, 2014 9:54 PM
>>>>> To: Jouni Korhonen
>>>>> Cc:
>>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>> 
>>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>>>> 
>>>>> 
>>>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen
>>>>> <jouni.nospam@gmail.com>
>>>>>  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
>>>>> 
>>>>> 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
>>>> _______________________________________________
>>>> 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