Subject: Re: interpretation of the Weight field in SRV

From: Michael Boe <[email-masked]>
Date: Sun, 2 May 1999 17:41:28 -0400 (EDT)

On 16-Apr-99 at 11:06, Keith Moore ([email-masked]) wrote:
>> I don't get all this about network link bandwidth, etc.  Almost all
>> serious servers are multiply connected and the bandwidth to them
>> depends on where you are in the network so you would want some
>> sort of hairy routing like algorithm to handle that.
> 
> In terms of network bandwidth or proximity, I'm thinking of a distributed 
> service with geographically dispersed servers rather than a single 
> multiply connected server.  But the argument for dynamic load balancing 
> applies even when all of the servers are located at the same place.
> 
>> SRV Weight is, I believe, intended for such differences as between
>> fundamentally faster and slower hardware at different servers.  That
>> sort of simple thing doesn't change dynamically anyway.  And that
>> sort of thing is common to all services I can think of.
> 
> Sure.  Though I do feel compelled to point out that the experience 
> of people that I work with (who have been doing distributed 
> computation systems for several years) is that static load balancing
> across dissimilar servers doesn't work very well.  This doesn't
> mean that Weight is not useful at all, but it might mean that (like
> MX preferences) it's not as useful as it seems at first.

My customers have had fairly good success at statically distributing load for
Telnet-based sessions. This is not to claim that static load-balancing is good
for all protocols, but seems to to work to good effect in this area.

For a math treatment of some similar problems, you might look here:

http://www.cisco.com/warp/public/cc/cisco/mkt/scale/distr/tech/ddran_wp.pdf

[Though my math isn't as good as Derek Bolton's (who wrote the paper), IMO the
results should be applicable to client-side distribution as long as the
randomization algorithms result in uniform distributions and the seeds are
different; ie, there's no pan-client synchronization present.]

Note that the nature of the SRV randomization of load between client is _not_
the same as you would get via the round-robin technique used in named. And in
general (and with sane client-side implementations), SRV will give superior
results, particularly at server-startup. [Keith, can you clarify as to what
sort of "static load balancing" your colleagues are dealing with?]  Certainly
there are better techniques where more information is known (see below), but
SRV is significant step forward in the case where no more knowledge is known at
the time of address resolution.

> 
>> I advocated *adding* an uninterpreted protocol dependent field
>> but almost no one on the WG thinks that throwing away the simple
>> and needed and library supported function of the current weight
>> field makes any sense.
> 
> I don't really advocate throwing away the Weight field either.  I 
> just don't want it to get in the way of other server selection 
> mechanisms that use dynamic load balancing or proximity estimation.
> And while having a library function to do the static balancing
> makes sense, I do not think that the API which used to select a server 
> from several candidates should blindly choose a server for the 
> application and prevent the application from considering other factors.
> 
> To put it another way, the current language regarding Weight seems
> to be making an architectural decision that protocols will use only
> static load balancing when choosing a server, and that dynamic 
> load balancing, proximity/bandwidth estimation, are being discouraged.
> I don't think we should be making such a statement.

I certainly agree with the sentiment expressed above. However, I'm unsure how
SRV Weight can be used simply in conjunction with other techniques in the final
mixing stage. Either the "other techniques" will have already resolved to an IP
address (in which case the SRV stuff isn't useful), or the "other techniques"
will have scoped the "view" of the problem to a single domain-name which then
is subject to SRV interpretation.

What is (to me) an easier and more interesting problem to solve is under what
circumstances a client can reuse the same IP-address as the SRV previously
returned. This (historically) has caused some problems and implementers could
benefit from clear, per-protocol guidance on the subject of IP-address re-use.

/msb