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