Subject: Re: ARP problems.
To: Charles M. Hannum <mycroft@MIT.EDU>
From: None <email@example.com>
Date: 03/20/2004 14:09:18
> On Fri, Mar 19, 2004 at 07:02:06PM +0100, firstname.lastname@example.org 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
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 :-)