Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Tue, 25 February 2014 09:30 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 59BB31A03F6 for <dime@ietfa.amsl.com>; Tue, 25 Feb 2014 01:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level:
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 4XZxrdeIQhoY for <dime@ietfa.amsl.com>; Tue, 25 Feb 2014 01:30:56 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 577991A03AB for <dime@ietf.org>; Tue, 25 Feb 2014 01:30:55 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-88-530c62cd1586
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BD.62.04853.DC26C035; Tue, 25 Feb 2014 10:30:54 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 10:30:53 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJlD7NvPtWONPVUazL45pZeb7hpquSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQgADcMfCAEHWF2YAAyG6Q
Date: Tue, 25 Feb 2014 09:30:53 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209784EE8@ESESSMB101.ericsson.se>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <E194C2E18676714DACA9C3A2516265D2026649BC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se> <E194C2E18676714DACA9C3A2516265D2026649F8@FR712WXCHMBA11.zeu.alcatel-luc! ent.com> <52FCB76E.6020202@usdonovans.com> <E194C2E18676714DACA9C3A2516265D2026686E4@FR712WXCHMBA12.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209775207@ESESSMB101.ericsson.se> <27861_1392393201_52FE3BF1_27861_1566_1_6B7134B31289DC4FAF731D844122B36E4A3E77@PEXCVZYM13.corporate.adroot.infra.ftgroup> <83E6BED2-035D-4C26-A1AF-9F833B1070C5@nostrum.com> <5302365A.8080408@usdonovans.com> <E194C2E18676714DA! CA9C3A2516265D2026697BC@FR712WXCHMBA12.zeu.alcatel-lucent.com> <27433_1392660486_53025006_27433_1223_1_6B7134B31289DC4FAF731D844122B36E4AB48A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <579DC2BE-CC3C-43E6-819C-ADB7B1182CED@nostrum.com> <530BBA98.9080903@usdonovans.com>
In-Reply-To: <530BBA98.9080903@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209784EE8ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje65JJ5gg1NfWCzm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtvj11gLHodUnNp8mq2B8Y97FyMnh4SAicTRWfeZIWwxiQv3 1rN1MXJxCAmcYJR4t3A5O4SzmFFi2uFDYFVsAnYSl06/YOpi5OAQEVCWOP3LASQsLOAt8ePD ZSYQW0TAR6K38QjYIBGBfYwShz6sBetlEVCVWDD7DQuIzSvgK3F63yWobW/YJe41nwPr5hTQ k5h7/Do7iM0IdNL3U2vA4swC4hK3nsxngjhVQGLJnvNQZ4tKvHz8jxXCVpJoXPKEFaI+X+L1 o5NQywQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFK FqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBMbTwS2/jXYwntxjf4hRmoNFSZz3OmtNkJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbG7Wuel/ZKXLi1sOHYp7qOJsmEBtuTFiodrw6rau3h 6T7UvUKg9vuy55fN3AKY5Szc1G7H9HouUzf+cF+344x/qbTWC0WX9yzfN0gemR/J7iLRf1D0 /XXLWoeFeznfqE1nkSx+NtXdP9bc6cW3jDPFV5YuOzhB59CbOJWlVqsF8ph57dgf3XqkxFKc kWioxVxUnAgA2FJrX3UCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4G3w0LvGv_wCND1T9zuUs3nYleY
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
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: Tue, 25 Feb 2014 09:30:58 -0000

Fine

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 22:33
To: dime@ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I think the proposal here is the following:

A reporting node communicates that an overload report is no longer valid by sending an OLR with a Validity-Period AVP with a value of zero.  This is the only way for a reporting node to indicate that an overload report is no longer valid.  For instance, setting the reduction-percentage to zero does not make the overload report invalid.

Do we have agreement on this?

Steve
On 2/17/14 12:44 PM, Ben Campbell wrote:



On Feb 17, 2014, at 12:08 PM, lionel.morand@orange.com<mailto:lionel.morand@orange.com> wrote:



I would like to highlight that my proposal is not related to the default Reduction-percentage algo.



Whatever the ago used, I think that an OLR can only be sent for two purposes:

- Send an indication of overload situation

- Send an indication of end of the overload situation



For me, providing both indications in the same message would be a non-sense. And I don't understand why the validity period would prevail in that case.



So here's the question: Let's assume a reporting node sends you an OLR using the "loss" algorithm, a reduction-percentage of 50%, and a Validity-Duration of 10 minutes. 5 minutes later, it sends you a new OLR with an invalid reduction percentage and a Validity-Duration of 0.



What's the current overload state?



What if the second OLR used the "rate" algorithm, with a valid value, but still had a validity duration of 0. Does that change anything?



I am arguing that, in both cases, the second OLR ends the overload period.



I'm actually okay if we have a normative statement to the effect that the reporting node MUST NOT send an invalid reduction percentage, and that a reacting node MUST ignore an OLR with an invalid value _except_ for the case of a validity-duration set to zero.



This all comes down to how much guessing we are willing to do about the intent of the sender when one receives an invalid OLR. I think it's reasonable to guess that a zero validity duration means to end an overload condition, without regard to the rest of the message. I _don't_ think it's reasonable to try to guess what the sender meant with an invalid reduction percentage, when the validity period is non-zero.



Another, perhaps simpler, approach would be to assert that the reception of _any_ invalid OLR automatically ends any existing overload condition. (I'm not necessarily arguing for that--it's just something to think about.)





Now, if what is argued by Ben and supported by JJ and Steve is clear for the rest of the group, I will not fight.



... but the fighting is the fun part :-)

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime