Re: [Dime] Diameter Load Editor's note on presence of overload report
"Trottin, Jean-Jacques (Nokia - FR)" <jean-jacques.trottin@nokia.com> Wed, 16 March 2016 12:23 UTC
Return-Path: <jean-jacques.trottin@nokia.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFE12D577 for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 05:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 54waIyFnyIW1 for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 05:23:30 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9BF12D579 for <dime@ietf.org>; Wed, 16 Mar 2016 05:23:29 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D31744D243B33; Wed, 16 Mar 2016 12:23:25 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2GCNRD5014120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 12:23:27 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2GCNPGd026356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Mar 2016 13:23:27 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.143]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 16 Mar 2016 13:23:25 +0100
From: "Trottin, Jean-Jacques (Nokia - FR)" <jean-jacques.trottin@nokia.com>
To: Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Diameter Load Editor's note on presence of overload report
Thread-Index: AQHRf36iKENfL4TngEqpXiEPNUmA8Q==
Date: Wed, 16 Mar 2016 12:23:24 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D29D4D17D5@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <56E20D8B.6010408@usdonovans.com> <16686_1457712545_56E2EDA1_16686_1479_1_6B7134B31289DC4FAF731D844122B36E01DFE739@OPEXCLILM43.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D29D4D00E7@FR712WXCHMBA12.zeu.alcatel-lucent.com> <56E6B622.3080400@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_E194C2E18676714DACA9C3A2516265D29D4D17D5FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/crNziugBMIwZzucuDhkn0Xq39cc>
Subject: Re: [Dime] Diameter Load Editor's note on presence of overload report
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 16 Mar 2016 12:23:32 -0000
Hi Steve and all This is about this Editor’s Note in draft-ietf-dime-load-01: Editor's Note: One area that requires thought is how load information is used, if at all, in the presence of an overload report from the same Diameter node. It might be that the load information from that Diameter node is ignored for the duration of the time that the overload report is in effect. It might also be possible that the load information can aid in the diverting of non-abated requests targeted for the overloaded Diameter node. In the current writing “from the “same” Diameter node”, the word “same”” is a bit misleading as it may be understood how the possible available load information of the overloaded node can be used and I do not well see the aid that load information from the overloaded node can bring, This is the load information from the other nodes which is helpful when diverting . I propose to, remove this editor’s note and replace it with the possible hereafter writing: “A reacting node which has received an overload report from a reporting node might ignore the load information received from that Diameter node for the duration of the time that the overload report is in effect. It might take into account the load information received from the other nodes to which it might divert requests targeted for the overloaded Diameter node.” For your feedback Best regards JJacques
- [Dime] Diameter Load value and SRV Steve Donovan
- Re: [Dime] Diameter Load value and SRV lionel.morand
- Re: [Dime] Diameter Load value and SRV Steve Donovan
- Re: [Dime] Diameter Load value and SRV Trottin, Jean-Jacques (Nokia - FR)
- Re: [Dime] Diameter Load Editor's note on presenc… Trottin, Jean-Jacques (Nokia - FR)
- Re: [Dime] Diameter Load Editor's note on presenc… Steve Donovan
- Re: [Dime] Diameter Load value and SRV Steve Donovan
- Re: [Dime] Diameter Load Editor's note on presenc… Trottin, Jean-Jacques (Nokia - FR)