<boisvert.ian@gmail.com> wrote:
> The example shows that if you want to queue TCP ACK packets you should
> use a rule like:
> pass in on fxp0 proto tcp from any to any port 22 flags S/SA keep
> state queue ssh
>
> I'm a little confused by this, though, because according to the packet
> filtering section of the FAQ, this will match SYN packets and not ACK
> packets.

This rule creates a state due to "keep state" and matches the following
ACK-packets to the state, not to a rule. The state "knows" which queue its
packets belong to. There can be two different queues a state assigns its
packets to. The first queue is used for bulk traffic, the other for packets
with TOS bit for low delay set and empty ACK packets.

pass in on fxp0 proto tcp from any to any port 22 flags S/SA keep state
queue (bulk, lowdelay)

This rule would assign traffic to two different queues, empty ACKs and low
delay packets to "lowdelay" and the rest to "bulk". Yet, interactive ssh
connections usually have the low delay bit set, so all traffic would be
assigned to the "lowdelay" queue. sftp-connections would be distributed on
the two queues, since low delay is not set there.

Your next question regarding "flags A/SA": I'd advise against creating a
state for a tcp-connection in the middle of that connection. Several
parameters are negotiated during the S/SA SA/SA phase. It should simply not
work reliably. Furthermore if you already have a "flags S/SA keep state"
rule, no valid packets could arrive at your A/SA rule.