Coyote Linux & BrazilFW Add-ons - Classic QOS setup tutorial

Classic QOS setup tutorial

QoS and bandwidth management | QoS documentation | QoS tutorial

This tutorial shows you how to setup QOS configuration when you are using Coyote or BrazilFW init scripts. It shows you how to setup correct upstream and downstream values and contains information about other QOS configuration options.

What is QOS, Traffic Shaping and Bandwidth limiting

QOS is an attempt to control computer network traffic in order to optimize or guarantee performance, low-latency, and/or bandwidth. QOS (Traffic shaping) deals with concepts of classification, queue disciplines, enforcing policies, congestion management, and fairness.

Traffic shaping provides a mechanism to control the amount and volume of traffic being sent into a network (bandwidth throttling), and the rate at which the traffic is being sent (rate limiting). For this reason, traffic shaping schemes need to be implemented at the network edges to control the traffic entering the network. It also may be necessary to identify traffic flows at the ingress point (the point at which traffic enters the network) with a granularity that allows the traffic-shaping control mechanism to separate traffic into individual flows and shape them differently.

Basic QOS setup

Basic QOS configuration is made in Web-admin configuration interface from "QOS configuration" panel. If you choose Coyote (BrazilFW) QOS init scripts, the configuration screen will look like this (click for large picture) ...

Web based QOS configuration

Now we will describe what the configuration options meen.

QOS init type

QOS configuration script init type. You can either use Wondershaper configuration or Coyote Linux (BrazilFW) QOS scripts configuration. This tutorial focuses on the second option. You can choose between default config and manual class config.

Real Downstream bandwidth

Real value of your downstream bandwidth..not the value your ISP pretends you have. For QOS to function properly it's very important to setup you downstream and mainly upstream maximal values properly. The correct values is almost every time even lower than the maximum value you download/upload from internet. The explanation of this effect is quite simple. QOS works on the principle of prioritizing some packet on the packet queue. Because the interface between you Coyote(BrazilFW) router and Cable/ADSL/Modem or whatever is a lot faster than your internet connection, if you setup you upstream/downstream speed too high, the queue is not build at the Coyote(BrazilFW) router but at Cable modem for example and QOS does not work.

Real Upstream bandwidth

Same as downstream bandwidth, only for upstream values. We will look how to setup correct values later.

Direct router -> inet class reserved bandwidth

How many percent of total bandwidth (Real Upstream Bandwidth) is used for connections made directly from internet to your Coyote Linux (BrazilFW) router. For example remote administration over the internet, Web server of FTP server on your Coyote Linux (BrazilFW)

Priority classes reserved bandwidth

Theese are percentage values of bandwidth reserved for priority classes. Ig there is not other traffic, the bandwidth is borrowed to lower priority classes.

Burst settings

Burst size is the limit of transfered data that can be transfered at full speed before any shaping occurs. It's goot for WWW traffic which mades requests in bursts.

Setting correct Upstream/Downstream values

It's the time for upstream/downstream values tweaking. First measure your free line latency. You will need your ISP's gateway address. If you don't know it run command prompt on your windows workstation and issue following command.

C:\Documents and Settings\Dolly22>tracert www.google.com

the output should look something like this:

Tracing route to www.google.akadns.net [216.239.59.104]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  coyote.sporilov.czf [192.168.0.1]
  2    10 ms    10 ms    12 ms  ac2.mistral.cz [62.24.94.2]
  3    18 ms    10 ms    12 ms  1hopsem-v103.dkm.cz [62.24.68.81]
  ...
ISP's gateway address is first public ip address in you tracert list, in my case it's ac2.mistral.cz [62.24.94.2]. You can use any address from your traceroute, but the closer the better (but DO NOT use your coyote linux IP address /by default 192.168.0.1/).

Now measure your free line latency with command

C:\Documents and Settings\Dolly22>ping -n 20 ac2.mistral.cz

the output should look something like this:

Pinging ac2.mistral.cz [62.24.94.2] with 32 bytes of data:

Reply from 62.24.94.2: bytes=32 time=306ms TTL=254
Reply from 62.24.94.2: bytes=32 time=219ms TTL=254

Ping statistics for 62.24.94.2:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 8ms, Maximum = 37ms, Average = 14ms
Note average ping value somewhere. Now look at this info from wonder shaper readme, it has some information what minimal latency you can expect on your connection (when full uploading with QOS enabled). Following text uses MTU term, you can read it from ifconfig output.
substitute eth1 with your inet interface ...

brazilfw# ifconfig eth1

eth1      Link encap:Ethernet  HWaddr 00:A0:C9:C5:4B:B7
          inet addr:62.245.67.193  Bcast:62.245.67.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                                          ^^^^^^^^  
          ...
Now here we go ...
Uplink speed   |  Expected latency due to upload
--------------------------------------------------
32             |  234ms
64             |  117ms
128            |  58ms
256            |  29ms

So to calculate your effective latency, take a baseline measurement (ping on an unloaded link), and look up the number in the table, and add it. That is about the best you can expect. This number comes from a calculation that assumes that your upstream keystroke will have at most half a full sized packet ahead of it.

This boils down to:

   mtu * 0.5 * 10
   --------------  + baseline_latency
       kbit

The factor 10 is not quite correct but works well in practice. 
Count your theoretical mimimal latency and we can start with tweaking. Full up your internet upstream with some transfer (upload to fast ftp server, ...), open command line on your windows workstation and start command
    ping -t ac2.mistral.cz
                ^^^^
                  substitute with your ISP's gateway

    output of this command look like this (it goes on forever :)) ...
    
    ...
    Reply from 62.24.64.4: bytes=32 time=159ms TTL=62
    Reply from 62.24.64.4: bytes=32 time=179ms TTL=62
    Reply from 62.24.64.4: bytes=32 time=347ms TTL=62
    Reply from 62.24.64.4: bytes=32 time=283ms TTL=62
    Reply from 62.24.64.4: bytes=32 time=329ms TTL=62
    ...
Your ping values should be quite high now, it's because you have initialized your upstream value with true line upstream. Now slowly lower your real upstream value and see what happens to your pings in other window.

You will have to RELOAD QOS configuration after every change.

Lower the UPSTREAM value, until your pings drop somewhere to theoreticaly computed latency value. Then free your upstream and repeat the same steps for DOWNSTREAM value (fill up downstream and slowly lower DOWNSTREAM value until the pings drop down).

Now save your coyote configuration and voila, you should have QOS set up and running.

Created by Dolly 2004, hosted by CZI s.r.o.