Re: [Dime] Diameter Load value and SRV

[Steve Donovan <[e-mail]>]

JJacques,

All great comments.  I will reflect this in the updated draft.

Regards,

Steve

On 3/14/16 7:53 AM, Trottin, Jean-Jacques (Nokia - FR) wrote:
>
> Hi Steve
>
> Aligning the load value with DNS SRV, (so a low value of the AVP 
> meaning a node closer to be fully utilized)   would also impact the 
> wording of the Load definition in section 2 (Terminology) where
>
> Load
>
> The relative capacity of a Diameter node.  A low value indicates
>
> that the Diameter node is under utilized.  A high value indicated
>
> that the node is closer to being fully utilized.
>
> We have to pay attention to the wording, especially about the word 
> “value”
>
> In the terminology, intent is more to say
>
>       The relative capacity of a Diameter node.  A low “load level” 
> indicates
>
> that the Diameter node is under utilized.  A high “load level” indicates
>
> that the node is closer to being fully utilized
>
> So I would propose  to not use the word “value” in the terminology, 
> but e.g. “level”,  and reserve the word “value” for the AVP
>
> It is also consistent with the use of the “load” word in other places
>
> - definition of Offered load also in section 2 which is high when the 
> traffic is high.
>
> - in section 4.1, where “At any given time that load maybe effectively 
> zero, effectively fully loaded, or somewhere in between”
>
> Then how the value of the Load AVP is encoded where a low value of the 
> AVP  will mean “heavily loaded” is defined in a further section as 
> written in your mail:
>
> As a result, a higher Diameter load value would indicate a LOWER load 
> on the sending node.  A node that is heavily loaded would send a lower 
> load value.
>
> Best regards
>
> JJacques
>
> *De :*DiME [mailto:[e-mail]] *De la part de* 
> [e-mail]
> *Envoyé :* vendredi 11 mars 2016 17:09
> *À :* Steve Donovan; [e-mail]
> *Objet :* Re: [Dime] Diameter Load value and SRV
>
> Hi Steve,
>
> I'm fine with this approach.
>
> Thank you.
>
> regards,
>
> Lionel
>
> *De :*DiME [mailto:[e-mail]] *De la part de* Steve Donovan
> *Envoyé :* vendredi 11 mars 2016 01:13
> *À :* [e-mail] <mailto:[e-mail]>
> *Objet :* [Dime] Diameter Load value and SRV
>
> All,
>
> The current version of the Diameter Load draft says that the load 
> value should be consistent with the use of DNS SRV.  It then has an 
> editor's note indicating that we need more detail.
>
> The following is my proposal for that additional detail.
>
> The relevant section from RFC 2782 (DNS SRV) is the description of the 
> Priority and Weight parameters in the SRV RR copied below.  It is 
> mostly based on the Weight section but I included Priority because it 
> is referenced in the Weight section.
>
> My proposal is that the Load value communicated in a Diameter Load 
> report be used to dynamically update the Weight value for an entries 
> in the Routing table and in the Peer table.  Note that the load 
> mechanism does not give a way to change the priority value.  That 
> would still either come as a result of a DNS SRV query or through 
> statically configuring a Diameter node.
>
> If this is the case, then the load value would be in the range of 
> 0-65535.
>
> The distribution algorithm below results in more messages being sent 
> to a node with a higher weight value.  As a result, a higher Diameter 
> load value would indicate a LOWER load on the sending node.  A node 
> that is heavily loaded would send a lower load value.  Stated another 
> way, a node that has zero load would have a load value of 65535.  A 
> node that is 100% loaded would have a load value of 0.
>
> The algorithm below would be a suggestion for how Diameter nodes would 
> use the load information but the actual method for using the load 
> information would be an implementation decision.
>
> The algorithm would be used in two places.  First, Diameter nodes 
> doing the server selection would use the load information to select 
> from a set of candidate servers for a request.  It would also be used 
> for selecting the next hop from a set of candidate peer nodes.
>
> If there is consensus on this general approach then I will add the 
> appropriate overview and normative requirements in the next version of 
> the Load draft.  I am planning to submit that draft prior to the IETF 
> 95 deadline.
>
> Regards,
>
> Steve
>
> -----
>
>    Priority
>         The priority of this target host.  A client MUST attempt to
>         contact the target host with the lowest-numbered priority it can
>         reach; target hosts with the same priority SHOULD be tried in an
>         order defined by the weight field.  The range is 0-65535.  This
>         is a 16 bit unsigned integer in network byte order.
>    Weight
>         A server selection mechanism.  The weight field specifies a
>         relative weight for entries with the same priority. Larger
>         weights SHOULD be given a proportionately higher probability of
>         being selected. The range of this number is 0-65535.  This is a
>         16 bit unsigned integer in network byte order.  Domain
>         administrators SHOULD use Weight 0 when there isn't any server
>         selection to do, to make the RR easier to read for humans (less
>         noisy).  In the presence of records containing weights greater
>         than 0, records with weight 0 should have a very small chance of
>         being selected.
>         In the absence of a protocol whose specification calls for the
>         use of other weighting information, a client arranges the SRV
>         RRs of the same Priority in the order in which target hosts,
>         specified by the SRV RRs, will be contacted. The following
>         algorithm SHOULD be used to order the SRV RRs of the same
>         priority:
>         To select a target to be contacted next, arrange all SRV RRs
>         (that have not been ordered yet) in any order, except that all
>         those with weight 0 are placed at the beginning of the list.
>         Compute the sum of the weights of those RRs, and with each RR
>         associate the running sum in the selected order. Then choose a
>         uniform random number between 0 and the sum computed
>         (inclusive), and select the RR whose running sum value is the
>         first in the selected order which is greater than or equal to
>         the random number selected. The target host specified in the
>         selected SRV RR is the next one to be contacted by the client.
>         Remove this SRV RR from the set of the unordered SRV RRs and
>         apply the described algorithm to the unordered SRV RRs to select
>         the next target host.  Continue the ordering process until there
>         are no unordered SRV RRs.  This process is repeated for each
>         Priority.
>
> _________________________________________________________________________________________________________________________
> 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.