From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 16:16:31 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC21816A420; Mon, 7 Nov 2005 16:16:31 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6217943D46; Mon, 7 Nov 2005 16:16:30 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 887CF5E5F; Mon, 7 Nov 2005 11:16:29 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25081-10; Mon, 7 Nov 2005 11:16:27 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id C974E5C67; Mon, 7 Nov 2005 11:16:26 -0500 (EST) Message-ID: <436F7DDB.40703@mac.com> Date: Mon, 07 Nov 2005 11:16:27 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051107140451.GU91530@cell.sick.ru> In-Reply-To: <20051107140451.GU91530@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 16:16:31 -0000 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