More precise hfsc than htb

Http://linux-ip.net/articles/hfsc.en/
Hfsc Scheduling with Linux
& Copy; 2005 Klaus rechert, Patrick mchardy & copy; 2006 Martin A. Brown (Translation)

For Complex Traffic Shaping scenarios, hierarchical algorithms are necessary. current versions of Linux support the algorithms htb and hfsc. while htb basically rearranges token bucket filter (TBF) into a hierarchical structure, thereby retaining the principal
Characteristics of TBF, hfsc allows proportional distribution of bandwidth as well as control and allocation of latencies. this allows for better and more efficient use of a connection for situations in which both bandwidth intensive data services and interactive
Services share a single network link.
When network access is used by multiple entities or for different services, then some sort of reasonable resource management is required. the assurance of minimum bandwidth for the individual services and users (Link-sharing) is one possible solution. for scenarios
Involving Voice over IP or streaming services, both pure bandwidth allocation and also prevention of high delay times become important. in one scenario two users share a single Internet connection with a 1000 kbit capacity; each user shoshould have control
At least 500 kbit of that capacity at any given moment. one of the users (Party A) uses a maximum of 100 kbit of his bandwidth for Internet telephony and the remainder of the transmission capacity for general data transport. figure 1 shows the corresponding
Hierarchy.

Figure 1:Hierarchy of shared network access.
Assume that all packets to be sent conform to a fixed size of 1500 bytes and all classes are sending at maximum rate. based on the 1000 kbit link capacity, it takes 12 ms (8*1500 byte/1000000 bit/s = 12 ms) to send a packet. the voice over IP Application sends
At 100 kbit which corresponds to 8 packets per second. in order to meet the guaranteed 100 kbit rate for this class, the qdisc must send a packet from this class every 120 ms, which wowould mean a maximum [queuing] delay of 132 Ms per packet. this example extends strates
The relationship between Bandwidth and delay. the hfsc algorithm is in a position to deal with both of these resources, bandwidth and delay. for this, the algorithm uses the service curve model for the allocation of resources. A Service Curve
S (t) represents the work achieved (service) in bits at time
T. the slope of the curve corresponds to the rate of transmission. the concept of the interaction with latency resides in the structure of the Service curves of the individual classes. by selecting a two-part service curve,
Each section of which is linear, the transmission delay for the Voice over IP class can be reduced to 30 ms. the first section of the Service Curve features a 400 kbit slope of 30 MS duration, where the second section exhibits a slope of 100kbit. this gain
In decreased delay of approximately 78 MS is earned at the expense of other classes. at no point, though, is the sum of the curves allowed to exceed the service curve of the total link capacity. in our example, the decreased delay for the Voice over IP class
Occurs at the cost of Party A's unspecified data class, whose service curve must be adjusted in order not to exceed the global limit. as a result, the maximum transmission delay of this class increases from 30 ms to a total of 52.5 Ms. for bulk data transport,
Such as FTP, for example, delay simply plays a secondary role in contrast to that of throughput, which isn't impaired by conforming to the service curve.

Figure 2:Scenario with linear and multi-part linear service curves.

The hfsc algorithm differentiates between real-time and link-sharing criteria. A leaf class can be assigned a real-time and a link-sharing curve, where inner classes can only have a link-sharing curve. the real-time criterion can only be applied to leaf classes
Because only these classes actually hold packets. this real-time oriented criterion is therefore responsible for carrying out of the guaranteed service. the link-sharing criterion only concerns itself with relationships to neighboring classes. it is responsible
For fair distribution of service rather than absolute guarantees. this separation into two criteria is necessary in order to be able to meet the guaranteed delay times under all circumstances. this also means that a class can send a packet on the basis
Its real-time guarantee even if the link-sharing curve of a class higher in the hierarchy is briefly violated, as a result. let's say our example data class from Party A is already active and sending at its maximum packet rate, 400 kbit. now, if at any point
In time, the voice over IP class becomes active, it is allowed to send with a higher rate on account of its real-time guarantee (Figure 3 ). thus, the Service for Class A, totals to abve 500 kbit, meaning that the link-sharing parameter for this class has
Been violated in the short term. In order to be able to carry out the link-sharing guarantees over the long term, Class A will be "punished" for this brief excess.

Figure 3:Between t1 and t2, exceeds the total maximum allowed capacity.

Each of the classes in the hierarchy is assigned a "virtual time", which corresponds to service actually attained. as soon as it is possible to send a packet, each level of the hierarchy is searched, starting at the root, for the class exhibiting the least
Attained virtual time. the leaf class found with this method then sends a packet and the virtual time of that class, along with each of its parent classes all the way up to the root, will be increased accordingly. if a class sends based on its real-time parameter,
Its virtual time will also be increased.
Hfsc usage on Linux
The first step to setting up an hfsc qdisc involves assigning a qdisc to a network interface, along with Optional specification of a default class:
TC qdisc add Dev$ DevRoot handle$ ID: Hfsc [Default
$ Classid] In the second step, the class hierarchy is constructed with consecutive class additions.
TC add class Dev$ DevParentParentidClassid
$ IDHfsc [[RTSC] [LsSC] | [SCSC] [Ul
SC] The participating attributes of each class are configured via the service curves which are described as follows:
SC: = [umaxBytesDmaxMS] Rate
BPSClasses at the lowest level of the hierarchy can be assigned a real-time curve (RT) as well as a link-sharing curve (LS ), where inner classes can only have a link-sharing
Curve. By using the UL service curve, an upper limit on service actually rendered to each class can be defined. Instead of specifying two identical
RT and LS curves, a single
SC curve can be specified. A service curve is described by its transmission rate, which correlates with the slope of the Curve. If the curve consists of two parts, it can be specified
Dmax the maximum delay at a certain transmission rate
Umax.

Example
# Example from figure 1. TC qdisc add Dev eth0 root handle 1: hfsc TC class add Dev eth0 parent 1: classid hfsc SC rate 1000 kbit ul rate 1000 kbit TC class add Dev eth0 parent classid hfsc SC rate 500 kbit ul rate 1000 kbit
TC class add Dev eth0 parent classid hfsc SC rate 500 kbit ul rate 1000 kbit TC class add Dev eth0 parent classid hfsc SC umax 1500b dmax 53 Ms rate 400 kbit ul rate 1000 kbit TC class add Dev eth0 parent classid hfsc SC umax 1500b
Dmax 30 ms rate 100 kbit ul rate 1000 kbit
References
[1] http://trash.net /~ Kaber/hfsc/[2]
Http://developer.osdl.org/dev/iproute2/download/ [3]
Http://lartc.org/[4]
Http://luxik.cdi.cz /~ Devik/QoS/htb/

Translator's note
The original German article, currently available
Http://klaus.geekserver.net/hfsc/hfsc.html, was initially published
Linux magazin in February 2005 (pages 28-37) in a series of articles on Queueing disciplines and was later republished in Special Edition (Sonderheft) number 3, 2006
(Pages 74-81 ).