QoS not following priorities?

[noric]

Ok, I've done some intensive testing about this subject and here is what I've found.
I've put in the QoS the two following rules:

The first rule does intercept file transfer on http/https ports and force it to follow the download limit I set for "Medium" priority (I test this by temporarily decreasing such limit to 5%, while everything else is 100%).
The second rule does intercept P2P traffic (I'm testing with qBittorrent downloading an Ubuntu iso) and force it to follow the download limit I set for "Lowest" priority (same testing methodology as above).

I want to stress that both of the rules work as expected if I test them individually (either http file transfer or qBittorrent).

The issue occurs if I download both from http and from qBittorrent at the same time: this is where QoS should come in handy, delivering most of the bandwidth to http and not to P2P (because Medium>Lowest). However it does exactly the opposite: qBittorrent downloads like crazy (say 1,7MB/s) and the http download crawls (0,3MB/s).

What am I missing about it?


Edit: I forgot to say I'm on 374.40 firmware.

 

[Grump]

The problem with QoS on the downstream is the packets are already entering your network before the router can decide what to do with them. You need QoS from your provider for it to be effective.

The nature of P2P opens many many connections. So your provider is sending you 100 p2p connections and 1 http connection. QoS on your router can't make the 100 p2p connections back off fast enough (google "TCP backoff") to allow the 1 http connection to function normally. The data was already sent over the link from your provider 100:1 before your router gets a chance to touch them.

 

[CooCooCaChoo]

I've never had to use QoS because I have a high speed cable connection (57/11). If you also have a high speed connection, its better to use the torrent client to throttle its own speed.

I'm not sure if it would work, but try having the lowest priority filters at the top.

 

[noric]

@Grump
I see, thanks. So is there a way you can make P2P traffic slow down if necessary? Something like cutting some connections, I guess.

I've never had to use QoS because I have a high speed cable connection (57/11). If you also have a high speed connection, its better to use the torrent client to throttle its own speed.

I'm not sure if it would work, but try having the lowest priority filters at the top.

The problem of using the torrent client is that it wouldn't be a prioritization but a bandwidth cut.
I'll try putting Lowest to the top, just in case. Thanks for the idea.

 

[CooCooCaChoo]

They both do the same thing.

QoS throttles traffic by delaying the transmission of ACK packets. If the server doesn't receive an ACK packet, it will stop sending data until the client acknowledges their receipt. There is a hard limit on how long QoS can wait. If QoS waits too long, the server thinks that the data was lost on the way and will retransmit the same data again, which would be bad. The end result is that the server thinks that the connection speed is slow and will send the data at a slower rate.

When you use the torrent to throttle traffic, it controls download rate at its level instead of allowing QoS or some other system on the router to do it.

Prioritization is only important mostly for real-time applications. Gaming, video conferences, VOiP, live streams, etc. Things that require low latency.

 

[noric]

@Grump
I was still thinking at your explanation.
But if TCP backoff were the problem, shouldn't it happen when I test the P2P rule alone too? I did test that rule with no other contemporary download task (see first post) and I found out it worked as expected. I set the download limit to 5% and the download decreased to exactly 5% of my total bandwidth. So no backoff problem, I would say.
The issue only takes place with contemporary downloads. In my opinion QoS should check (in real-time) that the P2P download speed doesn't slow down other higher-priority download tasks. But it doesn't do this check.

 

[noric]

They both do the same thing.

QoS throttles traffic by delaying the transmission of ACK packets. If the server doesn't receive an ACK packet, it will stop sending data until the client acknowledges their receipt. There is a hard limit on how long QoS can wait. If QoS waits too long, the server thinks that the data was lost on the way and will retransmit the same data again, which would be bad. The end result is that the server thinks that the connection speed is slow and will send the data at a slower rate.

When you use the torrent to throttle traffic, it controls download rate at its level instead of allowing QoS or some other system on the router to do it.

Prioritization is only important mostly for real-time applications. Gaming, video conferences, VOiP, live streams, etc. Things that require low latency.

I see your point, but I'd like to use the whole bandwidth for P2P, if and when I'm not using such bandwidth in another way. If I set the limit in the client, the download speed will be throttled 24/7.

 

[Grump]

Try classifying some other application that can maximize your bandwidth, like FTP (21,1024-65535), and test that against HTTP with different QoS ratios.

 

[noric]

Try classifying some other application that can maximize your bandwidth, like FTP (21,1024-65535), and test that against HTTP with different QoS ratios.

Done. I've used this ftp download: ftp://download.nvidia.com/XFree86/FreeBSD-x86_64/343.13/NVIDIA-FreeBSD-x86_64-343.13.tar.gz
The FTP rule works if tested alone, but if tested together with an HTTP download they get about half of the bandwidth each. Exactly the same happens if I turn QoS off.
It appears to me that Asus's "QoS" only cuts bandwidth according to percentages you set, but doesn't really care about priority.

 

[Noremacyug]

The problem with QoS on the downstream is the packets are already entering your network before the router can decide what to do with them. You need QoS from your provider for it to be effective.

The nature of P2P opens many many connections. So your provider is sending you 100 p2p connections and 1 http connection. QoS on your router can't make the 100 p2p connections back off fast enough (google "TCP backoff") to allow the 1 http connection to function normally. The data was already sent over the link from your provider 100:1 before your router gets a chance to touch them.

gotta disagree with you regarding your statement that you have to have qos provided by your isp. i run a ipfire box and have since relegated my rt-ac66 to a WAP. my ipfire box will shape traffic on both the upstream and downstream. i can have torrents, usenet, gaming, youtube, browsing, etc. going and dependent upon the class i have assigned to each determines the available bandwidth they are allowed. my connection can stay saturated (minus a little overhead on both the up and downstream) and all streams will be classified and allowed maximum bandwidth allotted to them. if there is not two or more applications calling for bandwidth, then a single application is allowed the full amount of bandwidth. works a charm and is essential since i currently only have a 6Mbit/512Kbit adsl connection.


as you can see in the screen from my ipfire box. the connection stays "saturated" (minus my overhead). once the normal class of traffic makes a request, the bulk traffic gives up that which is needed by the normal class. in this case the bulk is a download from usenet and the normal traffic is a youtube video that i eventually switch to 720p, then 1080p and then finally back to auto. notice how the bulk backs off and gives the normal class whatever it needs and then reclaims the bandwidth when the normal class isn't calling for it. the same is applied to upstream traffic.




so, to reiterate, this can be achieved via hardware without the isp getting involved. however, in my previous attempts i was not able to achieve this via merlin or the stock firmware. tomato running on the router could do this.... but the firmware was too unstable for me and required multiple reboots throughout the week. perhaps the newer merlin, stock, or tomato firmware works better now..... i've not tried them.

 

[noric]

perhaps the newer merlin, stock, or tomato firmware works better now..... i've not tried them.

I really think nothing's changed with newer Merlin builds. QoS hasn't been refined at all, AFAIK. From my testings I see that no traffic shaping is done, at least on the downstream. Priority levels are very missleading, because they are nothing more than bandwidth caps actually.

Let's hope Merlin enters this thread and gives us his 2 cents.

 

[Noremacyug]

I really think nothing's changed with newer Merlin builds. QoS hasn't been refined at all, AFAIK. From my testings I see that no traffic shaping is done, at least on the downstream. Priority levels are very missleading, because they are nothing more than bandwidth caps actually.

Let's hope Merlin enters this thread and gives us his 2 cents.

that was my findings as well. i think i remember being able to set permanent, 24/7 caps on classes, but nothing dynamic would take place like in ipfire. tomato on the other hand was great and worked beautifully.... but overall stability was an issue in my case.

if you have a spare pc laying around or want to dish out a little money you can build a low power ipfire box. the software is free, just need the hardware to run it on. i use a little celeron 847 board.

 

[noric]

Yes, bandwidth caps work perfectly.
About required hardware, is Celeron's performance really needed or that's what you had laying around?

 

[Noremacyug]

had the celeron laying around as it was my htpc before i bought a mac mini. this is the board i have http://www.newegg.com/Product/Product.aspx?Item=N82E16813128585 . you could probably find a used one for cheap. great board with the dual 1Gbit nics. they also have some newer embedded celeron boards for a reasonable price.

this should help you out on hardware requirements.

http://wiki.ipfire.org/en/hardware/start