tc-hfsc

Qdisc Options (for tc qdisc add ... hfsc):
    

default CLASSID
    Specifies the default child class for packets that do not match any explicit filter. If not set, non-classified packets are dropped.

r2q BPS_VALUE
    Real-time to quantum parameter. Specifies the maximum rate in bytes per second for automatic `rt` (real-time) service curve creation if no explicit quantum is defined and a link layer doesn't report bandwidth.

Class Options (for tc class add ... hfsc):
    

ls QUANTUM [ RATE ]
    Defines the Link Share (LS) service curve. This curve specifies the amount of bandwidth a class receives when its parent is congested and its sibling classes are also demanding bandwidth. QUANTUM is the number of bytes allowed per scheduling opportunity. RATE (optional) is the rate in bytes per second for this curve, setting its slope.

rt QUANTUM [ RATE ]
    Defines the Real-Time (RT) service curve. This curve provides a guaranteed minimum rate and bounded delay, making it suitable for latency-sensitive traffic. QUANTUM is the number of bytes allowed per scheduling opportunity. RATE (optional) is the rate in bytes per second for this curve, setting its slope.

ul QUANTUM [ RATE ]
    Defines the Upper Limit (UL) service curve. This curve imposes an absolute maximum rate for the class, regardless of available bandwidth, effectively shaping traffic. QUANTUM is the number of bytes allowed per scheduling opportunity. RATE (optional) is the rate in bytes per second for this curve, setting its slope.

HFSC is a sophisticated queueing discipline (qdisc) for Linux's traffic control subsystem, designed to provide precise control over bandwidth allocation and latency. Unlike simpler qdiscs, HFSC uses "service curves" to define how much bandwidth a traffic class can expect over time, even under contention. It supports hierarchical structures, allowing for intricate traffic management policies by nesting classes within parent classes.

HFSC aims to achieve fair sharing of bandwidth while providing strict guarantees for real-time traffic and setting upper limits for other traffic types. It achieves this through three types of service curves: Link Share (LS), Real-Time (RT), and Upper Limit (UL). LS ensures a fair share when there's demand, RT guarantees a minimum rate and bounded delay crucial for latency-sensitive applications, and UL imposes a maximum bandwidth limit. Its complexity makes it powerful but requires careful configuration.

HFSC is significantly more complex to configure and understand than simpler qdiscs like HTB, leading to a steeper learning curve. Incorrect configuration can lead to unexpected behavior or inefficient bandwidth utilization. Its per-packet scheduling logic can be CPU-intensive, especially on systems with very high packet rates or a large number of classes, potentially impacting overall system performance. Debugging HFSC setups can also be challenging due to the intricate interactions of its service curves and hierarchical structure.

HFSC's core lies in its service curves, which define the traffic flow. The three types are:
Link Share (LS): Ensures a fair share of a parent's bandwidth among competing children. It's active when the class has data to send and its parent's capacity is constrained.
Real-Time (RT): Guarantees a minimum rate and bounded delay, making it suitable for latency-sensitive applications like VoIP or gaming. It schedules packets to meet a specified deadline.
Upper Limit (UL): Imposes a strict maximum rate on a class, effectively shaping its traffic. It ensures a class never exceeds this rate, regardless of available bandwidth or its parent's capacity.

HFSC supports a hierarchical structure, meaning a qdisc can have multiple classes, and each class can in turn be a parent to further child classes, forming a tree-like structure. Traffic flows down this hierarchy, being shaped and prioritized at each level. Class IDs are typically in the format MAJOR:MINOR, where MAJOR is derived from the parent qdisc's handle and MINOR identifies the specific class.

HFSC was developed by Peter J. G. O'Donnell at the University of Cambridge and was introduced into the Linux kernel around version 2.6.7 (around 2004). It was designed to provide a more robust and flexible traffic control mechanism than existing fair queuing algorithms, particularly focusing on fulfilling service rate guarantees and bounding delays under diverse network conditions. While powerful, its complexity often leads administrators to opt for HTB for simpler bandwidth sharing needs.

tc(8), tc-qdisc(8), tc-class(8), tc-htb(8), tc-tbf(8), tc-prio(8)