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

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 15:38:41 -0500

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 <[email-masked]> wrote:
>
>> 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,
>>
>> 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..
>>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 25 Mar 2014 15:48:37 +0200

Fine with me.

On Mar 24, 2014, at 10:38 PM, Steve Donovan <[email-masked]> wrote:

>   expires without an explicit overload report containing an OC-Validity-Duration
>   value set to zero ("0").
> 
> 
>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>> Ben, Nirav,
>>> 
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of Nirav Salot (nsalot)
>>> Cc: 
>>> [email-masked] list; [email-masked]
>>> 
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of Ben Campbell
>>> Cc: 
>>> [email-masked] list; [email-masked]
>>> 
>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen 
>>> <[email-masked]>
>>>  wrote:
>>> 
>>>

---

From: <[email-masked]>
Date: Tue, 25 Mar 2014 14:53:23 +0000

+1

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

Fine with me.

_________________________________________________________________________________________________________________________

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.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Mar 2014 15:04:09 +0000

It sounds alright

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

+1

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

Fine with me.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Mar 2014 18:16:49 -0500

I do not agree. While this fixes a related problem of using a zero validity-duration to signal the end of an overload condition, it still implies that one SHOULD NOT let a report "just expire". As I've argued before, I believe there are time when it is just as good, if not better, to let an overload condition expire naturally.

> 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 _nev…

So, here's a different proposal for your first paragraph:

   "When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be 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"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so."

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 25 Mar 2014 23:51:41 +0000

Why, sorry but please repeat or I go with I believe consensus

Thanks

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]

> On Mar 25, 2014, at 7:17 PM, "Ben Campbell" <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Mar 2014 19:37:35 -0500

A reporting node has two ways of ending a reported overload condition. It can forcefully expire the report, by sending an updated report with a zero expiration time. Or it can let the report expire by not updating it.

This is analogous to how SIP handles registrations and subscriptions. You can remove one by sending a new REGISTER or SUBSCRIBE with expires=0.  Or if the registration or subscription is close to ending anyway, you can let it expire.

The "consensus" position says that you SHOULD do the first. That implies you SHOULD NOT do the second. My position is that we don't need that restriction; either choice is okay as long as it happens in a timely manner. In fact there may be times where sending an updated report does nothing but add unneeded messages.

I will go further to say that a normative preference for one or the other violates RFC 2119 guidance for normative language, in that the SHOULD is not necessary for interoperability, because both strategies work. And neither approach does damage, as long as it is timely.

Now, I agree that the reporting node SHOULD ensure that the overload report is invalidated in a timely manner. I just don't think we need to prefer one method of doing that over another.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 20:57:10 -0500

I'm ok with Ben's suggested wording.

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 26 Mar 2014 10:47:02 +0200

+1

---

From: "dime issue tracker" <[email-masked]>
Date: Wed, 26 Mar 2014 15:54:48 -0000

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

Comment (by [email-masked]):

 Current -02 wording:

 Change to:

 When a reporting node has recovered from overload, it SHOULD invalidate
 any existing overload reports in a timely matter. This can be 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"). If the overload report is about to expire naturally, the reporting
 node MAY choose to simply let it do so.

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

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

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

---

From: "dime issue tracker" <[email-masked]>
Date: Wed, 26 Mar 2014 15:54:58 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

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

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 10:59:17 -0500

Ben,

I took the liberty to close this issue for you based on your suggested
wording.  If you disagree please re-open.

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Mar 2014 11:09:31 -0500

I'm getting errors looking at the ticket. Hopefully that's temporary. But I do not object in principle.

On Mar 26, 2014, at 10:59 AM, Steve Donovan <[email-masked]> wrote:

> Ben,
> 
> I took the liberty to close this issue for you based on your suggested wording.  If you disagree please re-open.
> 
> Regards,
> 
> Steve
> 
>> Changes (by 
>> [email-masked]
>> ):