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

[Steve Donovan <[e-mail]>]

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
>