Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header

> Can anyone give us the benefit of experience with the 'secs' field
> in DHCPv4?  There hasn't been any interest in defining a new option
> with greater range or precision than the current 0-255 seconds
> measured in seconds.  Has the range or precision in DHCPv4 been
> inadequate in any specific instance?

A millisecond is a thousandth of a second.  So the range with 16 bits
is 65.536 seconds, not 655.36 seconds as Bernie said.  I think this is
too short to represent a reasonable set of cases.  There may be
devices, e.g. low power scientific devices that might want to probe
the network from time to time, but can't afford the power cost of
probing it frequently, where the desirable retry interval may be much
longer than that.  I do not know of any such devices that are in use
right now, but it seems plausible to me that someone might want to
deploy one, and I would like to account for that possibility.

> Another alternative for greater range would be to define the units
> of the data value to be tenths of a second.  My intuition is that
> tenths of a second should be sufficiently precise...

I think it's good to have better granularity than that.   We specify
the retry timeout in milliseconds, so the retry interval should also
be computed in milliseconds.

This is an option that will only be present in exceptional cases, and
we are discussing a difference in space consumption of 33%.  I am all
in favor of saving space in frequently-transmitted packets, but this
is not much space, and will not be in the most frequently-transmitted
packets.

I may be wrong that we need this extra breathing room, but the cost is
low, and I'd really appreciate it if we could stop arguing about this
and just take the risk that we might be being a little bit generous in
our allocation of bits.

			       _MelloN_

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg