Subject: [Dime] OVLI: OC-Validity-Duration

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 12 Dec 2013 07:53:45 +0000

Dear all,

I would like to reconsider the real need for the OC-Validity-Duration AVP to be included into overload report.
Overload mechanism is being design with a principle in mind: as soon as reporting node determines a reacting node overload behavior should change, reporting node sends a fresh overload report to this reacting node.
Therefore, latest overload report received will be always applicable until a new report is received, and then I do not see the value, but just complexity, of including a Duration in the report.

Let me know your views.
Best regards
/MCruz

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 12 Dec 2013 10:38:34 +0200

Hi,

I kind of like scheduled cleanups.. just to make sure there is no
stuff left hanging around when something unpredictable happens in
the network system.

Again, I would say this is a wrong place to "optimize".

- Jouni

On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome <[email-masked]> wrote:

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

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 07:53:14 -0600

+1

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 12 Dec 2013 16:38:16 +0000

Jouni,

I think the best way to manage "something unpredictable" is not to provide an estimation (on an unpredictable event) from the server.
If you really think that scheduled cleanups are helpful, this could always be considered in the client, with a default value, that does not need to be sent from the reporting node.

Regards
/MCrzu

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: jueves, 12 de diciembre de 2013 9:39
To: Maria Cruz Bartolome
Cc: [email-masked]
Subject: Re: [Dime] OVLI: OC-Validity-Duration

Hi,

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 14:59:48 -0600

> If you really think that scheduled cleanups are helpful, this could always be considered in the client, with a default value, that does not need to be sent from the reporting node.

The point is not for the reporting node to predict how long it's likely to be overloaded, it's to make sure things get cleaned up if some _other_ unpredictable event occurs. The idea is to set a time out so that, if the reacting node doesn't see an update in some period of time, it can discard the state. Otherwise, it could assume the overload condition to last forever. It's up to the implementation, but typically you choose your validity times to balance how long you are willing to let an expired report "hang" vs how many "update" messages you are willing to tolerate. I think it will be typical that servers choose a fixed timeout value (possibly configured) for all reports.

Soft state like this is a well known protocol design pattern used in many IETF protocols. The idea is that, if some failure occurs so that the recipient fails to get an update, the problem eventually expires, and heals itself.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 16 Dec 2013 21:34:31 +0000

Ben,

But does a reporting node need to send a Validity-Duration AVP in each message if this is just going to be used for clean-up purposes? Even more if we think it could be a pre-configured default value?

/MCruz

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:36:50 -0600

> But does a reporting node need to send a Validity-Duration AVP in each message if this is just going to be used for clean-up purposes? Even more if we think it could be a pre-configured default val…

I think it is a pre-configured value at the reporting node. But it still needs to be communicated to the receiving node. (You really _don't_ want to have to configure it for both, and keep the configuration in sync between them.)

This is exactly like how the Expires header works for SIP.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 17 Dec 2013 00:02:24 +0200

> But does a reporting node need to send a Validity-Duration AVP in each message if this is just going to be used for clean-up purposes? Even more if we think it could be a pre-configured default val…

Typically in a "client-server" communication, like we have here, the server decides and the client obeys. Less places to configure something.. 

- Jouni