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

From: "Trottin, Jean-Jacques (Nokia - FR)" <[email-masked]>
Date: Tue, 5 Jul 2016 09:34:11 +0000

Hi MCruz

I analysed your proposal about RDL and please see my JJ2> comment below your last comments in 5.

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : jeudi 30 juin 2016 14:50
À : Trottin, Jean-Jacques (Nokia - FR); Steve Donovan; [email-masked]
Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello JJ,

Nice to listening from you again.
See comments below
/MCruz

-----Original Message-----
From: Trottin, Jean-Jacques (Nokia - FR) [mailto:[email-masked]]
Sent: jueves, 30 de junio de 2016 13:00
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]
Cc: Uveges, Balint (Nokia - HU/Budapest); Wiehe, Ulrich (Nokia - DE/Munich)
Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-load-02

Dear all
 
About discussion regarding draft-ietf-dime-load-02, I was in line with the new 02 version Steve distributed some time ago. I here reviewed Maria Cruz comments and Steve's reactions.
 
Globally I remain in line with the Steve's hereafter comments. My main comment is on .5 about server capacity. The other updates have for me no protocol impact and were mainly wording enhancements  and  are worthwhile for me .
Please see my few comments in line (with JJ>). Main one is in 5. about the capacity topic
 
I would also take this opportunity to indicate that due to my job evolution, my colleague Balint Uveges will follow the load/overload dime aspects in IETF.

Best regards
 
JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : mercredi 29 juin 2016 19:19 À : Steve Donovan; [email-masked] Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello Steve,
Thanks for the responses, see some more comments below Best regards /MCruz

On 6/27/16 2:18 AM, Maria Cruz Bartolome wrote:
>
>> 4.1
>> Now:
>>      None of this prevents a Diameter node from deciding to reduce the
>>      offered load based on load information.   .
>>
>> Proposed
>>     (remove)
>>
>> Reasoning:
>> This sentence is not properly linked to previous paragraph and it is 
>> covered by previous paragraph already
>>
>> <JPG> OK with this, though not sure it is necessary to delete.</JPG>
> SRD> This sentence adds emphasis to the point that a similar result 
> SRD> can
> happen between load and overload, leading into the next sentence outlining the fundamental difference between the two.  I don't see the harm in leaving it, even if what is says is implied by the previous paragraph.
> MCRUZ> My problem with the sentence is that it is not straight forward to what refers "none of this". The reader will look above to check what it refers to... and it seems to be the whole paragraph, i.e. the differences between load and overload. But this sentence refers again to something that is mentioned above. Then, I think the sentence, as it is, is misleading that turns reading a bit unease.
SRD> How about: "A Diameter node can, however, decide to reduce offered
load based on load information."
MCRUZ> Fine

>> 5.
>> Now
>>      The second big difference between DOIC and Load is visibility of the
>>      DOIC or Load information within a Diameter network.  DOIC information
>>      is sent end-to-end resulting in the ability of all nodes in the path
>>      of the answer message that carries the OC-OLR AVP to act on the
>>      information.  The DOIC overload reports much remain in the message
>>      all the way from the reporting node to the node that is the target
>>      for the answer message.
>>
>>      For the Load mechanism there are two types of load reports.
>>
>>      The first is the load of the endpoint sending the answer message.
>>      This load report is carried end-to-end to enable any nodes that make
>>      server selection decisions to use the load status of the sending
>>      endpoint as part of  the server selection decision.
>>
>>      The second type of load report is a peer report.  This report is used
>>      by Diameter nodes as part of the logic to select the next hop
>>      Diameter node and, as such, do not have significance beyond the peer
>>      node.  These load reports are removed by the first supporting
>>      Diameter node to receive the report.
>>
>> Proposed:
>>      The second big difference between DOIC and Load is visibility of the
>>      DOIC or Load information within a Diameter network.  DOIC information
>>      is sent end-to-end resulting in the ability of all nodes in the path
>>      of the answer message that carries the OC-OLR AVP to act on the
>>      information, *although only one node can actually consume the report*.  The DOIC overload reports much remain in the message
>>      all the way from the reporting node to the node that is the target
>>      for the answer message.
> SRD> How about "although only one node actually reacts to the report",
> changing consume to react.
> MCRUZ> I think "consume" is better since it implies that from then on the report is removed.
SRD> How about consume and react?  "although only one node actually
consumes and reacts to the report"
MCRUZ> Fine
JJ> this would be the only place (here and I also think in DOIC RFC) where "consume" word is used and raising the question what "consume" means, in particular this does not imply to remove the report. "react" was OK for me but no opposition to "consume and react".  

>
>>      *However,* for the Load mechanism there are two types of load reports *and only the
>>       first one is transmitted end-to-end*.
> SRD> This is covered in the following paragraphs.
> MCRUZ> Yes, but I think we need an introduction for the analysis below, in order to understand we are going to compare. Trying to ease reading.
SRD> Okay.
...
>
> 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 * (2/1500) = 13.33 and Server2 RDL= 10000 * (70/55000) = 12.73 with the conclusion to select server2. This is a bit surprising as server 1 is only 2% loaded. This example is rather specific with a server 1 weight being 2,7% of server 2 weight. I did another 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>

JJ> I think we can remain with only the relative load information  proposed in the draft even when servers have different capacity. If a small capacity node sees its incoming traffic increasing it will quickly react by sending a higher load value, which, when received by a sending node, will become higher than the values  received from other nodes with higher capacity. Sending node will then reduce the traffic towards this node to ensure load balancing and will continue to adjust according to the load values received. This seems a simple loopback mechanism ensuring a right load balancing.
MCRUZ> This does not assure a proper load-balancing, because the client does not have information it can compare, then it does not know which server is less loaded, not even approximately. Obviously, when a server gets more loaded it will provide the information, but this will cause oscillations, that could even be critical for a server. For example, if one server has a very small weight, compared to the rest, it may be selected as the destination of requests but it would get easily loaded, and again, it needs to react. 
Moreover, the servers in the pool with higher capacity will be normally underutilized. In general, resources are not efficiently use (bigger server tend to be underutilized), the load fluctuates a lot (specially for the small servers), and some servers may be overloaded with peaks of traffic (small servers).
Then, my proposal is to include a normative sentence, as above, although the way to specifically do it may be operator specific. Then, on top of that, the example I provided is useful to understand the situation and I think should be in the draft as well.

Do you think it is not sufficient? To add capacity value (weight, group of servers) ..)increases the increases the complexity given this capacity may vary over time (eg a partial failure) so possibly requiring to be dynamically updated. 
More sophisticated behaviors can be introduced (implementation specific) without impacting the protocol and AVPs specified in the draft. If justified requirements drive to new AVPs, this could be part of future evolution, out of the scope of the present draft .

>
>
>> 5.
>> Now
>>      The load report includes the relative load of the sending node.  This
>>      relative load is specified in a manner consistent with that defined
>>      for DNS SRV [RFC2782].
>>
>> Proposed:
>>      The load report includes a value to identify the load of the sending node,
>>     specified in a manner consistent with that defined
>>      for DNS SRV [RFC2782].
>>
>> <JPG> Agree. </JPG>
> SRD> I don't understand the need for this change.
> MCRUZ> Using "relative" is misleading unless we clarify "relative to what".
SRD> Okay.  How about a small change to: "The load report includes a
value **indicating** the load of the sending node..."
MCRUZ> Fine

JJ> "relative" also used in the proposed update definition of "load" in section 2, which is consistent with the definition of the Load-Value AVP in 7.3., so for me relative is not misleading.
MCRUZ> I made same comment to that section. I think Steve's proposal is fine and more accurate.

...
>> 6.1.1
>> Now:
>>      The method for determining the load value included in the load report
>>      is an implementation decision.
>>
>> Comments:
>> In line to comment above, I agree it should be implementation specific, but we need to provide some guidance to be able to provide a value that could be used to achieve a successful load balancing.
> SRD> See my comment above about DNS SRV algorithm.
> MCRUZ> This is related to my comment above to 5, but to the part related to a way to provide a LOAD value that represents the available capacity of a server, taking into account its static capacity.
SRD> Okay, I'll propose some text, based on your example, in the next
version of the draft.  This would be a non normative example of how someone might compute the load value.
MCRUZ> Including the example is fine. Although above I proposed some normative text as well that I think we need to consider.

JJ> see my above comments to 5. The sender adjusts its traffic according the evolution of the received load values.  
MCRUZ> See my comments above. This causes a bunch of problems.

...
>
>> 7.3
>> Now:
>>      The Load-Value AVP is specified in a manner similar to the weight
>>      value in DNS SRV ([RFC2782]).
>>
>>      The Load-Value has a range of 0-65535.
>>
>>      A higher value indicates a lower load on the sending node.  A lower
>>      value indicates that the sending node is heavily loaded.
>>
>>         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.
>>
>> Comments:
>> I think it could be easier to use a %. It is more straight forward to figure out what it means.
> SRD> Percentage can be mapped to the range 0-65535 if that is the
> internal implementation decision.  The goal here is to be consistent 
> with RFC2782.
> MCRUZ> Why do we need to keep consistency to that RFC? I think it is clearer to use a percentage, it is more straight forward to identify the available load we refer to.
SRD> This was discussed and agreed to early in the process of writing
this mechanism.  There a a couple of reasons, first, its an algorithm that has already been specified and implemented.  Second, it  allows someone who has already implemented the DNS SRV algorithm to reuse it.  
Third, while RFC6733 doesn't directly address load balancing/distribution, it does reference use of DNS SRV for handling dynamic connections.  It is not unreasonable to expect that there are implementations would use the DNS SRV value for nodes that don't support load, along with load values received.
MCRUZ> I do not remember a discussion about this, sorry. I had the impression it was incorporated without much discussion.
However, I do not see that it helps reusing DNS SRV. Does an implementation take profit of anything previously implemented for DNS SRV when deciding what load value include in the AVP? I think the server will calculate the LOAD, and then it needs to reflect a value from totally-available to totally-loaded. It is more straight forward and more intuitive to simply use 0-100 as you agreed below.
I did not consider the comment before, sorry, but I think now it can be easily changed and simplify all the implementations and interpretation of LOAD value, don't you think?

> E.g. 50% loaded, using SRV is 32767,5;  25% is 49151,25;  and so on.
> In the mechanism we are defining we do not have the need to keep using a complex value like this one, when we can simply use 0 to 100%, 0 (totally available), 100 (totally loaded).
> In fact, this is in line to the definition in the doc:
SRD> I really don't want to revisit this decision this late in the
game.  While not as intuitive to a casual reader of the specification as a percentage value might be, Using the DNS SRV value works.
...
JJ> Preliminary version of the draft started with %, then Steve proposed to use the same definition as with SRV which didn't raise comments, I am OK to remain on Steve proposal.
MCRUZ> There is no reason to keep it unless we think it has some advantages, which as I explained above, I do not think there are. Let me know if you see any advantages.

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

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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 7 Jul 2016 09:09:36 +0000

Hello JJacques, all,

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

====== from previous emails (begin) =================================

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  

 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.

---

From: "Trottin, Jean-Jacques (Nokia - FR)" <[email-masked]>
Date: Wed, 13 Jul 2016 14:34:27 +0000

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:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : jeudi 7 juillet 2016 11:10
À : Trottin, Jean-Jacques (Nokia - FR); [email-masked]
Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello JJacques, all,

 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) ==========================

<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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 14 Jul 2016 08:44:52 +0000

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:[email-masked]] On Behalf Of Trottin, Jean-Jacques (Nokia - FR)
Sent: miércoles, 13 de julio de 2016 16:34
To: [email-masked]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hi MCruz, all,

Best regards
JJacques

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

Hello JJacques, all,

Server2 load (DL)= 45% so Server 2 consumed resource units= 3x45% = 1,65 Then

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.

Server2 load (DL)= 75% so Server 2 consumed resource units= 3x75% = 2,25 Then

Best regards

JJacques

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Sat, 16 Jul 2016 14:48:14 -0500

Hi all,

Some observations below:

<snip, and apologies for my mail client butchering the includes>

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

[ajm]  (With my implementer's hat on) Having clients chase the 
least-loaded server can go wrong, especially when lighting up a network, 
and a server's load goes from 0 to fully loaded really quickly. 
Depending on the design and timing, all the clients think the first 
server is the least loaded and they *all* pick it. Boom - the server is 
now maxed out. Clients should *distribute* their load across servers.

Now, distribution cannot be completely even, but that's OK. Because 
we're talking about load here. Not *overload*. If you've designed your 
system correctly, a fully loaded server is *not* in danger of overload. 
For instance - you've designed your system with 3 servers in a cluster 
that can handle one of their cluster mates going down. When "fully" 
loaded, each server in the cluster should never be so loaded such that 
they cannot handle one of their mates going down and taking on half of 
that mate's traffic.

*Overload* should be a rare event - like a tornado wiping out a chunk of 
your mobile network, and everybody calling and texting everybody else to 
make sure that they're ok.

Thanks!

Jean (who has actually had a customer point to the aftermath of a 
tornado and tell her, "Your solution has to handle THAT.")

<snip>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 18 Jul 2016 07:25:13 +0000

Hello Jean,

Thanks for providing your view.
See MCRUZ 2> comments below
Best regards
/MCruz

-----Original Message-----
From: A. Jean Mahoney [mailto:[email-masked]] 
Sent: sábado, 16 de julio de 2016 21:48
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hi all,

Some observations below:

>> traffic it will change its load value to a lower value and will start 
>> getting more traffic.

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

> capacity.  It is not strictly necessary that every request goes to the 
> least loaded node.

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

[ajm]  (With my implementer's hat on) Having clients chase the least-loaded server can go wrong, especially when lighting up a network, and a server's load goes from 0 to fully loaded really quickly. 
Depending on the design and timing, all the clients think the first server is the least loaded and they *all* pick it. Boom - the server is now maxed out. Clients should *distribute* their load across servers.
MCRUZ 2> Yes, the purpose of the draft is to provide a LOAD value that is valid to distribute load across servers.

Now, distribution cannot be completely even, but that's OK. Because we're talking about load here. Not *overload*. If you've designed your system correctly, a fully loaded server is *not* in danger of overload. 
MCRUZ 2> The issue is to be able to provide a LOAD value that allows the client to perform load distribution. If we do not take the weight into account, somehow (implementation dependent), the distribution will be very far from even, it may cause very important traffic oscillations (e.g. small servers will appear as low loaded but if traffic is sent towards then they may reach overload threshold very soon) and big server will normally be underutilized. Therefore, the expected load distribution is far from being achieved.

For instance - you've designed your system with 3 servers in a cluster that can handle one of their cluster mates going down. When "fully" 
loaded, each server in the cluster should never be so loaded such that they cannot handle one of their mates going down and taking on half of that mate's traffic.

*Overload* should be a rare event - like a tornado wiping out a chunk of your mobile network, and everybody calling and texting everybody else to make sure that they're ok.

Thanks!

Jean (who has actually had a customer point to the aftermath of a tornado and tell her, "Your solution has to handle THAT.")

<snip>

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 18 Jul 2016 14:13:09 -0500

Hi Maria,

OK, I see your point. I keep thinking that since DNS is so cool everyone 
would use it...

On 7/18/16 2:25 AM, Maria Cruz Bartolome wrote:
> MCRUZ 2> The issue is to be able to provide a LOAD value that allows
> the client to perform load distribution. If we do not take the weight
> into account, somehow (implementation dependent), the distribution
> will be very far from even, it may cause very important traffic
> oscillations (e.g. small servers will appear as low loaded but if
> traffic is sent towards then they may reach overload threshold very
> soon) and big server will normally be underutilized. Therefore, the
> expected load distribution is far from being achieved.

In section 5, the implementer is told to find server capacity via the 
DNS SRV query and then use it to calculate load:

But what if the Diameter node does NOT use DNS [1]? According to RFC 
6733, Section 5.2, DNS is "MUST be supported" but only "MAY be used". So 
where does the peer get the weight information if all of its connections 
are manually configured? I guess weights could be manually configured, 
but that becomes difficult to maintain as peers are upgraded.

So the question becomes:  Do we make use of DNS a MUST for this 
solution, or do we have reporting peers include capacity in their load 
reports?

Thanks!

Jean

[1] I've seen large-scale deployments with only manual configuration for 
all Diameter connections, with no DNS servers in the network.

---

From: "Trottin, Jean-Jacques (Nokia - FR)" <[email-masked]>
Date: Tue, 19 Jul 2016 07:18:47 +0000

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:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : jeudi 14 juillet 2016 10:45
À : Trottin, Jean-Jacques (Nokia - FR); [email-masked]
Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hello JJacques,

	

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

Hi MCruz, all,

Best regards
JJacques

-----Message d'origine-----

Hello JJacques, all,

Best regards

JJacques

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 19 Jul 2016 08:00:48 +0000

Hello JJacques,

In relation to the objectives you mentioned in the email, I think we need to be able to select servers according to the available capacity, this is what a load balancing is about in my opinion, then it is specifically related to your objective:
  "- one ensuring each server to have the same available capacity independently of its size (your use case)."

I think there are important drawbacks if the client selects servers without taking into account the real available capacity, as I explained before:
"the distribution will be very far from even, it may cause very important traffic oscillations (e.g. small servers will appear as low loaded but if traffic is sent towards then they may reach overload threshold very soon) and big server will normally be underutilized.".  It is easy to understand that a big server in a pool where there as smaller servers will  be underutilized, since even if it is 70% (e.g.) loaded, it may not be then selected (in front of other having e.g. 50%), but the available capacity of that big server is much bigger. If traffic is moved towards small servers, when they are considered to be low loaded, then the traffic will increase rapidly towards then, and since the real capacity is very small (since they are small servers), then they will get into high load level very easily, even it is possible to push then into overload, depending on how fast the load balancing algorithm is adjusted.

About the RDL, I used that term to ease explanation, in order to explain that we need to define that the Load calculated by each server should not be used without taking into account the weight of each server in comparison with the rest of servers in the pool.  
You mentioned, and I agreed, that we should not limit implementations, therefore the calculation should remain application independent. As long as the Load value takes into account servers' weight (RDL). 
Therefore, the key point is to define clearly that LOAD value to be used in the load-balancing should take into account servers' weight. 
In order to cover that, I proposed following sentence, that I will copy here again. I would appreciate if you could provide comments to the sentence itself, in order to get a common agreement:

Best regards
/MCruz

-----Original Message-----
From: Trottin, Jean-Jacques (Nokia - FR) [mailto:[email-masked]] 
Sent: martes, 19 de julio de 2016 9:19
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-load-02

Hi MCruz 

 

Best regards

JJacques 

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

Hello JJacques,

	

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

Hi MCruz, all,

Best regards
JJacques

-----Message d'origine-----

Hello JJacques, all,

Best regards

JJacques

---

From: Steve Donovan <[email-masked]>
Date: Tue, 19 Jul 2016 17:45:44 +0200

Maria Cruz,
JJacques,
Jean,

Thanks for the good discussion.  I haven't had a chance to respond but I 
will soon.  I need to work through a few scenarios that I hope to be 
able to show that the SRV algorithm will work without knowledge of the 
amount of remaining capacity.

Steve