Re: a proposed modification to ARP


Thomas Narten (narten@purdue.edu)
11 Jul 88 02:02:35 GMT


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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:50 GMT