Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Fri, 14 February 2014 08:46 UTC
Return-Path: <jean-jacques.trottin@alcatel-lucent.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 D01161A0151 for <dime@ietfa.amsl.com>; Fri, 14 Feb 2014 00:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 A_p3i7niY_tM for <dime@ietfa.amsl.com>; Fri, 14 Feb 2014 00:46:24 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 323281A0136 for <dime@ietf.org>; Fri, 14 Feb 2014 00:46:24 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1E8kKpP016103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Fri, 14 Feb 2014 02:46:22 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1E8kKpj018584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Fri, 14 Feb 2014 09:46:20 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 09:46:20 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
Thread-Index: AQHPJE88aqIYhHfy6k2vf6t9AbBIc5quSH0AgABOmACAAAPGAIAABRyAgABhFgCAABzDgIAA6jaAgAE7sICAAAPQgIAABFmAgAACcYCAAMwQ0IAAXtAAgABgLoCAABhOIP//+KIAgAAU8ICAABIAAIAAoHoQ
Date: Fri, 14 Feb 2014 08:46:19 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D2026686E4@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <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> <A9CA33BB78081F478946E4F34BF9AAA014D6C2C9@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3207@DEMUMBX014.nsn-intra.net> <E194C2E18676714DACA9C3A2516265D2026649BC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209774896@ESESSMB101.ericsson.se> <E194C2E18676714DACA9C3A2516265D2026649F8@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52FCB76E.6020202@usdonovans.com>
In-Reply-To: <52FCB76E.6020202@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026686E4FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Czr_GmJ_hOnD7U1PJdKNGEUZ-co
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: Fri, 14 Feb 2014 08:46:32 -0000
Hi MCruz, Steve I here answer Steve and MCruz mails About Steve, I have not said the reporting "needs" to send a 0% reduction valid ( it is an implementation choice of the reporting node to choose the % values it puts in OLR), I simply says to not forbid it. In an overload condition, a behavior example is that the reporting , by its own logic (not standardised) , determines the % reduction value it send in OLRs, and then will observe the effect of this OLR in the evolution of the received traffic that the reacting has throttled. Reporting will then decides to keep, increase or decrease the OLR %value .When we come to the end of overload, the reporting still receiving throttled traffic, will consider that it does not more need to request a % reduction. - One way is to send an OLR with validity period to 0 to indicate the end of the overload condition, but it does this without having yet received unthrottled traffic that in some case may nevertheless request to immediately send again an OLR requesting reduction, meaning that reporting, having terminated an overload condition, will immediately restart another one. This a way to proceed as Steve described , I do not say it does not work - The way I describe is that reporting sends a 0% value to see the effect of this new value on the traffic it will receive (that will be unthrottled), before concluding to the end of the overload , and if nevertheless the received unthrottled traffic still require to send OLRs, reporting will not conclude to the end of overload condition and again generate OLRs with a non zero % value. On the reacting, if it receives a 0% value, it simply does nothing, I remind I agree with the proposal that the end of the Overlaod condition is determined by the Value 0 of the Validity period , or the end of the expiry timer, but is not linked to the 0% traffic reduction Developers, have various possibilities in the way to manage the overload condition and the OLRS they send, I think that DOIC should leave flexibility. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : jeudi 13 février 2014 13:16 À : dime@ietf.org Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? JJ, Why does the reacting node need to send a reduction percentage of zero to determine if it is stable? Can't the reacting node just do its normal checking for overload after sending the validity period of zero? If it finds the need for reduction of traffic, it can just send a new overload report. Steve On 2/13/14 4:43 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Hi MCruz AS Ben proposed, and I agree, value of zero (0) for the Validity period indicates that an existing overload condition has ended and that the reporting node is in a stable condition. An important word is "stable". When the traffic peak on client side having created the overload decreases, the reporting node progressively diminishes the % traffic reduction in OLRs it sends towards clients taking care to minimize the possible oscillations. At a certain time , server will consider that it can indicate no traffic reduction to clients. Then is it stable? there may be different implementation dependent ways for the server to decide the situation is stable; one is to send 0% in OLRs and wait a certain number of seconds (not 24 hours) to check if situation is stable and then put the validity timer to 0 (or leaves the expiry timer expire). I do not see why to forbid this way to test the stable condition. So the end of overload condition, as Ben proposed, can remain ONLY based on Validity duration value 0 (or timer expiry), not on the value 0 of the % reduction (so a bit different from Nirav statement, but in line with Ulrich comment) . The value 0% of the traffic reduction is not forbidden as a possible way to check the stability condition . Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : jeudi 13 février 2014 10:56 À : dime@ietf.org<mailto:dime@ietf.org> list Objet : Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? Hello all, I think proposal to use just Validity-Duration=0 to end overload mainly has the intention to simplify and avoid the checks you just listed below. If we allow both, it means that the case Ulrich mentioned is valid, and even with 0% reduction OLR info cannot be deleted until Validity time expires, even we could receive a new OLR in sequence. Even, the reporting needs still to keep Validity timer on for this OLR. I think this does not provide any added value but simply makes things a bit more complex. What could be the reason to keep 0% reduction but a Validity of a few hours (e.g.)? Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: jueves, 13 de febrero de 2014 10:24 To: dime@ietf.org<mailto:dime@ietf.org> list Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? I am OK with Ulrich JJacques De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : jeudi 13 février 2014 09:56 À : ext Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org<mailto:dime@ietf.org> list Objet : RE: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? I also agree with the principle. One minor clarification: 0%-reduction with non-zero validity period is valid but validity period cannot be ignored: as long as not expired the sequence number needs to be stored for future checking; once expired, sequence number must not be used for future checking. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot) Sent: Thursday, February 13, 2014 4:11 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org<mailto:dime@ietf.org> list Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed? 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<mailto: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 _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime
- [Dime] [dime] #45: Why is a validity duration of … dime issue tracker
- Re: [Dime] [dime] #45: Why is a validity duration… Jouni Korhonen
- Re: [Dime] [dime] #45: Why is a validity duration… Steve Donovan
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Jouni Korhonen
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Jouni Korhonen
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… Jouni Korhonen
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #45: Why is a validity duration… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #45: Why is a validity duration… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #45: Why is a validity duration… Nirav Salot (nsalot)
- Re: [Dime] [dime] #45: Why is a validity duration… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #45: Why is a validity duration… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… Steve Donovan
- Re: [Dime] [dime] #45: Why is a validity duration… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… lionel.morand
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Steve Donovan
- Re: [Dime] [dime] #45: Why is a validity duration… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #45: Why is a validity duration… lionel.morand
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Steve Donovan
- Re: [Dime] [dime] #45: Why is a validity duration… Ben Campbell
- Re: [Dime] [dime] #45: Why is a validity duration… Maria Cruz Bartolome
- Re: [Dime] [dime] #45: Why is a validity duration… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #45 (draft-docdt-dime-ovli): Wh… dime issue tracker
- Re: [Dime] [dime] #45 (draft-ietf-dime-ovli): Why… dime issue tracker