From archie@dellroad.org  Sat Mar  3 18:30:03 2001
Return-Path: <archie@dellroad.org>
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
	by hub.freebsd.org (Postfix) with ESMTP id AE79137B719
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  3 Mar 2001 18:30:02 -0800 (PST)
	(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
	by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA37086
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 3 Mar 2001 18:27:02 -0800 (PST)
Received: (from archie@localhost)
	by arch20m.dellroad.org (8.11.1/8.11.1) id f242QrJ32138;
	Sat, 3 Mar 2001 18:26:53 -0800 (PST)
	(envelope-from archie)
Message-Id: <200103040226.f242QrJ32138@arch20m.dellroad.org>
Date: Sat, 3 Mar 2001 18:26:53 -0800 (PST)
From: Archie Cobbs <archie@dellroad.org>
Reply-To: archie@dellroad.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: ARP cache timeout behavior can be improved
X-Send-Pr-Version: 3.2

>Number:         25517
>Category:       kern
>Synopsis:       ARP cache timeout behavior can be improved
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 03 18:40:01 PST 2001
>Closed-Date:    Wed Mar 20 08:00:07 PST 2002
>Last-Modified:  Wed Mar 20 08:00:07 PST 2002
>Originator:     Archie Cobbs
>Release:        FreeBSD 4.2-RELEASE i386
>Organization:
Packet Design, Inc.
>Environment:

	All current versions of FreeBSD

>Description:

	When an ARP entry expires after 15 minutes, the ARP entry
	is simply deleted from the ARP cache. Then the next packet(s)
	destined for the other host are delayed while a new ARP
	query and response takes place.

	This delay is unnecessary and disruptive for certain
	protocols that are sensitive to jitter. Moreover, as network
	speeds increase while ARP query/response cycles continue
	to take roughly the same amount of time, this effect will
	become more and more pronounced.

	This problem should be easy to fix... 

	> From: Stephen Casner <casner@packetdesign.com>
	> 
	> The suggested enhancement is to _not_ flush an arp cache
	> entry when its timer expires.  Instead, go ahead and send
	> the arp request, but continue using the cache entry to send
	> packets.  If there is no response to the arp request after
	> the number of retries specified in the protocol, then flush
	> the cache entry.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: orion 
State-Changed-When: Wed Mar 20 07:57:53 PST 2002 
State-Changed-Why:  
Fix commited to netinet/if_ether.c. 

From the review request associated with fix: 

"Outbound packets pass through arpresolve (netinet/if_ether.c).  This 
function makes the decision about whether a packet should be forwarded 
or buffered awaiting an arp response.  It does this on the basis on 
whether there is a valid ARP cache entry for the receiving machine on 
the local network.  Since it fetches the ARP cache entry and the ARP 
cache entry has field stating when it will expire, we can trigger an 
ARP request packet if we are within a finite interval of the expiry 
time.  The response for this pre-expiry ARP request will update the 
ARP cache entry and push back the expiration time. 

The additional ARP requests are data-driven, so pre-expiration 
requests are only sent for hosts that we are sending data to.  Entries 
in the ARP cache that the host is not currently sending to are timed 
out in the usual manner. 

The patch referenced below uses a counter to send ARP requests 
triggered by data packets.  The counter ensures that we send at most 1 
ARP packet per arpt_down (default = 20) seconds.  Thus, if an ARP 
response is lost or corrupted we have several well spaced attempts at 
updating the ARP cache entry before it expires.  The number of 
pre-expiry attempts is set to the number of regular ARP request 
attempts (arp_maxtries, default = 5). 

The counter variable used is the same counter ARP uses for sending 
initial ARP requests.  It's state is already reset when ARP responses 
are received so there is no problem in re-using the variable for 
entries that have not yet expired. 

A solution very similar to this is discussed in the last three 
paragraphs of the original ARP RFC (RFC826) and by Casner in 
kern/25517." 


http://www.freebsd.org/cgi/query-pr.cgi?pr=25517 
>Unformatted:
