Subject: DHCP Load balancing draft addition

From: Steve Gonczi <[email-masked]>
Date: Thu, 24 Feb 2000 18:52:19 -0500

Greetings, 

I have new words (kindly contributed by Ted Lemon) that I would like to add
to the DHC load balancing draft. The net effect is to ALLOW a bias (in
addition to the hard yes/no) approach. 
If a server implements this unilaterally, in a worst case scenario we may
get a few extra
offers under heavy load. I would like to remind you all, the load balancing
only affects 
NEW leases.

Please share your  thougths!
Here is the text:

  DHCP server implementations may optionally be configurable to handle
  a case where load balancing is being done but where one DHCP server
  is not available, and the other is.   DHCP server implementations
  that provide this capability SHOULD have a configuration parameter
  that states the number of seconds to wait after the client's first
  request has been sent before responding to a client whose hash would
  not normally permit the client to be served.

  A DHCP server providing this capability SHOULD use the value in
  the secs field of the client request if its value is not zero.
  Because some clients may not correctly implement the secs field, a
  DHCP server MAY keep track of the first instance of a client
  transaction to which it would not normally respond.   If the server
  receives a request from a client that has the same transaction ID as
  a previously recorded request, and if the secs field in the second
  packet is zero, the DHCP server MAY use the time in seconds between
  receipt of the first client request and the receipt of the
  subsequent client request in place of the secs field in order to
  determine whether or not to respond.

---

From: Bernie Volz <[email-masked]>
Date: Fri, 25 Feb 2000 12:54:32 -0500

Why is the wording such that it would appear to prohibit a server from using
any stored information if the secs field is non-zero?

Shouldn't it be allowable to use either the secs field from the packet AND /
OR "stored" information about the time since the first request from that
client?

Why not just simplify the text to say:
a) A DHCP Server MAY do this.
b) A DHCP Server SHOULD use either the value in the secs AND / OR "stored"
information about the time since the first request from that client?

A discussion that the secs field may be sufficient because some clients
don't set it correctly would be useful (BTW, I have seen some cases where
either the packet probe reported or the client set the secs field
incorrectly - looked like a byte ordering issue).

The advantage to having the server "store" information is that it is
potentially more accurate. The disadvantages are the expensive of doing it
and the server may not have received all the packets (I think some relay
agents are able to do forwarding based on the secs field value as well and
hence may not forward to the "backup" server until some time has already
elapsed). So the combined method is actually the most desireable.

To summarize, I have no problem with the general concept though I would
encourage slight revisions to the wording.

- Bernie

-----Original Message-----
From: Steve Gonczi [mailto:[email-masked]]
Sent: Thursday, February 24, 2000 6:52 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]'
Subject: DHCP Load balancing draft addition

Greetings,