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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 9 May 2002 08:43:32 -0500

>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:[email-masked]]
Sent: Thursday, May 09, 2002 9:33 AM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option 

Ted Lemon <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

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

> retransmission until timeout or Reply.

I think if you let the relay agent make relaying decisions based on the 
time sent by the client, you're in big trouble.   Picture this:

client sends solicit A, t=0
relay sends solicit to server A
client sends solicit B, t=100
relay sends solicit to server B
server A responds to solicit A with advertise A
client sends Request A, t=100
relay sends Request A to server B
server B drops Request A on the floor

repeat until bored

The only reliable way to fix this is to have the server send the time it 
received from the client in the solicit back to the client in the advertise,
  and for the client to use that time in every subsequent Request, 
regardless of how long it has to retry.   This is complicated to specify, 
and complicated to implement.   Do we really want this?