.TH "TC\-HFSC" 7 "31 October 2011" iproute2 Linux

.SH "NAME"

tc-hfcs \- Hierarchical Fair Service Curve

.

.SH "HISTORY & INTRODUCTION"

.

HFSC (Hierarchical Fair Service Curve) is a network packet scheduling algorithm that was first presented at

SIGCOMM'97. Developed as a part of ALTQ (ALTernative Queuing) on NetBSD, found

its way quickly to other BSD systems, and then a few years ago became part of

the linux kernel. Still, it's not the most popular scheduling algorithm \-

especially if compared to HTB \- and it's not well documented for the enduser. This introduction aims to explain how HFSC works without using

too much math (although some math it will be

inevitable).

In short HFSC aims to:

.

.RS 4

.IP \fB1)\fR 4

guarantee precise bandwidth and delay allocation for all leaf classes (realtime

criterion)

.IP \fB2)\fR

allocate excess bandwidth fairly as specified by class hierarchy (linkshare &

upperlimit criterion)

.IP \fB3)\fR

minimize any discrepancy between the service curve and the actual amount of

service provided during linksharing

.RE

.PP

.

The main "selling" point of HFSC is feature \fB(1)\fR, which is achieved by

using nonlinear service curves (more about what it actually is later). This is

particularly useful in VoIP or games, where not only a guarantee of consistent

bandwidth is important, but also limiting the initial delay of a data stream. Note that

it matters only for leaf classes (where the actual queues are) \- thus class

hierarchy is ignored in the realtime case.

Feature \fB(2)\fR is well, obvious \- any algorithm featuring class hierarchy

(such as HTB or CBQ) strives to achieve that. HFSC does that well, although

you might end with unusual situations, if you define service curves carelessly

\- see section CORNER CASES for examples.

Feature \fB(3)\fR is mentioned due to the nature of the problem. There may be

situations where it's either not possible to guarantee service of all curves at

the same time, and/or it's impossible to do so fairly. Both will be explained

later. Note that this is mainly related to interior (aka aggregate) classes, as

the leafs are already handled by \fB(1)\fR. Still, it's perfectly possible to

create a leaf class without realtime service, and in such a case the caveats will

naturally extend to leaf classes as well.

.SH ABBREVIATIONS

For the remaining part of the document, we'll use following shortcuts:

.nf

.RS 4

RT \- realtime

LS \- linkshare

UL \- upperlimit

SC \- service curve

.fi

.

.SH "BASICS OF HFSC"

.

To understand how HFSC works, we must first introduce a service curve.

Overall, it's a nondecreasing function of some time unit, returning the amount

of

service (an allowed or allocated amount of bandwidth) at some specific point in

time. The purpose of it should be subconsciously obvious: if a class was

allowed to transfer not less than the amount specified by its service curve,

then the service curve is not violated.

Still, we need more elaborate criterion than just the above (although in

the most generic case it can be reduced to it). The criterion has to take two

things into account:

.

.RS 4

.IP \(bu 4

idling periods

.IP \(bu

the ability to "look back", so if during current active period the service curve is violated, maybe it

isn't if we count excess bandwidth received during earlier active period(s)

.RE

.PP

Let's define the criterion as follows:

.RS 4

.nf

.IP "\fB(1)\fR" 4

For each t1, there must exist t0 in set B, so S(t1\-t0)\~<=\~w(t0,t1)

.fi

.RE

.

.PP

Here 'w' denotes the amount of service received during some time period between t0

and t1. B is a set of all times, where a session becomes active after idling

period (further denoted as 'becoming backlogged'). For a clearer picture,

imagine two situations:

.

.RS 4

.IP \fBa)\fR 4

our session was active during two periods, with a small time gap between them

.IP \fBb)\fR

as in (a), but with a larger gap

.RE

.

.PP

Consider \fB(a)\fR: if the service received during both periods meets

\fB(1)\fR, then all is well. But what if it doesn't do so during the 2nd

period? If the amount of service received during the 1st period is larger

than the service curve, then it might compensate for smaller service during

the 2nd period \fIand\fR the gap \- if the gap is small enough.

If the gap is larger \fB(b)\fR \- then it's less likely to happen (unless the

excess bandwidth allocated during the 1st part was really large). Still, the

larger the gap \- the less interesting is what happened in the past (e.g. 10

minutes ago) \- what matters is the current traffic that just started.

From HFSC's perspective, more interesting is answering the following question:

when should we start transferring packets, so a service curve of a class is not

violated. Or rephrasing it: How much X() amount of service should a session

receive by time t, so the service curve is not violated. Function X() defined

as below is the basic building block of HFSC, used in: eligible, deadline,

virtual\-time and fit\-time curves. Of course, X() is based on equation

\fB(1)\fR and is defined recursively:

.RS 4

.IP \(bu 4

At the 1st backlogged period beginning function X is initialized to generic

service curve assigned to a class

.IP \(bu

At any subsequent backlogged period, X() is:

.nf

\fBmin(X() from previous period ; w(t0)+S(t\-t0) for t>=t0),\fR

.fi

\&... where t0 denotes the beginning of the current backlogged period.

.RE

.

.PP

HFSC uses either linear, or two\-piece linear service curves. In case of

linear or two\-piece linear convex functions (first slope < second slope),

min() in X's definition reduces to the 2nd argument. But in case of two\-piece

concave functions, the 1st argument might quickly become lesser for some

t>=t0. Note, that for some backlogged period, X() is defined only from that

period's beginning. We also define X^(\-1)(w) as smallest t>=t0, for which

X(t)\~=\~w. We have to define it this way, as X() is usually not an injection.

The above generic X() can be one of the following:

.

.RS 4

.IP "E()" 4

In realtime criterion, selects packets eligible for sending. If none are

eligible, HFSC will use linkshare criterion. Eligible time \&'et' is calculated

with reference to packets' heads ( et\~=\~E^(\-1)(w) ). It's based on RT

service curve, \fIbut in case of a convex curve, uses its 2nd slope only.\fR

.IP "D()"

In realtime criterion, selects the most suitable packet from the ones chosen

by E(). Deadline time \&'dt' corresponds to packets' tails

(dt\~=\~D^(\-1)(w+l), where \&'l' is packet's length). Based on RT service

curve.

.IP "V()"

In linkshare criterion, arbitrates which packet to send next. Note that V() is

function of a virtual time \- see \fBLINKSHARE CRITERION\fR section for

details. Virtual time \&'vt' corresponds to packets' heads

(vt\~=\~V^(\-1)(w)). Based on LS service curve.

.IP "F()"

An extension to linkshare criterion, used to limit at which speed linkshare

criterion is allowed to dequeue. Fit\-time 'ft' corresponds to packets' heads

as well (ft\~=\~F^(\-1)(w)). Based on UL service curve.

.RE

Be sure to make clean distinction between session's RT, LS and UL service

curves and the above "utility" functions.

.

.SH "REALTIME CRITERION"

.

RT criterion \fIignores class hierarchy\fR and guarantees precise bandwidth and

delay allocation. We say that a packet is eligible for sending, when the

current real

time is later than the eligible time of the packet. From all eligible packets, the one most

suited for sending is the one with the shortest deadline time. This sounds

simple, but consider the following example:

Interface 10Mbit, two classes, both with two\-piece linear service curves:

.RS 4

.IP \(bu 4

1st class \- 2Mbit for 100ms, then 7Mbit (convex \- 1st slope < 2nd slope)

.IP \(bu

2nd class \- 7Mbit for 100ms, then 2Mbit (concave \- 1st slope > 2nd slope)

.RE

.PP

Assume for a moment, that we only use D() for both finding eligible packets,

and choosing the most fitting one, thus eligible time would be computed as

D^(\-1)(w) and deadline time would be computed as D^(\-1)(w+l). If the 2nd

class starts sending packets 1 second after the 1st class, it's of course

impossible to guarantee 14Mbit, as the interface capability is only 10Mbit.

The only workaround in this scenario is to allow the 1st class to send the

packets earlier that would normally be allowed. That's where separate E() comes

to help. Putting all the math aside (see HFSC paper for details), E() for RT

concave service curve is just like D(), but for the RT convex service curve \-

it's constructed using \fIonly\fR RT service curve's 2nd slope (in our example

 7Mbit).

The effect of such E() \- packets will be sent earlier, and at the same time

D() \fIwill\fR be updated \- so the current deadline time calculated from it

will be later. Thus, when the 2nd class starts sending packets later, both

the 1st and the 2nd class will be eligible, but the 2nd session's deadline

time will be smaller and its packets will be sent first. When the 1st class

becomes idle at some later point, the 2nd class will be able to "buffer" up

again for later active period of the 1st class.

A short remark \- in a situation, where the total amount of bandwidth

available on the interface is larger than the allocated total realtime parts

(imagine a 10 Mbit interface, but 1Mbit/2Mbit and 2Mbit/1Mbit classes), the sole

speed of the interface could suffice to guarantee the times.

Important part of RT criterion is that apart from updating its D() and E(),

also V() used by LS criterion is updated. Generally the RT criterion is

secondary to LS one, and used \fIonly\fR if there's a risk of violating precise

realtime requirements. Still, the "participation" in bandwidth distributed by

LS criterion is there, so V() has to be updated along the way. LS criterion can

than properly compensate for non\-ideal fair sharing situation, caused by RT

scheduling. If you use UL service curve its F() will be updated as well (UL

service curve is an extension to LS one \- see \fBUPPERLIMIT CRITERION\fR

section).

Anyway \- careless specification of LS and RT service curves can lead to

potentially undesired situations (see CORNER CASES for examples). This wasn't

the case in HFSC paper where LS and RT service curves couldn't be specified

separately.

.SH "LINKSHARING CRITERION"

.

LS criterion's task is to distribute bandwidth according to specified class

hierarchy. Contrary to RT criterion, there're no comparisons between current

real time and virtual time \- the decision is based solely on direct comparison

of virtual times of all active subclasses \- the one with the smallest vt wins

and gets scheduled. One immediate conclusion from this fact is that absolute

values don't matter \- only ratios between them (so for example, two children

classes with simple linear 1Mbit service curves will get the same treatment

from LS criterion's perspective, as if they were 5Mbit). The other conclusion

is, that in perfectly fluid system with linear curves, all virtual times across

whole class hierarchy would be equal.

Why is VC defined in term of virtual time (and what is it)?

Imagine an example: class A with two children \- A1 and A2, both with let's say

10Mbit SCs. If A2 is idle, A1 receives all the bandwidth of A (and update its

V() in the process). When A2 becomes active, A1's virtual time is already

\fIfar\fR later than A2's one. Considering the type of decision made by LS

criterion, A1 would become idle for a long time. We can workaround this

situation by adjusting virtual time of the class becoming active \- we do that

by getting such time "up to date". HFSC uses a mean of the smallest and the

biggest virtual time of currently active children fit for sending. As it's not

real time anymore (excluding trivial case of situation where all classes become

active at the same time, and never become idle), it's called virtual time.

Such approach has its price though. The problem is analogous to what was

presented in previous section and is caused by non\-linearity of service

curves:

.IP 1) 4

either it's impossible to guarantee service curves and satisfy fairness

during certain time periods:

.RS 4

Recall the example from RT section, slightly modified (with 3Mbit slopes

instead of 2Mbit ones):

.IP \(bu 4

1st class \- 3Mbit for 100ms, then 7Mbit (convex \- 1st slope < 2nd slope)

.IP \(bu

2nd class \- 7Mbit for 100ms, then 3Mbit (concave \- 1st slope > 2nd slope)

.PP

They sum up nicely to 10Mbit \- the interface's capacity. But if we wanted to only

use LS for guarantees and fairness \- it simply won't work. In LS context,

only V() is used for making decision which class to schedule. If the 2nd class

becomes active when the 1st one is in its second slope, the fairness will be

preserved \- ratio will be 1:1 (7Mbit:7Mbit), but LS itself is of course

unable to guarantee the absolute values themselves \- as it would have to go

beyond of what the interface is capable of.

.RE

.IP 2) 4

and/or it's impossible to guarantee service curves of all classes at the same

time [fairly or not]:

.RS 4

This is similar to the above case, but a bit more subtle. We will consider two

subtrees, arbitrated by their common (root here) parent:

.nf

R (root) -\ 10Mbit

A  \- 7Mbit, then 3Mbit

A1 \- 5Mbit, then 2Mbit

A2 \- 2Mbit, then 1Mbit

B  \- 3Mbit, then 7Mbit

.fi

R arbitrates between left subtree (A) and right (B). Assume that A2 and B are

constantly backlogged, and at some later point A1 becomes backlogged (when all

other classes are in their 2nd linear part).

What happens now? B (choice made by R) will \fIalways\fR get 7 Mbit as R is

only (obviously) concerned with the ratio between its direct children. Thus A

subtree gets 3Mbit, but its children would want (at the point when A1 became

backlogged) 5Mbit + 1Mbit. That's of course impossible, as they can only get

3Mbit due to interface limitation.

In the left subtree \- we have the same situation as previously (fair split

between A1 and A2, but violated guarantees), but in the whole tree \- there's

no fairness (B got 7Mbit, but A1 and A2 have to fit together in 3Mbit) and

there's no guarantees for all classes (only B got what it wanted). Even if we

violated fairness in the A subtree and set A2's service curve to 0, A1 would

still not get the required bandwidth.

.RE

.

.SH "UPPERLIMIT CRITERION"

.

UL criterion is an extensions to LS one, that permits sending packets only

if current real time is later than fit\-time ('ft'). So the modified LS

criterion becomes: choose the smallest virtual time from all active children,

such that fit\-time < current real time also holds. Fit\-time is calculated

from F(), which is based on UL service curve. As you can see, its role is

kinda similar to E() used in RT criterion. Also, for obvious reasons \- you

can't specify UL service curve without LS one.

The main purpose of the UL service curve is to limit HFSC to bandwidth available on the

upstream router (think adsl home modem/router, and linux server as

NAT/firewall/etc. with 100Mbit+ connection to mentioned modem/router).

Typically, it's used to create a single class directly under root, setting

a linear UL service curve to available bandwidth \- and then creating your class

structure from that class downwards. Of course, you're free to add a UL service

curve (linear or not) to any class with LS criterion.

An important part about the UL service curve is that whenever at some point in time

a class doesn't qualify for linksharing due to its fit\-time, the next time it

does qualify it will update its virtual time to the smallest virtual time of

all active children fit for linksharing. This way, one of the main things the LS

criterion tries to achieve \- equality of all virtual times across whole

hierarchy \- is preserved (in perfectly fluid system with only linear curves,

all virtual times would be equal).

Without that, 'vt' would lag behind other virtual times, and could cause

problems. Consider an interface with a capacity of 10Mbit, and the following leaf classes

(just in case you're skipping this text quickly \- this example shows behavior

that \f(BIdoesn't happen\fR):

.nf

A \- ls 5.0Mbit

B \- ls 2.5Mbit

C \- ls 2.5Mbit, ul 2.5Mbit

.fi

If B was idle, while A and C were constantly backlogged, A and C would normally

(as far as LS criterion is concerned) divide bandwidth in 2:1 ratio. But due

to UL service curve in place, C would get at most 2.5Mbit, and A would get the

remaining 7.5Mbit. The longer the backlogged period, the more the virtual times of

A and C would drift apart. If B became backlogged at some later point in time,

its virtual time would be set to (A's\~vt\~+\~C's\~vt)/2, thus blocking A from

sending any traffic until B's virtual time catches up with A.

.

.SH "SEPARATE LS / RT SCs"

.

Another difference from the original HFSC paper is that RT and LS SCs can be

specified separately. Moreover, leaf classes are allowed to have only either

RT SC or LS SC. For interior classes, only LS SCs make sense: any RT SC will

be ignored.

.

.SH "CORNER CASES"

.

Separate service curves for LS and RT criteria can lead to certain traps

that come from "fighting" between ideal linksharing and enforced realtime

guarantees. Those situations didn't exist in original HFSC paper, where

specifying separate LS / RT service curves was not discussed.

Consider an interface with a 10Mbit capacity, with the following leaf classes:

.nf

A \- ls 5.0Mbit, rt 8Mbit

B \- ls 2.5Mbit

C \- ls 2.5Mbit

.fi

Imagine A and C are constantly backlogged. As B is idle, A and C would divide

bandwidth in 2:1 ratio, considering LS service curve (so in theory \- 6.66 and

3.33). Alas RT criterion takes priority, so A will get 8Mbit and LS will be

able to compensate class C for only 2 Mbit \- this will cause discrepancy

between virtual times of A and C.

Assume this situation lasts for a long time with no idle periods, and

suddenly B becomes active. B's virtual time will be updated to

(A's\~vt\~+\~C's\~vt)/2, effectively landing in the middle between A's and C's

virtual time. The effect \- B, having no RT guarantees, will be punished and

will not be allowed to transfer until C's virtual time catches up.

If the interface had a higher capacity, for example 100Mbit, this example

would behave perfectly fine though.

Let's look a bit closer at the above example \- it "cleverly" invalidates one

of the basic things LS criterion tries to achieve \- equality of all virtual

times across class hierarchy. Leaf classes without RT service curves are

literally left to their own fate (governed by messed up virtual times).

Also, it doesn't make much sense. Class A will always be guaranteed up to

8Mbit, and this is more than any absolute bandwidth that could happen from its

LS criterion (excluding trivial case of only A being active). If the bandwidth

taken by A is smaller than absolute value from LS criterion, the unused part

will be automatically assigned to other active classes (as A has idling periods

in such case). The only "advantage" is, that even in case of low bandwidth on

average, bursts would be handled at the speed defined by RT criterion. Still,

if extra speed is needed (e.g. due to latency), non linear service curves

should be used in such case.

In the other words: the LS criterion is meaningless in the above example.

You can quickly "workaround" it by making sure each leaf class has RT service

curve assigned (thus guaranteeing all of them will get some bandwidth), but it

doesn't make it any more valid.

Keep in mind - if you use nonlinear curves and irregularities explained above

happen \fIonly\fR in the first segment, then there's little wrong with

"overusing" RT curve a bit:

.nf

A \- ls 5.0Mbit, rt 9Mbit/30ms, then 1Mbit

B \- ls 2.5Mbit

C \- ls 2.5Mbit

.fi

Here, the vt of A will "spike" in the initial period, but then A will never get more

than 1Mbit until B & C catch up. Then everything will be back to normal.

.

.SH "LINUX AND TIMER RESOLUTION"

.

In certain situations, the scheduler can throttle itself and setup so

called watchdog to wakeup dequeue function at some time later. In case of HFSC

it happens when for example no packet is eligible for scheduling, and UL

service curve is used to limit the speed at which LS criterion is allowed to

dequeue packets. It's called throttling, and accuracy of it is dependent on

how the kernel is compiled.

There're 3 important options in modern kernels, as far as timers' resolution

goes: \&'tickless system', \&'high resolution timer support' and \&'timer

frequency'.

If you have \&'tickless system' enabled, then the timer interrupt will trigger

as slowly as possible, but each time a scheduler throttles itself (or any

other part of the kernel needs better accuracy), the rate will be increased as

needed / possible. The ceiling is either \&'timer frequency' if \&'high

resolution timer support' is not available or not compiled in, or it's

hardware dependent and can go \fIfar\fR beyond the highest \&'timer frequency'

setting available.

If \&'tickless system' is not enabled, the timer will trigger at a fixed rate

specified by \&'timer frequency' \- regardless if high resolution timers are

or aren't available.

This is important to keep those settings in mind, as in scenario like: no

tickless, no HR timers, frequency set to 100hz \- throttling accuracy would be

at 10ms. It doesn't automatically mean you would be limited to ~0.8Mbit/s

(assuming packets at ~1KB) \- as long as your queues are prepared to cover for

timer inaccuracy. Of course, in case of e.g. locally generated UDP traffic \-

appropriate socket size is needed as well. Short example to make it more

understandable (assume hardcore anti\-schedule settings \- HZ=100, no HR

timers, no tickless):

.nf

tc qdisc add dev eth0 root handle 1:0 hfsc default 1

tc class add dev eth0 parent 1:0 classid 1:1 hfsc rt m2 10Mbit

.fi

Assuming packet of ~1KB size and HZ=100, that averages to ~0.8Mbit \- anything

beyond it (e.g. the above example with specified rate over 10x larger) will

require appropriate queuing and cause bursts every ~10 ms. As you can

imagine, any HFSC's RT guarantees will be seriously invalidated by that.

Aforementioned example is mainly important if you deal with old hardware \- as

is particularly popular for home server chores. Even then, you can easily

set HZ=1000 and have very accurate scheduling for typical adsl speeds.

Anything modern (apic or even hpet msi based timers + \&'tickless system')

will provide enough accuracy for superb 1Gbit scheduling. For example, on one

of my cheap dual-core AMD boards I have the following settings:

.nf

tc qdisc add dev eth0 parent root handle 1:0 hfsc default 1

tc class add dev eth0 parent 1:0 classid 1:1 hfsc rt m2 300mbit

.fi

And a simple:

.nf

nc \-u dst.host.com 54321 

nc \-l \-p 54321 >/dev/null

.fi

\&...will yield the following effects over a period of ~10 seconds (taken from

/proc/interrupts):

.nf

319: 42124229   0  HPET_MSI\-edge  hpet2 (before)

319: 42436214   0  HPET_MSI\-edge  hpet2 (after 10s.)

.fi

That's roughly 31000/s. Now compare it with HZ=1000 setting. The obvious

drawback of it is that cpu load can be rather high with servicing that

many timer interrupts. The example with 300Mbit RT service curve on 1Gbit link is

particularly ugly, as it requires a lot of throttling with minuscule delays.

Also note that it's just an example showing the capabilities of current hardware.

The above example (essentially a 300Mbit TBF emulator) is pointless on an internal

interface to begin with: you will pretty much always want a regular LS service

curve there, and in such a scenario HFSC simply doesn't throttle at all.

300Mbit RT service curve (selected columns from mpstat \-P ALL 1):

.nf

10:56:43 PM  CPU  %sys     %irq   %soft   %idle

10:56:44 PM  all  20.10    6.53   34.67   37.19

10:56:44 PM    0  35.00    0.00   63.00    0.00

10:56:44 PM    1   4.95   12.87    6.93   73.27

.fi

So, in the rare case you need those speeds with only a RT service curve, or with a UL

service curve: remember the drawbacks.

.

.SH "CAVEAT: RANDOM ONLINE EXAMPLES"

.

For reasons unknown (though well guessed), many examples you can google love to

overuse UL criterion and stuff it in every node possible. This makes no sense

and works against what HFSC tries to do (and does pretty damn well). Use UL

where it makes sense: on the uppermost node to match upstream router's uplink

capacity. Or in special cases, such as testing (limit certain subtree to some

speed), or customers that must never get more than certain speed. In the last

case you can usually achieve the same by just using a RT criterion without LS+UL

on leaf nodes.

As for the router case - remember it's good to differentiate between "traffic to

router" (remote console, web config, etc.) and "outgoing traffic", so for

example:

.nf

tc qdisc add dev eth0 root handle 1:0 hfsc default 0x8002

tc class add dev eth0 parent 1:0 classid 1:999 hfsc rt m2 50Mbit

tc class add dev eth0 parent 1:0 classid 1:1 hfsc ls m2 2Mbit ul m2 2Mbit

.fi

\&... so "internet" tree under 1:1 and "router itself" as 1:999

.

.SH "LAYER2 ADAPTATION"

.

Please refer to \fBtc\-stab\fR(8)

.

.SH "SEE ALSO"

.

\fBtc\fR(8), \fBtc\-hfsc\fR(8), \fBtc\-stab\fR(8)

Please direct bugreports and patches to: <netdev@vger.kernel.org>

.

.SH "AUTHOR"

.

Manpage created by Michal Soltys (soltys@ziu.info)