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

["A. Jean Mahoney" <[e-mail]>]

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>