Yah, we have the adaptive.start/end stuff. I think I have a pretty
good handle on the issues now. I understand NetBSD's viewpoint on
connection tracking.
But for my own network I am extremely uncomfortable allowing a router
to drop a good TCP connection, and even more uncomfortable having the
router control timeouts considering that the only way to overcome such
a situation in the face of overload would be to drop the keepalive
timeouts on all my machines down to fairly small values. I don't want
a reboot of my router to blow up the several hundred active TCP
connections from half a dozen servers that are running through it.
At the same time I really want to use the keep-state mechanic to serve
as a basis for caching that hash code for my fairq. I don't want to
roll my own like the WFQ code does... that would be a massive duplication
of work.
I think the solution is to add another flavor of keep state that
is explicitly meant for use with fairq (or fairq-like) mechanisms,
or for middle-of-network routing (verses edge routing), which want
that hash code or want some sort of identification entity for flows.
If I create a 'hash state' keyword that would be fairly obvious
in its function. It would basically operate the same as keep state,
but explicitly omit any checks which cannot be done if the state is
picked up in the middle of the connection.
I definitely want to make fairq portable to other OS's. What do you
think about a 'hash state' keyword? From a coding perspective it's
a little work in parse.y and maybe three or four conditionals in the
TCP state code (to omit the sequence space checks for that case).
-Matt
