---

   tc-hfsc    ( 7 )

---

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
       doesn't happen):

       A - ls 5.0Mbit
       B - ls 2.5Mbit
       C - ls 2.5Mbit, ul 2.5Mbit

       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.