Understanding queue size

[Martin Bartelds]

I think you should consider to use xmit/recv in stead of in/out via.
This because the in/out via seems to be related to the direction
of the TCP pipe and not the direction of (heavy) packet flow.
You can test this using FTP transfers. You'll probably notice
a huge difference in SSH response, if you initiate the transfer from
your local system compared to an initiation from the outside, despite
the heavy flow going out.

You also might consider the consequences of http and active/passive FTP transfers.

/Martin.

On Fri, 23 May 2003 17:05:18 +0200, jeremie le-hen wrote:

>> Ah, you're adjusting the camel from the wrong end. ;-)
>> 
>> It's not queue size you want to adjust.  If you want to reduce
>> delays for interactive traffic (telnet?  ssh?  etc.) assign that
>> traffic to a different queue, and all the queues to the same pipe.
>> Then you get the promised "worst case weighted fair queueing"
>
>In fact, I already have some queues in order to improve delays for
>interactive traffic. Here they are:
>
>pipe 1 config bw 125Kbit/s queue 76KBytes
>queue 10 config weight 100 pipe 1 mask all
>queue 20 config weight 100 pipe 1
>queue 30 config weight 50 pipe 1
>queue 40 config weight 1 pipe 1
>
># IRC, FTP, ICQ
>add queue 10 tcp from any to any 6667,5190,21 out via tun0
># SSH small packets (not file transfert via scp)
>add queue 10 tcp from any to any 22 iplen 1-1000 out via tun0
>add queue 10 tcp from any 22 to any iplen 1-1000 out via tun0
># small ICMP, DNS requests and identd replies
>add queue 10 icmp from any to any iplen 1-200 out via tun0
>add queue 10 udp from any to any 53 out via tun0
>add queue 10 tcp from any 113 to any out via tun0
># TCP small packets (including SYNs, ACKs)
>add queue 20 tcp from any to any iplen 1-60 out via tun0
># SSH big packets (scp / rsync)
>add queue 40 tcp from any to any 22 iplen 1001-1500 out via tun0
>add queue 40 tcp from any 22 to any iplen 1001-1500 out via tun0
># everything else
>add queue 30 tcp from any to any out via tun0
>
>
>This just works fine, compared to when I didn't have any traffic shapping
>enabled. But I wanted to improve the responsivness of interactive traffic
>more and more, so I got concerned with queue size for the main pipe.
>
>> Once you've done this, then you might consider decreasing the
>> queue size on the interactive traffic.  If it's full, it will
>> get priority.  I'd think in terms of numbers of packets rather
>> than octets, probably...
>
>I hadn't understood I had to play with queue size for each queues, and not
>with the one of the main pipe. But that's the key ! :)
>
>Does reducing or increasing queue size of the main pipe have any relevance ?
>
>Finally, I should reduce size of interactive traffic queues, and increase
>size of the others. But how much ?
>
>Regards,
>-- 
>Jeremie aka TtZ/TataZ
>jeremie.le-hen at epita.fr
>_______________________________________________
>freebsd-ipfw at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>