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

["Trottin, Jean-Jacques (Nokia - FR)" <[e-mail]>]

Hi MCruz 

I continued to  investigate your inputs;  I am sorry but I still have issues with your analysis and proposal.

We have to be careful on the definitions to put in the draft. In the current v2 draft we have:
- a definition in section 2 indicating the "relative capacity" of a node. 
- the Load-Value AVP (section 7.3) conveying "relative load information" with a 0-65535 value range, value O corresponding to a fully loaded node and 65535 to a node having no load 

Dynamic Load (say DL) that you defined in % (100% is totally loaded) for easier calculations in a previous mail is equivalent to the above defined load although some difference in their value definition so in line with the current draft.

Then, you want to consider servers with different capacities (and I agree that the Load control mechanism covers this case); so you proposed to introduce a "LOAD value that identifies the same amount of available capacity regardless the server that has calculate it ". For this you introduced the RDL = DL/ Weight with the intent to have  a load per "resource unit", but this RDL is not for me rightly defined and does not work (as shown in my previous mail) given that if a server comprising several resource units having a  global DL of 40% , this means that each resource units in average also has a 40% load.  I do not think you can divide a DL by a weight.
So I do not yet identify how you evaluate this new Load value. It is important that the server sending this info and the traffic sender give the same meaning to this new Load value.  You need to do some proposals/ examples on this calculation, and how you fulfill the load balancing objective.
 
So I still remain on the current Load definition of the V2 draft and weights (eg obtained by DNS), allowing each sender to evolve its traffic distribution towards a load balancing objective. I even described two possible objectives in a previous mail for the sender (according to operator policy):
- one ensuring each server to have the same proportion of available capacity compared to its size (in fact to converge to the same DL).
- one ensuring each server to have the same available capacity independently of its size (your use case).

To note that when the overall traffic increases, the two above objectives will consume the capacities of all servers before entering in overload, which can also be an objective of the Load Control mechanism.

Best regards

JJacques 


-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de Maria Cruz Bartolome
Envoyé : jeudi 14 juillet 2016 10:45
À : Trottin, Jean-Jacques (Nokia - FR); [e-mail]
Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello JJacques,

Thanks for your analysis. 
I checked this through and I agree the proposal I made of a possible RDL calculation may not be providing the selection of the least loaded server in all cases, the examples you made are very good to understand that.
However, the concern behind keeps being perfectly valid, I think we need to provide not the DL as such, but a value that takes into account the different servers' weights, in order to be able to compare the amount of free resources, that is, the capability of different servers to deal with traffic.
In case we have servers with different weights (what is the most common scenario),  both may be 50% loaded (DL), and this value is not useful for the client to be able to perform load balancing. If a server has 4 times more resources than the other, obviously that server has more free resources and it will be able to deal with more traffic. Therefore,  my concern is that DL does not provide enough information for the client to be able to perform load balancing, that is the ultimate expectation of this mechanism. We need a "relative" DL, taking into account servers' weights.

Then, I would say that my proposal below keeps being valid.
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 agree 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 accurately compare values from different servers, i.e. LOAD value identifies the same amount of available capacity, regardless the server that has calculate it. "
	
Let me know if you could agree with these conclusions, or if you have a different view.
Thanks
/MCruz


-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Trottin, Jean-Jacques (Nokia - FR)
Sent: miércoles, 13 de julio de 2016 16:34
To: [e-mail]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hi MCruz, all,

Thanks for your feedback. 
I still have some understanding issues

See comments <JJ3> to your last reflections.

Best regards
JJacques

-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de Maria Cruz Bartolome Envoyé : jeudi 7 juillet 2016 11:10 À : Trottin, Jean-Jacques (Nokia - FR); [e-mail] Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

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.

<JJ3> I analysed your above new example which raises same questioning from my side:
By applying the factor 10000 for simplification we have 
Server1 weight  6 so I can say that Server1  has a capacity of 6 resource units   
Server2 weight  3 so a capacity of 3 resource units.
Server1 load (DL)= 90% so Server 1 consumed resource units= 6x90% = 5,4
Server2 load (DL)= 45% so Server 2 consumed resource units= 3x45% = 1,65 Then
Server1 remaining (available)  resources= 6-5,4 = 0,6
Server2 remaining (available)  resources= 3-1,35 = 1,65 

So in my understanding server2 (the smaller server) has still more available capacity than server 1, so I would conclude to transfer some traffic from server 1 to server 2;  But you said that both servers are equally loadedas having the same RDL=15, and concluded the system being well balanced, which I do not agree

You also mention that we should have the "same load per resource unit", which also raises questioning from me:
If Server1 has a load of 90% for its 6 resource units, this also means that each resource unit has a load of 90%. 
I have difficulty to understand the definition of RDL = DL/Weight So I think we are not yet well aligned on a common understanding of the example, so thanks if you can give still some more explanation.

I continued the same exercise but with my assumptions
a) objective (according to my previous mail) is that the two servers have the same load, this drives to DL=75% with
Server1 load (DL)= 75% so Server 1 consumed resource units= 75% = 4,5
Server2 load (DL)= 75% so Server 2 consumed resource units= 3x75% = 2,25 Then
Server1 remaining resources= 6-4,5 = 1,75
Server2 remaining resources= 3-2,25 = 0,75 but the % of remaining resources compare to its capacity is the same for each server

b) another possible objective is that the two servers have the same remaining (available) resource, , this drives to
Server1 load (DL)= 81,3% so Server 1 consumed resource units= 6x81,3% = 4,88
Server2 load (DL)= 62,4% so Server 2 consumed resource units= 3x62,4% = 1,87	
Then
Server1 remaining resources= 6-4,88 = 1,12
Server2 remaining resources= 3-1,87 = 1,13 so same remaining resources

Is this b) case relating more to your concern? The "least loaded" node would be the one having the highest remaining capacity, so with traffic transfer to this node until both nodes have the same remaining capacity

Other type of load balancing objectives may be considered, but load balancing  objectives are for me operator dependent and implementation specific.

Then to come back to weights:
- case a), as I said, according to received load from servers senders, a sender can adjust the traffic to converge to the same/nearly same load among servers. The fact to know server weights would improve the convergence to this objective
- Case b) needs to have knowledge on the server weights as this is needed to evaluate the remaining resources objectives

As indicated, server weights can be configured (eg for DAs in front of servers) or obtained from a DNS query (as Steve mentioned), or through other means that are out of the scope.

I would like we share the same understanding before finalizing a normative text <JJ3/>

Best regards

JJacques    


_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime