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