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

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

That was my assumption. The time should reflect when a transaction is started. So, to be a bit more clear:

- Time is 0 when first Solicit is sent. Time continues to increase as Solicits are retransmitted.

The one open question is what to do with the time when the client sends a Request. In the DHCPv4 specification (if I read it correctly), the secs for DHCPv4 Request should not increase with retransmissions as that was to assure that the Relay uses the same logic in what servers it sends the messages to (in case it used the secs to send to a different set of servers). I don't know if this is needed and my feeling is that we should NOT reset the time when the Request transmissions start (the time should reflect the time since the FIRST Solicit).

If the server should fail to get a Reply to the Request and restarts the Solicit, time should not be reset.

- Time is 0 when first Renew/Rebind is sent. Increases with each retransmission until timeout or Reply.

- Time is 0 when first Decline/Release is sent. Increases with each retransmission until timeout or Reply.

- Time is 0 when first Information-Request is sent. Increases with each retransmission until timeout or Reply.

Note that the elapsed time increasing or changing is likely not that critical during Request/Reply, Renew/Reply, Decline/Reply, Release/Reply as these are interactions with a specific server. It is really only valueable when a request is being sent to many servers. Perhaps we should point this out and say that the Elapsed Time Option is not needed if the Server Identifier Option is included in a client message?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:33 AM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option 

Ted Lemon <Ted.Lemon@nominum.com> writes:

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

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

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

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