Skip to main content

4. The "Weight" Field

4.1 Design Limitations​

Weight, the server selection field, is not quite satisfactory, but the actual load on typical servers changes much too quickly to be kept around in DNS caches.

Authors' Perspective

It seems to the authors that offering administrators a way to say "this machine is three times as fast as that one" is the best that can practically be done.

4.2 Alternatives for Dynamic Load Balancing​

The only way the authors can see of getting a "better" load figure is asking a separate server when the client selects a server and contacts it.

4.2.1 Issues with Short-Lived Services​

For short-lived services an extra step in the connection establishment seems too expensive.

4.2.2 Issues with Long-Lived Services​

For long-lived services, the load figure may well be thrown off a minute after the connection is established when someone else starts or finishes a heavy job.

4.3 Experimental Approaches and Future Study​

Current Research

There are currently various experiments at providing relative network proximity estimation, available bandwidth estimation, and similar services. Use of the SRV record with such facilities, and in particular the interpretation of the Weight field when these facilities are used, is for further study.

4.4 Design Intent​

4.4.1 Static vs Dynamic Selection​

Design Limitation

Weight is only intended for static, not dynamic, server selection.

Using SRV weight for dynamic server selection would require assigning unreasonably short TTLs to the SRV RRs, which would:

  • Limit the usefulness of the DNS caching mechanism
  • Increase overall network load
  • Decrease overall reliability

4.4.2 Intended Use Cases​

Server selection via SRV is only intended to express static information such as:

  • "this server has a faster CPU than that one"
  • "this server has a much better network connection than that one"
Tags:
Last updated on