In one scenario two users share a single Internet connection with a1000 kbit capacity; each user should have control of at least500 kbit of that capacity at any given moment. One of the users(party A) usesa maximum of 100 kbit of his bandwidth for Internet telephony and the remainder ofthe transmission capacity for general data transport. Figure 1 shows thecorresponding hierarchy.
Figure 1: Hierarchy of shared network access.
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 modelfor the allocation of resources. A service curve S(t)
represents the work achieved (service) in bits at time t
. Theslope of the curve corresponds to the rate of transmission.
The concept of the interaction with latency resides in the structure of theservice curves of the individual classes. By selecting a two-part servicecurve, each section of which is linear, the transmission delay for the Voiceover IP class can be reduced to 30 ms. The first section of the servicecurve features a 400 kbit slope of 30 ms duration, where the second sectionexhibits a slope of 100kbit. This gain in decreased delay of approximately78 ms is earned at the expense of other classes. At no point, though, isthe sum of the curves allowed to exceed the service curve of the total linkcapacity. In our example, the decreased delay for the Voice over IP classoccurs at the cost of party A's unspecified data class, whose servicecurve must be adjusted in order not to to exceedthe global limit.As a result, the maximum transmission delay of this class increases from30ms to a total of 52.5 ms. For bulk data transport, such as FTP, forexample, delay simply plays a secondary role in contrast to that ofthroughput, which isn't impaired by conforming to the service curve.
Figure 2: Scenario with linear and multi-part linear service curves.
Let's say our example data class from party A is already active and sendingat its maximum packet rate, 400 kbit. Now, if at any point in time, theVoice over IP class becomes active, it is allowed to send with a higher rateon account of its real-time guarantee (Figure 3). Thus, the service forclass A, totals to above 500 kbit, meaning that the link-sharing parameterfor this class has been violated in the short term. In order to be able tocarry 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.
tc qdisc add dev $dev root handle $ID: hfsc [default $classID ]
In the second step, the class hierarchy is constructed with consecutiveclass additions.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 servicecurves 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-timecurve (rt
) as well as a link-sharing curve (ls
),where inner classes can only have a link-sharing curve. By using theul
service curve, an upper limit on service actually renderedto each class can be defined. Instead of specifying two identicalrt
and ls
curves, a single sc
curvecan be specified. A service curve is described by its transmission rate,which correlates with the slope of the curve. If the curve consists of twoparts, it can be specified with dmax
the maximum delay at acertain transmission rate umax
.
# Example from Figure 1.tc qdisc add dev eth0 root handle 1: hfsctc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbittc class add dev eth0 parent 1:1 classid 1:10 hfsc sc rate 500kbit ul rate 1000kbittc class add dev eth0 parent 1:1 classid 1:20 hfsc sc rate 500kbit ul rate 1000kbittc class add dev eth0 parent 1:10 classid 1:11 hfsc sc umax 1500b dmax 53ms rate 400kbit ul rate 1000kbittc 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).