What exactly is ackQueue supposed to be doing?
-
As I was playing around with the traffic shaper I tried using the ackQueue. This is on 2.3.3-p1.
The idea of prioritizing TCP ack packets makes sense. They are tiny and delaying or dropping them can make your connections retransmit unnecessarily.
So in firewall rules, we have a queue and an ackQueue. From the name "ackQueue", and the way firewall rules keep state one would naturally assume this means if you set this value it will put the TCP acks into the ackQueue and all other traffic of the connection into the regular queue.
From my testing however this is not at all what happens. I setup a LAN rule on my test network to tag outbound packets with "test". Then I setup outbound WAN floating rule to match "test" and apply queue=qDefault and ackQueue=qAck. In this test, I only have queues setup on WAN, none on LAN. I'm using the PRIQ algo.
My test was to download a freebsd iso over http.
From pftop, what it looks like is that the outbound request to download the iso went into qDefault, but then all of the return traffic (the entire multi-GB iso itself) all went to qAck.
From that test, it looks like the ackQueue feature is actually a separate queue assignment for all of the return traffic, not just TCP acks.
Is this the expected behavior of "ackQueue"? If so, why does it have the misleading name of "ackQueue" vs something else that would better indicate its real purpose?
-
As I was playing around with the traffic shaper I tried using the ackQueue. This is on 2.3.3-p1.
The idea of prioritizing TCP ack packets makes sense. They are tiny and delaying or dropping them can make your connections retransmit unnecessarily.
So in firewall rules, we have a queue and an ackQueue. From the name "ackQueue", and the way firewall rules keep state one would naturally assume this means if you set this value it will put the TCP acks into the ackQueue and all other traffic of the connection into the regular queue.
From my testing however this is not at all what happens. I setup a LAN rule on my test network to tag outbound packets with "test". Then I setup outbound WAN floating rule to match "test" and apply queue=qDefault and ackQueue=qAck. In this test, I only have queues setup on WAN, none on LAN. I'm using the PRIQ algo.
My test was to download a freebsd iso over http.
From pftop, what it looks like is that the outbound request to download the iso went into qDefault, but then all of the return traffic (the entire multi-GB iso itself) all went to qAck.
From that test, it looks like the ackQueue feature is actually a separate queue assignment for all of the return traffic, not just TCP acks.
Is this the expected behavior of "ackQueue"? If so, why does it have the misleading name of "ackQueue" vs something else that would better indicate its real purpose?
Did you reset states? https://doc.pfsense.org/index.php/Reset_States
-
I've been wondering about this as well. Does the assigned ackQueue actually look at TCP flags, or is it simply the return traffic on an outbound rule?
-
If you're only assigning ACK traffic to the queue, then it is only ACK packets.
-
For detailed info about pf's integrated ACK classification you should probably look to OpenBSD's pf documentation.