:I think "reduced state tracking" and the fairq are orthogonal.  You can 
:have either independent of each other.  If I were to do reduced states, 
:I'd probably make it a "state-opt" (see pf.conf(5) BNF) so that it could 
:be applied to any keep state rule with various effects.  This way you 
:could even do modulate state or synproxy state as long as you see the 
:initial SYN.  If not, you fall back to creating a reduced state.  This 
:option would, of course, also have a setting where it would always just 
:create a reduced state and be done with it.
:
:As for the name ... maybe, 'extra-tcp-state' with a possible setting 
:of 'on' (default), 'off' and 'force-off' or something like that.  This 
:could also be a global setting similar to the timeouts which can also be 
:set on a per-rule basis.
:
:-- 
:/"\  Best regards,                      | mlaier@freebsd.org
:\ /  Max Laier                          | ICQ #67774661

    I will go this route, adding state-opts for reduced-state tracking.

    I agree, they are orthogonal.  The issues simply need to be documented
    properly (S/SA verses reduced-state verses classifying the bucket for
    fairq, etc).

    I just had an evil thought.  One could have additional flags to tell
    it to track even more reduced state... as in, just IP-IP traffic, or
    by source or destination IP only, as a means of classifying the 
    hoppers for fair-q.  It is certainly food for thought and might even
    be worth implementing queue recursion.  Overall queue for IP, sub-queues
    for connections from IP.  Hmm.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>