Subject: Re: Scalability vs. Periodic Messages (was Re: periodic messages)

From: James Kempf <[email-masked]>
Date: Wed, 9 Aug 2000 08:39:28 -0700 (PDT)

Dan,

I believe there was earlier a discussion on the list that zero-conf does
not necessarily mean small. Therefore, I think scalability is important.
If the draft does not say this, then I think it should.

		jak

>Delivered-To: [email-masked]
>Date: Wed, 09 Aug 2000 11:27:05 -0400
>From: Daniel Senie <[email-masked]>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Erik Guttman <[email-masked]>
>Cc: "Hattig, Myron" <[email-masked]>, [email-masked], 
[email-masked]
>Subject: Scalability vs. Periodic Messages (was Re: periodic messages)
>Content-Transfer-Encoding: 7bit
>
>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
>
>
>Erik Guttman wrote:
>> 
>> >
>> > >  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
>
>
>-- 
>-----------------------------------------------------------------
>Daniel Senie                                        [email-masked]
>Amaranth Networks Inc.                    http://www.amaranth.com
>

---

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 10 Aug 2000 10:25:46 -0400

> 
> Please note that it is possible to create a scalable zeroconf 
> protocol.
> These protocols don't have to be relegated to link-local operation, 
> either.
> 
> We succeeded in this respect with SLP.  When you turn on stateless 
> directory agents, you effectively turn off multicast-based requests.  
> This is a fundamental requirement of the SLP, which uses the same 
> protocol peer to peer as when a DA is present.  
> 

This makes me reformulate a question a sent previously:
Is a protocol that provides support for both serverless and server-based
operation considered zeroconf? Or, just the serverless mode and the
transition to server-based mode is zeroconf, while the server-based mode is
non-zeroconf?

Example for DHCP:
Is AutoIP zeroconf and DHCP non-zeroconf? Or, DHCP+AutoIP is zeroconf and
DHCP without AutoIP is non-zeroconf?

In SLP case:
SLP with DAs is not zeroconf because it relies on DAs (centralized). SLP
without DAs is zeroconf but is not scalable (potentially) because there is
no DA. Making SLP scalable involves turning on DAs thus making SLP
non-zeroconf.
Conclusion: zeroconf SLP is non-scalable; non-zeroconf SLP is scalable.
Scalability involves full and automatic transition to non-zeroconf.

Am I right?

---

From: Erik Guttman Sun Frankfurt Staff Engineer <[email-masked]>
Date: Thu, 10 Aug 2000 19:13:49 +0-200

Dan,

>transition to server-based mode is zeroconf, while the server-based mode is

One step at a time.

The distinction I want to draw is a priori vs. a posteriori configuration.

Whether you have a peer to peer or client server protocol is a *secondary
characteristic.*  The primary thing is *where does the configuration come
from?*  In SLP, it comes from the peers.  The DA only caches that info
and makes it more efficient and robust to access.  The DA's presense or
absence does not change the result of any particular operation (except
how long it takes an how likely it is to not get clobbered due to network
congestion).

>DHCP without AutoIP is non-zeroconf?

DHCP is not zeroconf.  The hosts in the network *get* their configuration
from the DHCP server.  

A separate question, which some folks seem to get hung up on is 'How does 
the DHCP server get configured?'  If the DHCP server makes up addresses
on its own, isn't that zeroconf?  I say no - since the *other* hosts on
the network have nothing to say about it.

Once you turn on a configuration server, which determines the configuration
for the network (DHCP, NIS, MADCAP, whatever) you are no longer in a zeroconf
network, hosts are no longer building up configuration, servers are handing 
it out.

That is not to say non-zeroconf protocols are bad.  They are wonderful!  We
simply need to draw the line and leave work on these protocols to some other
group.

>In SLP case:
>SLP with DAs is not zeroconf because it relies on DAs (centralized). 

No - SLP doesn't rely on DAs.  If the DAs go away, everything continues
to work.  Being a central point of data registration and access doesn't
mean that it is configured.  DAs are stateless except for what they
gather from the peers on the network.

Disagreeing with your first premise, I don't come to your conclusion.

>Scalability involves full and automatic transition to non-zeroconf.

Conceivably you could do this DNS, too.

*If* a DNS servers were to announce themselves (using multicast say) 
and *if* all hosts were to use dynamic update to register their RRs you 
could achieve the same result as with SLP:  A posteriori configuration
drawn entirely from the network.  As long as the set of RRs in the
DNS server is the same as the set of RRS one could obtain from hosts
issuing a peer to peer name to address resolution protocol, the DNS
server would only serve to make name resolution more efficient and
reliable.  But the DNS server could come and go and the resolvers
would continue to get the same results from their requests.

DHCP and MADCAP are *allocation* protocols.  That is, if you do the
allocation with a server and the server fails, you lose your state.
Zeroconf protocols (as I am arguing we define them) do not rely on 
this state - they *acquire* it from the net in a fully distributed
fashion.  There is no central authority with respect to network
configuration.

Erik

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 10 Aug 2000 11:27:13 -0700

> Scalability involves full and automatic transition to non-zeroconf.

I'm crossing over threads here, but that's okay I think ...

Great questions/examples. These are the types of things I've struggling with
... specifically with IP host config. One scheme we had included getting
info from routers. If we consider the router as has having "state", then
that protocol would not have been a zc protocol. However, that protocol
reverted to autonet (aka autoIP, aka link-local addressing) when the router
was not available to provide the state info. So was that protocol zeroconf
or not??? 

Extending Erik's arguement using DHCP. A network with a single DHCP server
is not zc because if the DHCP server fails, then the whole protocol fails.
Okay now say there are two DHCP servers - this is still not zc because both
servers could fail. Now say there are 3, then 4 DHCP servers - still not a
zc because they could all fail. Now lets say every host has a DHCP server
and they will respond to their own queries if no "real DHCP" responds - now
(I think) according to Erik's definition, this becomes solution is a ZC
protocol.  An early version of mDNS has the function of a DNS server in each
host, each host would respond to DNS queries for itself - thus mDNS is a ZC
protocol. What do you call these protocols when the "real" server exists?
Are they suddenly non-ZC protocols?

When state info is stored in different places such a server, router, or
registry, this definition becomes harder to apply. In addition, I question
the value of such a definition. Will it help protocol designers? Will it
help end users? Will it help solve the problems as stated in the quote from
STD-2? (nice quote btw)

      1.2.4  Configuration
 
         It would be ideal if a host implementation of the Internet
         protocol suite could be entirely self-configuring.  This would
         allow the whole suite to be implemented in ROM or cast into
         silicon, it would simplify diskless workstations, and it would
         be an immense boon to harried LAN administrators as well as
         system vendors.  We have not reached this ideal; in fact, we
         are not even close.

I don't think so. Even the STD-2 quote mentions making life easier for
network admins (translates to users) and vendors (translates to fewer
customer support calls). My opinion remains the same - we should just say no
"user configuration".

-myron

---

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 10 Aug 2000 17:17:56 -0400

Erik,
Thanks for the response.

> and makes it more efficient and robust to access.  

The example makes sense and it helps a lot.
The criteria is *where from* (peers) and perhaps *how* (purely
collaborative) the configuration is generated. The means it gets to a
consumer is irrelevant. Right?

However, I still have trouble mapping the above SLP exemplification to the
proposed definition. 
Is it obvious that *where does the configuration come from* point translates
to *a host obtains all configuration a posteriori*? I am tempted to link "a
posteriori" to time (when) rather than source (where from) or method (how). 

BTW, "a priori" and "a posteriori" of what? Of the protocol's
initialization/bootstrap?

I understand that "a posteriori" refers to when the host obtains the
information. It does not imply that the configuration was *built* by peers.
Furthermore the configuration is built by peers "a priori". So, a zeroconf
protocol requires "a priori" configuration.

What is meant by configuration? Is it something like the IP address for a
server (e.g. DNS server). This IS NOT needed "a priori".
Or, it refers also to the information already *built* and in use by the
network (e.g. data cached by a SLP DA based on previous registrations). This
IS needed "a priori".

Well, if I am the only one having trouble with the interpretation, I guess
the definition stands up. But I would still love to see your above
clarification in the draft.

> The DA's presense or

I believe SLP DAs were brought up as the method of making SLP scalable. I
was referring to the above exception in parenthesis. The DA absence makes
SLP not scalable. Right?

> DHCP is not zeroconf.  The hosts in the network *get* their 

It must be my fault. It was the second attempt and I still did not get the
question right. Let me try one last time:
The draft talks about protocols "in the same area" and how some are zeroconf
and others not: DHCP and AutoIP, DNS and mDNS, SLP and SLP (?).
The draft also talks about transitions within those protocol pairs.
Question:
Are those protocols separate and when you make the transition you switch
protocols. Or they are only modes of operation for a single protocol?
Response 1: They are different protocols. Then what is the non-zeroconf peer
for SLP?
Response 2: The same protocol enhanced with zeroconf features; different
modes of operation. Then the combination of DHCP and AutoIP (one protocol)
is zeroconf or not?
 
> the network have nothing to say about it.

The other hosts don't have any contribution for AutoIP either. 
Except for IP conflict detection; but a DHCP client may check for IP
conflicts as well and it can reject the lease. (I am figuring a DHCP server
that makes up the IPs but it uses the same random algorithm as AutoIP does)

> network, hosts are no longer building up configuration, 

This makes sense again. The key is how the information is *built*. Purely
collaborative (e.g. SLP registrations) or not. Right?
However AutoIP does not use any collaborative method to build IP addresses.
From this point of view the difference between AutoIP and a DHCP server that
generates random linklocal IP addresses is questionable.

> gather from the peers on the network.

Does SLP rely on DAs *for scalability* or not? 
If DAs go away from large networks does everything continue to work?

Does SLP rely on boundary routers to prevent packet spillage? Does SLP
automatically take any scalability-related action when there are no boundary
routers; like using a lower TTL (<255)?

If SLP didn't require that as soon as a DA is detected everybody must switch
to unicast what would happen? I see this SLP requirement as a mandatory
transition (to non-zeroconf if I may, I don't know how to call it). But
zeroconf requirements leave room for coexistence. 
What if SLP were designed based on zeroconf requirements but the transition
to DA-mode wasn't mandatory?

> Conceivably you could do this DNS, too.

Indeed. *If* the mDNS design mimics SLP and *if* you agree to drop some SLP
enhanced functionality, then you can do with mDNS whatever SLP does. Would
we need SLP for zeroconfig purposes then? *If feasible*, the idea of doing
both zeroconfig name resolution and service discovery with a single protocol
sounds appealing.
 
> fashion.  There is no central authority with respect to network

Indeed DHCP and MADCAP fall under a different category than DNS and SLP.
Would it be OK to specify that *allocation* protocols MAY coexist, while the
others MUST transition?

Wouldn't be easier to have separate definitions for what zeroconf is for
each specific category? E.g.:
An *allocation* protocol is zeroconf if the following conditions are met: 1
2 3 etc
A *resolution* protocol is zeroconf if the following conditions are met: 1 2
3 etc

Or, at least having a common, general and possibly interpretable definition.
And then giving a clear definition and examples for each protocol category.
(Something like you've given all over this reply and I found it very useful,
thanks)

...

> 
> If we leave it open whether protocols can require central servers
> or not, we leave it open whether ZC protocols can have central
> points of failure, misconfigured servers, two servers (not good
> when we're talking DHCP), etc etc. 
> 

That's exactly the point! The definition must be very clear that a central
server is unacceptable. The problem is how you formulate it to make clear?

dan