The Resource Control Subsystems:
The CPU control subsystem uses the kernel’s CFS task scheduler to share CPU bandwidth among groups of processes. It’s an effective but somewhat mechanically complicated way to allocate CPU capacity.
The Memory control subsystem limits memory usage in user-space processes, primarily by discarding least recently used pages (LRU) to reclaim memory when a group of processes exceeds a preset limit. This subsystem imposes no restrictions on memory use by the Linux kernel.
The Disk I/O control subsystem allows or denies disk access to groups of tasks.
* The Network I/O control subsystem allows or denies network access to groups of tasks.


ARCHITECTURE
The fundamental idea behind controlling network resources using control groups is to connect control groups to the existing packet classification and scheduling architecture which already provides means to classify and schedule network packets accordingly.



For this purpose, a new cgroup subsystem (net_cls) has been introduced which enables cgroups to specify which traffic class packets originating from the group will be classified to. This is done by assigning a classification identifier (classid) to the cgroup which is then used by the newly introduced packet classifier (cls_group) to filter packets into the corresponding traffic class matching the classid as seen in the following diagram.
In order to keep the architecture as simple and non-intrusive as possible the classid is not stored in the packet while traveling the network stack. Instead the packet classifier uses the process context information of the packet to look up the cgroup respectively classid. The disadvantage of this architecture is that it only works on packets leaving the stack in process context, i.e. it will not work with packets generated by the kernels itself (ACKs, ICMP replies, etc.) or if a packet is queued and rescheduled before the packet passed the packet classifier.



Traffic classes can be organized in trees and may contain any number of queuing disciplines (qdisc) to implement prioritization, bandwidth constraints or fair queuing. Traffic classes must be assigned to network interfaces, therefore if a cgroup sends packets over multiple interfaces a separate set of traffic classes must be maintained for each interface.
The major advantage of this architecture lies in the possibility to combine the classification by classid with any of the existing classification features to for example prioritize interactive traffic inside task groups, i.e. it is not required to create a seprate cgroup for each desired traffic class.


HTB is meant as a more understandable, intuitive and faster replacement for the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use of the outbound bandwidth on a given link.
** Both allow you to use one physical link to simulate several slower links and to send different kinds of traffic on different simulated links. In both cases, you have to specify how to divide the physical link into simulated links and how to decide which simulated link to use for a given packet to be sent.