ARP request retransmitting

[Chuck Swiger]

Hi--

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.

Well, we've got ten or a hundred times as much bandwidth, so sending more data 
is relatively cheap, but the per-packet overhead hasn't improved to the same 
extent.  ARP requests still get sent to and are processed by all machines on 
the network, even if a switch is being used.

>   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.
> 
>   Any objections?

No, no objection.  However, this type of situation could be handled by either 
an incremental or exponential timeout.  Instead of waiting:

1 1 1 1 1

...seconds between packets as you proposed, consider waiting either of:

1 2 3 4 5
1 2 4 8 16

...seconds, and cap the maximum wait between ARP requests to 16 or so.  Backing 
off politely and gradually when the host is not getting any answers is more 
network-friendly.

-- 
-Chuck