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

From: ravi kumar <[email-masked]>
Date: Thu, 15 Oct 2009 18:23:39 +0530

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Oct 2009 09:51:55 -0700

> Please correct me if I am wrong!

Why do you want to transmit fewer packets?

---

From: ravi kumar <[email-masked]>
Date: Fri, 16 Oct 2009 11:59:31 +0530

I just wanted to confirm, if it is as per RFC conformance, incase for an
existing Dhcpv6 client implementation to transmit fewer number of packets.

regards
Ravi

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Oct 2009 00:45:58 -0700

On Oct 15, 2009, at 11:29 PM, ravi kumar wrote:
> I just wanted to confirm, if it is as per RFC conformance, incase  
> for an existing Dhcpv6 client implementation to transmit fewer  
> number of packets.

That's not what the spec means.   You shouldn't do this.   The reason  
the spec allows you to retry fewer times is because you stop retrying  
once you get a response.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Oct 2009 09:53:33 -0400

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: [email-masked] [mailto:[email-masked]] 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.

regards

Ravi

---

From: ravi kumar <[email-masked]>
Date: Mon, 19 Oct 2009 12:54:44 +0530

Thanks Bernie for your valuable information. I agree with your view of
default values mentioned in RFC 3315. There is no hard and fast rule placed
in RFC that all implementations must use the values mentioned in RFC, but
instead provide with a preferred set of values that can be used for message
re-transmissions.

regards
Ravi
On Sat, Oct 17, 2009 at 7:23 PM, Bernie Volz (volz) <[email-masked]> wrote:

>  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
> 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
> 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:* [email-masked] [mailto:[email-masked]] *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
>
>
>
> 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.
>

---

From: Bud Millwood <[email-masked]>
Date: Mon, 19 Oct 2009 14:21:59 +0200

On Saturday 17 October 2009, Bernie Volz (volz) wrote:

> ... but as the delay between retransmissions should be

To the guy in 2012 who is going to make our lives miserable because you're too 
overworked to read the RFC: That is **doubled WITH RANDOMIZATION**!

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 20 Oct 2009 12:29:33 -0400

The randomization is +0.1 to -0.1 ... so this impact is small (it does
mean that the limit, which is also subject to randomization, could be 33
seconds to 27 seconds). I don't think it really changes much of anything
in my analysis and the point I was trying to make.

I guess you're predicting that DHCPv6 will hit the big time in 2012?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bud Millwood
Sent: Monday, October 19, 2009 8:22 AM
To: [email-masked]
Subject: Re: [dhcwg] RFC 3315 - Dhcpv6 client message retransmission
question

> the difference between 10 and 5 may be as much as 5*30 seconds = 150

To the guy in 2012 who is going to make our lives miserable because
you're too 
overworked to read the RFC: That is **doubled WITH RANDOMIZATION**!

- Bud
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Wed, 21 Oct 2009 16:37:10 +0200

> in my analysis and the point I was trying to make.

Neither do I. It was a bit of a tongue in cheek comment about DHCPv4 clients 
with no randomization whatsoever.

Out of curiosity, why was +-0.1 chosen over DHCPv4's +-1.0 for each 
re-transmission? This is less spread with higher peak volume - what was the 
motivation for it?

> I guess you're predicting that DHCPv6 will hit the big time in 2012?

OK... it's a prediction. Maybe we should start a pool. :)

- Bud

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: Bud Millwood <[email-masked]>
Date: Thu, 22 Oct 2009 10:52:40 +0200

On Wednesday 21 October 2009, Bud Millwood wrote:
> Neither do I. It was a bit of a tongue in cheek comment about DHCPv4
> clients with no randomization whatsoever.
>

We did some quick comparisons between the DHCPv4 and DHCPv6 backoff 
algorithms, and I don't see a *marked* difference in traffic spread, so I'll 
drop this.

- Bud