Subject: RE: periodic messages (was RE: comments on requirements draft 04)

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 9 Aug 2000 09:23:00 -0700

Erik,

I'm in violent agreement with you. We don't want protocols with a bunch of
broadcasts cluttering up the wire. I didn't think the requirements were
written in such a way that would automatically require such a protocol -
that's why in the previous note I made the distinction between ACTIONs and
MESSAGES. From your last email:

> Just because periodic messages are currently used doesn't mean its a
> good idea.  For instance, current Autoconf IPv4 clients periodically
> request DHCP servers by sending DHCP DISCOVER messages.  This could
> be improved by having DHCP servers announce themselves periodically.
> So rather than n broadcasts you have 1, per time interval.

Both have periodic ACTIONS, not necessarily MESSAGES. In general the draft
should state protocol requirements not prescribe solutions.

Again, I'm 99% sure that we agree and would be surprised if anyone disagreed
with your comments. The question is how do we word the requirements.
Obviously the current wording allows people to confuse actions with messages
so the text should change.

-myron

> -----Original Message-----
> From: Erik Guttman [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2000 11:53 PM
> To: Hattig, Myron
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: periodic messages (was RE: comments on requirements draft 04)
> 
> 
> > 
> > >  5. Several places in the document discuss periodic 
> messages.  This is
> > >     *not* the requirement - in fact it is a highly 
> > > undesirable protocol
> > >     feature.
> > 
> > Where is the requirement for a periodic message. 
> 
> In draft 4:
> 
>    These scenarios require the periodic actions as well as specific
>    actions at startup.
>    - The ability to detect the presence or absence of a DHCP server
>      at startup of a device and periodically after a devices starts.
>    - The ability to periodically ensure the uniqueness of a selected
>      host name.
>    - The ability for a host to determine if another host has
>      allocated an address that has been allocated by itself; this
>      SHOULD be done periodically.
>    - The ability to detect the presence or absence of a MADCAP server
>      at startup of a device and periodically after a devices starts.
>    - The ability for a host to determine if another host has
>      allocated an address that has been allocated by itself; this
>      SHOULD be done periodically.
> 
> > Periodic actions ARE required. 
> 
> Why are periodic messages required?  Imagine we have a situation where
> there is duplicate configuration, but no communication.  In this case,
> we do not need to detect the situation at all.  Once there is 
> communication
> the detection of the duplicates should be swift.  That is the 
> meaning of my
> comments which follow:
> 
> > I agree with the comments: 
> > 
> > >     In each case there are protocol design alternatives.  For 
> > > instance,
> > >     if ARP, mDNS, AAP replies were multicast instead of 
> unicast, then
> > >     hosts could detect collisions through the normal use of 
> > > the protocol.
> > >     Note these protocols either don't exist yet or do not 
> support this
> > >     operation today, but they could be enhanced to do so.  
> > 
> > The statement:
> >    > The requirement is detection of conflicts after 
> allocation, not that 
> >    > periodic messages be sent.  
> > is not accurate. There are no requirements for periodic messages.
> > 
> > I'll let someone else pick up this thread if further 
> discussion is needed.
> 
> Please note there has been extensive research in this area 
> showing that
> periodic messages are a complete disaster.  Do you want references?
> 
> Just because periodic messages are currently used doesn't mean its a
> good idea.  For instance, current Autoconf IPv4 clients periodically
> request DHCP servers by sending DHCP DISCOVER messages.  This could
> be improved by having DHCP servers announce themselves periodically.
> So rather than n broadcasts you have 1, per time interval.
> 
> I maintain the requirement is timely detection of conflicts and the
> ability to resolve them, as well as the ability to detect newly 
> available infrastructure.
> 
> This should be done as efficiently as possible.  Maybe we 
> will be stuck
> with having each host poll the network with broadcasts.  I hope not &
> certainly maintain we can't require that they do.
> 
> Erik
> 
>

---

From: Erik Guttman <[email-masked]>
Date: Thu, 10 Aug 2000 09:38:03 +0200 (MET DST)

Myron wrote:
> I didn't think the requirements were
> Erik wrote:

The important distinction here is that there are no actions taken at
all, unless there is a state change.  For example, if servers announced
themselves instead of being polled for, there would be no announcements
if there were no servers.  If peers could discover configuration conflict
with other peers by observing their messages - there would be no actions
to perform if the peers were not communicating.  

We should state the goal in the requirements draft, not the mechanism.
That is especially true if the mechanism is dubious.  

In place of text in the draft which mentions periodic actions or messages,
I suggest we add text which requires the proper behavior:

---
  p 9

   These scenarios require the periodic actions as well as specific
   actions at startup. The action is the same whether it be periodic
   or at startup. The action is an attempt to discover a DHCP server.
   If the DHCP server is discovered the host uses DHCP, otherwise the
   host uses the zeroconf IP host configuration protocol.

 ->

   These scenarios require that hosts be able to discover DHCP servers
   both initially, at startup, and during normal operation.

---
  p 10

  ->
   - The ability to detect the presence or absence of a DHCP server
     at startup of a device and afterwards, during normal operation.

---
  p 11
   - The ability to periodically ensure the uniqueness of a selected
     host name.
  ->
   - The ability to detect non-uniqueness of a selected host name
     at startup and afterwards, during normal operation.

---
  p 14 and p 16
   - The ability for a host to determine if another host has
     allocated an address that has been allocated by itself; this
     SHOULD be done periodically.
  ->
   - The ability for a host to determine if another host has
     allocated an address that has been allocated by itself
     at startup and afterwards, during normal operation.

---
  p 15 and p 16
   - The ability to detect the presence or absence of a MADCAP server
     at startup of a device and periodically after a devices starts.
  ->
   - The ability to detect the presence or absence of a MADCAP server
     at startup of a device and afterwards, during normal operation.

---
 
Erik