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

Ben Campbell <> Mon, 16 December 2013 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 96DC91A1F5E for <>; Mon, 16 Dec 2013 13:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TOdG49L9mwow for <>; Mon, 16 Dec 2013 13:02:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A2181ACCE4 for <>; Mon, 16 Dec 2013 13:02:34 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id rBGKxuUv095346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 14:59:57 -0600 (CST) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Mon, 16 Dec 2013 14:59:48 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Maria Cruz Bartolome <>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: "" <>
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Dec 2013 21:02:39 -0000

On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome <>; wrote:

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

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.

> Regards
> /MCrzu
> -----Original Message-----
> From: Jouni Korhonen [] 
> Sent: jueves, 12 de diciembre de 2013 9:39
> To: Maria Cruz Bartolome
> Cc:
> Subject: Re: [Dime] OVLI: OC-Validity-Duration
> 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 <>; wrote:
>> 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
>> _______________________________________________
>> DiME mailing list
> _______________________________________________
> DiME mailing list