Date: Mon, 07 Nov 2005 11:16:27 -0500 From: Chuck Swiger <cswiger@mac.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting Message-ID: <436F7DDB.40703@mac.com> In-Reply-To: <20051107140451.GU91530@cell.sick.ru> References: <20051107140451.GU91530@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?436F7DDB.40703>