Documente Academic
Documente Profesional
Documente Cultură
Introduction
This is not a step by step guide on how to configure your QoS. I do not know how to write such a
guide so instead I will write about how QoS operates in the hopes that armed with a little
knowledge you will be successful in what you want to accomplish. There is a lot written here
because unfortunately the subject is rather complex and full of nuances so it’s what’s required in my
view.
The simplest thing you can do is to use the default setup. QoS will then make sure that all the
devices connected on the side of your router share the WAN equally. It will also ensure that web
browsing gets priority over any other WAN activity. QoS can do much more than this but to get
more you need to read more. To use the default you have to enter your upload line speed on the
upload QoS page and check the enable box. Then you have to move to the download page, enable
download QoS, enter your download line speed and check the enable for the active congestion
controller. To learn more about how QoS works and what other things you can do with it read on.
Quality of Service (QoS) is the term used to talk about how we prioritize access to a limited
resource. The limited resource in your routers world is access to the wide area network (WAN) link
which connects the router to the Internet. This is almost always the most expensive and limited
resource you have. When I use the term QoS do not be fooled into thinking that means everyone
gets high quality of service. Quite the opposite is true. For some to experience high quality others
must experience low quality. Perhaps a better term would be “Priority of Service” but, hey, I did not
invent the term QoS and there are already enough synonymous terms out there so we will use the
term QoS.
Let’s start by trying to identify when QoS might provide benefit for you. If for example you are
already happy with your Internet experience then you do not need to use QoS or to read any further.
However, if you play online games or use voice of internet technology then you know when
someone else is watching youtube videos at the same time suddenly you get high pings and
timeouts or very poor voice quality. Another case might be that your roommate runs his bittorrent
application constantly and your web browsing suffers greatly because of it. Or you may administer
a campsite and get complaints that some campers have good access but others are not getting their
fair share. Having multiple people, devices or programs involved is when you can benefit from
QoS. Fairness is the goal of the QoS system. We say QoS is being fair when it is able to enforce the
rules you created for internet access. QoS is perhaps the only time in your life you get to decide
what is fair.
An important fact about fairness is that it has a cost. In the case of QoS the cost will come in terms
of reduced utilization of your WAN link. Lots of work has been invested in making this cost as low
as possible but you are going to take a 5-10% hit on your WAN throughput to get fairness. This is
the cost of QoS and if you do not want to pay it you can stop reading now. When you are having the
problems that QoS can solve you will be more than willing to give up 5% of your bandwidth to
solve them.
How about an analogy? I fly a lot and if you do too then you understand that when it’s time to board
the airplane we do not just all rush at the door. The gate agent enforces the airline’s quality of
service plan for each passenger. She starts by boarding handicapped folks, then we move onto the
airline’s diamond members, then gold, silver and finally we arrive at the bulk class. In this analogy
the gate agent is the router and the passengers are the packets of data trying to get through to the
WAN. The point is that for those diamond members to experience high quality the average Joes
must wait. When people are waiting to board we call this the 'saturated' condition because the door
cannot accommodate any more people per second. One interesting lesson from this example is that
if there is no one else waiting to board the plane when you show up it does not matter what your
status is, you get to board next. The lesson here is that if the WAN is not saturated your QoS setup
will not matter much, all packets get immediately transmitted.
Before we get into the particulars of how to configure your router we need to discuss the concept of
packets, classes and rules. Data on the Ethernet travels in packets. Each packet is preceded by a
header which contains information about its source, destination, type and length. In its journey
through the QoS system it is never broken up and all bytes travel together. Packets range in size
from 64 bytes to roughly 1500 bytes. Rules match packets to the classes. When a packet arrives the
router uses the rules to figure out which class to route the packet into. For the most part rules are
looking at data in the header of the packet to decide what to do. Classes are where packets wait
before being allowed onto their final destination. How long they will wait is determined by how
busy the WAN link is and the service level that is specified for the class they are assigned to. When
the link indicates it is ready to accept another packet your router consults with the classes to
determine which class is entitled to be next to transmit a packet. The above is the fundamental
process your router goes through and is good to keep in mind when configuring your QoS setup.
If you are new at this then I recommend that you enter your link speeds on the QoS
upload/download pages but otherwise just enable the default QoS configuration so that you can
study how it works. In particular look at the “Status→Connection List” page and the QoS column
shown there. Looking at this page we can see if your rules are working correctly or not. There is a
rule in the default configuration for destination/source port 80. Port 80 is the well known port used
by web browsers. If you open your web browser and navigate to www.google.com you will notice
several new connections appear all marked for the ‘Normal’ class. This proves that our rule is
working. Anytime you write a rule for QoS you should use this technique to ensure that it is
working the way you intend. The most common error I see with new users is improper rule writing
and then failure to check that their rule is operating properly.
Now a short word about connection tracking. When an application on your computer starts to
communicate with another computer on the internet it is the normal course of events that the two
computer exchange many packets back and forth. If you were to look at the header area of these
packets you would see that they are nearly identical since the source, destination and type of
packets are all the same. Your router calls this stream of packets a ‘connection’. The connection
starts when the first packet is sent and ends when no more packets are being sent. To learn more
about connection tracking I refer you to www.google.com. There is much written about this subject.
Rules can be written to match on the contents of the packet headers, the number of bytes which
have passed through the connection and the data that appears in the first few packets of the
connection (called L7 pattern matching). Rule writing is the most frustrating part of QoS. There are
only limited ways that we can classify data reliably and often we must compromise what we want to
do because of it. You have to think about how to classify your traffic based on what the rules can do
which probably is not exactly what you want but can be very close in many circumstances.
QOS Example
Let’s start by an example in which we want a specific computer on your to have higher priority
internet access than those computers in the Normal class. First we really have only one way to
identify a particular computer and that is by its IP address. To guarantee that this specific computer
always gets the same IP address we visit the connection→DHCP page and assign it a static IP
address based on its MAC address. Now every time this computer asks the router for an IP address
the router will give it the same one. Finally we can write our rule using the IP address knowing that
it will apply to this computer. When this computer sends a packet to the internet the source IP
address will be this IP address. In addition whenever the response comes from the internet the
destination address will be this IP address. So on the QoS download screen we use this IP as the
destination address and on the QoS upload screen we use this IP address as the source IP address.
This is an important point and often the cause of erroneous rules.
This idea of source/destination also applies to port numbers which are another way we have to
classify packets.
Matching
Matching by IP address:
This was covered in some detail in the example above. On the download page we normally use the
destination address and on the upload page we normally use the source address. Using the source
address on the upload page is problematic because we usually do not know the address of the server
we are talking to. IP addresses can be specified as a single address or in what is known as CIDR
notation. CIDR notation allows you to specify a range of addresses (ie 192.168.1.8/30). I refer you
again to Google to learn more about how to specify ranges with this type of notation.
L7 Pattern Matching
This method of matching looks at the data (not the header) in the first few packets transmitted on a
connection. The idea is that by looking at the data we can determine something about the
application that is sending the data and classify appropriately. The trouble is that applications are
changing constantly sending new and different types of data which makes any pattern matching
problematic. Couple this with the rise of SSL (Encrypted data) and it becomes impossible to glean
anything meaningful from the data passing through the router. As a result I do not recommend this
type of matching and may remove it entirely from Gargoyle in the future. The authors of the L7
matching code seem to agree having pretty much given up maintain or improving the code.
So now we have covered all the individual ways we can match on packets. Gargoyle allows you to
combine these together to form more complex rules. First we can select multiple methods in one
rule. In this case all the individual elements must match before the rule is considered a match. Next
we can write multiple rules. These are evaluated by the router in the order that they appear in the list
starting at the top. Once a match is found the evaluation stops and the class determined by the
matching rule is applied. Finally if none of the rules match we apply the default class. In all cases
every packet must be placed in a class. Again I must emphasis how critical it is to test your rules by
observing the connection list to make sure they are working as you intend. I am not aware of any
limit on the number of rules you can write other than the amount of RAM memory and CPU
performance your router has.
Classes
As soon as a packet arrived at the router the QoS rules are consulted to figure out what to do with it.
Rules do not store packets, they only analyze them and sends them to the appropriate class. It is the
class that contains the queue where the packet waits until its time comes. One attribute of Gargoyle
classes requires no configuration and that is per IP sharing. Per IP sharing ensures that when
multiple devices on your are using the same class they will all get an equal share of whatever
bandwidth that class has. In addition to this there are four user definable attributes for a class. We
will look at those next.
Minimum Bandwidth
This is the bandwidth Gargoyle guarantees to provide the class. This is not quite the same as percent
bandwidth in several cases. One important case is when Gargoyle’s active congestion controller is
used. As we will see later the controller monitors the downlink performance and detects when the
service your ISP is delivering varies. More on that later, for now suffice it to say that this is the
attribute you should use when a fixed amount of bandwidth is needed by a particular application.
The three most common cases I know are online gaming (ie XBOX Live), VoIP (SIP service or
Skype) and streaming video (ie NetFlix). If you use any such applications you should determine
what they require by first creating a rule and class for them using any parameters you want and then
observing what they require while they are in use. Then set the minimum bandwidth to this value
with a little margin (say 10%). Gargoyle will satisfy the minimum bandwidth requirements of all
classes before working on the percent bandwidth requirement so use this parameter judiciously.
When Gargoyle calculates the percentage bandwidth it includes whatever service it included under
the minimum requirement in that calculation. Like percentage bandwidth, minimum bandwidth
does not have any meaning unless the link is saturated. If all the minimum bandwidth of the active
classes add to more than the available bandwidth then obviously they do not get the minimum they
require but instead again proportionally less than the minimum. You should try to avoid this
situation by using minimum bandwidth sparingly and only for the types of applications that need it.
Maximum Bandwidth
This parameter defines the maximum bandwidth that the class will have even if the link is available.
This is the only class parameter which is not affected by link saturation. The class will not get more
than this amount of bandwidth even if the WAN is not fully utilized.
Router Performance
Your router has a CPU and that CPU has a limit on how much data is can process per second.
Almost nothing written on this page will be true if you are trying to exceed the limitations of your
router. Quoting Clint Eastwood “A man needs to know his limitations” so know your router's
limitations. When you are exceeding your throughput limitation you will see “CPU Load Averages”
on the Status screen approach 1.0 and strange unexplained things happening.
This will happen somewhere between 10Mbps and 500Mbps depending on your router and what
Gargoyle features you are using. To use Gargoyle you must reduce the download/upload link speeds
on your QoS pages so that your CPU never gets near the 1.0 limit even under fully saturated
conditions.
Bandwidth monitoring and QoS are the two features that take the most processing for your router. If
you turn them off you will get more through put but of course you will lose many of the reasons you
are trying to use Gargoyle.
Don't complain on the forum that your router's native firmware gives you better throughput than
Gargoyle firmware does. With Gargoyle you are getting features and stability which you do not
have with your native firmware. If you cannot achieve the speeds you want get a faster router.
All routers have a maximum processing speed for the WAN link. If you lower your total WAN
bandwidth (upload plus download) to below this maximum on the Gargoyle QoS screens then
Gargoyle will throttle your throughput and all your Gargoyle functions will work properly. This
may result in you not being able to utilize the full bandwidth your ISP provides you but you will
have stable and predictable performance.
Selecting a router that has enough horsepower to handle your full bandwidth is important if you
really want to use all your available bandwidth. Stock firmware which comes with your modem will
usually provide higher throughput than Gargoyle. The reason for this is simple. The stock firmware
does not have the advanced features of Gargoyle. Especially QoS and Bandwidth monitoring. These
are the features that require CPU horsepower. If you turn them off in Gargoyle you will also see a
high throughput capability.
Like a car top-end speed is not the only desirable feature. The many other features that you use
everyday are usually what you should concentrate on and these are what Gargoyle provides.
FAQS
How is the link shared if some classes are not active
Q. I have three classes defined with 15, 35 & 60% link share. How is the link shared if only the first
two classes are active and the WAN link is saturated by them.
A.If the link is saturated then it is divided according to the percentages of the active classes. So in
this case the split becomes 15/(15+35)=30% and 35/(35+15)= 70%
Class 'Priority'
Q. How can I get my special class to get ‘Priority’ over other classes?
A. In Gargoyle we use the concept of bandwidth to allocate the WAN resource and not the concept
of ‘priority’. One reason is the the word 'priority' is ambiguous in meaning. It could mean that
Priority packets always get transmitted before the lower priority classes. You can achieve this
behavior in Gargoyle by setting the minimum bandwidth of the priority class equal to your link
speed and setting the minimum bandwidth of all other classes to zero. In the real world you will
find that that Gargoyle's %BW, minBW and maxBW concepts are more flexible so I encourage you
to think of your problem in these terms and abandon the concept of 'Priority'.
Common Myths
QoS cannot control my downlink speed
Statement: QoS cannot control the download speed because the router cannot stop data from
coming in the WAN link.
Rebuttal: False my friend. It can and does.
'ACK' packets are special I want them treated with higher priority
Statement: It’s necessary to handle ‘ACK’ packets with special ‘priority’ so my uplink does not
affect my downlink when I am using HTTP.
Rebuttal: It is not necessary to handle ACK packets different than other packets. As with all
packets you need to think about how to allocate WAN resource for them. ACK packets are typically
around 54 bytes long and the maximum packets around 1500 bytes. This ratio is 54/1500 = 3.6%.
Any class which includes TCP traffic in the download needs a matching upload class that has
allocation greater than 3.6% of the download bandwidth in bps. Many WAN links are asymmetrical
in that the download is much faster than the upload so this affects the calculation.
Example: On a 10Mbps down/1Mbps up link we want HTTP traffic to consume 50% of the WAN
down link when saturated. Let’s say our HTTP traffic is routed into the Normal class on both upload
and download. The %BW in the download Normal class is simply 50%. On the uplink we must
account for the fact that the link is asymmetrical so we allocate 3.6% * 10Mbps/1Mbps = 36% to
the Normal class in the uplink. With this setup if either the uplink or downlink is saturated the
HTTP traffic will be allocated not less than 5Mbps in the downlink.