Re: hierarchical shaping versus shaping in conjunction to cbwfq

From: Pierre-Alex (paguanel@hotmail.com)
Date: Sat Jun 03 2006 - 13:16:54 ART

Petr,

Thank you for the reply, but I do not understand the point about the
configuration being meaningless: shaping does introduce a point of congestion,
doesn't it?

I would interpret the config bellow as follows:

" class A
shape 128000
bandwidth 128

class B
shape 64000
bandwidth 64

Introduce a point of congestion at 128000 for Class A, then if shapping is
activated, allocate 128 K of the total bandwidth of the interface to class A.

Introduce a point of congestion at 64000 for Class A, then if shapping is
activated, allocate 64 K of the total bandwidth of the interface to class
B.

2) Woud that then mean that the CCO example is incorrect?

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_
c/fqcprt4/qcfcbshp.htm#wp1002798

3)

Thanks for your help

Pierre

  ----- Original Message -----
  From: Petr Lapukhov
  To: Pierre-Alex
  Cc: ccielab@groupstudy.com
  Sent: Saturday, June 03, 2006 5:50 PM
  Subject: Re: hierarchical shaping versus shaping in conjunction to cbwfq

  Pierre,

  I did not dig though all of you scenarios in depth, but it seems that you
  confuse some concepts here.

  First, CBWFQ. This is basically good old WFQ. But at this time, we
  set "weights" and define "classes" ourself. So a good undestanding of
  WFQ is required to get how CBWFQ works, by the way.

  Secondly, "bandwidth". This is what replaces automatic weight computation
  of WFQ (WFQ uses flow, instead of class, and precedence to weight the
flows).

  Bandwidth command actually sets class' weight for CBWFQ scheduler,
  and engages per-class FIFO queue in case of congestion. Sure thing,
  if no congestion occurs (TX-Ring is not filled up), your bandwidth setting
has
  no effect, and does _not_ limit traffic at all.

  (If you need to limit traffic flow, you need either shaper of policer)

  Third thing, the shaper. Now, as you recall shaper utilizes leaky bucket
algorithm
  to delay traffic, and hence introduces some sort of queue, to hold delayed
packets.

  Back in days, GTS utilizes only WFQ as queueing system. Nowdays, you may
  specify CBWFQ as per-shaper queue system. This is precisely what is being
  done when you write:

  ...
  class X
  shape 128000
  service-policy CBWFQ

  where policy-map CBWFQ defines your queueing configuration. That is,
  you shape all traffic of class X to rate 128K, and apply CBWFQ queueing
  strategy to shapers' queue.

  So you see now, that things like:

  ...
  class A
  shape 128000
  bandwidth 128
  ...

  are rather useless, since they do _different_ things! Bandwidth specifies
  class weight in case of congestion, and shape limits traffic flow for
class.
  I don't see any practical reason to use these things together.

  Also, placing shaper in class-default is the standard way to queue traffic
at
  subinterface. That is, subinterface by default has no queue by itself, so
  you need to introduce one. You then put CBWFQ configuration inside shaper,
  and that is your queueing mechanism for subinterface.

  HTH
  Petr

This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:31 ART