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

"Nirav Salot (nsalot)" <nsalot@cisco.com> Thu, 13 February 2014 03:11 UTC

Return-Path: <nsalot@cisco.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 48E981A00B6 for <dime@ietfa.amsl.com>; Wed, 12 Feb 2014 19:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 917ZtyXuwtvV for <dime@ietfa.amsl.com>; Wed, 12 Feb 2014 19:11:32 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7D1A00AF for <dime@ietf.org>; Wed, 12 Feb 2014 19:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43235; q=dns/txt; s=iport; t=1392261091; x=1393470691; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=GNVyBI6MiMGXSzXko5gV5ZU04ajrlClJYW+q2hDx2IE=; b=Ziup83+3vbuoCMDR05rxzaYK9IICLGAf+dvXIs3+3l56ONLiywOuymjv Cx4Vg0zK23YpU70b2iao2utZzJs/xxYcJvWFFrndYbGIHkPGrKAs5k4sr kjQqLvvWwCJaUcH5yru438pnMdZfqI5RMsj6Q3LdltDdV/hG7b+bjKQCU 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFABI3/FKtJV2d/2dsb2JhbABZgkZEOFe/OYEXFnSCJQEBAQQBAQEqQRsCAQgRBAEBCxYBBgchBgsUCQgCBAESCIdpAxENv2INiDwTBIxfgUkBAQoULQoBgySBFASJEI0vjkqFQ4MtgXE5
X-IronPort-AV: E=Sophos; i="4.95,836,1384300800"; d="scan'208,217"; a="303728933"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 13 Feb 2014 03:11:29 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1D3BT2w028588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 03:11:29 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 21:11:29 -0600
From: "Nirav Salot (nsalot)" <nsalot@cisco.com>
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>, "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE84KkJeLCuVkUibLddl7UiIfJquvdYAgABOmACAAAPGAIAABRuAgABhFgCAABzEgIAA6jWAgAE7sYCAAAPPgIAABFqAgAACcICAAL+eAIAABGyw
Date: Thu, 13 Feb 2014 03:11:28 +0000
Message-ID: <A9CA33BB78081F478946E4F34BF9AAA014D6C2C9@xmb-rcd-x10.cisco.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <A27A0204-5080-46F6-B1F4-B4FE1CB1AD5D@gmail.com> <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com> <B28458B2-D601-4914-B51D-C05C61B3DCB8@gmail.com> <61BD40D6-20C5-4F47-876D-27E2D323C241@nostrum.com> <97EF76DD-0AAA-458C-90E4-A16443E5B06B@gmail.com> <F8DA59C4-65A5-44B5-8DD9-AEDA8F04C32D@nostrum.com> <087A34937E64E74E848732CFF8354B9209772FEF@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209774086@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F04@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209774131@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2F51@DEMUMBX014.nsn-intra.net> <E194C2E18676714DACA9C3A2516265D202664851@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <E194C2E18676714DACA9C3A2516265D202664851@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.142.140.46]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D6C2C9xmbrcdx10ciscoc_"
MIME-Version: 1.0
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: Thu, 13 Feb 2014 03:11:37 -0000

I also tend to agree with JJ below.
Unless there is a strong reason, no point in forbidding the use of 0% reduction - which can also indicate end of overload condition.

May be we can clarify that 0% reduction and/or 0 validity period indicates end of overload. In my view, both are valid for the use, individually and together. So,

-          0 reduction, non-zero validity period => Valid. The reacting node can ignore the validity period if reduction is 0.

-          Non-zero reduction, 0 validity period => Valid. The reacting node can ignore the reduction if validity period is 0.

-          0 reduction, 0 validity period => Valid as well. Generally, this is what the reporting node will use to indicate the end of overload condition.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, February 13, 2014 2:18 AM
To: dime@ietf.org list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear all

On this ticket,  I agree on Ben's  proposal  to use the Validity period of 0 to indicate the end of overload.
But about the value of 0% reduction why to forbid it ?

In the process to  return to normal traffic conditions, the  server still sending OLR eg with  5% reduction    will consider to no request anymore traffic reduction but without being yet sure if  it will be  stable (end of overload condition as Ben reminded means stable  situation without traffic reduction ) , so server  can send 0% reduction OLR  but with a validity duration different from 0.
Otherwise it has to  use 1% throttling to check stability and if traffic with the client is 1000 request per second this means 10 requests throttled per second which should not be throttled.
In addition, we do not need to handle the 0% reduction  as an error case (cf Mcruz mail)

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mercredi 12 février 2014 10:22
À : ext Maria Cruz Bartolome; dime@ietf.org<mailto:dime@ietf.org> list
Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Thank you for the clarification.
I agree.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:13 AM
To: dime@ietf.org<mailto:dime@ietf.org> list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Dear Ulrich, all,

The proposal was to use OC-Validity-Duration AVP =0 to indicate end of overload, since this could be generally applied to any algorithm.
Then, Reduction-Percentage = 0 should be considered as invalid.
I found this reasonable.

Best regards
/MCruz


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: miércoles, 12 de febrero de 2014 9:57
To: Maria Cruz Bartolome; dime@ietf.org<mailto:dime@ietf.org> list
Subject: RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

I'm confused,

I thought that people were in favour of allowing 0 to indicate end of overload.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 9:44 AM
To: dime@ietf.org<mailto:dime@ietf.org> list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben, all,

This comment affects as well clause 5.5.2:

   value == 0

      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

This should be modified to explain this value is not valid and what is the expected behavior (i.e. it is discarded).

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: martes, 11 de febrero de 2014 14:54
To: dime@ietf.org<mailto:dime@ietf.org> list
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Ben,

This approach sounds reasonable to me.
But I would like to clarify what should be the behavior if a Reduction-Percentage=0 is received. This is an invalid value, then I presume it should be discarded by client.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 0:56
To: Jouni Korhonen
Cc: dime@ietf.org<mailto:dime@ietf.org> list; draft-docdt-dime-ovli@tools.ietf.org<mailto:draft-docdt-dime-ovli@tools.ietf.org>
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

So, here's some proposed text. (intentionally ignoring the related discussion about handling invalid values):

Section 4.5, first paragraph, last 2 sentences:

Old:

Validity duration values 0 (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity-Duration AVP were not present.

New:

Validity duration values above 86400 MUST NOT be used. Invalid validity duration values are treated as if the OC-Validity-Duration AVP were not present. A value of zero (0) indicates that an existing overload condition has ended and that the reporting node is in a stable condition.

Section 4.7, 2nd paragraph:

Old:

 The value of the Reduction-Percentage AVP is between one (1) and one hundred (100).  Values greater than 100 are interpreted as 100.  The value of 100 means that no traffic is expected, i.e. the reporting node is under a severe load and ceases to process any new messages. The Reduction-Percentage AVP MUST be present in an overload report that uses the default abatement algorithm.

Note that there is no zero (0) value defined for the Reduction-Percentage AVP. A zero value would logically indicate that no overload abatement is requested. Instead, reporting nodes use a OC-Validity-Duration AVP value of zero (0) to indicate the end of an overload condition. [Section 4.5]






On Feb 10, 2014, at 4:12 PM, Jouni Korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>> wrote:
Just post it here.



On Feb 10, 2014, at 6:25 PM, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> wrote:
Okay. Does that mean we should assign the issue to me in the tracker?

On Feb 10, 2014, at 10:06 AM, Jouni Korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>> wrote:

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> wrote:

On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>> wrote:

On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org<mailto:trac+dime@trac.tools.ietf.org>> wrote:
#45: Why is a validity duration of 0 disallowed?

Section 4.5 disallows a validity duration of zero. Why do we want to
disallow that? It would allow a quick way of ending any existing overload
condition without worrying about the semantics of the abatement algorithm.
(We currently use a reduction percentage of zero to end an overload
condition--but that's specific to the loss algorithm and might not make
sense for all future ones.)

Right. Avoiding two ways of ending overload condition was the reason.
I am OK to have validity duration 0 as an additional method ending the
overload condition based on the reasoning above.

I would go further and make duration 0 the _preferred_ way, for two reasons:

1) It's algorithm independent. (reduction-percentage of 0 is specific to algorithms that use reduction percentage.)

2) Explicit signaling of the end of an overload condition becomes semantically identical to the expiration of an overload condition. This allows a simpler implementation.



_______________________________________________
DiME mailing list
DiME@ietf.org<mailto:DiME@ietf.org>
https://www.ietf.org/mailman/listinfo/dime