[LARTC] Anti-CBQ Statements in Howto

[LARTC] Anti-CBQ Statements in Howto

[Michael T. Babcock]

I find the negative attitude toward CBQ to be distracting and 
non-professional in the HOWTO.  I've re-read it for the first time in 
about a month and comments like "This can be configured in a variety of 
ways, which I do not understand. Use HTB" do not encourage me about the 
writer.

This is not a personal critique, as I can imagine this being said on a 
personal website, but as a generic HOWTO, this is out of place.  A 
statement like "if you don't understand these options, you may find HTB 
to be easier to follow" is professional and possibly more accurate.

I've seen other documents that describe the options the author says he 
doesn't understand whose authors like CBQ and/or believe it to be 
well-designed.  I've had no real problems with it and don't actually 
see HTB as being easier to configure or follow if you leave the 'knobs' 
on CBQ to their suggested defaults.

Just my $0.02 worth (actually $1 in paid time to type this).
-- 
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/

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

Re: [LARTC] Anti-CBQ Statements in Howto

[bert hubert]

On Thu, Dec 06, 2001 at 03:30:47PM -0500, Michael T. Babcock wrote:
> I find the negative attitude toward CBQ to be distracting and 
> non-professional in the HOWTO.  I've re-read it for the first time in 
> about a month and comments like "This can be configured in a variety of 
> ways, which I do not understand. Use HTB" do not encourage me about the 
> writer.

There is exactly one place that says 'use HTB :-)'. But I will remove it.

> This is not a personal critique, as I can imagine this being said on a 
> personal website, but as a generic HOWTO, this is out of place.  A 
> statement like "if you don't understand these options, you may find HTB 
> to be easier to follow" is professional and possibly more accurate.

Well, there are a lot of reasons why CBQ may not fit your needs. I really
want to downplay the 'holy grail' status it has achieved. New text:

	You may wonder what happens to traffic that is not classified by any
	of the two rules. It appears that in this case, data will then be
	processed within 1:0, and be unlimited. The unfiltered behaviour can
	be configured in a variety of ways, which have not yet been
	documented adequately. HTB is clearer in this respect, so you may
	prefer it.

> I've seen other documents that describe the options the author says he 
> doesn't understand whose authors like CBQ and/or believe it to be 
> well-designed.  I've had no real problems with it and don't actually 

Read linux/net/sched/sch_cbq.c for some enlightenment.

> see HTB as being easier to configure or follow if you leave the 'knobs' 
> on CBQ to their suggested defaults.

If you see CBQ working well, you are probably on an empty 10 or 100mbit
segment, talking directly to the switch, or using a plain-old-modem with a
fixed bitrate. In other cases, CBQ is 'saved' because it actually contains
token bucket filters, which ARE pretty accurate.

CBQ relies on being dequeued at a well known rate, which is simply not
always the case. Furthermore, often there is no 'well known rate', for
example when using a PPP-over-Ethernet modem over a userspace socket.

Anyway, 'use HTB :-)' may indeed not be appropriate and has been changed,
thanks.

Regards,

bert hubert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

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

Re: [LARTC] Anti-CBQ Statements in Howto

[Michael T. Babcock]

(Warning: long reply ...)

On Thu, Dec 06, 2001 at 10:01:29PM +0100, bert hubert wrote:
> There is exactly one place that says 'use HTB :-)'. But I will remove it.

I decided to use the exact quote as an example, but I'm glad you
understood what I meant.

> Well, there are a lot of reasons why CBQ may not fit your needs. I really
> want to downplay the 'holy grail' status it has achieved.

I can understand that feeling, but CBQ hasn't necessarily achieved holy grail
status among those people who would first approach the HOWTO having never
done traffic shaping at all before.  Many of those working with Linux traffic
shaping may or may not have come from Cisco, etc. backgrounds, but I for one
simply started with Linux's offerings in 2.2.x and worked from there.

> Read linux/net/sched/sch_cbq.c for some enlightenment.

The first thing I did with the 2.2.x kernels was read most of the source for
most of the sch_*.c files I found interesting along with a couple of 
co-workers to understand what they were doing.  That makes me a techie and
probably not a typical user ... but that's ok, right?

> If you see CBQ working well, you are probably on an empty 10 or 100mbit
> segment, talking directly to the switch, or using a plain-old-modem with a
> fixed bitrate. In other cases, CBQ is 'saved' because it actually contains
> token bucket filters, which ARE pretty accurate.

Actually, I've got a 10/100 switch attached to three servers, four ethernet
clients and a gateway that is on a fibre optic link to the Internet with
a backup cable modem for web traffic (like A/V streaming) and one dial-in
customer who expects to get snappy response on their 33k6 modem.

I have sold those clients exact rates of bandwidth and allow full sharing
of the available bandwidth when it is available and prioritise traffic
to and from servers, especially interactive traffic, and specify different
rates for each customer to and from our servers vs. to and from the Internet.

I measure the effects with RRDTool as per a script I've sent a couple of
other people for review and have had pretty good results from what I can see
and the clients have not complained of getting less than what they should,
nor is my current remote SSH session lagged at all.

> CBQ relies on being dequeued at a well known rate, which is simply not
> always the case. Furthermore, often there is no 'well known rate', for
> example when using a PPP-over-Ethernet modem over a userspace socket.

I'm sure this is a common case for some users, but its hasn't been something
I've had to deal with, thus my lack of empathy.

PS, I do appreciate the HOWTO and the help its been.  If I may make another
suggestion though, having links to external ressources from within the HOWTO
sections might be useful -- descriptions of how RED and SFQ work according
to people who've done masters work with them and/or designed them are online
in PDF and other formats which I've found quite enlightening for knowing how
these things ought to work.
-- 
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/

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

Re: [LARTC] Anti-CBQ Statements in Howto

[bert hubert]

On Thu, Dec 06, 2001 at 04:17:10PM -0500, Michael T. Babcock wrote:

> > Read linux/net/sched/sch_cbq.c for some enlightenment.
> 
> The first thing I did with the 2.2.x kernels was read most of the source for
> most of the sch_*.c files I found interesting along with a couple of 
> co-workers to understand what they were doing.  That makes me a techie and
> probably not a typical user ... but that's ok, right?

Yeah, but I specifically mean comments from Alexey himself about CBQ in
Linux:

        --- It seems that cbq-2.0 is not very accurate. At least, I cannot
        interpret some places, which look like wrong translations
        from NS. Anyone is advised to find these differences
        and explain to me, why I am wrong 8).

        --- Linux has no EOI event, so that we cannot estimate true class
        idle time. Workaround is to consider the next dequeue event
        as sign that previous packet is finished. This is wrong because of
        internal device queueing, but on a permanently loaded link it is
	true.
        Moreover, combined with clock integrator, this scheme looks
        very close to an ideal solution.  */

> > If you see CBQ working well, you are probably on an empty 10 or 100mbit
> > segment, talking directly to the switch, or using a plain-old-modem with a
> > fixed bitrate. In other cases, CBQ is 'saved' because it actually contains
> > token bucket filters, which ARE pretty accurate.
> 
> Actually, I've got a 10/100 switch attached to three servers, four ethernet
> clients and a gateway that is on a fibre optic link to the Internet with
> a backup cable modem for web traffic (like A/V streaming) and one dial-in
> customer who expects to get snappy response on their 33k6 modem.

So you fall into the 'CBQ should work well' category. 

> > CBQ relies on being dequeued at a well known rate, which is simply not
> > always the case. Furthermore, often there is no 'well known rate', for
> > example when using a PPP-over-Ethernet modem over a userspace socket.
> 
> I'm sure this is a common case for some users, but its hasn't been something
> I've had to deal with, thus my lack of empathy.

Well, I decided to get to the bottom of this due to the relatively large
number of 'CBQ doesn't work!' complaints I receive.

> PS, I do appreciate the HOWTO and the help its been.  If I may make another
> suggestion though, having links to external ressources from within the HOWTO
> sections might be useful -- descriptions of how RED and SFQ work according
> to people who've done masters work with them and/or designed them are online
> in PDF and other formats which I've found quite enlightening for knowing how
> these things ought to work.

If you have good links, I would be very happy to receive them! I don't need
to invent the wheel, if good stuff is available, I want to link it.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

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