Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!helios.ee.lbl.gov!ace.ee.lbl.gov!leres
From: leres@ace.ee.lbl.gov (Craig Leres)
Newsgroups: comp.protocols.appletalk
Subject: Re: the comming appletalk crisis
Message-ID: <1966@helios.ee.lbl.gov>
Date: 23 Feb 89 06:05:53 GMT
References: <8902211606.AA11107@dsunx1.DSRD.ORNL.GOV>
Sender: usenet@helios.ee.lbl.gov
Reply-To: leres@helios.ee.lbl.gov (Craig Leres)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 49

W. N. Naegeli writes:
> I am not a network protocol expert, but it appears to me that one of the
> principal problems with EtherTalk is that it uses broadcasts where multi-
> casts would do. If broadcasts were used only initially and then multicasts
> were used at perhaps a somewhat longer interval than the present 10 seconds
> I believe all the complaints I hear from other network users would go away.

Unless all the ethernet interfaces you're using have hardware support
for multicasts, I'm afraid you're out of luck. Do you want to limit
yourself to DEC hardware? Or perhaps go promiscuous and check EVERY
packet to see if it's the multicast you've been waiting for?

In any case, multicasts don't fix anything, they just help you the hide
bad side effects of a poorly designed protocol. A large DECnet network
uses a great deal of ethernet bandwidth just doing "background"
multicasts.

Remember that multicasts are really a special kind of broadcast and any
protocol that does a lot of broadcasting is broken. ARP is about the
only protocol I can think of that uses broadcasts without abusing them.
Even so, if enough other things go wrong, you can still have ARP
broadcast storms.

If you have great interest in the Multicast Religious Wars, please
check out the comp.protocols.tcp-ip archives.

> I am looking at AppleTalk as a cost-effective general-purpose solution for
> small and medium-size networks rather than for high performance or huge
> networks.  Above all, AppleTalk needs to be a good citizen on existing
> networks. Currently it really is somewhat of an 'enfant terrible,' but
> blaming it for problems experienced for users who are even less well behaved,
> notably the diskless SUN workstations that hog network resources, is
> inappropriate.  Sure, the idea of diskless workstations is great, but they
> should either use their own Ether cable or use a medium with much higher
> bandwith. It's really a solution for the future that doesn't match very well
> with the network technology of yesterday.

Based on my experience here at LBL, I must disagree with your remark
about diskless Suns. They do not hog network resources. Of the
bandwidth used on our main ethernet segment, most is taken up with
"background multicasts for LAVC and DECnet.

Perhaps you misinterpreted my comment about diskless Suns not being
able to boot when the broadcast rate exceeds 1 pps. The problem here is
not that Suns need a lot of bandwidth when they boot. Instead, it's
that the Sun rom boot code gets confused if it receives an unexpected
packet during a one second window.

		Craig