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

[Maria Cruz Bartolome <[e-mail]>]

It sounds alright

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: martes, 25 de marzo de 2014 15:53
To: Jouni Korhonen; Steve Donovan
Cc: [e-mail]
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire

+1

-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de Jouni Korhonen Envoyé : mardi 25 mars 2014 14:49 À : Steve Donovan Cc : [e-mail] Objet : Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire


Fine with me.

On Mar 24, 2014, at 10: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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime