Wird ein Nezuzugang von mehreren Parteien und verschiedenen Diensten genutzt, so ist ein sinnvolles Management der Ressourcen notwendig. Die Zusicherung von Mindestbandbreiten (link-sharing) für die einzelnen Dienste und Nutzer ist eine Möglichkeit. Bei Szenarien mit Voice-Over-IP oder Streaming-Diensten steht neben der reinen Bandbreitenvergabe zudem noch die Vermeidung von Verzögerungszeiten im Vordergrund.

In einem Szenario, in dem sich zwei Nutzer eine Internetleitung mit 1000kbit Sendeleistung teilen, sollen beide Nutzer zu jedem Zeitpunkt mindestens jeweils über 500kbit Sendeleistung verfügen. Einer der Nutzer verwenden zudem maximal 100kbit seiner Bandbreite für Internet-Telefonie, die restliche Sendeleistung für allgemeine Datentransportdienste verwendet. Abbildung 1 zeigt die entsprechende Hierarchie.

Angenommen, alle zu sendenden Pakete entsprechen einer festen Größe von 1500 Byte und alle Klassen senden mit maximaler Kapazität, dann dauert es aufgrund der Leitungskapazität von 1000 kbit 12 ms (8 * 1500 byte / 1000000 bit/s = 12ms), um ein Datenpaket zu versenden. Die Voice-Over-IP Anwendung sendet mit 100 kbit, was etwa 8 Paketen pro Sekunde entspricht. Um die garantierte Rate von 100 kbit für diese Klasse einzuhalten, muss die Qdisc spätestens alle 120 ms ein Datenpaket der Klasse versenden, was eine maximale Verzögerung von etwa 132 ms pro Paket bedeuten würde. Dieses Beispiel illustriert den engen Zusammenhang von Bandbreite und Verzögerungszeit.

Der HFSC-Algorithmus ist in der Lage die beiden Ressourcen, Bandbreite und Verzögerungszeit, getrennt zu behandeln. Hierfür nutzt der Algorithmus für die Vergabe der Ressourcen das Modell der Service-Kurve. Eine Service-Kurve S(t) repräsentiert die geleistete Arbeit (Service) in gesendeten Bits zu einem Zeitpunkt t. Die Steigung der Kurve entspricht der (Sende)-Rate.

Die Idee zur Beeinflussung der Latenzzeiten liegt in der Gestaltung der Service-Kurven der einzelnen Klassen. Erstellt man für die Voice-Over-IP Klasse eine zweiteilige, stückweise lineare Service-Kurve, deren erster Abschnitt eine Steigung von 400 kbit aufweist und 30 ms lange ist, und deren zweiter Abschnitt eine Steigung von 100 kbit aufweist, lässt sich die Sendeverzögerung auf 30 ms reduzieren. Dieser Gewinn von etwa 78 ms Verzögerungszeit geht jedoch zu Lasten der anderen Klassen, da zu jedem Zeitpunkt die Summe aller Kurven, die Service-Kurve der Leitung, also deren Gesamtkapazität, nicht überschreiten darf. In unserem Beispiel soll die verkürzte Verzögerungszeit für die Voice-Over-IP Klasse auf Kosten der Klasse für unspezifizierte Daten der Partei A gehen, deren Service-Kurve angepasst werden muss, um das globale Limit nicht zu überschreiten. Dadurch erhöht sich die maximale Sendeverzögerung dieser Klasse von 30 ms auf insgesamt 52,5 ms. Für reinen Datentransport, wie zum Beispiel FTP, spielt die Verzögerungszeit, im Gegensatz zu dem Datendurchsatz, der durch die Anpassung der Service-Kurve nicht beeinträchtigt wird, lediglich eine untergeordnete Rolle.

Der HFSC-Algorithmus unterscheidet zwischen einem "Real-Time"-Kriterium und "Link-Sharing"-Kriterium. Einer Leaf-Klasse kann eine Real-Time und eine Link-Sharing Service-Kurve zugeordnet werden, inneren Klassen hingegen nur eine Link-Sharing Service-Kurve. Das Real-Time-Kriterium wird nur bei Leaf-Klassen angewandt, da nur diese Klassen tatsächlich Pakete enthalten können. Es ist Echtzeit orientiert und ist für die Einhaltung des garantierten Service verantwortlich. Das Link-Sharing Kriterium orientiert sich nur an den Verhältnissen zwischen benachbarten Klassen. Es ist nur für die faire Verteilung des Service, nicht aber für absolute Garantien zuständig. Die Trennung in zwei Kriterien ist notwendig, um die garantierten Verzögerungszeiten unter allen Umständen einhalten zu können. Das bedeutet auch, dass eine Klasse ein Paket aufgrund seiner Real-Time Garantie senden kann, wenn dadurch kurzfristig das Link-Sharing-Kriterium von Klassen weiter oben in der Hierarchie verletzt wird.

Ist beispielsweise die Datenklasse von Partei A bereits aktiv, so sendet diese mit maximal 400 kbit Pakete. Wird jetzt zu einem beliebigen Zeitpunkt die Voice-Over-Ip Klasse von A aktiv, so darf diese aufgrund ihrer Real-Time-Garantie kurzfristig mit einer höheren Rate senden (Abbildung 3). Dadurch summiert sich der Service für die Klasse A auf über 500 kbit, wodurch kurzfristig das Link-Sharing-Kriterium dieser Klasse verletzt wurde. Um langfristig jedoch auch die Link-Sharing Garantien einhalten zu können, wird die Klasse A für diese kurzfristige Überschreitung "bestraft".

Jeder Klasse der Hierarchie ist eine "Virtual-Time" zugeordnet, die dem geleisteten Service entspricht. Sobald ein Paket gesendet werden kann, wird auf jeder Ebene der Hierarchie, beginnend an der Wurzel, diejenige Klasse gesucht, die die geringste virtuelle Zeit aufweist. Die auf diesem Weg gefundene Leaf-Klasse sendet ein Paket und die virtuelle Zeit der Klasse wird, ebenso wie die aller parent-Klassen bis zur Wurzel, entsprechend erhöht. Sendet eine Klasse aufgrund ihres Real-Time Kriteriums, so wird ihre virtuelle Zeit ebenfalls erhöht. Falls dadurch parent-Klassen das Link-Sharing Kriterium verletzen (d.h. senden, obwohl Geschwister-Klassen mit geringerer Virtual-Time existieren), gleicht das Link-Sharing-Kriterium dies bei nächster Gelegenheit aus, indem es die Klasse nicht mehr auswählt, bis die anderen Klassen diesen Vorteil wieder aufgeholt haben.

Die Einrichtung einer HFSC Qdisc erfolgt zunächst durch die Zuordnung einer Qdisc zu einer Netzwerkschnittstelle mit optionaler Angabe der Default-Klasse:

tc qdisc add dev $dev root handle $ID: hfsc [default $classID ]

In einem zweiten Schritt wird die Klassenhierarchie durch sukzessives Einfügen von Klassen erstellt: tc add class dev $dev parent parentID classid $ID hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]

Die speziellen Eigenschaften einer Klasse werden durch ihre Service-Kurven (SC) festgelegt, die sich als SC := [ umax bytes dmax ms ] rate BPS

beschreiben lässt. Klassen auf den untersten Hierarchie-Ebenen können sowohl eine Real-Time Kurve (rt) als auch eine Link-Sharing Kurve (ls) zugeordnet werden, inneren Klassen nur Link-Sharing Kurven. Mittels der ul Service-Kurve lässt sich eine obere Leistungsschranke für jede Klasse definieren. Alternativ kann statt zwei identischen rt- und ls-Kurven auch nur eine sc-Kurve angegeben werden. Eine Service-Kurve wird durch die (Sende)-Rate (rate) beschrieben, die der ihrer Steigung entspricht. Soll die Kurve aus zwei Teilstücken bestehen, kann durch dmax die maximale Verzögerungszeit für eine bestimmte Sendeleistung umax angegeben werden.

# Beispiel aus Abbildung 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