QOS rules updating - suggestions?

Discussion in 'Tomato Firmware' started by Madumi, Jul 19, 2018.

  1. Madumi

    Madumi Serious Server Member

    Hi guys,

    I've really appreciated tomatoUSB over the years, especially it's ability to cope with loads from multiple users.

    Up till now, I've simply taken the "example QOS classification rules" which are included by default and stuck with them without change... thinking one day I'll dig into them and update them.

    So... the next number of months might be a good time to udpate the QOS rules... but I'm ignorant what's the best way to do this. If I was to overhaul the QOS rules, can anyone suggest a good resource to use to check/update rules?
  2. Bad_Dog

    Bad_Dog Connected Client Member

    The defaults are pretty good, albeit some are old (MSN and Yahoo Messenger are still in the list; not sure how long they've been gone). But by and far, the default entries are good.

    I use QOS, and here's what I did...
    - Removed some of the old/outdated ones that I knew I don't need. Mostly those involved online multiplayer game/servers and messaging apps.
    - Created many of my own. Mainly for P2P like Bittorrent, file transfers for my Cloud backup service, so I can directly assign it to a different class than the default HTTPS one, since it's also using port 443.
    - Added specific IP's to a class so traffic from a couple of my network cell phone repeater/extenders always go into its own VOIP/Media class, instead of trying to determine what ports it's using. If traffic is going to/coming from these IPs, which I have reserved in DHCP, then it's definitely VOIP-related.

    And the rest of the work was setting up the lower/upper percentage limits for the bandwidth usage for each inbound and outbound classes. It's worked fine for me for years, but always willing to learn more. If you do find a resource, please share it!
    Madumi, NotVeryClever and nodnarb91 like this.
  3. Monk E. Boy

    Monk E. Boy Network Guru Member

    Personally I dump the entire ruleset and create my own from scratch based on my actual traffic. Many of my rules serve a similar purpose to the stock ruleset but I tend to group like rules together and do less L7 filtering because I don't care if you're watching a YouTube video, streaming a Netflix movie, or poking around the Amazon store - they're all 80/443 traffic so they can all be classified as 80/443 traffic. I tend to deprioritize progressively large transfers, so <1MB is high, 1MB-250MB is medium, >250MB is low, that kind of stuff. Paying attention to the QoS graphs and lists while building up your ruleset is key since whatever gets caught by the default rule is going to be traffic you need to look at to possibly create additional rules from.

    In fact there's something to be said for simply prioritizing traffic based on size alone, since small traffic like DNS queries should get a high priority and the larger the transfer the less likely it is to be time-sensitive. The problem is that P2P transfers tend to be small so they could create problems, though one could prioritize DNS, NTP, etc. up top and then implement size-based rules below. I try to stay away from L7 filtering because it can have a severe impact on transfer rates.

    I try to think of the minimum % for each category as guaranteed bandwidth. The router will try to guarantee that that percentage of bandwidth is available for use for that category. Though rules high in the list tend to need a smaller % minimum because they get first crack at bandwidth.
    Madumi, NotVeryClever and cloneman like this.
  4. cloneman

    cloneman Addicted to LI Member

    An underrated aspect of enabling Tomato QoS is that it makes things better even without any manual classification rules at all, thus removing the need for obsessing over the ruleset. This is because a fair queiing scheduler (sfq or fq_codel) gets enabled and prioritizes smaller traffic "flows" automatically.

    Just dumping everything into "default" and setting you Global up/down bandwidths properly yields good performance.

    Yes - there are still some advantages to manual rules. I graphed the performance some time ago, manual rules slightly outperform "doing nothing except turning on fq". Thus they are suitable for things like dumping large transfers out of default and manually prioritizing VoIP devices.


    Red (Manual Rules) Slightly Outperforms Green (Automatic SFQ), but both are far better than QoS disabled and only slightly worse than having no traffic on the line.
  5. Yim Sonny

    Yim Sonny Serious Server Member

    Good advice. Many of us do the same. If you are using an ARM based router be sure to take note of the firmware bug requiring the first rule in the list to be left alone. Finding that bug ate up several hours of my time when moving to ARM. There is no obvious indication of this requirement anywhere.
    Techie007 likes this.
  6. Madumi

    Madumi Serious Server Member

    thanks so much for replies!

    Thanks so much for your reply & the graph is really nice to see the difference with manual rules in place.

    quick question:
    Tomato uses fq_codel for fair queuing right? Would that mean that ubnt would perform similarly (afaik they've also implemented fq_codel for QOS?) and for that matter, mikrotik, while it doesn't have fq_codel, it has sfq, so wouldn't that be similar... Or does tomato have something else under the hood?
  7. cloneman

    cloneman Addicted to LI Member

    Many of these implementations are likely similar. Tomato has options for sfq and fq_codel on ARM, but only sfq MIPS.

    There are differences in setting up manual classes. I don't know that ubnt allows you to use fq_codel + manual rules at the same time, unless you use the CLI.

    Tomato was "ahead" of the rest as far as implementing ingress QoS (IMQ/IFB) and DSL overhead value, I think anyone that implements fq_codel has caught up.
    Madumi likes this.
  8. Madumi

    Madumi Serious Server Member


    Thanks for your reply... Out of interest, how did you perform your QOS testing--especially how did you maintain a constant load?
  9. Bad_Dog

    Bad_Dog Connected Client Member

    I seem to recall a bug in Shibby that would cause problems with the graphing if you deleted any of the stock ones... what's the bug with the first rule? I'm still on Shibby 140, BTW.

    And what is the actual first rule? Just want to confirm whether or not I've deleted it since it's been more than a week since I've set up QOS? :)
  10. Monk E. Boy

    Monk E. Boy Network Guru Member

    If its the same as MIPS, then it's DNS 53. That's one of the rules I normally don't get rid of since I need to classify DNS traffic, although I usually make it UDP 53. I don't allow external DNS, and I don't think netmasq uses TCP 53.
  11. cloneman

    cloneman Addicted to LI Member

    Probably just a single file upload. The test certainly wasn't a comprehensive analysis and was something I did quickly to try and confirm weather manual rules made any difference.
    Madumi likes this.
  12. Bad_Dog

    Bad_Dog Connected Client Member

    Yeah, that's what I have as rule #1: TCP/UDP Port 53, DNS. So... does it blow up if I were to delete it?
  13. Yim Sonny

    Yim Sonny Serious Server Member

  14. Bad_Dog

    Bad_Dog Connected Client Member

    Ow, nasty bug. Thanks for that.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice