Re: [Dime] Diameter Load Editor's note on presence of overload report

Steve Donovan <srdonovan@usdonovans.com> Wed, 16 March 2016 15:16 UTC

Return-Path: <srdonovan@usdonovans.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 1B2CE12D9AC for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 08:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 DgPtNADZjKoh for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 08:16:57 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 3031712D9F7 for <dime@ietf.org>; Wed, 16 Mar 2016 08:15:42 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:53889 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1agDAh-002CkY-RS; Wed, 16 Mar 2016 08:15:41 -0700
To: "Trottin, Jean-Jacques (Nokia - FR)" <jean-jacques.trottin@nokia.com>, "dime@ietf.org" <dime@ietf.org>
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>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <56E9789A.1090904@usdonovans.com>
Date: Wed, 16 Mar 2016 10:15:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <E194C2E18676714DACA9C3A2516265D29D4D011C@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------080904040105070605060705"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/xP7fTE41Mg3LVg_CFnN9Tou0TVI>
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:16:58 -0000

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 misleadingas 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
>