From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 14:53:03 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 27AED16A420; Mon, 7 Nov 2005 14:53:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8211643D6E; Mon, 7 Nov 2005 14:52:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA7EqrPG061101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2005 17:52:53 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA7EqrgO061100; Mon, 7 Nov 2005 17:52:53 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2005 17:52:53 +0300 From: Gleb Smirnoff To: Robert Watson Message-ID: <20051107145253.GB91530@cell.sick.ru> References: <20051107140451.GU91530@cell.sick.ru> <20051107143620.P9690@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051107143620.P9690@fledge.watson.org> User-Agent: Mutt/1.5.6i 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 14:53:03 -0000 On Mon, Nov 07, 2005 at 02:40:43PM +0000, Robert Watson wrote: R> > I have a proposition on changing the behavior of ARP retransmitting. R> >Currently we after sending several ARP requests, sending ARP requests R> >for given IP is suppressed for some interval (by default 20 seconds). R> >Probably this feature was designed in early 90th, when sending one R> >additional broadcast packet was an expensive thing. R> > R> > I suggest to keep sending ARP requests while there is a demand for this R> >(we are trying to transmit packets to this particular IP), ratelimiting R> >these requests to one per second. This will help in a quite common case, R> >when some host on net is rebooting, and we are waiting for him to come R> >up, and notice this only after 1 - 20 seconds since the time it is R> >reachable. R> R> While networks have gotten a lot faster in the last few years, I've R> noticed that many of the ones I deal with have also gotten a lot larger in R> terms of number of hosts. This has been possible both because of the R> absolute increase in bandwidth, and also because of the widespread use of R> switches to suppress unnecessary unicast traffic to segments. I worry R> that significantly increasing the amount of broadcast traffic will be a R> problem for sites with large bridged network configurations. On the other R> hand, they already have to deal with things like windows network R> neighborhoods, various service discovery protocols, and so on. R> R> Do you have any information on what other operating systems may have done R> in terms of tweaking ARP for improved responsiveness? I imagine we can't R> be the first to discuss such changes, and if there is already a widely R> deployed system with ARP adaptations of this sort, it would be interesting R> to know if they've seen any problems or have recommendations. Frankly speaking, I have written my email after looking at Linux behavior. It sends one ARP request per second while there is demand for this ARP entry. After demand has disapparead, it sends a few retransmits driven by timer. If again there is a demand, it starts to retransmit again. Under "demand" here I mean a traffic to this particular IP, either locally generated or routed. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE