[Dime] Proposed resolutions of LOAD discussion

Steve Donovan <srdonovan@usdonovans.com> Tue, 16 August 2016 14:50 UTC

Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7600312D87E for <dime@ietfa.amsl.com>; Tue, 16 Aug 2016 07:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o_peFCjV5jY6 for <dime@ietfa.amsl.com>; Tue, 16 Aug 2016 07:50:25 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com []) (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 5CEA412D7E9 for <dime@ietf.org>; Tue, 16 Aug 2016 07:50:25 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([]:63306 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 1bZfh9-003Dm8-W4 for dime@ietf.org; Tue, 16 Aug 2016 07:50:24 -0700
From: Steve Donovan <srdonovan@usdonovans.com>
To: "dime@ietf.org" <dime@ietf.org>
Message-ID: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com>
Date: Tue, 16 Aug 2016 09:50:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
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: <https://mailarchive.ietf.org/arch/msg/dime/_17Dp8Mb-dfsFcMIZgjwY7lyWwA>
Subject: [Dime] Proposed resolutions of LOAD discussion
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: Tue, 16 Aug 2016 14:50:26 -0000


I have outlined proposed solutions for the issues raised in the 
discussion around the Diameter Load draft.

Please let me know if I've missed anything from the discussion.



Primary Issues:

1) Use of DNS SRV weighted value as format for LOAD value.

This was discussed and agreed to early in the process.  It has the 
advantage that Diameter nodes can use a combination of values received 
via the DNS SRV interface and dynamic values received through the 
Diameter LOAD interface.  While I agree that it isn't as intuitive as a 
straight percentage value, I don't see this as compelling enough of a 
reason to change a decision the working group has already made.

2) Need to add wording that the calculated LOAD value needs to be based 
on overall available capacity.

I agree with Maria Cruz's comment that we need to add wording indicating 
that the calculated LOAD value needs to reflect available capacity.  To 
this end, I propose adding the following to section 6.1 (this is based 
on wording proposed by Maria Cruz):

The calculated LOAD value MUST reflect the Diameter nodes capacity 
relative to the total available capacity across the Diameter nodes to 
which requests can be routed.  This could be either a set of Diameter 
endpoints or a set of Diameter agents, depending on the type of the LOAD 
report.  The method for determining the total available capacity is 
outside of the scope of this document.

    Note: The LOAD value should be calculated in a way that reflects the 
available load independently of the weight of each
    server.  This allows the Diameter node that routes a request, 
including nodes doing server selection and agents routing
    requests, to accurately compare values from different nodes.  Any 
specific LOAD value needs to identify  the same
    amount of available capacity, regardless the Diameter node that 
calculates the value.

The mechanism used to calculate the LOAD value that fulfills this 
requirement is an implementation decision.

3) Wording in Appendix A.

Before we reword Appendix A, we need to decide if it is still needed.  
It was valuable in helping to generate the solution but I'm not 
convinced it is still needed in the document.  Is there objection to 
removing this section?