Setting up QoS. Is QoS useless

[kamikaze96]

I've been trying to figure out how to turn QoS On and tell it to give my PC priority over other devices, but I've read that QoS would lower your internet speed and it wouldn't actually help because it's the ISP that sends data to you, so if the ISP sends you a data packet for a certain device with a low priority the router would just have to send it through anyway. That's what I understood anyway. Is it true?
QoS seems to be the solution to a lot of people's problems. If QoS really isn't useful, is there an alternative?

 

[abailey]

QOS has many good applications inside of a network, from VOIP to media streaming. The problem comes in when you try to use it on internet bandwidth as you loose control of the QOS as soon as it leaves your network. You can do some prioritizing of devices with QOS as related to sending traffic out of your network to the internet, but yes, you have no control of how it comes back and the bandwidth is distributed. You can cap the max bandwidth a client can take for himself with some routers or AP's, but that is not really QOS.

 

[kamikaze96]

So 'bandwidth control' is a better option to use than QoS.
Actually after thinking about it, Bandwidth control Is really what I need, but its only problem is that when the device with the highest priority is not using the internet, other devices would still be stuck with whatever bandwidth is assigned for them, which in my case isn't such a big deal but other's might not like it.

 

[abailey]

I see you have seen this topic: http://www.tomshardware.com/answers/id-2086006/qos-setup-specific-game.html
In the second post bill001g does a good job of talking about QOS related to internet speed. Even if you cap the bandwidth on the outgoing or incoming internet connection, it is usually of little value unless you cap it so much that the other devices are seriously hampered.

 

[bill001g]

The key thing to remember is you can only control data that is SENT from your router. So you can do lots of fancy tricks with QoS on the UPLOAD side of your connection. So you could limit a person who was seeding too many torrents or was streaming a high def feed to twitch.

On the download side you can do nothing. The ISP has already discarded whatever packets they felt like and by the time your router gets the data there is little you can do to get data back. No ISP will bother to even discuss with you what traffic YOU think is important. The only things you can do with bandwidth control on the download side is to limit certain traffic even more than the ISP did and hope the error correction in TCP detects it and slows the connection down. Lets say the ISP send 7m of traffic to a user and you discard 2m and give the machine the remaining 5m. From the user machine perspective it is only getting 5m and seeing lots of packet loss. From the circuit perspective you are still using 7m
The only reason this can even think to work is if he user machine responds by slowing down because of the packet loss. Some applications do not slow down...mostly UdP based stuff but torrent also is not affected as much as would be desired.

 

[kamikaze96]

The key thing to remember is you can only control data that is SENT from your router. So you can do lots of fancy tricks with QoS on the UPLOAD side of your connection. So you could limit a person who was seeding too many torrents or was streaming a high def feed to twitch.

On the download side you can do nothing. The ISP has already discarded whatever packets they felt like and by the time your router gets the data there is little you can do to get data back.

I don't think I understand this very well. If I set the router to limit the upload speed of a user that I would like to give low priority to, shouldn't it wait more to get its response back from the ISP while my PC with a higher priority and a higher upload speed gets more attention from the ISP and my data is being sent more frequently?

 

[kamikaze96]

Even if you cap the bandwidth on the outgoing or incoming internet connection, it is usually of little value unless you cap it so much that the other devices are seriously hampered.

Why is that?

 

[bill001g]

The ISP completely ignore any setting you place on packets. In fact they reset them all to zero. In addition the actual source of the data may be a different ISP. So say someone is streaming a high def video from netflix and a different user is playing some game. There is no way to tell where in the internet this is coming from but eventually it gets to the ISP router that is going to send it to your house. How does it know traffic from netflix is more or less important than the game traffic. This traffic is coming from some random servers in the internet and it all appears to go to the same IP address. The ISP has no idea which machines are really going to get the traffic. So they don't even bother to try and they just send stuff randomly and whatever doesn't fit gets discarded.

I will very briefly touch on limitation of upload affecting download but you really must understand a very advanced concept called tcp window size. So the theory is you can limit the download by limiting the amount of traffic a user is allowed to send. Of course it works really well if you say a user can not send any traffic at all so they therefore will never get any traffic in response. As soon as you start allowing "some" traffic it gets massively complex. A overly simplistic example just to demonstrate without going into the maze window size and burst rates calculations.

So a user wants to watch a high def video that streams 10m/sec. He sends a message "send video1" and the server start sending data at 10m/sec. Then once every minute the server asks do you want me to continue and the user send "yes". So now you have sent 11 characters to get it started and 3 characters to keep the feed going. So what number can you pick on the outbound rate when he can send 3 characters/min and get 10m/sec. It can be done if you really know the application well but it takes massive knowledge and even I who do QoS in a corporate environment for a living never attempt to limit inbound traffic by applying QoS policies outbound.

 

[kamikaze96]

I will very briefly touch on limitation of upload affecting download but you really must understand a very advanced concept called tcp window size. So the theory is you can limit the download by limiting the amount of traffic a user is allowed to send. Of course it works really well if you say a user can not send any traffic at all so they therefore will never get any traffic in response. As soon as you start allowing "some" traffic it gets massively complex. A overly simplistic example just to demonstrate without going into the maze window size and burst rates calculations.

Alright, I'm gonna trust you on this one 😉

So it seems like there is no 'perfect' way to solve this. It's all controlled from the ISP's side!

 

[kamikaze96]

Would creating multiple wireless networks using the same router* (different SSIDs) introduce a solution of some kind?
(So that the less important device connects to a different network.)

*I think my router can do this, I haven't looked into it much.

 

[bill001g]

Most consumer routers will only allow a single lan network. Don't confuse the wireless WMM QoS with internet QoS they are not really the same. Lets say you use a commercial router that can run QoS on the lan ports you could come up with QoS policies between the different devices within your network since you are in complete control.

From the internet standpoint nothing at all has changed. All traffic is still coming back to the same IP address. All that changes is the way you can identify the traffic being sent. That never was the problem in the first place. You still have the issue of how do you drop certain outbound traffic to limit inbound.

 

[Kewlx25]

If your router supports throttling your upload bandwidth, set it to about 80% of what your upload actually is. Latency is not a congestion issue in the normal sense, it's a buffer issue, packet-loss is a congestion issue. Limiting your upload speed keeps your buffer from filling up and causing latency, assuming your ISP is any good.