Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

[Maria Cruz Bartolome <[e-mail]>]

Hello JJacques, all,

See comments only to your last reflections.
Best regards
/MCruz


====== from previous emails (begin) =================================
> 5.
> Now
>     The goal is make it possible to use both the load values received as
>      a part of the Diameter Load mechanism and weight values received as a
>      result of a DNS SRV query.  As a result, the Diameter load value has
>      a range of 0-65535.  This value and DNS SRV weight values are then
>      used in a distribution algorithm similar to that specified in
>      [RFC2782].
>
> Comments:
> In order to have an efficient load balancing algorithm, it is not enough for the reacting node (for the node in charge of load balancing) to know the Load of each server, but it needs to know the load in relation to each server capacity. Unless we do so, the Load value of a server can't be compared with the Load of a Server with a different weight.
> Then, in my opinion, we need to find a way to provide a Load value that is in fact comparable with the rest of the Load values of the servers in the group.
> Reflecting a bit longer on this, I think we need then to define a group of servers in the load-balancing group, like a load-balancing context, and then, for all servers in such a group we need to provide a relative value of dynamic Load.
>
> <JPG> Agree with the thought- if "Little Server" is 30% utilized and 
> "Big Server" is 50% utilized, it still makes sense to send more 
> traffic to Big Server.  But I am not sure if that is withn the scope 
> of this document. </JPG>
> SRD> I don't understand the concern.  The load values supplied will be
> input into the route selection algorithm as specified in RFC2782.  If 
> a node isn't getting enough traffic it will change its load value to a 
> lower value and will start getting more traffic.
> MCRUZ> Unless the LOAD info provided is in fact a value that represents the available capacity, then the load balancing will not select the less loaded server. Being able to select the less loaded server is the whole purpose of this mechanism, then we need to find a way to provide a LOAD value from different servers that we are able to compare, i.e. the value provide must indicate the available capacity regardless the static capacity of each server.
SRD> I view the goal of this a little differently.  The goal is to make
sure that requests are delivered to nodes with available capacity.  It is not strictly necessary that every request goes to the least loaded node.
MCRUZ> Well, I do not agree. The whole purpose of providing LOAD info is to be able to choose a node with available  load (I agree), but among the node with available load we need to choose the least loaded (or one of the least loaded). It does not make sense, in my opinion, to simply select a node with available load, when we are providing info about load. The information provided should be valid to be able to select the least (or close to) loaded.


> Providing an example, let me use dynamic Load (say DL) in % (100% is totally loaded) that I found it easier for calculation:
> - Server1: weight=1500; DL= 2%
> - Server2: weight=55000; DL= 70%
> Then, if we only use DL in the LB algorithm, obviously Server 1 seems to be clearly less loaded, but however, taking into account its weight is much smaller it may be the other way around. In fact, if traffic is redirected to this server, it may get overloaded rapidly (due to its small capacity).
> One possible way to calculate the relative DL is  to divide it by the weight, then for this example:
> - Server1 RDL= 10000 * (2/1500) = 13.33
> - Server2 RDL= 10000 * (70/55000) = 12.73 (I multiplied by 10000 
> simply to get rid of the decimals for our discussion).
> Then, we actually find out that available load for both servers is pretty similar. In fact, in this case, a correct load balancing should select Server2 as the less loaded server instead of server1.
> My proposal is to consider this reflection in the draft, and then make a clear distinction between dynamic load (DL) and RELATIVE DL. We need to provide the RDL in the message, not DL.
SRD> This is about how the load value is calculated which is explicitly
stated as being an implementation decision.
MCRUZ> Not exactly. We need to reflect in the draft that the LOAD provided should be the relative available load, taking into account the static weight. This is the only way we are providing a load value that can possibly be used by a client to LOAD-balance. 
I could accept that we leave the way to do so up to implementations.
Proposal: "LOAD should be calculated in a way that reflects the available load independently of the weight of each server, in order to allow the Diameter node that performs server selection to accurateraly compare values from different servers, i.e. LOAD value identifies the same amount of available capacity, regardless the server that has calculate it. "

JJ2> I analysed a bit more your example with Server1 RDL= 10000 * 
JJ2> (2/1500) = 13.33 and Server2 RDL= 10000 * (70/55000) = 12.73 with 
JJ2> the conclusion to select server2. This is a bit surprising as 
JJ2> server 1 is only 2% loaded. This example is rather specific with a 
JJ2> server 1 weight being 2,7% of server 2 weight. I did another 
JJ2> example with less difference in the weights
- Server1: weight=30000; DL= 30%
- Server2: weight=60000; DL= 50%
This drives to
Server1 RDL= 10000 * (30/30000) = 10,0
Server2 RDL= 10000 * (50/60000) = 8,3	 
Here also, if I follow your reasoning, this would drive to select server 2 to increase its RDL. Again the result is to increase server2 load

Even by taking a 80% load for server 2 (so a high load in practice) and 50% for server 1
Server1 RDL= 10000 * (50/30000) = 16,7
Server2 RDL= 10000 * (80/60000) = 13,3
This still drives to select server 2, although the reasoning would be to increase server 1 load Nevertheless, if server 1 has only 30% load  its RDL becomes 10 and it will be selected, so here OK  

Please  check if I am wrong somewhere, but currently RDL, for me, can give strange outputs.

About static weight I agree that static weight can be useful, e.g. a last hop DA can be configured with  the server weight to distribute its traffic among the servers it is connected to.    

My point is about the targeted load balance between the servers. Often, the objective is to have the same load among servers (even if they have some difference in their capacity / weight), which is the way to maximize the traffic without entering overload in any server. So the "DL" (as defined in the current draft) indicates whether they have the same load, and if the objective is achieved. For me I do not well see how you define the targeted load among servers with the RDL you mentioned.

 If received load from servers is not the same, the sending node has to send a bit more traffic to the less loaded node. For this, as you said, an objective is to avoid oscillations, and sending node has to evaluate the amount of traffic it will switch from the more loaded server to the less loaded server, this switched traffic being not too high to avoid oscillations and also not too low to avoid maintaining unbalanced situation. In the draft, it is left to implementation on the sending node on how to modify the current traffic distribution among the servers according to the received load (DL), and I am OK on this. In my previous mail  I indicated that the sending node will adjust its traffic distribution according to the updated load (DL) received from server and converge to the balanced situation, in this process, I agree that the weight attached to each server can be an additional useful input when available, but keeping the current load (DL) definition <JJ2>
====== from previous emails (end) ==========================

About the examples you discussed above. 
I think the results you got are valid. Take into account that the static weight identifies the server capability, then a server1 with weight:60000 has double resources than a server2 with 30000. Then, server2 45% load is making usage of double of resources than server1 90% load.
DL/Weight provides a value than indicates the load per "resource unit". Then, the least loaded server is the one that has less load per "resource unit".
This can be seen in the following example:
Server1 RDL= 10000 * (45/30000) = 15
Server2 RDL= 10000 * (90/60000) = 15
Both servers are equally loaded, as long as the Big Server (Server2) is loaded double as the Small Server (Server1), that is half size in resources than Big Server.

Then, JJacques, I think we agree the Diameter node that is responsible for server selection should have the means to select the least loaded server, and the available load depends on the capacity of each node, not only on the DL that is identified at a moment in time.
Then, I think we need to include some normative text on that, although the specific means to achieve so could remain implementation specific. Proposed text is:
"LOAD should be calculated in a way that reflects the available load independently of the weight of each server, in order to allow the Diameter node that performs server selection to accurately compare values from different servers, i.e. LOAD value identifies the same amount of available capacity, regardless the server that has calculate it.  The means to calculate the LOAD value that fulfils this requirement are implementation specific."
I think, as Steve agreed, that the example could be included in the draft as well, it is very useful to understand how the static weight determines the available load.