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

From: "dime issue tracker" <[email-masked]>
Date: Fri, 07 Feb 2014 21:59:39 -0000

#46: Bad normative advice on not letting overload reports expire

 Section 4.5 says " As a general guidance for implementations it is
 RECOMMENDED never to let any overload report to timeout." In my opinion,
 this is bad advice. If an overload report is close to expiring anyway,
 it's better to just let it expire than to generate a new report to end the
 condition.

 Furthermore, this falls into the category of normative language that does
 not effect interoperability. That is forbidden by RFC 2119, except for
 situations where not following it does significant harm. If we believe
 letting reports expire does significant harm, we should explain why.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-docdt-dime-
  [email-masked]        |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  draft-       |    Version:  1.0
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/46>
dime <http://tools.ietf.org/wg/dime/>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 13:16:12 +0200

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..

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Feb 2014 10:24:08 -0600

> 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.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 11 Feb 2014 10:22:58 +0000

Ben,

I resonate with your thinking below.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Monday, February 10, 2014 9:54 PM
To: Jouni Korhonen
Cc: [email-masked] list; [email-masked]
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire

On Feb 10, 2014, at 5:16 AM, Jouni Korhonen <[email-masked]> 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..
> 

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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 10:24:49 +0000

Ben, Nirav,

I follow same argumentation.
Regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Nirav Salot (nsalot)
Sent: martes, 11 de febrero de 2014 11:23
To: Ben Campbell; Jouni Korhonen
Cc: [email-masked] list; [email-masked]
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire

Ben,

Regards,
Nirav.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 12 Feb 2014 00:31:41 +0200

Fine with me.

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 12 Feb 2014 19:30:29 +0000

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:[email-masked]] De la part de Jouni Korhonen
Envoyé : mardi 11 février 2014 23:32
À : Maria Cruz Bartolome
Cc : [email-masked] list
Objet : Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire

Fine with me.

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Feb 2014 06:24:10 -0600

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