Subject: [dhcwg] dhcpv6-24: Elapsed Time option

From: Thomas Narten <[email-masked]>
Date: Wed, 08 May 2002 11:12:29 -0400

> 22.9. 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 (8)
> 
>       option-len    2.
> 
>       elapsed-time  The amount of time since the client began its
>                     current DHCP transaction.  This time is expressed in
>                     hundredths of a second (10^-2 seconds).

Would it make sense to change this option to carry the retransmission
number rather than an actual time? I.e., backup servers would respond
only on (say) a retransmission?

I understand this to be a holdover from DHC. But if the goal is to
provide backup servers info on when they should respond, the
retransmission count might be more useful than the elapsed time.

Thoughts?

Thomas

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 May 2002 11:12:45 -0500

> retransmission count might be more useful than the elapsed time.

It's true that a count would serve the functional purpose, but the 
retransmission time is easy to generate, serves the same purpose, and 
provides additional information.   So why use the less functional 
retransmission count?

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 09:33:26 -0400

> provides additional information.   So why use the less functional 

Would there be any value in including both?

The problem with just including the time is that servers need to guess
whether a client has been waiting "too long". Or, is it the case that
when the client  sends out its initial Solicit, the value MUST be
zero? If so, it might be good to specify this. If this were the case,
I agree that including the time is probably sufficient.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 May 2002 11:44:24 -0500

> I agree that including the time is probably sufficient.

Ah, I see the problem now.   Yes, we should make this explicit.   As to the 
practical matter of "how long is too long," we address this in DHCPv4 by 
letting the server administrator decide.   AFAIK, this solution has proven 
satisfactory - I haven't heard any complaints about it.