NetFlow TCP RST/FIN handling:

	    According to some Cisco specs, and also according to the
	IPFIX Applicability spec, the flows expiration algorithm
	includes the condition where flushing is performed when
	the Metering Process can detect the end of a Flow.
	The example is given specifying the TCP RST or FIN bits
	as the indicators of a connection termination.
	    This supposedly intuitive behavior nevertheless has
	a big flaw: the TCP connection does NOT usually end with
	one these flags. Under normal circumstances, the last packet
	of the TCP stream is ACK, which acknowledges a correctly
	processed FIN (RFC793, #3.5).
	    Any implementation which blindly expires the record
	when it sees the RST or FIN TCP flags will indeed create
	two flow records, one with the flow information about the
	main body of a TCP connection, and another with only the
	data about the ACK packet of that previously discovered
	TCP stream.

	    Overall, the question boils down to the following:
	what is better: create a single flow and expire it
	only after several seconds of its inactivity (when the
	flow is supposedly finished), or create two flows,
	one of which contains the main body of a connection and
	another one describes the final ACK packet of this
	connection (the last one is generated only after _its_
	inactivity).

	    The first way is chosen for IPCAD.