Our manager wants us to do applicaiton qos which is quite different from the well-known system qos. We have many services of three types, they have priorites, the manager wants to suspend low priority services requests when there are not enough bandwidth for high priority services. But if the high priority services requests decrease, the bandwidth for low priority services should increase and low priority service requests are allowed again.

There should be an algorithm involving priority and bandwidth. I don't know how to design the algorithm, can anyone assist in getting this right?

All these services are within a same process. We are setting the maximum bandwidth for the three types of services via ports of services via TC (TC is the linux qos tool whose name means traffic control).

  • 1
    I don't see anything that wouldn't be already solved by existing priority queue variants. Would you please explain why priority queue, hierarchical token bucket or other queueing disciplines provided by Linux don't suit you?
    – Jan Hudec
    Nov 25 '13 at 12:17

The first thing to understand is that you're basically needing to build a subset of all the parts that go into an operating system scheduler, including:

  • instrumentation and monitoring (What resources are currently available?)
  • Decision making / policy (How should resources be allocated? How will the users or administrators communicate their policy / priority desires?)
  • Enforcement (How should processes be restricted from using more than their allocated amount?)

The good news is that a lot of the components, especially in the monitoring and enforcement realms, will be very thin layers on existing mechanisms such as as Linux cgroups, netstat, and tc.

There is even a chance that the policy mechanism of cgroups will be sufficient to your need. It's a lot more sophisticated than the "priorities" of historical Unix, and many commercial shops have relied on similar (albeit proprietary / single vendor) facilities such as HP PRM and AIX WPARs for application QoS management.

These typically work on some variant of fair share scheduling, which allows one to define relative priorities for different classes or groups of jobs/processes, and arrange the classes/groups with respect to one another, so that their relative importance and resource allocations are as the policy or "as the business" intended, yet without completely starving the lower-priority jobs. (If you're willing to starve lower-priority jobs completely, simpler mechanisms can be used.)

Simple forms of FCS use single-level classes, with each member in a class being equal to the others. More refined forms use hierarchical groupings, so that the "minimum 50% resources devoted to Platinum" users can be further subdivided with specific allocations or minimums for subgroups or even individual users. (Having a single app/job be the only member of a group is an easy way to give it the group's entire allocation.) This page goes into some detail about how one of these "workload managers" (Adaptive Computing's Moab) operates.

example hierarchical priority or share allocation

There are a variety of ways the policies can be defined. "Shares" is a relatively sophisticated way, but one that novice users often find difficult. "Percentages" or "priorities" are somewhat less precise and more perturbable, but can be more popular with less mathematical policy-setters.

And there are a lot of nuances possible. The LPAR allocations of AIX and IBM Power machines, for example, have a number of subtle options for temporary priority inversions, "stealing" cycles that would otherwise go unused, and otherwise tweaking the policies. If you want something very sophisticated, proprietary Unix systems have a number of good study points.


I don't see anything that wouldn't be already solved by the existing queueing "disciplines".

All you need to do is rate-limit the root and sort the traffic into appropriate queues by priority.

Normally you QoS traffic before it enters the narrowest link. But if you want to prioritize download, it is still possible with sacrificing a bit of total bandwidth. If you rate-limit the incoming traffic to a bit less than the total bandwidth (say 5-10%), the low priority traffic will get more discarded packets than the high priority one which will make the TCP congestion algorithm retract faster for the low priority traffic and it will after short while grind to halt if there is enough high-priority traffic.


There are companies who do application QoS for living (Exinda, Riverbed, etc..) and it is not a job that can be completed by a single person if you need a reliable system. Having said that if you still want to go ahead and implement a cheaper solution, TC in linux is a good place to start this will allow you to throttle traffic. IPtables can be used to create rules to mark the traffic with a mark and route packets to different TC buckets based on the mark.I cannot give more specific answers as to configuration of iptable rules and tc without more information about your network and type of applications you are trying to prioritize.

In terms of queuing there are many generic algorithms like FIFO,HTB.

You might be able to get away with the simple bash scripts if you are trying to prioritize just generic traffic like HTTP, FTP or ports as you are trying to do.

If you are looking to for a more sophisticated system that can detect different types of web applications you might have to take a look at some sort deep packet inspection tool(most of them have to be purchased).If you have a decent firewalls in your premise they might also have some QoS capabilities.

My point is it is a very humongous task to build a QoS system in large scheme of things,But if you can give more specific input on what you are trying to achieve some one might be able to help you.

Disclaimer: I work with Exinda.


One solution would be to run the services through a message queuing solution (like RabbitMQ, MQSeries, etc.). That will provide priorities, can be load balanced, and offers guaranteed delivery.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.