Re: ACKs queueing
OK, now I understood that the second queue specified with the queue keyword apply to the ACKs in the SAME DIRECTION. I initially though that it somehow applied to the ACKs that are the replies to the same flow, so in the inverse direction. Now I understand the logic of that second queue: it is for high priority traffic (ACKs and lowdelay TOS). But I still don't understand what happens when keep state is used. You say: BTW, queue assigment happens for all packets matching a state, no matter what direction they flow in. So, if keep state is specified, all packets in the same flow will be automatically assigned to the same queue of the original packet. And this is OK. But, as you say, the state is applied to the packets in the inverse direction too (e.g. the ACKs to the flow). So, are these packets assigned to the same queue too??? If so, I don't understand how it can work! A given queue has a sense only in a single direction! Maybe the automatic queue assignment happens only to packets in the original direction? Or is there something else that I miss? Thanks. -- ___ __ |- [EMAIL PROTECTED] |ederico Giannici http://www.neomedia.it ___
Re: ACKs queueing
Having received no useful replies, let me try a simpler question: How can I identify (i.e. filter) TCP ACKs with no data payload? I know how to identify ACKs, but is there any way to identify packets with no payload, something like a payload-size 0 condition? Thanks. Federico Giannici wrote: In a gateway with two NICs, we classify the traffic as HiPri and LowPri, for both NICs, so there are a total of 4 queues. I'd like to assign the ACKs of the HiPri queue in a given direction to the HiPri queue of the opposite direction. I have read that two names can be given to the queue keyword, and the second one is used for the TCP ACKs with no data payload. Is it correct that it is referencing the ACKs in the opposite direction, so it works only if keep state is used? Moreover, the second queue is used for packets which have a TOS of lowdelay too, but I don't want it, because I want to specify a queue in the opposite direction! Is there a way to avoid this second case? Is there some other way to assign a queue to the ACKs (and only them) relative to flows assigned to another queue (in the opposite direction)? Thanks. -- ___ __ |- [EMAIL PROTECTED] |ederico Giannici http://www.neomedia.it ___
Re: ACKs queueing
On Sat, Oct 07, 2006 at 06:29:46PM +0200, Federico Giannici wrote:
Having received no useful replies, let me try a simpler question: How
can I identify (i.e. filter) TCP ACKs with no data payload?
I know how to identify ACKs, but is there any way to identify packets
with no payload, something like a payload-size 0 condition?
No, that's hardcoded and you'll have to patch the source if you want to
change that. See src/sys/net/pf.c pf_test()
if ((th.th_flags TH_ACK) pd.p_len == 0)
pqid = 1;
This sets the pqid flag (use the second queue specified) for TCP packets
with TH_ACK set and no payload.
if (action == PF_PASS r-qid) {
if (pqid || (pd.tos IPTOS_LOWDELAY))
pd.pf_mtag-qid = r-pqid;
else
pd.pf_mtag-qid = r-qid;
This assigns the rule's second specified queue if the pqid flag is set
before, or if IPTOS_LOWDELAY is set.
Change as you see fit. Adding a keyword about payload size to the parser
is much more work, compared to the kernel part ;)
BTW, queue assigment happens for all packets matching a state, no matter
what direction they flow in. If you have two four queues (two for each
interface involved), you want to make sure that the right queue is
assigned last (the mbuf tag gets overwritten, and only the last write is
relevant, should it happen multiple times to the same packet).
Daniel
