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

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