Re: [dhcwg] RFC 3315 - Dhcpv6 client message retransmission question

["Bernie Volz (volz)" <[e-mail]>]

While I'm surprised it was stated (at least I didn't find it in a very
superficial search of the document), I believe the values in section 5.5
(as stated in section 19.1.2) are the "Default and initial values". This
means that these are the values that clients should use as default
values and they MAY provide a means to override these values.

 

Whether doing so is a good idea is a separate issue and you'd have to
evaluate that on a case by case basis.

 

Personally, I don't see a problem in reducing REQ_MAX_RC from 10 to say
5 as this just means that if the server fails to respond after the fewer
retries, the client would return to the SOLICIT phase. If the server is
still unresponsive, it would obviously not respond to the SOLICIT and if
another server was present, the client would use it; otherwise it would
continue to SOLICIT periodically until a server was responsive.

 

The ONE impact of reducing REQ_MAX_RC is that if the server is very
'slow' in responding, the client may NEVER successfully complete getting
an address. We did have a customer issue one time where there were
DHCPv4 clients that would only retransmit a DHCPREQUEST twice and then
return to DHCPDISCOVER. And, in a particular situation (where other
servers that the DHCP server needed to contact before responding to the
DHCPREQUEST had a high latency), the clients would never successfully
complete coming on line. Those that retransmitted the request more times
(i.e., over a longer period of time) had no issues.

 

So, reducing the REQ_MAX_RC, if there are long latencies involved
(either because of network, load, other issues) may result in a
situation where clients fail to come on line whereas using the default
REQ_MAX_RC would not. I haven't done the math  (well I did do it below)
to see what period of time a REQ_MAX_RC of 10 would be versus a
REQ_MAX_RC of 5 - but as the delay between retransmissions should be
doubled with each attempt up to a maximum of 30 seconds (REQ_MAX_RT),
the difference between 10 and 5 may be as much as 5*30 seconds = 150
seconds.

 

In the case I mentioned above, the DHCPv4 clients were only waiting
about 4-8 seconds - which was much too short for the conditions. But, a
REQ_MAX_RC of 5 already provides a minute (1, 2, 4, 8, 16, 30 if one
assumes this means 6 total transmissions) so this SHOULD be long enough.
With a value of 10, this would be about 200+ seconds which is kind of
long to wait for a server to respond (IMHO).

 

-          Bernie

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of ravi kumar
Sent: Thursday, October 15, 2009 8:54 AM
To: DHC WG
Subject: [dhcwg] RFC 3315 - Dhcpv6 client message retransmission
question

 

I would like to get a clarification regarding section : "14. Reliability
of Client Initiated Message Exchanges" of RFC 3315 :

 

Is it possible for Dhcpv6 client implementations to use relaxed MRC /
MRD values than default values specified in RFC. For instance, default
value of "REQ_MAX_RC" is 10. Can a specific Dhcpv6 client implementation
use a different value say 5, for REQ_MAX_RC.

 

The only reason why I would like to clarify this is because, it is
mentioned in RFC that, MRC specifies an upper bound on the number of
times a client "may" retransmit a message and not client "MUST"
retransmit a message.

Since it is not specified with MUST clause, I assume RFC doesnot mandate
client to retransmit exact MRC number of messages.

Similar is the case for MRD.

 

Please correct me if I am wrong!

 

regards

Ravi