Most recent edit on 2008-01-26 19:33:34 by ErmalLuci [Continue completing the hfsc notes]

Additions:
* if you DO not specify "linkshare", you should specify bandwidth.
* HFSC isn't documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. The curve is used as a "weight" for bandwidth
distribute available bandwidth equally among those waiting it.
* 'realtime' is the maximum guarantee; its m1 parameter will always be satisfied in the
timeframe specified by d and m2 is the maximum that this discipline will allow to be used,
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth = 'realtime'
than 'linkshare', if it qualifies for it, in the bounds specified by 'upperlimit'.
* 'upperlimit' m1 parameter can even be used as limiting the bursting option.
It means that in the timeframe(d) you will not get more than packet size(m1) service.

Deletions:
* if you will not specify "linkshare", you should specify bandwidth
* Setting the bandwidth on each queue to 25% should do that. HFSC isn't
documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. That curve is used as a "weight" for bandwidth
distribute available bandwidth equally among those wanting it.
'realtime' is the maximum guarantee; it will always be satisfied, if you specify parameter m1 greater than m2.
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (linkshare) <= upperlimit". Or should, anyway :)
* 'upperlimit' m1 parameter can even be used as bursting option or minimum delay guarantee.

---

Edited on 2008-01-24 23:59:11 by ErmalLuci [Correct the first part of these notes. The other part needs to be checked.]

Additions:
* in hfsc, "realtime" is the scheduler used to guarantee upper bound delay
for a class it is valid only for child queues. "Linkshare" shares the bandwidth
between classes if available, and a hard limit for a "linkshare" specification
can be set by "upperlimit".
* if you will not specify "linkshare", you should specify bandwidth
documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. That curve is used as a "weight" for bandwidth
'realtime' is the maximum guarantee; it will always be satisfied, if you specify parameter m1 greater than m2.
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (linkshare) <= upperlimit". Or should, anyway :)
* 'upperlimit' m1 parameter can even be used as bursting option or minimum delay guarantee.

Deletions:
* in hfsc, "realtime" is the primary bandwidth allocator
for the class, plus some bandwidth borrowed by "linkshare" from
parent if available, and hard limited by "upperlimit".
* if link_share is not specified, use bandwidth
documented real well, but the bandwidth option is used to set the
linkshare curve. That curve is used as a "weight" for bandwidth
'realtime' is the minimum guarantee; it will always be satisfied.
'linkshare' is for sharing the remaining bandwidth, after all
'realtime' guarantees have been taken care of. pf also has
'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (excess weighted by linkshare) <= upperlimit". Or should,
anyway :)

---

Oldest known version of this page was edited on 2007-08-18 23:55:30 by ChrisBuechler []

HFSC Bandwidth Shaping notes

We will use this page to assemble Documentation information

* in hfsc, "realtime" is the primary bandwidth allocator
for the class, plus some bandwidth borrowed by "linkshare" from
parent if available, and hard limited by "upperlimit".

* if link_share is not specified, use bandwidth

* Setting the bandwidth on each queue to 25% should do that. HFSC isn't
documented real well, but the bandwidth option is used to set the
linkshare curve. That curve is used as a "weight" for bandwidth
distribution, not as a hard limit. So a 25% linkshare for each should
distribute available bandwidth equally among those wanting it.

* The hfsc(upperlimit) option would do hard bandwidth limiting.

'realtime' is the minimum guarantee; it will always be satisfied.
'linkshare' is for sharing the remaining bandwidth, after all
'realtime' guarantees have been taken care of. pf also has
'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (excess weighted by linkshare) <= upperlimit". Or should,
anyway :)

Example researched by Leon (leoandru (at) gmail (dot) com):

Say that the hierarchy is your setup used for you office, with bandwidth assigned to departments A,B,C accordingly. using CBQ you assign the priorities of 7, 4, 1 to A,B and C respectively. Bill in department A decided to stream tom & jerry cartoon :) during work hours and GeekGod in department B is pulling the latest version of pfSense over http. and I'm trying to talk to customers on the phone and ssh to client's machine over the net in department C. Because both department has a higher priority than my department C, their traffic will get preference over mine in most cases (not fair), this may delay the packets in my voice and ssh session long enough to make them fall below acceptable levels, my voice call gets choppy and ssh unresponsive (high latency). Because the priority is static there is nothing to be done about it.

Lets say you use HFSC instead, replace the priorities with some realtime values. (realtime is only done on leaf queues) to my voice of 500Kb/s and same to ssh. hfsc calculates a minimum deadline on every single packet in my session, when Bill and Scott starts to endanger the deadline on my packets the priority on my session starts to increase the longer they stay in the queue or as time gets closer to the each packet's deadline. If and when that deadline is reached hfsc realize that my service curve (guaranteed bandwidth) is going to be broken and switches to realtime scheduling and sends my packet out over both Bill's and Scott's packets. Dynamic priority as the algorithm puts it. CBQ can guarantee the session bandwidth but cannot guarantee the delay (think of a satellite link).
An easy way of thinking about this is an algorithm that queues up 500 1Kb packets and send them all within 1 second, the bandwidth is met but there is a delay of 1 second between each transmission. In this case the HFSC algorithm will make sure to send each of the 500 packet with an average delayed 1/500s on each packet, guaranteeing the delay and the bandwidth allocation at the same time. This is something very important as my ssh session will not use its 500Kbps of the bandwidth if it sends one packet per second, the delay on that one packet is what really matters here. While CBQ priority can do the same its weakness lies where the queueing hierarchy becomes nested, like the hierarchy above.