rfnm	If notice rfnm count getting too high on acc box, use following
	additional kludge:
	1.  IMP times out connection <after 180 seconds of inactivity or
	    if short of space> if rfnm == 0
	2.  redesign host timeout to go by inactivity of entry.
	    All entries are timing out.
	    Reset timer to max on a.  rfnm message... b.  send pkt

	Have noticed dropped rfnnms.  (Can still go out to other hosts.)

	DONE at bbn for 4.2

CHECKSUMMING
	((struct sockaddr_in *) &(loif.if_addr))->sin_addr == pkt dst
	=> don't need to checksum on output or input

	Do this when start to use protocols for intra-machine a lot.  Since
	most use is currently for inter-machine use, don't bother since
	probably averages out to be additional unec expense right now.
	(RDP/TCP/UDP)  Does domain name server traffic now justify this?

RDP checksumming
	if retransmissions occur "a lot", just as save datagram length,
	can save checksum of data region for the retransmission.  Note,
	this depends on the header length being a multiple of 4 bytes
	with/without eack options ******  CAN'T BE DONE (hdr 18 bytes).

IP forwarding (gateway action in ip_forward())
	Another reason (in addition to wasted time) ip_input should be called
	with pointer to ifp that packet came in on.

TCP persistence
	Could follow retransmit timer methods and have the persistence
	timer back off, too.  (could ++ instead of <<, though)
	Probably not important though unless someone finds a lot of
	persistence is going on.

route choice
	[ip_route/rtalloc]
	Could use # hops in addition to use count for route choice.  But
	we don't know # hops as paths used by first hop change dynamically
	and we don't know # hops for ICMP redirects.  Let gateway do
	hops/cost/speed evaluation via gateway routing algorithms.

	should some weight be given to the reference count?  recent use?
	Store recent use in internet specific part of route data structure.

	Add ip_ttl field to route data structure so can deal with ICMP
	time exceeded messages.  (Done for Butterfly.)

	Mike may be right about timing out or replacing old routes to nets,
	since we can get them back from the default gateways.  WRONG!  Since
	have been times where couldn't get EGP gateway or approval, but did
	have need to get packets from A to B.  Differentiate user/kernel
	installed routes for this reason?  Timeout may involve timer or
	reference count or icmp redirects.  (Make sure if use redirect path
	that are replacing right route on a multihomed host and that put
	new one in right tables...)

pinging algorithm
	could avoid multiple pings to gateways used by more than one route
	When a gateway pings out, only active routes (inp->... ip_gdown())
		are declared down, not all routes.  This means that it
		can take longer to be redirected to an up gateway.
	Therefore, do we really need to get gateway stuff out of route
		structure and into it's own data structure?  (Did for
		Butterfly.)

move some of the ICMP and error interaction path back to the Butterfly
	to reduce interprotocol knowledge.  Have to think about this one.

RDP timers
	Make r_closewait and r_rttl adaptive, rather than fixed?

raw input
	loads machine a lot since a copy of every packet is made whether
	we need it or not.  => raw input should be passed original and
	it should make copies.

	do port as well as address matching?

code formatting
	It was originally in "kernel style".  If you don't like spaces for
	tab stops or the bracing (I don't), sorry, I let Craig at it just
	before 4.3 release.  But Craig did have some good ideas about
	other things.

ioctl/sockopt path
	Craig has good point that can view ioctl as fixed length sockopt
	and that could have single path that can deal with both.  Use of
	levels must be made better: see some comments in the c & h files.
	But it was a little too close to the release date to try anything
	new, so maybe some one can convince Mike for 4.4.

include files
	Reorganize to be like Butterfly's.  Separate protocol information
	from implementation information.

check Butterfly code NOTES file

move NOACT adjustments back to butterfly

all the comparisons and benchmarks are probably out of date by now.
	Someone should compare the 4.3 versions of the Berkeley and BBN code
	profiling should probably be redone.  I had had some things done inline
	and very carefully chosen register variables..., and in the conversion
	to 4.3 some of that was lost.  The gross use of macros to minimize
	subroutine call overhead (Bill Joy contended subroutines were very
	expensive on the VAX to Rob.  Was that one of the reasons for the
	divergence...?  The macros were introduced in an attempt to catch
	up to the 4.2 Berkeley code in speed.) could be re-evaluated.
