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