Subject: RE: Change to 'seconds' field in DHCP message header

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 23 Aug 2001 12:59:08 -0500

Perhaps also worth saying that if the elapsed time is >655.35 seconds,
655.35 seconds should be used? It probably will never be the case that
a client waits that long, but just in case (since it would be bad to
have it wrap around and start at low values again).

I agree with Ted's comment to add Relays. But, perhaps it should be a
new sentence, such as "Relays MAY use the data value in this option as
input to policy controlling to which server(s) the relay forwards the
client's message."

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 9:55 AM
To: DHCPv6 discussion list
Subject: Change to 'seconds' field in DHCP message header

This change eliminates the 'seconds' field from the message header and
replaces it with the "Elapsed Time" option.  The transaction-ID is now
24 bits.

The "Elapsed Time" option carries a 16 bit integer, giving the number
of seconds elapsed since the client began its current transaction.
The number of seconds is expressed in hundredths of a second (10^-2
seconds). The "Elapsed Time" option can indicate times in the range of
0 to 655 seconds, in increments of 10^-2 seconds.

This change address the following issue from the London WG meeting:

* Add 'secs' field to fixed header

  WG consensus: if client retransmits, MUST send option called
  "milliseconds"

Affected text:
--------------

8. Message Formats

   Each DHCP message has an identical fixed format header; some messages
   also allow a variable format area for options.  Not all fields in
   the header are used in every message.  In this section, every field
   is described for every message and fields that are not used in a
   message are marked as "unused".  All unused fields in a message MUST
   be transmitted as zeroes and ignored by the receiver of the message.

   The DHCP message header:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |               transaction-ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

18.6. Elapsed Time

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OPTION_ELAPSED_TIME      |           option_len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          elapsed time         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_ELAPSED_TIME (4)

      option-len    MUST be 2

      option-data   The amount of time since the client began its
                    current DHCP transaction.  This time is expressed in
                    hundredths of a second (10-2seconds):

   If a client retransmits a DHCP message, it MUST include an Elapsed
   Time option in the message to indicate how long the client has been
   trying to complete a DHCP transaction.  Servers MAY use the data value
   in this option as input to policy controlling how a server responds
   to a client message.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 27 Aug 2001 08:41:11 -0500

Because it wastes several additional bytes for what I believe is very little gain.

Perhaps there are some bizarre future applications where we want to wait for "long" periods of time, but I can't see any value in this. What this is to be used for is failover type support (either failover protocol or just multiple servers, one which is to be used unless the other fails).

If we're really concerned about being able to store long times, why don't we just make this seconds? I can't see any need to make the resolution 100ths of seconds and with seconds we can store many hours worth of time.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Sunday, August 26, 2001 10:44 PM
To: DHCPv6 discussion list
Subject: Re: Change to 'seconds' field in DHCP message header 

> I think 16-bits is enough (with the counter maxing out). If an attempt goes
> on that long, no server is probably available and the relays (or servers)
> will likely long have taken alternative actions (which probably failed as
> well). So, I see little need to make this more than 16-bits.

That's a pretty set of suppositions, but you may well be wrong.   Why
not make sure that it works if you are?

			       _MelloN_

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 27 Aug 2001 08:46:40 -0500

I supported the change to 1/10th of a second (would even support a change to 1 second as mentioned previously).

I agree with Ralph. I don't see the need to waste the additional bytes.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, August 27, 2001 9:12 AM
To: [email-masked]
Subject: [Dhcwg] Re: Change to 'seconds' field in DHCP message header

(Please note that this message has been sent to the new dhc WG mailing list, [email-masked].  The current mailing lists, [email-masked] and [email-masked], will be taken off line tomorrow, Aug 28, around 4PM.  I will arrange for e-mail to the old lists to be forwarded to [email-masked] for a couple of months.  I will also save the archives from the old lists and make them available on line as soon as possible. - RD)

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...

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?

- Ralph

>not make sure that it works if you are?

_______________________________________________
Dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Aug 2001 10:04:38 -0400

(All - please respond through [email-masked]. - RD)

>From: "Bernie Volz (EUD)" <[email-masked]>
>To: DHCPv6 discussion list <[email-masked]>
>Subject: RE: Change to 'seconds' field in DHCP message header 
>Date: Mon, 27 Aug 2001 08:41:11 -0500
>X-Mailer: Internet Mail Service (5.5.2653.19)
>Reply-To: [email-masked]
>Sender: [email-masked]
>
>From: Ted Lemon [<mailto:[email-masked]>mailto:[email-masked]] 

dhcwg mailing list
[email-masked]