Re: [Dime] Proposed resolutions of LOAD discussion

<> Mon, 19 September 2016 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C37C12B006 for <>; Mon, 19 Sep 2016 15:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.916
X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yi7wgasmr5Mu for <>; Mon, 19 Sep 2016 15:07:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1070712B562 for <>; Mon, 19 Sep 2016 15:07:14 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) by (ESMTP service) with ESMTP id 841252021F; Tue, 20 Sep 2016 00:07:12 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by (ESMTP service) with ESMTP id 46C171A005D; Tue, 20 Sep 2016 00:07:12 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0301.000; Tue, 20 Sep 2016 00:07:12 +0200
From: <>
To: Steve Donovan <>, "" <>
Thread-Topic: [Dime] Proposed resolutions of LOAD discussion
Thread-Index: AQHR982JsHJ6KECqOEaXB6jDMNvt0KCBkwsQ
Date: Mon, 19 Sep 2016 22:07:11 +0000
Message-ID: <17142_1474322832_57E06190_17142_11002_1_6B7134B31289DC4FAF731D844122B36E01FBA733@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Dime] Proposed resolutions of LOAD discussion
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Sep 2016 22:07:42 -0000

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

[LM] ok to keep DNS SRV weighted value type.

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

[LM] see other email.

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

[LM] if it is only for information, we can just remove them. If someone identifies important aspects that need to be kept, it would mean that the body is not self-consistent. If we keep it, we will have to ensure that the content is correct, even if informative, as the appendix is reviewed during IETF LC as any other part of the document and it would be painful to trigger useless discussions on a pure informative part.
> _______________________________________________
> DiME mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.