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

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 16 December 2013 22:02 UTC

Return-Path: <jouni.nospam@gmail.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 2237F1ACCD9 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 14:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 qakYfHR4G_qN for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 14:02:31 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id E66581A1F3E for <dime@ietf.org>; Mon, 16 Dec 2013 14:02:30 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id x18so1089455lbi.25 for <dime@ietf.org>; Mon, 16 Dec 2013 14:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lQdDhcbpf1MbKwCxt1d1FSHvhxyiYhSUwmwfzRI/o1E=; b=MTe9lYFk9CeHShlwWCLauuZ/y7iYsSko/7ug+xfum0pWVTbAHd1EzUR/wJ2ToosNGz UgYijXQg0VhE7Uitq4uOd/QdpJyyLAF5/vEJ4lsTu90d2VDISxsiidrjNO/IrSBlToVe tGk4NB8IatQneZgBTlu2XQTUrwEr6fF8DgOFXf1AQOLXX8Uh9yV5c1UqRKo2JqN9h7WO 1E6UTn2NBmNGKuFvwXX2kfXsV564z/Lccl+Z0PvyZbJWumbgWEDirPo21h4eFVILZSGC 42PANgVsl9ZqoGFF7eLuj9yvye2rx1HktL4IhYv6hPcQ4c47xgXHsdYcmaPcVMFWhyX/ FInQ==
X-Received: by 10.152.116.46 with SMTP id jt14mr7739014lab.31.1387231349426; Mon, 16 Dec 2013 14:02:29 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id e6sm10967749lbs.3.2013.12.16.14.02.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 14:02:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
Date: Tue, 17 Dec 2013 00:02:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <02C20B51-F92F-4F16-A282-2069808DD7F6@gmail.com>
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se> <E8A3170E-3C42-4506-A22D-B947B2D03E54@gmail.com> <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se> <C00D2172-09E9-44CC-AD58-F94D6164A417@nostrum.com> <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell <ben@nostrum.com>, "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 22:02:33 -0000

On Dec 16, 2013, at 11:34 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>; wrote:

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

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

- Jouni


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