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

Ted Lemon <> Tue, 28 August 2001 00:54 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id UAA05409; Mon, 27 Aug 2001 20:54:58 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id UAA14329; Mon, 27 Aug 2001 20:54:08 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id UAA14307 for <>; Mon, 27 Aug 2001 20:54:06 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id UAA05384 for <>; Mon, 27 Aug 2001 20:52:45 -0400 (EDT)
Received: from ( []) by (8.11.3/8.6.11) with ESMTP id f7S0mGf10246; Mon, 27 Aug 2001 17:48:16 -0700 (PDT)
Received: from (localhost []) by (8.11.3/8.6.11) with ESMTP id f7REZNi00390; Mon, 27 Aug 2001 10:35:23 -0400 (EDT)
Message-Id: <>
To: Ralph Droms <>
Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header
In-Reply-To: Message from Ralph Droms <> of "Mon, 27 Aug 2001 09:11:35 EDT." <>
Date: Mon, 27 Aug 2001 10:35:23 -0400
From: Ted Lemon <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

> 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

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.


dhcwg mailing list