Date: Mon, 7 Nov 2005 12:49:17 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Chuck Swiger <cswiger@mac.com>, Gleb Smirnoff <glebius@freebsd.org> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: ARP request retransmitting Message-ID: <p06230904bf9542d696b6@[128.113.24.47]> In-Reply-To: <436F7DDB.40703@mac.com> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06230904bf9542d696b6>