> On Fri, Mar 19, 2004 at 07:02:06PM +0100, ragge@ludd.luth.se wrote:
> > The ARP implementation in NetBSD will delete an existing ARP entry
> > after arpt_keep seconds (20 minutes), regardless whether there are 
> > traffic on the interface or not, and do a new ARP request if a new 
> > packet is sent out for that route.  While this is OK for slow links,
> > it is a disaster for high-speed long-distance communications.
> > 
> > As an example, when the ARP entry on the path of a TCP flow running
> > at 4Gbit over a distance of > 10000km times out, it may take 5-10ms
> > for the entry to be renewed, and during that time ~1500 packets may
> > be lost, which will effectively stop the transfer.
> > 
> > A solution to this is to send out a new ARP request some time before
> > the entry is removed (if the routing entry has been active since the
> > last ARP update), and let the reply refresh the ARP entry, hence 
> > avoid the arp entry update delay time.
> > 
> > I plan to implement this and send out patches unless someone else
> > have another better way of solving the ARP problem.
> 
> Given that we already waste time tracking "use" values, checking whether
> the "use" value has changed since the last check, before deleting the
> ARP entry would be sufficient.  However, this would bloat the routing
> table.
> 
I don't want any increased complexity of this at all, only solve 
the problem.  Using rmx_pksent for storing sent time would be sufficient.

> I would STRONGLY oppose any solution that puts additional overhead in
> any of the critical paths.
> 
Believe me, I would also do that :-)  

-- Ragge