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

[Steve Donovan <[e-mail]>]

JJ,

I thought we already had wording in the draft about the reacting node
gradually increasing traffic sent to the host after the end of an
overload condition.  This would apply both when the reporting node
explicitly ends the overload period and when the validation timer expires.

Does this cover your concern?

Steve

On 2/12/14 1:30 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
>
> I come back on this ticket and your current conclusions;
> We are in the area of guidance about the use of the expiry timer  but I think there are important points to take care with the expiry timer :
>
> If a server  sends OLRs with 50% traffic reduction, the client will divide the traffic by two. Then, if the server does not update the expiry timer and leaves  it expire and that traffic conditions have not changed  on client side, the client will stop  throttling  and will double the traffic which  I think the server will worry about. 
>  We need to avoid oscillations, and have a graceful behavior as expressed in the requirements 2 , 3 and 7. In fact the server should  progressively decrease the value of the % reduction in OLRs it sends according to the diminution of the traffic it will observe (due to the decrease of the input traffic coming back to normal conditions  on client side)  This is when server will  send  OLRs with 0% of traffic reduction without generating overload that it can  leave the expiry timer expire and no more send OLRs.
> The other application of the expiry timer is for error or out of sync situations (Ulrich I think mentioned this point)  where the expiry timer acts as a reset of the DOC mechanism but in such a case the server should  expect a sudden increase of traffic from clients generating overload on its side and then enter in the overload control by generating the relevant OLRs . 
>
> So for me the use of expiry timer should be quite limited, the main tool of overload control is the % of reduction put the OLRs and its evolution over time. Ben has mentioned other possibilities in the use of the expiry time, may be, but we have to take care of the ones I mentioned  
>
> So I consider worthwhile to have  some recommendations in the draft on the expiry timer use.
>
> Best regards
>
> JJacques 
>  
>
> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de Jouni Korhonen
> Envoyé : mardi 11 février 2014 23:32
> À : Maria Cruz Bartolome
> Cc : [e-mail] list
> Objet : 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 <[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
>