Re: [Dime] Proposed resolutions of LOAD discussion

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Mon, 19 September 2016 18:45 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 97F0212B4DC for <dime@ietfa.amsl.com>; Mon, 19 Sep 2016 11:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pgoV3OU8jDrV for <dime@ietfa.amsl.com>; Mon, 19 Sep 2016 11:45:14 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 CBF6112B13B for <dime@ietf.org>; Mon, 19 Sep 2016 11:45:13 -0700 (PDT)
X-AuditID: c1b4fb30-b73ff70000000cb2-cf-57e03237a015
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id CE.F4.03250.73230E75; Mon, 19 Sep 2016 20:45:12 +0200 (CEST)
Received: from ESESSMB101.ericsson.se ([169.254.1.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Mon, 19 Sep 2016 20:45:07 +0200
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Proposed resolutions of LOAD discussion
Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgIAbDa6AgAAihBD///dngIAAIdpg
Date: Mon, 19 Sep 2016 18:45:06 +0000
Message-ID: <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se>
References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com>
In-Reply-To: <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7tK6F0YNwg72v+Czm9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Mnqf/WIu2Ohe8WLKWrYGxnbLLkZODgkBE4nD k+YwdTFycQgJrGeUeHr3KwuEs4RR4mPbYTaQKjYBO4lLp18wgdgiAr4SxztPs4DYwgLWEtv3 7maGiNtIfPixAaomSqJn9kqwXhYBVYlHyw+B2bxAvQ/mbYRasJVZoqnzLliCU8BJYsm/dWA2 o4CYxPdTa8AGMQuIS9x6Mp8J4lQBiSV7zjND2KISLx//Y4WwlSR+bLjEAlGvI7Fg9yc2CFtb YtnC18wQiwUlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiBEXFwy2+DHYwvnzseYhTgYFTi4U14fz9ciDWxrLgy9xCjBAezkgjvOd0H4UK8KYmV ValF+fFFpTmpxYcYpTlYlMR5zVYCVQukJ5akZqemFqQWwWSZODilGhg1Fs+J8uuaJji3YU/A DpWjM5yDrgdfO5NmIh1zp1LUUpuVTfdSnK1aYnjkvBvtW32jjDtvHJ7ieM/9mY6yXLPweav5 21QS2OTestW4sxs8WvFZQGvBC6NwoY9eFW8ez72a7qYxqz0sZLLqxc2X4jQYjwvoLgpdv8iX Y/GmQ3mbt5sWfjVfoarEUpyRaKjFXFScCADzJs9OhAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/8RH6BYr1m0I5ayc4DSPwo2BVP5A>
Subject: Re: [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: Mon, 19 Sep 2016 18:45:17 -0000

Hello Steve,

See proposal:

"The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum capacity for a Diameter node in the group of nodes the messages are load balanced".

I removed "available" because it may be misinterpreted as "available at a moment in time", what is not right, it is just the maximum capacity it is offered, it can be reached.
"for a Diameter node": in order to indicate that it is the maximum capacity of "any" of the Diameter nodes, what a Diameter node is normally offering. 
But we can limit that to the group of nodes that are receivers of messages, i.e. the load-balancing group.

Does it make sense to you?
Thanks Steve

-----Original Message-----
From: Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: lunes, 19 de septiembre de 2016 20:35
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] Proposed resolutions of LOAD discussion

Actually, looking at it again, I think the following wording is needed:

"The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the set of Diameter nodes that are potential receiving nodes for the future messages covered by the LOAD report."

We probably need some words on what the set of Diameter nodes comprises, as it is different for HOST reports and PEER reports.

Does this work?

Steve

On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote:
> Hello Steve,
>
> Thanks for the clarification
> I still think the last part of the sentence is misleading: "... relative to the maximum available capacity for the reporting Diameter node ".
>
> It should be "... relative to the maximum available capacity for a reporting Diameter node".
>
> The reasoning is that it should be relative to the maximum capacity not of that particular reporting node, but any of the nodes. That is, if we use SRV to provide the load value, the maximum load is 65535, but a particular node may just have a maximum capacity of e.g. 4000. Then the load value of this reporting node should be relative not to 4000 but to 65535, and it should be done the same for all nodes, in a way that the load is then comparable by the reacting node.
> Is my point clearer now?
> The NOTE you wrote clarified that point in fact.
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: lunes, 19 de septiembre de 2016 19:02
> To: Maria Cruz Bartolome; dime@ietf.org
> Subject: Re: [Dime] Proposed resolutions of LOAD discussion
>
> Maria Cruz,
>
> I think we are saying the same thing.  My original has an unfortunate typo and should have read as follows:
>
> "The calculated LOAD value MUST reflect the sending Diameter node's capacity relative to the maximum available capacity for the sending Diameter node."
>
> In thinking about this, the word sending might also not be clear enough.  We might want to use the reporting node instead.  This would change it to the following:
>
> "The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the reporting Diameter node."
>
> Regards,
>
> Steve
>
> On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote:
>> Hello Steve,
>>
>> Thanks for the proposal.
>> I still think the text is a bit misleading:
>>
>> "The calculated LOAD value MUST reflect the sending Diameter nodes 
>> capacity relative to the maximum available capacity for the sending 
>> Diameter node."
>>
>> I think it should be:
>> "The calculated LOAD value MUST reflect the sending Diameter node 
>> capacity relative to the maximum available capacity for a sending 
>> Diameter node."
>>
>> Reasoning: a node may have a very limited maximum capacity, but the key point is precisely to provide a LOAD value relative to the maximum value A node may have.
>>
>> I hope this clarifies
>> Thanks
>> /MCruz
>>
>> -----Original Message-----
>> From: Steve Donovan [mailto:srdonovan@usdonovans.com]
>> Sent: martes, 30 de agosto de 2016 5:59
>> To: Maria Cruz Bartolome; dime@ietf.org
>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion
>>
>> Maria Cruz,
>>
>> Thanks for your comments.  See my replies inline.
>>
>> Regards,
>>
>> Steve
>>
>> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote:
>>> Hello Steve,
>>>
>>> Thanks for the proposals, see below
>>> Best regards
>>> /MCruz
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>>> Sent: martes, 16 de agosto de 2016 16:50
>>> To: dime@ietf.org
>>> Subject: [Dime] Proposed resolutions of LOAD discussion
>>>
>>> All,
>>>
>>> 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.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> 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.
>>> [MCruz] I still think using SRV values is error prone and anti-intuitive, but I can live with this if you really think it is not possible to re-evaluate this now.
>> SRD> I haven't seen any argument that using the SRV values doesn't
>> work.  As such, I prefer to not change this at this stage of the process.
>>> 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.
>>>
>>>
>>> [MCruz] Some comments to proposed text:
>>> " 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. ": I think it may be misleading what is the "total available capacity across nodes".
>>> See proposal:
>>> " The calculated LOAD value MUST reflect each Diameter node capacity relative to the maximum available capacity for a Diameter node to which requests can be routed."
>> SRD> This wording could imply that the LOAD value carries load
>> information for multiple Diameter nodes.  How about the following:
>>
>> "The calculated LOAD value MUST reflect the sending Diameter nodes 
>> capacity relative to the maximum available capacity for the sending 
>> Diameter node."
>>
>>> 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?
>>>
>>> [MCruz] I prefer this to remain, it provides some hints that may be valuable for first time readers.
>> SRD> I'd like to hear other opinions on this as there is work 
>> SRD> required
>> to make the section consistent with the mechanism defined.
>> Implementors will still have access to this information by reviewing 
>> the history of the process of writing the specification.
>>
>> SRD> Are there schedule pressures in 3GPP to get this to RFC state?
>> SRD> If
>> so, it will be faster to just remove this section.
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime