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: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] 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