From: Pavel Mores <pvl@uh.cz>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] "weight" parameter in htb?
Date: Tue, 02 Apr 2002 12:05:34 +0000 [thread overview]
Message-ID: <marc-lartc-101774919817578@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101750276922029@msgid-missing>
On Tue, Apr 02, 2002 at 11:42:28AM +0200, Martin Devera wrote:
> > > > > Am I right? Is there another way to influence distribution of excess
> > > > > bandwidth among siblings? E.g. is it possible to say that class A will
> > > > > acquire excess bw say 4 times faster than class B, even though class
> > > > > A's rate is just half of class B's rate?
> > > >
> > > > Nop, that's not possble.
> > >
> > > Thanks for your answer. I suppose there are no plans to implement such a
> > > functionality at this time?
> > Devik?
>
> no there are not. While it is rather simple I can't find
> meaningfull application of it. Why would someone need it ?
Well, suits might need it. It might be a selling point.
I don't feel that rate of a class and its access to excess bandwidth are
fundamentally tied in any way. I think that these parameters are
independent, just as a class' rate and ceil are independent of each
other. It makes sense to sell a service with ceil=4*rate or
ceil\x100*rate (although that might be a little weird ;-) and it makes
sense to sell ceil=1.00*rate. The same holds for rate and participation on
excess bandwidth.
E.g. you might have a customer agency which needs say 256 kbps for its
headquarters and 64 kbps for its factory. They pay for 512 kbps which
means that they buy 512-256-64\x192 kbps of "excess" bw available to both
sites on demand. Well, it makes sense to me that they would be worried
about the "headquarters" class draining the other class in case both
classes have demand. They might want to say "We buy lower rate for our
factory because Internet access is rarely needed there. But *when* it
*is* needed we want to let the factory take at least 1/2 of the "excess"
bw we buy even if headquarters demand excess bw too. We already buy 256
kbps for headquarters so it makes little sense to feed them even more
bandwidth and deny service to the factory class in the process.".
There might be a way to do this with what we already have. But how?
Clearly, headquarters' HTB "rate" parameter would have to be 256 kbps,
the other class would have rate of 64 kbps. What next? You don't want to
set headquarters' ceil to 256+192/2 and factory's ceil to 64+192/2
because that would mean that even if one of the classes doesn't demand
bw the other is not able to use full 512 kbps and 192/2 kbps is wasted.
If you assign a better priority to the factory they you enable it to
consume whole 192 kbps of excess bw thus possibly draining headquarters
(I mean, limiting hq to its rate) which might not be what you want
either.
There are numerous other scenarios that would benefit from an
independent control of distribution of excess bw between siblings. You
could sell an aggregated service where you throw a couple of folks
together with some excess bw into the same class and even though each of
them buys different rate you might want to guarrantee equal access to
the excess bw. You might want to make the distribution of excess bw
dependent on time ("if there's a congestion, you guys will get *most*
(sic - not *whole*) of the bw during the business hours and those other
guys will win in the evening and night") etc. etc.
Is there a way to achieve these things now?
pvl
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2002-04-02 12:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1980-01-03 23:36 [LARTC] "weight" parameter in htb? Stef Coene
2002-03-29 14:21 ` Pavel Mores
2002-04-02 9:24 ` Pavel Mores
2002-04-02 9:32 ` Stef Coene
2002-04-02 9:42 ` Martin Devera
2002-04-02 12:05 ` Pavel Mores [this message]
2002-04-02 13:34 ` Martin Devera
2002-04-02 14:02 ` Pavel Mores
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-101774919817578@msgid-missing \
--to=pvl@uh.cz \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.