An easy way to priotize gaming on a router? (dd-wrt)

[I3ordo]

Hello all,

i want to ask if it is okay to priotize all (1-65535) UDP ports? I want to have VOIP, UDP based multiplayer games on HIGHEST Priority.

 

[Kewlx25]

http://www.dd-wrt.com/wiki/index.php/QoS

This part is the main part

Select HTB as your packet scheduler if you have "queuing discipline" listed below it, if not then use HFSC.
Select FQ_CODEL as your queuing discipline.

HTB is how you rate limit your connect and FQ_CODEL is your "QoS". Don't even worry about doing port ranges or anything else, just set these two things.

 

[I3ordo]

http://www.dd-wrt.com/wiki/index.php/QoS

This part is the main part

Select HTB as your packet scheduler if you have "queuing discipline" listed below it, if not then use HFSC.
Select FQ_CODEL as your queuing discipline.

HTB is how you rate limit your connect and FQ_CODEL is your "QoS". Don't even worry about doing port ranges or anything else, just set these two things.

My dd-wrt (seems like the latest one) is Firmware: DD-WRT v3.0-r28015 std (10/23/15)
and neither mode (HB or HSFC) has queing discipline options. It looks like this.
https://dl.dropboxusercontent.com/u/72248093/qos2.JPG

I tired setting it to HSFC mode and applied the "changes" but that queing discpline option did not come up.

However, what i am curious about is, as i assigning the whole UDP port range as Premium"/"Maximum" what damage does it do, as far as i know, UDP ports are used for real time stuff. like VOIP and online gaming.(though i am not sure about that)

 

[Kewlx25]

There seems to be a missing option. Maybe fq_Codel is enabled by default? Are you having latency issue?

 

[Kewlx25]

I found this

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=983393

PostPosted: Sun Sep 13, 2015 2:13 Post subject: fq_codel support for which makes? dir-615c1 missing QoS Reply with quote
DD-WRT v3.0-r27805 std (09/11/15)
Router Model D-Link DIR-615-C1

Queueing Discipline option does not display. Tried HTB and HFSC in case they were toggled options.

Router was factory reset after upgrade. Any help is greatly appreciated.

 

[I3ordo]

I found this

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=983393

PostPosted: Sun Sep 13, 2015 2:13 Post subject: fq_codel support for which makes? dir-615c1 missing QoS Reply with quote
DD-WRT v3.0-r27805 std (09/11/15)
Router Model D-Link DIR-615-C1

Queueing Discipline option does not display. Tried HTB and HFSC in case they were toggled options.

Router was factory reset after upgrade. Any help is greatly appreciated.

that post clearly explains the problem. Though i was not having issues with using HTB... and everything was working fine...

I still wonder, what s the downside of priotizing all UDP ports , all i want is having the priority of "downloads" at lower priority than gaming VOIP and steamings...

 

[bill001g]

That option is mostly to prevent buffer bloat. It can fix problems for data like VoIP and games that have critical timing issues because it prevents TCP streams from hogging a link.

It does not fix the problem of UDP based file transfer like torrent . It also does not really give any type of data priority. It more or less gives everyone average.

What it mostly works for is TCP data transfers that tend to create the buffer bloat issue. It is forcing data to be lost rather that delayed which in turn allows the TCP session to detect this loss and reduce the rate they request data. This also causes packet loss in the UDP streams rather than delay. It works best when there are only a small number of tcp streams a large number still each get their so called fair share.

It really depends what your problem is. If you have torrent running there is little you can do to limit that because it is designed to get around limitations even by ISP.

Generally the method that works the best is to set a maximum rate for all other traffic that you do not want priority. If you had a 10m connection and you limit it to 6m for all non important traffic it would leave 4m for your important traffic. Again it really only works well for TCP traffic UDP is greatly dependent on the application and even some TCP server stack implementations are not always limited if they are tuned to be very aggressive on the tcp window size.

 

[I3ordo]

That option is mostly to prevent buffer bloat. It can fix problems for data like VoIP and games that have critical timing issues because it prevents TCP streams from hogging a link.

It does not fix the problem of UDP based file transfer like torrent . It also does not really give any type of data priority. It more or less gives everyone average.

What it mostly works for is TCP data transfers that tend to create the buffer bloat issue. It is forcing data to be lost rather that delayed which in turn allows the TCP session to detect this loss and reduce the rate they request data. This also causes packet loss in the UDP streams rather than delay. It works best when there are only a small number of tcp streams a large number still each get their so called fair share.

It really depends what your problem is. If you have torrent running there is little you can do to limit that because it is designed to get around limitations even by ISP.

Generally the method that works the best is to set a maximum rate for all other traffic that you do not want priority. If you had a 10m connection and you limit it to 6m for all non important traffic it would leave 4m for your important traffic. Again it really only works well for TCP traffic UDP is greatly dependent on the application and even some TCP server stack implementations are not always limited if they are tuned to be very aggressive on the tcp window size.

What i gather from your reply is : Every kind of connection may use any kind of protocol so, priotizing the whole UDP port range may also priotize torrenting and filetransfers also...

So the priotizition must be applied on per application basis.

For that to happen, i need to be able to monitor the router and the ports being used by each pplication or device. As the playstations/xbox'es do not have transpercy of their actions.. I need a network tool or command that will report to me as:
192.168.1.44 started using port 56456 UDP
192.168.1.44 started using port 56499 TCP

and i will priotize those ports for future use... Any known user-friendly applications like that?

 

[bill001g]

This is the biggest pain there is getting QoS setup. The DD-wrt has some abilities to log traffic but I forget the details. You used to be able to put in firewall rules that allowed all traffic but logged it.

I tend to use netflow data capture on a dd-wrt router which is massive overkill for what you want to do. I just always have that running so I have forgotten the other ways to do it.

It might also have a screen that shows current open sessions I know the asus dd-wrt version recently added one so you would think the real dd-wrt has it. You forget so much when you don't mess with things for months.

 

[Kewlx25]

That option is mostly to prevent buffer bloat. It can fix problems for data like VoIP and games that have critical timing issues because it prevents TCP streams from hogging a link.

It does not fix the problem of UDP based file transfer like torrent . It also does not really give any type of data priority. It more or less gives everyone average.

What it mostly works for is TCP data transfers that tend to create the buffer bloat issue. It is forcing data to be lost rather that delayed which in turn allows the TCP session to detect this loss and reduce the rate they request data. This also causes packet loss in the UDP streams rather than delay. It works best when there are only a small number of tcp streams a large number still each get their so called fair share.

It really depends what your problem is. If you have torrent running there is little you can do to limit that because it is designed to get around limitations even by ISP.

Generally the method that works the best is to set a maximum rate for all other traffic that you do not want priority. If you had a 10m connection and you limit it to 6m for all non important traffic it would leave 4m for your important traffic. Again it really only works well for TCP traffic UDP is greatly dependent on the application and even some TCP server stack implementations are not always limited if they are tuned to be very aggressive on the tcp window size.

Bufferbloat is the entire issue, it's why VoIP and games "feel laggy". VoIP and UDP based games handle loss quite well, but they do not handle latency and jitter well.

Cake should replace HTB and fq_codel in the next year. It's almost done, then it's just a matter of getting merged in. Unlike fq_Codel, Cake has perfect flow isolation in all tested good-actor benchmarks and loadtests. May not work correctly under a DDOS. This means games and VoIP should, in theory, have less than a few ms of additional latency or jitter, and no loss, assuming there is actually enough bandwidth.

 

[bill001g]

That option is mostly to prevent buffer bloat. It can fix problems for data like VoIP and games that have critical timing issues because it prevents TCP streams from hogging a link.

It does not fix the problem of UDP based file transfer like torrent . It also does not really give any type of data priority. It more or less gives everyone average.

What it mostly works for is TCP data transfers that tend to create the buffer bloat issue. It is forcing data to be lost rather that delayed which in turn allows the TCP session to detect this loss and reduce the rate they request data. This also causes packet loss in the UDP streams rather than delay. It works best when there are only a small number of tcp streams a large number still each get their so called fair share.

It really depends what your problem is. If you have torrent running there is little you can do to limit that because it is designed to get around limitations even by ISP.

Generally the method that works the best is to set a maximum rate for all other traffic that you do not want priority. If you had a 10m connection and you limit it to 6m for all non important traffic it would leave 4m for your important traffic. Again it really only works well for TCP traffic UDP is greatly dependent on the application and even some TCP server stack implementations are not always limited if they are tuned to be very aggressive on the tcp window size.

Bufferbloat is the entire issue, it's why VoIP and games "feel laggy". VoIP and UDP based games handle loss quite well, but they do not handle latency and jitter well.

Cake should replace HTB and fq_codel in the next year. It's almost done, then it's just a matter of getting merged in. Unlike fq_Codel, Cake has perfect flow isolation in all tested good-actor benchmarks and loadtests. May not work correctly under a DDOS. This means games and VoIP should, in theory, have less than a few ms of additional latency or jitter, and no loss, assuming there is actually enough bandwidth.

That is true but that is not what he asked. He was concerned that UDP file transfers would impact his game. Buffer bloat is purely a TCP related concept and none of these solution will fix a issue where a UDP file transfer is causing the issue. Both torrent and a number of game downloaders can not be contained by these methods. The main issue with it is it makes all data equal. If you have multiple a tcp applications that have 99 sessions open and you have 1 game session open the game will get only 1/100 of the bandwidth. You can not fix a connection that is actually overloaded with these magic click one box things.

 

[Kewlx25]

That option is mostly to prevent buffer bloat. It can fix problems for data like VoIP and games that have critical timing issues because it prevents TCP streams from hogging a link.

It does not fix the problem of UDP based file transfer like torrent . It also does not really give any type of data priority. It more or less gives everyone average.

What it mostly works for is TCP data transfers that tend to create the buffer bloat issue. It is forcing data to be lost rather that delayed which in turn allows the TCP session to detect this loss and reduce the rate they request data. This also causes packet loss in the UDP streams rather than delay. It works best when there are only a small number of tcp streams a large number still each get their so called fair share.

It really depends what your problem is. If you have torrent running there is little you can do to limit that because it is designed to get around limitations even by ISP.

Generally the method that works the best is to set a maximum rate for all other traffic that you do not want priority. If you had a 10m connection and you limit it to 6m for all non important traffic it would leave 4m for your important traffic. Again it really only works well for TCP traffic UDP is greatly dependent on the application and even some TCP server stack implementations are not always limited if they are tuned to be very aggressive on the tcp window size.

Bufferbloat is the entire issue, it's why VoIP and games "feel laggy". VoIP and UDP based games handle loss quite well, but they do not handle latency and jitter well.

Cake should replace HTB and fq_codel in the next year. It's almost done, then it's just a matter of getting merged in. Unlike fq_Codel, Cake has perfect flow isolation in all tested good-actor benchmarks and loadtests. May not work correctly under a DDOS. This means games and VoIP should, in theory, have less than a few ms of additional latency or jitter, and no loss, assuming there is actually enough bandwidth.

That is true but that is not what he asked. He was concerned that UDP file transfers would impact his game. Buffer bloat is purely a TCP related concept and none of these solution will fix a issue where a UDP file transfer is causing the issue. Both torrent and a number of game downloaders can not be contained by these methods. The main issue with it is it makes all data equal. If you have multiple a tcp applications that have 99 sessions open and you have 1 game session open the game will get only 1/100 of the bandwidth. You can not fix a connection that is actually overloaded with these magic click one box things.

UDP file transfers is pretty much limited to Bittorrent and that responds to loss and bloat better than TCP does.

Networks flows are pretty much limited to two types
1) Fixed low bandwidth
2) Dynamic high bandwidth

You can't fix 1, but 2 responds to loss, and codel, fq_codel, and cake all bias loss against heavy flows.

TCP on Bittorrent actually has massive bloat issues that floods my connection. I have a 100Mb that is pretty much 0.0001% loss and I get my rate 99.99% of the time. The one time that I see almost any loss at all is when a Bittorrent seeder has massive bufferbloat and is using TCP instead of uTP(UDP based).

I did a packet capture to dig into why I was getting upwards of 20% packetloss, which is insane. I configured my Bittorrent client to rate limit to 50Mb/s. When I looked at my WAN packet capture, I was seeing between 10Mb/s and 15Mb/s of duplicate TCP packets. When I set Bittorrent up to 80Mb/s, I was seeing 20Mb/s+ of dup TCP packets and loss. Over 1/4 of my incoming traffic was dupe packets.

I grabbed a list of several IP addresses that were sending me these extra packets, and did a traceroute. What I saw a nice low latency most of the way to them, but when 2-3 hops before the trace got to their IP addresses, I suddenly saw latency shoot up into the 2k-3k ms ranges. At those pings, TCP assumes the packets got lost and resends.

I don't get this issues with uTP because it limits bufferbloat.

 

[I3ordo]

too bad i still can't extract the information out of these posts... What i just wanted was to prioritize
real time applications>steraming data > file downloads > p2p file transfers and even on one of the best route firmware available on earth can't solve this problem, practically enough.... truly disappointed.


There must be some kind of software that let me monitor the connections that goes through the router and let me prioritize stuff on future use...

 

[Kewlx25]

Since your version of dd-WRT does not have an option for fq_codel, you're stuck doing it the hard way. I see experts with 15+ years of network experience get QoS wrong quite regularly. That's why they made "Cake". It's meant to be "easy as cake". fq_codel is the next closest thing.