---

   tc-hfsc    ( 7 )

---

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:

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

           2)  allocate excess bandwidth fairly as specified by class
               hierarchy (linkshare & upperlimit criterion)

           3)  minimize any discrepancy between the service curve and
               the actual amount of service provided during linksharing

       The main "selling" point of HFSC is feature (1), 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 (2) 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 (3) 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 (1). 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.