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

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Mon, 16 December 2013 21:34 UTC

Return-Path: <maria.cruz.bartolome@ericsson.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBAC1ADED5 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 13:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dIRY4bUeKRx for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 13:34:45 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE4091A1F1B for <dime@ietf.org>; Mon, 16 Dec 2013 13:34:44 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-3b-52af71f2365c
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DB.77.23787.2F17FA25; Mon, 16 Dec 2013 22:34:43 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.73]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 22:34:32 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] OVLI: OC-Validity-Duration
Thread-Index: Ac73DRNgVjMdaw2ATnC3EBEvo4YB4gAABXsAABLFinAA0EgEAAADM9cA
Date: Mon, 16 Dec 2013 21:34:31 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se> <E8A3170E-3C42-4506-A22D-B947B2D03E54@gmail.com> <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se> <C00D2172-09E9-44CC-AD58-F94D6164A417@nostrum.com>
In-Reply-To: <C00D2172-09E9-44CC-AD58-F94D6164A417@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7nwvVBBpNncljM7zzNbjG3dwWb xf51DUwOzB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mg5tP8pS0CRd8bP9AFMD 4yvRLkZODgkBE4n3W/4xQdhiEhfurWfrYuTiEBI4xCgxo+kHC4SzmFFiV8dndpAqNgE7iUun X4B1iAgoSTxv3soCYjML+Egsv74QyObgEBbQk7h9SB+iRF9i04QLLBC2m0TntLlsIDaLgKrE +8tHwUbyCvhKLP+6mwli109Gickb3zKBzOEUsJd4c4QVpIYR6Ljvp9YwQawSl7j1ZD7U0QIS S/acZ4awRSVePv7HCmErSazYfokRol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGNlzEzNz0ssNNzEC4+bglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBsbai6u5XvXnVn7Z4GOQ8NToavSiDUIBD/ROJE0NeSiq/+BR 3dZ1j2+dz6hUWLlohlr2yU1rLx0peXiXqW1ezob315jly2d7qnLwsP1tezlNZZf2pBfhmcVN Chtzjuy9yn+qt6nCbNYKjomrTbymP9wgVn1zZxxXVlDLhDdtvZu28v351L1r61V5JZbijERD Leai4kQAedvG/mkCAAA=
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 21:34:47 -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


-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: lunes, 16 de diciembre de 2013 22:00
To: Maria Cruz Bartolome
Cc: Jouni Korhonen; dime@ietf.org
Subject: Re: [Dime] OVLI: OC-Validity-Duration


On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>; 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 [mailto:jouni.nospam@gmail.com] 
> Sent: jueves, 12 de diciembre de 2013 9:39
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> 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 <maria.cruz.bartolome@ericsson.com>; 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime