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 15:30 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 8D72C12D9C4 for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 08:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 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, T_KAM_HTML_FONT_INVALID=0.01] 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 FQRfZMkHVzJX for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 08:30:39 -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 8261012D6F5 for <dime@ietf.org>; Wed, 16 Mar 2016 08:30:15 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 724FCF5087A24; Wed, 16 Mar 2016 15:30:11 +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 u2GFUDMv008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 15:30:13 GMT
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 u2GFTgpK023650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Mar 2016 16:30:10 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.143]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 16 Mar 2016 16:29:29 +0100
From: "Trottin, Jean-Jacques (Nokia - FR)" <jean-jacques.trottin@nokia.com>
To: EXT 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: AQHRf5a4769y+DUcMEaZx/lJ0UYXLJ9cManA
Date: Wed, 16 Mar 2016 15:29:28 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D29D4D1881@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> <E194C2E18676714DACA9C3A2516265D29D4D011C@FR712WXCHMBA12.zeu.alcatel-lucent.com> <56E9789A.1090904@usdonovans.com>
In-Reply-To: <56E9789A.1090904@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_E194C2E18676714DACA9C3A2516265D29D4D1881FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/0t-iXtFSGNVXXEibkrpScsZvFSs>
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 15:30:44 -0000

Hi Steve

Yes the Editor’s note  is about receiving overload and load reports from the same node. I  am OK with your new writing.

Best regards

JJacques

De : EXT Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoyé : mercredi 16 mars 2016 16:16
À : Trottin, Jean-Jacques (Nokia - FR); dime@ietf.org
Objet : Re: [Dime] Diameter Load Editor's note on presence of overload report

JJacques,

I had already come up with the following wording to replace the editor's note:

        It should be noted that a Diameter node will need to process both Load reports and Overload
        reports from the same Diameter node.   The reacting node for the Overload
        report always has the responsibility to reduce the amount of Diameter traffic sent to the
        overloaded node.  If, or how, the reacting node uses Load information to achieve this is
        left as an implementation decision.

I think this does a better job of addressing the editor's note, which is about receiving overload and load reports from the same node.  I also think that the second sentence of your proposal is not needed, as this is normal use of load information, independent of whether there is an active overload report.

Regards,

Steve
On 3/14/16 9:41 AM, Trottin, Jean-Jacques (Nokia - FR) wrote:
Hi Steve
About this Editor’s Note



      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 . Possible herafter writing (with suppression of the Editor’s note) :



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.


Best regards
JJacques