ARP request retransmitting

[Robert Watson]

On Mon, 7 Nov 2005, Gleb Smirnoff wrote:

>  I have a proposition on changing the behavior of ARP retransmitting. 
> Currently we after sending several ARP requests, sending ARP requests 
> for given IP is suppressed for some interval (by default 20 seconds). 
> Probably this feature was designed in early 90th, when sending one 
> additional broadcast packet was an expensive thing.
>
>  I suggest to keep sending ARP requests while there is a demand for this 
> (we are trying to transmit packets to this particular IP), ratelimiting 
> these requests to one per second. This will help in a quite common case, 
> when some host on net is rebooting, and we are waiting for him to come 
> up, and notice this only after 1 - 20 seconds since the time it is 
> reachable.

While networks have gotten a lot faster in the last few years, I've 
noticed that many of the ones I deal with have also gotten a lot larger in 
terms of number of hosts.  This has been possible both because of the 
absolute increase in bandwidth, and also because of the widespread use of 
switches to suppress unnecessary unicast traffic to segments.  I worry 
that significantly increasing the amount of broadcast traffic will be a 
problem for sites with large bridged network configurations.  On the other 
hand, they already have to deal with things like windows network 
neighborhoods, various service discovery protocols, and so on.

Do you have any information on what other operating systems may have done 
in terms of tweaking ARP for improved responsiveness?  I imagine we can't 
be the first to discuss such changes, and if there is already a widely 
deployed system with ARP adaptations of this sort, it would be interesting 
to know if they've seen any problems or have recommendations.

Robert N M Watson