From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 17:49:22 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 45FF916A420; Mon, 7 Nov 2005 17:49:22 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 743C643D45; Mon, 7 Nov 2005 17:49:21 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id jA7HnIR5009575; Mon, 7 Nov 2005 12:49:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <436F7DDB.40703@mac.com> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> Date: Mon, 7 Nov 2005 12:49:17 -0500 To: Chuck Swiger , Gleb Smirnoff From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 Cc: arch@freebsd.org, Robert Watson 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 17:49:22 -0000 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