Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Conference Call Agenda)

From: Bernie Volz <[email-masked]>
Date: Mon, 18 Sep 2000 18:38:07 -0400

>These problems could be solved with a mixed multicast/unicast strategy - 
>multicast the first reconfigure message and unicast any retransmitted 
>reconfigure messages.  For this to work, the client behavior should, I 
>think, be specified to be "respond to every reconfigure regardless of 
>whether it has been retransmitted".

You might also solve them by:
- Having the client remember the "transaction id" / server source address
and dropping any reconfigure messages with the same transaction id received
within some time period (several minutes?). Of course, all subsequent
retransmitted reconfigure messages MUST use the same "transaction id".
- Having the client ignore additional multicast reconfigure messages (on the
same interface) for some time period after receiving one (again, several
minutes). This method has the added benefit that fake messages can't
repeatedly trigger reconfigurations except at some reasonable slow rate. Of
coures, it makes multiple renumbering events take longer (but that they'd
occur within minutes of each other is rather unlikely anyway).

I do think the technique in 12.4.2 is somewhat flawed anyway since if one or
more clients are down, the "expected" number of messages may never be
returned.

I think a better server strategy is to multicast several Reconfigure
messages several seconds apart (this presumes that a client hopefully won't
miss all if it is up and on the network). Then, if any clients fail to
respond within the alloted time, those clients are sent unicast packets.
(Perhaps the server can also make a determination of how many clients failed
to response and if it exceeds some threshold (>50?), it MAY multicast again
with the same transaction-id).

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, September 18, 2000 6:23 AM
To: DHCPv6 discussion list
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
on Conference Call Agenda)

At 10:23 PM 9/17/00 -0400, Jim Bound wrote:

>1/3 of bandwidth is pretty good though on a network.

The computer scientist in me says 1/3 is only a constant factor and doesn't 
contribute to scalability...

>I don't believe it does not scale?  Unless you believe that multicast
>does not scale as a general technology as some do?

I would hesitate to apply the observation that "multicast scales as a 
general technology" to this specific case without working through the 
details.  I think there is question about whether reliable multicast
scales...

As to the complexity of multicast reconfigure, I still believe the devil is 
in the details.  The text you cited in 12.4.2, for example, does not 
address the question of how a client responds to a retransmitted 
reconfigure message.  Does the client try to detect retransmitted 
reconfigure messages?  If so, does the client respond only to the first 
reconfigure message and ignore retransmitted reconfigure messages?  Suppose 
the client's reconfigure-reply message is lost - how does the client know 
that it should respond to a retransmitted reconfigure message?

These problems could be solved with a mixed multicast/unicast strategy - 
multicast the first reconfigure message and unicast any retransmitted 
reconfigure messages.  For this to work, the client behavior should, I 
think, be specified to be "respond to every reconfigure regardless of 
whether it has been retransmitted".

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Wed, 20 Sep 2000 20:40:03 -0400

>occur within minutes of each other is rather unlikely anyway).

Yes this would work.  But I think the idea Ralph proposed by server does
multicast once for trigger reconfigure-init and then unicast for those
that did not respond is a simpler solution for now?  A more complex
solution later can be adapted or extended later from what Ralph
proposed pretty easily.  But I do think your idea has much merit.

>more clients are down, the "expected" number of messages may never be

That would need to be fixed I thought we put wording about this
elsewhere but I will check, it might be we only did it for the
reconfigure and not the reconfigure-reply.

>with the same transaction-id).

We did put threshold in there for reconfigure.  But I agree this can
work as you suggest.

Also I think we have to assume one multicast message normally works or
we are not really assuming multicast works.  There should be no reason
to send multiple multicast messages unless there is a network problem.
I suppose if no one responds and then unicasting a few to see if it
works would be a good way to implemement this (not saying put this in
the spec).

regards,
/jim