Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Wed, 12 February 2014 19:30 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 D04471A062C for <dime@ietfa.amsl.com>; Wed, 12 Feb 2014 11:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ztTY_c39WZe8 for <dime@ietfa.amsl.com>; Wed, 12 Feb 2014 11:30:33 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B566A1A0647 for <dime@ietf.org>; Wed, 12 Feb 2014 11:30:33 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1CJUVHb016285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Wed, 12 Feb 2014 13:30:32 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1CJUUcR027049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Wed, 12 Feb 2014 20:30:30 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 20:30:30 +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] #46: Bad normative advice on not letting overload reports expire
Thread-Index: AQHPJxXELMYu9QS3d0uaLCS8tFO+/5qwkyKAgAFlB/A=
Date: Wed, 12 Feb 2014 19:30:29 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D202664816@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> <B08CCDA3-4E2B-444A-AE27-9DE2D9C0B458@gmail.com> <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com> <A9CA33BB78081F478946E4F34BF9AAA014D6979E@xmb-rcd-x10.cisco.com> <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com>
In-Reply-To: <58574389-BAEB-49DA-A07E-B6648905C291@gmail.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.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
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: Wed, 12 Feb 2014 19:30:37 -0000
Dear all I come back on this ticket and your current conclusions; We are in the area of guidance about the use of the expiry timer but I think there are important points to take care with the expiry timer : If a server sends OLRs with 50% traffic reduction, the client will divide the traffic by two. Then, if the server does not update the expiry timer and leaves it expire and that traffic conditions have not changed on client side, the client will stop throttling and will double the traffic which I think the server will worry about. We need to avoid oscillations, and have a graceful behavior as expressed in the requirements 2 , 3 and 7. In fact the server should progressively decrease the value of the % reduction in OLRs it sends according to the diminution of the traffic it will observe (due to the decrease of the input traffic coming back to normal conditions on client side) This is when server will send OLRs with 0% of traffic reduction without generating overload that it can leave the expiry timer expire and no more send OLRs. The other application of the expiry timer is for error or out of sync situations (Ulrich I think mentioned this point) where the expiry timer acts as a reset of the DOC mechanism but in such a case the server should expect a sudden increase of traffic from clients generating overload on its side and then enter in the overload control by generating the relevant OLRs . So for me the use of expiry timer should be quite limited, the main tool of overload control is the % of reduction put the OLRs and its evolution over time. Ben has mentioned other possibilities in the use of the expiry time, may be, but we have to take care of the ones I mentioned So I consider worthwhile to have some recommendations in the draft on the expiry timer use. Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoyé : mardi 11 février 2014 23:32 À : Maria Cruz Bartolome Cc : dime@ietf.org list Objet : Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire Fine with me. - Jouni On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote: > Ben, Nirav, > > I follow same argumentation. > Regards > /MCruz > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot > (nsalot) > Sent: martes, 11 de febrero de 2014 11:23 > To: Ben Campbell; Jouni Korhonen > Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting > overload reports expire > > Ben, > > I resonate with your thinking below. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Monday, February 10, 2014 9:54 PM > To: Jouni Korhonen > Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting > overload reports expire > > > On Feb 10, 2014, at 5:16 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote: > >> >> My reasoning for explicit termination was that knowing the >> implementation folks they will let overload conditions expire unless advised otherwise. >> And having unnecessary stuff hanging around waiting for a cleanup is >> not a good thing in general. But I am open here for other options.. >> > > I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. > > And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization. > > _______________________________________________ > 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 > > _______________________________________________ > 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
- [Dime] [dime] #46: Bad normative advice on not le… dime issue tracker
- Re: [Dime] [dime] #46: Bad normative advice on no… Jouni Korhonen
- Re: [Dime] [dime] #46: Bad normative advice on no… Ben Campbell
- Re: [Dime] [dime] #46: Bad normative advice on no… Nirav Salot (nsalot)
- Re: [Dime] [dime] #46: Bad normative advice on no… Maria Cruz Bartolome
- Re: [Dime] [dime] #46: Bad normative advice on no… Jouni Korhonen
- Re: [Dime] [dime] #46: Bad normative advice on no… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #46: Bad normative advice on no… Steve Donovan
- Re: [Dime] [dime] #46: Bad normative advice on no… Steve Donovan
- Re: [Dime] [dime] #46: Bad normative advice on no… Jouni Korhonen
- Re: [Dime] [dime] #46: Bad normative advice on no… lionel.morand
- Re: [Dime] [dime] #46: Bad normative advice on no… Maria Cruz Bartolome
- Re: [Dime] [dime] #46: Bad normative advice on no… Ben Campbell
- Re: [Dime] [dime] #46: Bad normative advice on no… DOLLY, MARTIN C
- Re: [Dime] [dime] #46: Bad normative advice on no… Ben Campbell
- Re: [Dime] [dime] #46: Bad normative advice on no… Steve Donovan
- Re: [Dime] [dime] #46: Bad normative advice on no… Jouni Korhonen
- Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Ba… dime issue tracker
- Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Ba… dime issue tracker
- Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Ba… Steve Donovan
- Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Ba… Ben Campbell
- Re: [Dime] [dime] #46 (draft-ietf-dime-ovli): Bad… dime issue tracker