In one scenario two users share a single Internet connection with a 1000 kbit capacity; each user should have control of 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.
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
represents the work achieved (service) in bits at time
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 to exceed the global limit. As a result, the maximum transmission delay of this class increases from 30ms 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.
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 above 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.
tc qdisc add dev $dev root handle $ID: hfsc [default $classID ]
In the second step, the class hierarchy is constructed with consecutive
tc add class dev $dev parent parentID classid $ID hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]
The particular attributes of each class are configured via the service
curves which are described as follows:
SC := [ umax bytes dmax ms ] rate BPS
Classes at the lowest level of the hierarchy can be assigned a real-time
rt) as well as a link-sharing curve (
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
ls curves, a single
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 with
dmax the maximum delay at a
certain transmission rate
# Example from Figure 1. tc qdisc add dev eth0 root handle 1: hfsc tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit tc class add dev eth0 parent 1:1 classid 1:10 hfsc sc rate 500kbit ul rate 1000kbit tc class add dev eth0 parent 1:1 classid 1:20 hfsc sc rate 500kbit ul rate 1000kbit tc class add dev eth0 parent 1:10 classid 1:11 hfsc sc umax 1500b dmax 53ms rate 400kbit ul rate 1000kbit tc class add dev eth0 parent 1:10 classid 1:12 hfsc sc umax 1500b dmax 30ms rate 100kbit ul rate 1000kbit
The original German article, currently available at http://klaus.geekserver.net/hfsc/hfsc.html, was initially published by 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).