gnu@hoptoad.UUCP.UUCP (04/05/87)
brescia@CCV.BBN.COM (Mike Brescia) writes: > The goal is to completely eliminate use of the broadcast address. TCP/IP > implementations may be overusing this feature, between ARP, RWHO, etc. I heartily agree with this goal. While working at Sun I noticed a large number of broadcast packets passing around, and this caused a few amusing problems, especially when these packets were addressed to user-mode daemons which swapped in over the ether. Note, however, that the current volume of broadcasts has the worst impact on hosts with old or badly designed Ethernet interfaces, e.g. 3Com boards with one or two receive buffers. These interfaces typically don't filter multicast packets anyway -- you can set a bit saying "receive multicast" or "toss multicast" and no more. Moving broadcast applications to multicast will only benefit hosts with more modern, e.g. AMD or Intel VLSI, interfaces. > Go to the ethernet number czar and get two (2) groups of 65536 (2^^16) > multicast addresses. By that, I mean the high order 32 bits are assigned by > the czar, and the low 16 bits are ours to play with. It might be worth looking at the filtering algorithms in the common Ethernet chips before figuring out the configuration of the multicast numbers. Typically they hash the addresses down to ~6 bits and the user supplies a 64-bit filter mask. We should try to match the number assignment to the hash functions. > Thus ARP, > instead of polluting all the hosts in the net, would send to the address > <ether-link>.8.6 (0x0806 is the number assigned to the address resolution > protocol). Virtually every host has to implement ARP so they will all be listening on <ether-link>.8.6 and there would be no benefit over just broadcasting. In the case of ARP, it would be better if the multicast address included the low byte of the Internet address you're looking for, so that hosts which don't know anything about that Internet address could ignore the packet in hardware. Note that most machines on one Ethernet will have the same high 3 bytes of their Internet address, so supplying the whole thing would be overkill. If a scheme like this gets worked out, I suggest that we allocate a bit in the ARP packets for "I listen to multicast for IP broadcasts", to tell a sending kernel which scheme to use (like the trailer protocol stuff). This begs the question of how the sending kernel decides how to send the ARP Request packet, but we're designing on the fly here anyway. Of course, a receiving kernel that handles multicasts should also accept the old broadcast packets for compatability.
deering@PESCADERO.STANFORD.EDU.UUCP (04/06/87)
From Hans-Werner Braun <hwb@MCR.UMICH.EDU>:
You have to watch out, though. Most interfaces I know of only support a
limited set of multicast addresses (DEQNAs, I think, just have a table
for fourteen or so addresses in general). You don't really want to end
up having to listen to each and every packet in a multiprotocol gateway,
just because your multicast address table in the EThernet device
overflows.
You don't have to listen to every packet, just every *multicast* packet,
when your multicast filter is exceeded. The DEQNA and other interfaces
provide such a reception mode. If we are just replacing broadcast packets
with multicast packets, listening to all multicasts is no worse than the
current situation of having to listen to all broadcasts. However, using
multicast addresses is much better for those hosts that *are* able to filter
multicasts adequately. Besides, it is not unreasonable to expect a
sophisticated multiprotocol gateway to have a sophisticated Ethernet
interface. The important thing is to stop sending unwanted packets to
non-gateway hosts.
I agree that we should conserve multicast addresses by looking out for
situations in which more than one application may reasonably use the same
multicast address, but I don't think we should be bound by the limitations
of current hardware. Once there is a demand for good multicast filtering,
the manufacturers will improve their products.
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
It might be worth looking at the filtering algorithms in the common
Ethernet chips before figuring out the configuration of the multicast
numbers. Typically they hash the addresses down to ~6 bits and the
user supplies a 64-bit filter mask. We should try to match the number
assignment to the hash functions.
That's a good idea if they all use the same hash function. Both the AMD
7990 and the Intel 82586 send incoming multicast addresses though their
CRC generators and take 6 bits of the result as a hash value, as you
described. From the documents I have, it is not obvious that they
both use the same 6 bits of the CRC in the same order. (Can anyone say
for sure?) Are there other hashing functions in use in other interfaces?
Virtually every host has to implement ARP so they will all be listening
on <ether-link>.8.6 and there would be no benefit over just
broadcasting.
Hosts that aren't running IP aren't interested in ARP-for-IP packets.
Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO
protocols. We don't like their broadcasts and they don't like ours.
If a scheme like this gets worked out, I suggest that we allocate a bit
in the ARP packets for "I listen to multicast for IP broadcasts", to
tell a sending kernel which scheme to use (like the trailer protocol
stuff).
I don't think any new bits are needed. Just send your ARP requests to
the multicast address, and if you don't get an answer, try the broadcast
address.
Steve Deering