Re: Issues with 2052bis (SRV)

[Rob Austein <sra@hactrn.net>]

A few comments on Robert's message of 15 July.  This is an edited
repost of a message that I sent privately to Robert and the person who
proposed the new wording in question.

   Date: Thu, 15 Jul 1999 15:12:53 +0200
   From: Robert Elz <kre@munnari.oz.au>
   To:	 namedroppers@internic.net
   Subject: Issues with 2052bis (SRV)

   ...
   Issue 6:

   It has been suggested that the actual description of the weight
   algorithm is unclear.   The suggestion was (originally) that it
   be replaced by the following text.

       A load balancing mechanism.  The weight field specifies a relative
       weight for entries with the same priority. Larger weights SHOULD be
       given a proportionately higher probability of being selected. The range
       of this number is 0-65535.  This is a 16 bit binary integer in network
       byte order.

What's a "16 bit binary integer"?  Same as "16-bit unsigned integer",
presumably.  Probably ought to use that term instead.

       Domain administrators SHOULD use Weight 0 when there isn't any
       load balancing to do, to make the RR easier to read for humans
       (less noisy).  In the presence records containing weights
       greater than 0, records with weight 0 have a very small chance
       of being selected.

       In the absence of a protocol whose specification calls for the use
       of other weighting information, implementations SHOULD implement the
       effect of the following algorithm:  Each time a target is needed, the
       client orders the remaining (not previously used) SRV RRs at the
       current priority in any random fashion,

Does it have to be random at all, or do we simply not care?  Could
this equally well say "in any order at all"?  If so, that would be
better, we have enough fun with random numbers further on.

       except that all those with
       weight 0 are placed at the beginning of the list.  Compute the sum of
       the weights of those RRs, and with each RR associate the running sum
       in the selected order.  Then choose a uniform random number

The term "uniform random number" is probably too obscure (more
precisely, if a reference to modular arithmetic is too obscure, this
is too, and Robert beat me senseless the last time I proposed
mentioning modular arithmetic in a DNS document...).

       between 0
       and the sum computed (inclusive), and select the RR whose running sum
       value is the first in the selected order which is greater than or
       equal to the random number selected. Note that the random numbers used
       here MUST NOT be restricted to integer values if this algorithm is to
       work properly.

   It was later pointed out that this seems to suggest that floating point
   must be used, which would make implementation difficult on systems with
   no floating point capabilities (no hardware, no software either).   Since
   it is entirely possible to implement a suitable algorithm, entirely in
   integer arithmetic (hardware integer arithmetic) - typically using some
   fixed point scheme, it has ben suggested that this should be reworded
   yet again to avoid the floating point suggestion.   Text is welcome...

I was the person who raised the objection to the implied requirement
for floating point.  Presumably one can accomplish the purpose of this
algorithm in fixed point simply by simply by multiplying through by
the number of RRs in the bucket, or something like that.

However, I'm a bit unclear on the motivation for the "MUST NOT"
restriction.  Perhaps I'm just missing the blindingly obvious, but I
don't get it.  Would someone who sees the difficulty care to explain?