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

[Ben Campbell <[e-mail]>]

A reporting node has two ways of ending a reported overload condition. It can forcefully expire the report, by sending an updated report with a zero expiration time. Or it can let the report expire by not updating it.

This is analogous to how SIP handles registrations and subscriptions. You can remove one by sending a new REGISTER or SUBSCRIBE with expires=0.  Or if the registration or subscription is close to ending anyway, you can let it expire.

The "consensus" position says that you SHOULD do the first. That implies you SHOULD NOT do the second. My position is that we don't need that restriction; either choice is okay as long as it happens in a timely manner. In fact there may be times where sending an updated report does nothing but add unneeded messages.

I will go further to say that a normative preference for one or the other violates RFC 2119 guidance for normative language, in that the SHOULD is not necessary for interoperability, because both strategies work. And neither approach does damage, as long as it is timely.

Now, I agree that the reporting node SHOULD ensure that the overload report is invalidated in a timely manner. I just don't think we need to prefer one method of doing that over another.


On Mar 25, 2014, at 6:51 PM, DOLLY, MARTIN C <[e-mail]> wrote:

> 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
> [phone]
> [e-mail]
> 
>> On Mar 25, 2014, at 7:17 PM, "Ben Campbell" <[e-mail]> 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
>> 
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime