Subject: DC meeting: Discussion question #3, Reply to RECONFIGURE? (Final)

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Tue, 16 Nov 1999 13:53:09 -0500 (EST)

3) Is a reply to a RECONFIGURE always desirable?

EXPLANATION: This question was intended to seek additional information
regarding Thomas Narten's concern about the RECONFIGURE_REPLY "implosion"
when a RECONFIGURE is multicast (or the server being hammered due to
RECONFIGURE_INIT message(s) being multicast). If scenario B described in
question #2 were used, and a RECONFIGURE message was sent out to change
the DNS server, one could argue that a RECONFIGURE_REPLY isn't necessary
or even preferred.

A server could also reduce its exposure to such "implosions" by sending
groups of clients different multicast RECONFIGURE addresses, ensuring that
the possible RECONFIGURE_REPLY/REQUESTs load is managable. Text describing
the problem and recommending a solution would need to be added to the draft.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Nov 1999 18:07:44 -0500 (EST)

> the problem and recommending a solution would need to be added to the draft.

I've been concerned for some time with the basic idea that the server
multicasts (widely) to a set of clients, and the clients are required
to ack. This results in ack implosion and there is no easy way around
the problem. I.e., this is the reliable multicast problem, which we
don't have good general solutions for.

I also think the same effect can be achieved by changing the semantics
of RECONFIGURE. That is, instead of having the RECONFIGURE mean "send
me an ACK", have it instead tell the client "the server has new info,
use your normal DHCP protocol exchanges to get that info
reliably". This message can be multicast a number of times, with the
client ignoring subsequent retransmissions. That way the server can
retransmit multicast RECONFIGUREs to ensure that everyone gets a copy,
and it can also check for subseqent client REQUEST messages if it
really wants to know who has received its RECONFIGURE. I.e., the
subsequent REQUESTs are the ACK the server is looking for.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Tue, 16 Nov 1999 22:44:51 -0500 (EST)

>subsequent REQUESTs are the ACK the server is looking for.

I view it as ACK explosion (client exploding acks towards the servers)
but no big deal. 

A compromise might be to attach a suffix to this reconfigure type like
RCONFIGURE-INIT and have it mean as you say do a request via dhcp.
Then down the road if we figure out scalable multicast we add a new
message type called RECONFIGURE-INIT-W/ACK or some such name and new msg
type.

If we did this then would you and others be OK with how we would do the
hack now to prevent clients from responding to multiple multicasts of
this nature? 

/jim

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Nov 1999 12:36:38 -0500 (EST)

> 3) Is a reply to a RECONFIGURE always desirable?

Addressing just this specific question, I have to wonder whether such
a Reconfigure would be useful in practice. If I were a site
administrator, the idea that a change in the configuration would not
be reliably communicated to all clients is troubling. If you have new
information that clients should use immediately and needs to be sent
out ASAP, presumably it is important for nodes to get that information
and in particular stop using the older information.

One possible argument for having a non-reliable notification is that
maybe the information isn't really that important, and its OK for
clients that miss the Reconfigure to get it the next time they contact
the DHCP server for other reasons (e.g., to extend an address
lifetime). But if that is the case, does the information need to be
pushed to the clients in the first place?

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 1999 01:10:49 -0500 (EST)

> don't have good general solutions for.

Multicast protocols tend to deal with this by having the sender
of the multicast packet include a parameter to control over how long time
the receivers should do a random delay. That way, since the DHCP server knows
who many clients are listening on each multicast address, it can 
suggest a reasonable random delay to avoid overload.

Presumably such a mechanism is needed for both the RECONFIGURE/RECONFIGURE_ACK
and the RECONFIGURE_INIT/REQUEST/REPLY exchanges since they can both
cause implosion when the first message is multicast.

> subsequent REQUESTs are the ACK the server is looking for.

Making the RECONFIGURE* message(s) idenpotent seems like a good idea.
But even with a RECONFIGURE_INIT/REQUEST/REPLY exchange we need random
delays to avoid a request implosion.

  Erik

---

From: Charles Perkins <[email-masked]>
Date: Fri, 19 Nov 1999 17:09:27 -0500 (EST)

> suggest a reasonable random delay to avoid overload.

I can live with this, but there are two other points worth noting.

1. We already spread out responses over the time interval
   sefined by RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP.

2. It is expected that DHCP servers would assign populations of DHCP
   clients to different multicast groups, in order to spread out the
   workload for reconfiguration to the different groups.  Being able to
   limit the size of the multicast group was a prime consideration
   for creating this feature.  Being able to manage renumbering
   separately for different departments was an excellent side benefit.

Therefore, I suggest that any such random delay parameter as you
suggest should be left for later, to see if its needed in real
deployments.  This is the kind of thing that comes better with
experience, I think; it is doable as a new DHCP extension at a later
time.

> delays to avoid a request implosion.

As noted, we already do have some degree of randomness.

Regards,
Charlie P.