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

Why, sorry but please repeat or I go with I believe consensus

Thanks

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360
md3135@att.com

> On Mar 25, 2014, at 7:17 PM, "Ben Campbell" <ben@nostrum.com> 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