Subject: RE: interpretation of the Weight field in SRV

From: Stuart Kwan <[email-masked]>
Date: Fri, 16 Apr 1999 08:12:42 -0700

For the record, I agree with Paul.

-----Original Message-----
From: Paul A Vixie [mailto:[email-masked]]
Sent: Friday, April 16, 1999 12:24 AM
To: [email-masked]
Subject: Re: interpretation of the Weight field in SRV 

i've been staying out of this since the discussion has made no sense to me.
i finally think i have an inkling of the iesg's thinking, so i'll jump in:

> ....  the reason that I think change is likely is
> that we will probably want to have protocols that ...

we shouldn't debate what we will probably want, or not.

> if we can clarify the document to say:
> 
> - - Weight is intended for static, not dynamic, load balancing;  and SRV
>   records SHOULD NOT be changed rapidly to accomodate transient load 
>   changes on server hosts.

"should not" is the wrong way to say this.  "Dynamically changing the SRV
Weights to reflect real time server load will probably have no effect, due
to caching in the client.  SRV's Weight field is intended for static load
balancing, as in ``this server has a faster CPU than that one.''"

> - - Weight does not take precedence over server selection algorithms
>   which use dynamic load-balancing and/or relative proximity or 
>   bandwidth estimation.  the effect of Weight on such server selection
>   algorithms is protocol-specific (or for further study) but should 
>   be equivalent to the (then-current) "default" weight estimation 
>   algorithm when all servers are of equivalent load and equivalent
>   proximity to the client.

this overrestricts.  "SRV's Weight algorythm is intended to guide the first
order RR sorting, by perturbing the random number generation when the
Priority
of two RRs is the same.  Specific implementations and/or specific protocols
might reorder the resulting list of server addresses based on other
criteria."

> and perhaps:
> 
> - - Interpretation of Weight may change for new protocols as experience
>   is gained with its use.  (or course we could always change it by
>   revising the SRV RFC...)

i don't like this at all.

> would that satisfy the working group?  

see above.