[LARTC] What happens when guaranteed BW cannot be delivered (HTB and CBQ)

[LARTC] What happens when guaranteed BW cannot be delivered (HTB and CBQ)

[Mathieu Deziel]

Hi all,

Suppose you have the following hypothetical scenario.
Your traffic enters the root queue (HTB or CBQ).  Then, traffic is
subdivided into level 2 classes.  Some of the level 2 classes are
subdivided further into level 3 classes.
This is all done according to some filters (this is not the point here,
though).

                    [L1 Root]
                       |            |
                     L2        L2
                                  /   \
                                L3   L3

Of course, all the leaf classes are configured to a given "base" or
"guaranteed" rate.
The sum of these guaranteed rate does not exceed the total available
bandwidth".
The sum of the base rates of the children of a class does not exceed the
base rate of the parent.
Also, if other queues are not using their base BW, their available BW
can be borrowed by other, up to "the total available bandwidth"
Specifically, if we are using HTB, the ceil of each class would be set
to the "the total available bandwidth"

Now, on some medium, it is hard to evaluate in advance the available
bandwidth on the link.
For example, on Ethernet, when there is a lot of traffic, the available
BW for a node can become low.

Lets say that this is what happens:
1. The sum of the base rate of all leafs classes is 1Mbps.
2. Ethernet 10Mbits/sec NIC card is used.
3. At a given point in time, there is a lot of traffic in the network,
and our node has only 0.7Mbits/sec available for transmission.  The
situation remains like this for a while.
4. During the same period, all flows are using completely their base
rate (i.e. traffic is flowing in all classes at their base rate, so
globally there is 1Mbps flowing in the queuing mechanism).

Definitely, some classes will not get their base rate.
And now, finally, here are my questions.

For both CBQ and HTB, which classes will start to starve first?  Is this
done according to their priority, according to their base rate, or is it
totally random?
Have HTB and CBQ been designed to handle this kind of situation?

I am looking for answers in term of general behavior of HTB and CBQ.

Thank you all,
Mathieu.


--
Mathieu Deziel
Computer Network Researcher

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

Re: [LARTC] What happens when guaranteed BW cannot be delivered (HTB and CBQ)

[Stef Coene]

On Friday 08 November 2002 20:33, Mathieu Deziel wrote:
> Hi all,
>
> Suppose you have the following hypothetical scenario.
> Your traffic enters the root queue (HTB or CBQ).  Then, traffic is
> subdivided into level 2 classes.  Some of the level 2 classes are
> subdivided further into level 3 classes.
> This is all done according to some filters (this is not the point here,
> though).
>
>                     [L1 Root]
>
>                      L2        L2
>                                   /   \
>                                 L3   L3
>
> Of course, all the leaf classes are configured to a given "base" or
> "guaranteed" rate.
> The sum of these guaranteed rate does not exceed the total available
> bandwidth".
> The sum of the base rates of the children of a class does not exceed the
> base rate of the parent.
> Also, if other queues are not using their base BW, their available BW
> can be borrowed by other, up to "the total available bandwidth"
> Specifically, if we are using HTB, the ceil of each class would be set
> to the "the total available bandwidth"
>
> Now, on some medium, it is hard to evaluate in advance the available
> bandwidth on the link.
> For example, on Ethernet, when there is a lot of traffic, the available
> BW for a node can become low.
>
> Lets say that this is what happens:
> 1. The sum of the base rate of all leafs classes is 1Mbps.
> 2. Ethernet 10Mbits/sec NIC card is used.
> 3. At a given point in time, there is a lot of traffic in the network,
> and our node has only 0.7Mbits/sec available for transmission.  The
> situation remains like this for a while.
> 4. During the same period, all flows are using completely their base
> rate (i.e. traffic is flowing in all classes at their base rate, so
> globally there is 1Mbps flowing in the queuing mechanism).
>
> Definitely, some classes will not get their base rate.
> And now, finally, here are my questions.
:)

> For both CBQ and HTB, which classes will start to starve first?  Is this
> done according to their priority, according to their base rate, or is it
> totally random?
> Have HTB and CBQ been designed to handle this kind of situation?
>
> I am looking for answers in term of general behavior of HTB and CBQ.
Htb will handle this nicely.  All traffic will distributed according to the 
rates.  I'm doing some tests about it, but someone gave me 30 vcd's with 
StarTrek movies on it, so some of my tests are delayed :)
I did some tests about it but I have no results available.  But the settings 
like rate and burst are satisified even if there is less bandwidth available 
then configured.
I think cbq does the same but I'm not sure.


Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

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

Re: [LARTC] What happens when guaranteed BW cannot be delivered (HTB and

[Mathieu Deziel]

> But the settings
> like rate and burst are satisified even if there is less bandwidth available
> then configured.

How can the rate be satisfied, when it is not physically available?

Mathieu.

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

Re: [LARTC] What happens when guaranteed BW cannot be delivered (HTB

[Mathieu Deziel]

> i think that both cbq and htb will won't do good, beacouse (as i see it)
> the estimator is based on the bandwidth known by the kernel so that is at
> cbq by the tc ... bandwidth xxx parameter, and at htb ???? mmm no param,
> probably from rate/ceil or ????
> and the logic is that the kernel sends the packet and after at the
> interface driver is droped/delayed. So only if the kernel cbq/htb "look"
> at the errors on the medium maybe they estimate well.
>

I am planning to test this specific scenario in a week or two.  I will let you know
my conclusions.

Mathieu.

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