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

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

Hello Jean,

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

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

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