I didn't find the manual's explanation of QoS incredibly helpful, I think it's written with the assumption you already fully understand QoS.

I found a need to configure QoS this weekend when the GF's family came over and fired up their BitTorrent clients. I wanted a graceful way to handle this and QoS seemed to be just the ticket. I wanted to achieve the following:

1. Allow resolution of site names. This seemed to be the big problem, I couldn't resolve names any more but could ping sites fine.

2. Reserve bandwidth for the people who lived in the house to ensure they always got a reasonable connection.

3. Make general improvements to my non-QoS setup where possible.

To this end I did the following:

a) Class 1 was given a 5% bandwidth reservation for all DNS connections. This was set to IP precedence 1.

b) Class 2 was given a 35% bandwidth reservation for all traffic coming from my GF's PC

c) Class 3 was given a 35% bandwidth reservation for all traffic coming from my PC

d) QoS was set to BOTH

e) TCP_ACK prioritisation was enabled to account for the asynchronous nature of an ADSL line

f) UDP was limited to 75% to prevent video streaming from preventing other activities continuing on the line.

This looks to have got the job done, but I'm left with a number of questions:

i) Do these reservations hold X% of bandwidth permanently, or is it simply that when a class is triggered by one of its rule it then attempts to reserve X% of bandwidth?

ii) Am I correct in thinking that IP precedence 1 is higher than 7?

iii) Is it a mistake to use a bandwidth reservation based solely on a machine IP? My concern being that a machine is always sending some kind of traffic over the net these days and is therefore causing a loss of bandwidth for other uses for no good reason.

Alas, this doesn't appear to have fixed my problem. I came in this morning and attempting to reach the web results in "Resolving host" while the web remains pingable.

I wonder whether this is a bandwidth issue or the Draytek not handling the number of connections the torrent client is putting through it.

General Comments

1. If a % is given to a class, then that class is guaranteed the %

If a class isn't using it's full % then the spare % is made available to other classes. The first dibs on spare bandwidth goes to the higher priority class first (1 then 2 then 3)

2. When setting QoS rules, don't set the IP precedence unless you know that the device generating the traffic is adding a precedience to the TOS field. The router does not add to the DiffSrv code point field, it just inspects. With QoS packets are put into a queue if they match ALL of the bits specified in the QOS rule. Therefore, if a DiffSrv code point it set the packet being received by the router much have that code point set for it match the rule.

Answer to your questions:

a. Don't set the DiffSrv code point
f. This could impact on DNS because it's UDP, but your first class should help give DNS higher priority than other competing UDP traffic


i. No. It's dynamic so unused bandwidth is redistributed, however as mentioned above the % gives a minimum guarantee
ii. Probably not important for your requirements
iii. Depends, if you know that anything from the machine is important, then you don't really mind.

Last note: Class 1 is the highest priority class, so put your most important stuff in this class. I would normally put the important PCs in this class and give them a decent %

Thank you, that's very helpful. I'll strip the IP precedence from the DNS QoS.

How much bandwidth does DNS need? From what I recall it's a very lite protocol so 5-10% is more than enough, I just want to ensure it gets something.

When setting up QoS myself I haven't come across DNS resolution issues but I expect that the configuration you had initially it might has starved DNS of bandwidth because (due to it not being categorised into class one as intended) it would have been fighting equally with all other UDP traffic (ie agressive P2P connections) for the 25% of bandwidth that UDP traffic was allowed to use.

Ah, good point.