Subject: interpretation of the Weight field in SRV

From: Keith Moore <[email-masked]>
Date: Thu, 15 Apr 1999 16:20:29 -0400

(this is slightly edited from a reply that I sent to a message from Thomas 
Narten, explaining why the dnsind WG did not want to adopt my suggestion
for changing the interpretation of the Weight field of the SRV 
record)

> > 4. Use of the weight feature should be defined on a per-application basis.
> >    Some applications may need to define their own weighting or load-
> >    balancing schemes, which might either use the Weight field in a
> >    protocol-specific way or ignore it entirely.  Even the authors of SRV 
> >    admit that DNS is not a good place to put weighting, so the weighting 
> >    scheme recommended in SRV should not be assumed to be universally 
> >    applied.
> 
> The WG does not want to make this change. Specific subpoints:
> 
> 1) I think the WG would be willing to put in wording to make it clear
> that rapid changes in weight will not work well with SRV records, and
> other techniques should be used in such cases. However, static weight
> still seems useful.
> 
> 2) Having uniform interpretation of weights across all applications
> was deemed to be a good thing, and facilitates using a shared
> library. Plus, it doesn't make doing better load balancing harder
> (e.g, you can set weights to 0 and use other techniques).

yes, it seems useful to have uniform interpretation of the Weight field.  
but, as the authors point out, the utility of Weight as stated in the 
document is somewhat dubious.  to me it makes more sense to allow for 
that interpretation to change in the future, perhaps on a per-protocol 
basis (so that we don't have to change the interpretation of Weight 
for already-deployed protocols that are using it), than to insist that
we will always be stuck with an interpretation that we already know
has technical omissions.  the reason that I think change is likely is
that we will probably want to have protocols that do dynamic load-balancing
and some that select servers based on available bandwidth or proximity.
(and the algorithm for making server selections based on load balancing or 
proximity will almost certainly be protocol-specific.)  I don't want
the use of SRV and the Weight field to preclude development of such 
facilities.

otherwise, if we find out that Weight doesn't work very usefully,
or that it needs tweaking (for instance to define its 
interaction with proximity estimation services), then we will have 
to define a new SRV2 RR type, which might be identical to the old
one but with a different kind of Weight field.  either that or we
will have to abandon Weight altogether.

this is why I think Weight should be protocol specific - not because
I want every protocol to treat it differently, but so that we can
evolve use of that field for new protocols based on experience.
and I don't think that interpretation of Weight should take precedence
over, say, load and proximity measurements.

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.

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

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

would that satisfy the working group?  

Keith

p.s. incidentally, I suspect Weight will probably get most of its use
in static load-balancing between different network links (rather than
server hosts), and perhaps in allowing gradual cut-over from one
kind of server to another.   my understanding is that distributed 
computations tend to have difficulty adjusting to asymmetrical 
processor capability; and linear models for those asymmetries tend 
not to work very well at either balancing the actual load, or 
minimizing delay, or getting high utilization from all resources.

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 16 Apr 1999 00:23:34 -0700

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.

>   records SHOULD NOT be changed rapidly to accomodate transient load 

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

>   algorithm when all servers are of equivalent load and equivalent

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

>   is gained with its use.  (or course we could always change it by

i don't like this at all.

> would that satisfy the working group?  

see above.

---

From: Greg Hudson <[email-masked]>
Date: Fri, 16 Apr 1999 10:43:42 EDT

I agree 100% with what Paul said on this issue.  I will add a little
bit.

> otherwise, if we find out that Weight doesn't work very usefully, or
> that it needs tweaking (for instance to define its interaction with
> proximity estimation services)

This is terribly unrealistic in my mind.  A proximity estimation
service is orders of magnitude more complicated than "foo is twice as
fast as bar, so pick foo twice as often as bar."  That wouldn't be a
"tweak"; that's an entirely new proposal and one that no one has made
so far.

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

Writing this kind of statement into a spec only adds FUD.  I don't
want us to endanger a common library implementation of reading SRV
records by making it unclear how the weight field should be handled.

We have a simple, understandable proposal here, applicable within a
limited but well-defined realm.  It won't get in the way of more
sophisticated load-balancing proposals, as long as they don't want to
hijack the field.  We don't need to write any escape hatches into the
spec.

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Apr 1999 10:39:22 -0400

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

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

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Apr 1999 10:48:05 -0400

> "tweak"; that's an entirely new proposal and one that no one has made

People have indeed made proposals for proximity estimation services.

But the point is, we should not be saying that server selection
should be made exclusively based on static load estimates.

Keith

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 16 Apr 1999 07:53:21 -0400

Thanks,
Donald

From:  Keith Moore <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
cc:  [email-masked], [email-masked]
Date:  Thu, 15 Apr 1999 16:20:29 -0400

---

From: Randy Bush <[email-masked]>
Date: Sat, 17 Apr 1999 07:43:26 -0700 (PDT)

[ mod note - the list seems somewhat broken.  i have received cc:s of email
  addressed to the list for which i have yet to receive approval requests.
  mark is checking into it.  -- randy
  ]

> should be made exclusively based on static load estimates.

no one is.  they are merely defining one mechanism.  

there may be others.  i-ds awaited.

randy