ARP request retransmitting

[Garance A Drosihn]

At 11:16 AM -0500 11/7/05, Chuck Swiger wrote:
>Hi--
>
>Gleb Smirnoff wrote:
>>   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.
>
>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.

I think Chuck's suggestion is a very good idea.  In a separate message
in this thread, Robert noted that:


    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.

While that "other hand" is true, here at RPI we deal with some of
those other-hand issues by simply turning them off.  We turn off
multi-cast by default on some of our networks, for instance.  But
there's no way we can turn off ARP, so I think more care needs to
be taken to make sure ARP remains network-friendly.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu