HFSC Scheduling with Linux

来源：互联网发布：php 转发http请求编辑：程序博客网时间：2024/05/16 08:09

For complex traffic shaping scenarios, hierarchical algorithms arenecessary. Current versions of Linux support the algorithms HTB and HFSC.While HTB basically rearranges token bucket filter (TBF) into a hierarchicalstructure, thereby retaining the principal characteristics of TBF, HFSCallows proportional distribution of bandwidth as well as control andallocation of latencies. This allows for better and more efficient use of aconnection for situations in which both bandwidth intensive data services andinteractive 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 assuranceof minimum bandwidth for the individual services and users (link-sharing) isone possible solution. For scenarios involving Voice over IP or streamingservices, both pure bandwidth allocation and also prevention of high delaytimes become important.

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.

Assume that all packets to be sent conform to a fixed size of 1500 bytesand all classes are sending at maximum rate. Based on the 1000kbit link capacity, it takes 12ms (8*1500 byte / 1000000 bit/s = 12ms) to senda packet. The Voice over IP application sends at 100kbit which corresponds to8 packets per second. In order to meet the guaranteed 100kbit rate for thisclass, the qdisc must send a packet from this class every 120ms, which wouldmean a maximum [queuing] delay of 132ms per packet. This example illustratesthe 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 modelfor the allocation of resources. A service curveS(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.

The HFSC algorithm differentiates between real-time and link-sharingcriteria. A leaf class can be assigned a real-time and a link-sharingcurve, where inner classes can only have a link-sharing curve. Thereal-time criterion can only be applied to leaf classes because onlythese classes actually hold packets. This real-time oriented criterion istherefore responsible for carrying out the guaranteed service. Thelink-sharing criterion only concerns itself withrelationships to neighboring classes. It is responsible for fairdistribution of service rather than absolute guarantees. This separationinto two criteria is necessary in order to be able to meet the guaranteeddelay times under all circumstances. This also means that a class can senda packet on the basis of its real-time guarantee even if the link-sharingcurve 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 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.

Each of the classes in the hierarchy is assigned a "virtual time", whichcorresponds to service actually attained. As soon as it is possible to senda packet, each level of the hierarchy is searched, starting at the root, forthe class exhibiting the least attained virtual time. The leaf class foundwith 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 beincreased 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 anetwork interface, along with optional specification of a default class:

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 ] [ lsSC ] | [ sc SC ] ] [ ul SC ]

The particular attributes of each class are configured via the servicecurves which are described as follows:SC := [ umaxbytes 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 andls 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 withdmax the maximum delay at acertain transmission rate umax.

Example

# 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

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 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).

0 0