Subject: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315

From: <[email-masked]>
Date: Fri, 2 Feb 2007 18:46:56 +0900

Hi all,

I'd like to know your thought regarding MRC meaning.

RFC3315 section 14 says,
-----------
(snip)
      MRC    Maximum retransmission count  
(snip)
   MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.
---------

Does this mean that MRC is the number of retransmitted messages?
For example, in the case of MRC  is 3 and message type is Solicit,
which behavior is correct?
[Case 1]
Client
	transmit 		1st Solicit 	---->
	retransmit(MRC=1)	2nd Solicit 	---->
	retransmit(MRC=2)	3rd Solict	---->
	retransmit(MRC=3)	4th Solicit	---->
	no more transmit of Solicit

or

[Case 2]
Client
	transmit (MRC=1)	1st Solicit 	---->
	retransmit(MRC=2)	2nd Solicit 	---->
	retransmit(MRC=3)	3rd Solict	---->
	no more transmit of Solicit

Could you let me know which behavior is correct, please?

Best regards,
....Hideshi

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 2 Feb 2007 11:30:59 -0500

You do point out an inconsistency as several of the parameters that are
used to "set" MRC say retry attempts whereas others say attempts, such
as REL_MAX_RC.

And, if this was just the retries, there would be no way to configure no
retries (since a MRC if 0 means "unlimited").

This is useful to resolve for a RFC 3315-bis.

I guess I'd "vote" to make all of these "attempts" as that would allow 1
to mean send it only once (though that likely is of marginal value).
Thus, if the value is configured to be 3, it means send the packet 3
times (2 retries).

In general I doubt that this will make a significant difference and I'm
not sure I'd build the Tahi tests or DHCPv6 ready logo program to
provide explicit tests for this -- and as many of these COULD be
configurable in various implementations, it may be possible to adjust
the settings to mean either interpretation (except of course the no
retries setting).

- Bernie 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, February 02, 2007 4:47 AM
To: [email-masked]
Subject: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315

Hi all,

RFC3315 section 14 says,
-----------
(snip)

or

[Case 2]
Client

Best regards,
....Hideshi

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 2 Feb 2007 09:00:58 -0800

> 	no more transmit of Solicit

I don't know the answer, but this is the case I selected for our
client.

It seemed to me that rfc3315 was talking about retries and not
transmissions (taking at least one transmission for granted).

I agree with Bernie that case 2 would be more flexible for future
protocol development, even if we can't imagine a use for it.  It
would also be clearer.

Since modern implementors are prone to use the same function for
the transmission as the retransmission, it's of less use these
days to differentiate between the two types of transmission.

In hindsight, I think 3315 could have used an all-ones value for
'infinite retries' in the same way all ones values are used for
infinite lease times.  Thus we'd get MRD=0 for no retries.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 2 Feb 2007 09:48:23 -0800

> This is useful to resolve for a RFC 3315-bis.

While we're on the subject of retransmission state, I have two
more petty things, one of which can probably be ignored.

The 3315 text says the random factor should be beteen -0.1 and 0.1,
which suggests non-inclusive.  I'm not sure that was the intent of
the authors nor the WG.  A simple ", inclusive" suffix to the
existing text would make it clearest.

Because of the 'between x and y' wording (vs for example "from x to
y"), our implementation has chosen to interpret this as
'non-inclusive', which only aggravates my second petty issue.

Next, our DHCP software architecture can only schedule events on a
second-granular scale.  This is a limitation we already despise for
a number of reasons...it's something we want to get away from, but
the reality is that this is going to be future work.

1 * 0.1 is always going to be zero if you can only schedule
second-granular integer times.

So for example our Solicit behaviour is always 2, 4, 8, then at
what would be 16, it starts to get random.

The reason we start at 2 on Solicit is a different section of 3315
that first requires a RAND value strictly greater than zero be
selected for the first interval, and a second requirement that the
result be greater than IRT.  Where IRT=1, and the highest random
time difference we can select is zero (0.1 * 1 = 0), the only way
to select an RT that is greater than IRT is to add 1.

That's where we wound up anyway.

I'm not sure what should be done here if anything.  It just
doesn't sit right.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Feb 2007 11:04:58 -0700

> I'm not sure what should be done here if anything.  It just

What you need to do is fix the scheduler.   Until you fix it, you  
aren't conformant.   This isn't the end of the world, though - I  
think it's fine to leave it for future work, as long as you're going  
to do it.   And since the draft doesn't specify the precision,  
"between 0.1 and -0.1" even if you treat it as exclusive amounts to  
being inclusive, since you're perfectly justified in saying that the  
resolution is fifteen decimal places.   I think the reason we didn't  
specify this is that it's just not important.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 2 Feb 2007 13:14:38 -0500

Personally, I don't think some of these issues are that important.

I think the basic goals were:
- Use randomized values so that if there are lots of the same clients,
they won't all hammer on the network and servers at the same time.
Whether you err a bit in the actual value is no big deal. (Note the
"bit"!)
- Retransmit with appropriate delays between attemtps and use a backoff
algorithm.

However, if you're supposed to randomize between -0.1 and 0.1 (whether
inclusive or exclusive), I do think you'll have a problem if you only
have timers with 1 second resolution. Since I presume that means you
might wait 0 or 1 seconds, which basically only spreads the clients out
into two "lots" if they are all the same implementation.

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 2 Feb 2007 11:01:44 -0800

On Fri, Feb 02, 2007 at 11:04:58AM -0700, Ted Lemon wrote:
> What you need to do is fix the scheduler.

I can only rewrite your code so fast.  :(

>  Until you fix it, you  
> aren't conformant.

On a matter of principle and reasonable-ness, I agree.

On a matter of strict interpretation of the document, I do not.

---

From: Ralph Droms <[email-masked]>
Date: Sat, 03 Feb 2007 08:59:31 -0500

Unless this seems like something that needs to be resolved quickly, I'll
throw this thread in the "RFC3315bis" bin.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Sat, 3 Feb 2007 23:37:59 +0000

> throw this thread in the "RFC3315bis" bin.

I'm not sure it needs to be solved at all, much less soon.

It would be a fine thing for rfc3315bis, so long as we don't take
WG bandwidth away from more important issues.

Inclusive vs non-inclusive is a trivial thing.

Minimum clock resolution is something that has a better tendency
to reach logheads.