Prioritizing ACKS on cable modem connection

Prioritizing ACKS on cable modem connection

Post by Syn » Thu, 05 Jun 2003 17:51:23



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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Konfuziu » Fri, 06 Jun 2003 00:39:12


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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Marc » Fri, 06 Jun 2003 06:20:40



> 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.

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Konfuziu » Fri, 06 Jun 2003 08:21:50


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


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

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Syn » Fri, 06 Jun 2003 16:14:51



> 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.

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Konfuziu » Fri, 06 Jun 2003 16:41:12




> 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 ?

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Syn » Fri, 06 Jun 2003 20:22:13



> From 'man pf.conf'

>>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.

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Konfuziu » Sat, 07 Jun 2003 00:08:26



> 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.

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Marc » Sat, 07 Jun 2003 06:59:04



> 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.

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Konfuziu » Sat, 07 Jun 2003 07:25:50




>> 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.

> 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....

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Marc » Sun, 08 Jun 2003 19:05:48


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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Konfuziu » Tue, 10 Jun 2003 20:42:39


Hi Marc/Syn,


> 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)".

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

 
 
 

Prioritizing ACKS on cable modem connection

Post by Syn » Wed, 11 Jun 2003 20:50:26



> 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).

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

 
 
 

1. Cable modem..56 modem dial up, 500K cable modem download stream...

I have 2 network cards and 1 modem in a Linux Box with RH6.
My cable modem uses the modem to start a PPP session, and the network card
is then hooked up to the VPN of the ISP.

I would like to setup a IP Masquraded Firewall to hook some of my other
boxes
behind the firewall.

I  cannot find a HOW-TO to setup the Linux box using this type of Cable
Modem.  I
have only found 2 way cable modems.  Can someone point me it the right
direction.

My problem is that I don't know how to get Linux connected, then also, how
do I configure
ipchains or ipfwadm to use the correct rule set.  Do I do the modem or the
network card.  The
network card has a static IP of 10.0.0.1 which is usally used for VPNs.  My
cable company
is of corse not supporting Linux, so I have to do it myself.  The PPP dialup
uses DHCP to
assign my address so I have dhcp setup.

Thanks in advance..

Aaron

2. Mawk, a version of new awk

3. How can I route to a cable modem connection AND a DSL connection?

4. subdomains in solaris.

5. Cable modem/modem connection

6. Linux, NT4 and Win95

7. Cable Modem (COX @HOME), I NEED HELP SETTING UP MY CABLE MODEM WITH RH 5.1

8. Gateway Handbook 486 & Linux?

9. @Home Cable Modem and RedHat 6.0 -- no packets get past the cable modem at all!

10. Prioritizing "interactive" connections over SLIP?

11. how to reset ip address for cable modem connection

12. Cable modem connection problem

13. cable modem internet connection