Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!husc6!purdue!narten From: narten@cs.purdue.EDU (Thomas Narten) Newsgroups: comp.protocols.tcp-ip Subject: Re: a proposed modification to ARP Message-ID: <4462@medusa.cs.purdue.edu> Date: 11 Jul 88 02:02:35 GMT Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University Lines: 31 Is broadcast traffic associated with ARP responsible for so much traffic that it must be stamped out? Or is it the case that tuning existing implementations so as not to time out entries so fast, etc. would suffice? For instance: A typical implementation of ARP sends out an ARP request whenever a packet is destined for a host that has no entry in the local ARP cache. If a particular machine is down, many hosts start ARPing for it simultaneously. Moreover, if the machine is heavily used (a file server for instance) many useless broadcasts are sent out. On our local nets, ARP traffic is pretty minimal as long as all machines are up. When one goes down however, ARPs increase dramatically. Incidentally, NFS is the worst offender at generating many consecutive ARPs (TCP backs off and eventually gives up). Adding an additional HOST_DEAD state to the ARP tables could be used to handle these cases; ARPs for dead hosts would be limited to no more than one every minute or so. A sophisticated algorithm would arp very frequently initially, but use a backoff to increase the delay between successive ARPs as the number of consecutive non-responses increases. This scheme also has the beneficial side effect of allowing IP to return ICMP host unreachables for dead machines. 4.3 BSD ARP times out unaccessed cache entries every 20 minutes. Is there any good reason not to increase the value to several hours or longer? Broadcasts are expensive and memory is cheap. -- Thomas Narten narten@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!narten