Very Computer

Hello,

Are there any examples out there on how I can prioritize ACKs on a cable
modem connection ? The downstream is 2048 kbit/s and the upstream is 512
kbit/s. My interface dc3 is connected to the cable modem.

Many thanks

Regards

Hi Syn,

You can enable queueing in the outgoing direction only. So your example
could look like:
---------
altq on dc3 bandwidth 512Kb cbq queue { normal, ack }
queue normal bandwidth 80% cbq( red default borrow ) priority 2
queue ack bandwidth 20% cbq( red borrow ) priority 5

pass out on dc3 all keep state queue( normal, ack )
pass in on dc3 all keep state queue( normal, ack )
---------
This would allow everything and assign all packets without payload and
packets using ToS low-delay to the queue with higher priority.
These priorities come into play in high load situations only.

HTH Konfu

Hi Konfuzius,

Many thanks for your example, sure that helps, I have now added the
following queuing rules to my pf.conf:

altq on $ext_if cbq bandwidth 512Kb queue { q_normal, q_ack }
queue q_normal  bandwidth 70%   priority 2      cbq(red borrow default)
queue q_ack     bandwidth 30%   priority 5      cbq(red borrow)

And as I have a default policy to block everything which is incoming and
outgoing of $ext_if I have added to all my pass in and pass out rules
using $ext_if the following:

queue (q_normal, q_ack)

For example:

pass in on $ext_if inet proto tcp from any to $www_ip port 80 flags S/SAFR
modulate state queue (q_normal, q_ack)

pass  out     on $ext_if inet proto tcp  all flags S/SAFR modulate
state        $queuing_params
pass  out     on $ext_if inet proto udp  all              keep
state            $queuing_params
pass  out     on $ext_if inet proto icmp all              keep
state            $queuing_params
pass  out     on $ext_if inet proto gre
all                                    $queuing_params

where $queuing_params is a macro equivalent to "queue (q_normal, q_ack)"

Does these few example look allright ?

Now that I have implemented this, what is the best test I can do to be
sure queuing works properly ?

I've did the following test case:

- launch a wget on a machine on the internet which will retreive a big
file available on my web server
- in the same time start pinging around from my local network

Unfortunately when the wget is running the pings are still very bad: 200,
300 ms when it usualy is only 40 ms when nothing is happening. How can I
fix that too ?

Many thanks again for your help

Regards

[snip]
Yes, this example seems to be O.K..

Well, you need to establish two concurrent TCP-connections. One upstream,
one downstream. First one up, to verify your max. upload speed. Then one
down (without the upstream) to verify your downstream bandwidth. And finally
both. If the empty ACK packets are not properly favored, both streams will
have a severe drop in bandwidth usage. If all goes O.K. then the bandwidth
usage should only differ slightly.

Quote:> I've did the following test case:

> - launch a wget on a machine on the internet which will retreive a big
> file available on my web server
> - in the same time start pinging around from my local network

> Unfortunately when the wget is running the pings are still very bad:
> 200, 300 ms when it usualy is only 40 ms when nothing is happening.
> How can I fix that too ?

If you really need your ping to be the fastest possible, then you have two
possiblities:
1. You send all ping packets (or even all ICMP) to the queue with higher
priority.
2. You establish another queue, which has an even higher priority and use it
for pings (or even all ICMP).

An appropriate rule could look like:
pass out on $ext_if inet proto icmp all keep state queue q_ping

Replace q_ping with q_ack if you want.

HTH Konfu

Well, SUCCESS, it works fine only a few kbytes/s are missing but that's
nearly nothing compared to the bad performance before when uploading and
downloading in the same time.

Quote:> If you really need your ping to be the fastest possible, then you have two
> possiblities:
> 1. You send all ping packets (or even all ICMP) to the queue with higher
> priority.
> 2. You establish another queue, which has an even higher priority and use it
> for pings (or even all ICMP).

> An appropriate rule could look like:
> pass out on $ext_if inet proto icmp all keep state queue q_ping

> Replace q_ping with q_ack if you want.

I will then create a new queue with a high priority just for ICMP
traffic and reserve 5% of the bandwidth, that should be plenty.

Now this makes me think that actually prioritizing ACKs is only valid
for TCP traffic right ? Prioritizing ACKs for UDP, GRE, ESP and ICMP
wont be of any benefit as just seen with the ICMP protocol, right ? So
that would mean I only need to add the queue parameter to my pass in and
pass out rules which uses TCP and no other rules ?

Regards

From 'man pf.conf'

Quote:> Packets can be assigned to queues based on filter rules by using the
> queue keyword.  Normally only one queue is specified; when a second one
> is specified it will instead be used for packets which have a TOS of
> lowdelay and for TCP ACKs with no data payload.

So ignoring the TOS-flags, you are right. As soon as you want to treat
traffic differently using TOS as part of your criteria, you will need to
give two queues again.

BTW: I've never heard of ICMP- and UDP-ACKs. No idea about the other two.

HTH Konfu

Ok so to resume, am I right saying that I should then only use the
second queue paramter for pass in and pass out rules which use TCP and
only TCP ? For all other rules not using TCP I will then only give one
parameter to the queue option.

Regards

Yes, this would be the standard approach if you do not use TOS-lowdelay in
your traffic (or if you want to ignore it on non-TCP traffic).
Doing it like you propose will work well in most environments.

HTH Konfu

Well I don't want to ignore non TCP traffic but I think it's not possible to
apply this to non TCP traffic as this works only on ACKs and for example
UDP has no ACKs....

Would that be ok if I simply apply the same queue parameter (with the default
queue and the ack queue) to all of my pass in and pass out rules of my
external interface ? Won't that hurt ?

Regards

I do not expect you to ignore all non-TCP-traffic. I just wanted to point
out that all IP-traffic that has the TOS-lowdelay-flag set will also be
assigned to the second queue (the one with the higher priority). So this
would work if your UDP-traffic used this flag.

Quote:> Would that be ok if I simply apply the same queue parameter (with the
> default queue and the ack queue) to all of my pass in and pass out
> rules of my external interface ? Won't that hurt ?

In most environments it will not hurt.
You should still know what kind of traffic you want to prefer. You are not
limited to two queues with 2 different priorities. You can expand that
scheme to fit your situation perfectly. You can give UDP a priority between
the empty TCP-ACKs and the other TCP-packets. You can do countless things
using queueing in a complex way. Yet, you have to be absolutely clear about
what kind of traffic you see and which traffic you would give higher
priorities and which less ....

HTH Konfu

Hi Konfuzius,

A very last question, now I have applied the following altq paramters:

altq on $ext_if cbq bandwidth 512Kb queue { q_normal, q_icmp, q_ack }
queue q_normal  bandwidth 70%   priority 2      cbq(red borrow default)
queue q_icmp    bandwidth 10%   priority 4      cbq(red borrow)
queue q_ack     bandwidth 20%   priority 5      cbq(red borrow)

And have added "queue (q_normal, q_ack)" to all pass in and pass out rules of
$ext_if except for icmp pass in/pass out rules. For icmp pass in and pass out
rules I have added "queue (q_icmp)". Now this works fine I have for example
tested it by fully using my upstream link and then simply did a ping from my
internal network to an internet host. The response times are unafected, GREAT
that works perfect !

But now I have tested a case where it doesn't work, and that's the opposite of
what I have just described, which is actually to fully use the downstream link
and then try some pings from the internal network to an internet host. Then
the PING response times are bad !!

I guess that this has to do with the fact that queuing is only applied to
outgoing packets which is the upstream link...

Is there any solutions for that ??? Or it's simply like that and I cannot do
anything about it ?

Regards

Hi Marc/Syn,

Okay, let's have a look.
q_normal < q_icmp < q_ack
Empty TCP-ACKs will be forwarded more quickly than ICMP packets and TCP
packets with payload are least favored.

Quote:> Now this
> works fine I have for example tested it by fully using my upstream
> link and then simply did a ping from my internal network to an
> internet host. The response times are unafected, GREAT that works
> perfect !

Should be, since occupying your upstream probably used TCP packets with
payload. These packets are delayed in favor of ICMP packets (pings).

Quote:> But now I have tested a case where it doesn't work, and that's the
> opposite of what I have just described, which is actually to fully
> use the downstream link and then try some pings from the internal
> network to an internet host. Then the PING response times are bad !!

Where does that increased delay come from ?
1. Queueing delay at your ISP (congested downstream).
2. Queueing delay at your upstream (empty TCP-ACKs are favored).

You cannot do anything about #1, but you could minimize #2 by giving q_icmp
a priority above the priority of q_ack.

Quote:> I guess that this has to do with the fact that queuing is only
> applied to outgoing packets which is the upstream link...

Well, sort of. #1 yes, #2 no.

HTH Konfu

I think it's problem number 1. Because i was just testing the
downstream, that means fully using my whole downstream, upstream is fine
  and still has enough bandwidth.

Quote:> You cannot do anything about #1, but you could minimize #2 by giving q_icmp
> a priority above the priority of q_ack.

Looks like I cannot do anything about that... Well let's hope that maybe
sometime my provider will use something like weight-fair queueing...

Thanks for the help

Regards