[LARTC] Re: HFSC

[Patrick McHardy <kaber@trash.net>]

Nuutti Kotivuori wrote:
> Patrick McHardy wrote:
> 
>>This is currently all there is. If you have some specific questions,
>>just ask (but please CC lartc). If anyone wants to write some
>>documentation I'd be happy to help, but I don't have time for it
>>myself.
> 
> 
> I am not sure if the original poster has specific questions, but I
> sure do.
> 
> I just recently got into this HFSC mess myself, so I'm a bit fuzzy in
> all the terms and differences in implementation. I read the paper
> (SIGCOM97) on HFSC and I think I understood most of it. But there are
> some things in the implementation that I couldn't really realize.
> 
> I'll quote the usage here for reference:
> 
> ,----
> | Usage: ... hfsc [ rt SC ] [ ls SC ] [ ul SC ]
> |  
> | SC := [ [ m1 BPS ] [ d SEC ] m2 BPS
> |  
> |  m1 : slope of first segment
> |  d  : x-coordinate of intersection
> |  m2 : slope of second segment
> `----
> 
> Okay, the SC parameters I think I understand rather well - they are
> there to define the service curve itself. But the way hfsc takes three
> optional parameters of service curves puzzles me.
> 
> I believe 'rt' referes to 'Real-Time Service Curve', 'ls' to 'Link
> Sharing Service Curve' and 'ul' to 'Upper Limit Service Curve'. If I
> understand correctly, the SIGCOM97 paper mentioned that the link
> sharing selection need not be the same as the real time selection, but
> in examples assumed for simplicity that they were. Also, from the
> source I conclude that 'Upper Limit Service Curve' cannot be specified
> without 'Link Sharing Service Curve'.

Correct so far.

> So, this, all in all, baffles me :-)
> 
> The possible combinations I can make here are:
> 
>   Real-Time
>   Link-Sharing
>   Real-Time, Link-Sharing
>   Link-Sharing, Upper-Limit
>   Real-Time, Link-Sharing, Upper-Limit
> 
> How do these behave? If I specify *only* the real-time curve, what is
> used for the link-sharing part? Or does that mean that there is no
> sharing? Or if I only specify the link-sharing curve, does that mean
> that no specific deadlines are for packets, just that they are sent
> based on the link-sharing model? And what actually is the upper-limit
> service curve? I take it that it is some kind of a packet drop curve,
> but I don't know how it would behave - nor why it would require the
> link-sharing curve.

The combinations you list are correct. Real-time curves are only valid
for leaf-classes, whereas link-sharing and upper-limit curves are valid
for all classes in the heirarchy. When multiple curves are used, the
following must hold: rt <= ls <= ul

To understand why there are two (forgetting about upper-limit curves
for now) different curves your need to know that scheduling in HFSC is
based on two criteria: the real-time criterion which ensures that the
guarantees of leaf-classes are met and the link-sharing criterion which
tries to satisfy the service curves of intermediate classes and
distributes excess bandwidth fairly. The reason why there are two
different criteria is that in the Fair Service Link-sharing model that
is approximated by HFSC it is not always possible to guarantee the
service of all classes simultaneously at all times (with non-linear
service curves). HFSC chooses to guarantee the service curves of
(real-time) leaf-classes (because only leaves carry packets), and
uses the link-sharing criterion to minimize the discrepancy between
the actual service received and the service defined by the Fair Service
Link-sharing Model.

The upper-limit curve is used to limit the link-sharing curve. Without
an upper-limit curve, packets are dequeued at the speed the underlying
device is capable of. For example in the case of software devices,
this is not very desireable, so you can limit the total output rate.


For your other questions:
- If you specify only a real-time service curve the class will not
   participate in link-sharing. This means it can only send at it's
   configured rate. The difference two a link-share+upper-limit curve
   is that the service is guaranteed.

- If you specify only a link-share curve their are no deadlines and
   no guarantees can be given.


Some other notes you might find helpful:
- The sum of all real-time curves must not exceed 100%.

- The actual bandwidth assigned to link-sharing classes doesn't matter,
   only the relative difference between sibling-classes is important

> 
> So, any pointers on these would be helpful, or if you manage to get
> the time to explain it specifically.
> 
> I will probably cook up atleast an example script using HFSC for
> normal QoS if I manage to understand how it works, perhaps even some
> documentation.

Great! I started some documentation last year, but never got to
finishing it. I can send it to you in private, but I don't want
to publish it as long as it's unfinished.

Regards
Patrick

> 
> -- Naked
> 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/