Subject: Re: DC meeting: Discussion question #3, Reply to RECONFIGURE?

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Wed, 17 Nov 1999 09:47:38 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
---------------------------------------------------------------------------
Jim Bound <[email-masked]> writes:

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

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

The common term that describes this situation (single multicast packet
resulting in a flood of return ACKs) is ack implosion, even though
explosion might seem like a more appropriate description.

But I do think that this is a big deal. If you have ten nodes, no big
deal. But if you have 100? or 1000? Such a large number of ACKs sent
at the same time will almost certainly result in congestion and lost
packets. Even worse, if the request packet is retransmitted, the exact
same thing will likely happen again (i.e., slow servers lose), with it
fairly likely that the *exact* same packets that were lost the first
time being lost again. Hence, retrasmitting request messages is much
less effective than in the unicast case.

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

I think so. One other detail I didn't mention before. It may also make
sense to have the reconfigure message include a delay time value in
it. Clients don't respond immediately to the Reconfigure, but delay a
random amount of time between 0 and the delay time value in the
received message. That way a server can arrange that clients contact
it over a period of (say) ten minutes rather than all at once (which
could result in similar problems as ACK implosion).

Thomas

---

From: Jim Bound <[email-masked]>
Date: Wed, 17 Nov 1999 17:57:34 -0500 (EST)

>explosion might seem like a more appropriate description.

I know I have seen this before.  I don't agree with the "common term".
But not asking anyone to change it.  Just making my view known.

>less effective than in the unicast case.

My mail was not clear.  I mean't no big deal about whether its
"implosion" or "explosion" I agree with you on the above.
Funny this thing called "email" ----).............

>could result in similar problems as ACK implosion).

Thats a good idea.  Would be easy to add to the draft and easy to
implement.

/jim