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

From: Erik Guttman <[email-masked]>
Date: Wed, 9 Aug 2000 08:53:23 +0200 (MET DST)

> 
> >  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: Daniel Senie <[email-masked]>
Date: Wed, 09 Aug 2000 11:27:05 -0400

Erik,

I'm concerned that your statements over periodic messages conflicts with
the draft. Specifically, the draft states that scalability is not a
major issue for zeroconf, as it is expected that zeroconf will be used
in small evironments.

Read section 1.2.4 of the -04 draft, then reread your comments about
periodic messages. One of the two is problematic.

I make no judgement over whether periodic messages are bad, or whether
the scalability text in 1.2.4 is incorrect. I would like to start a
discussion on the relative merits of the two. I think it's very
important to the direction of zeroconf.

Dan

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Erik Guttman <[email-masked]>
Date: Wed, 9 Aug 2000 17:51:35 +0200 (MET DST)

> major issue for zeroconf, as it is expected that zeroconf will be used

I don't think anyone will defend periodic messages per se.  We want
to detect claim/defend collisions and recently become available services
in a timely way.

I argue in my comments on 04 that scalability isn't a requirement
for zeroconf protocols as it is for other protocols the IETF develops,
but it is a valuable feature.  When evaluating two protocols which
perform the same functions, the one which scales should be preferred
for inclusion in the 'zeroconf profile' or during standardization.

These goals do not conflict.  

We had a terrible time defining what 'small' meant and have since dropped
such language from the requirements draft.  

Whatever we do, zeroconf protocols *will* be used on larger networks.  
Its only good sense and  proper engineering to make the zeroconf 
protocol as scalable as we reasonably can.   Maybe we can't do any
better than periodic messages by each host - but that would be a
worse outcome than if we standardized a protocol which didn't require
this.

Erik