Re: Shapers, CBWFQ, and tx_ring, oh my!

> Two things muck with my understanding:
> In https://supportforums.cisco.com/thread/2132501 , a Cisco employee says
> that the shaper uses WFQ (or HQF in the newest releases) to de-queue the
> CBWFQ queues. Why is the shaper implementing any dequeueing strategy at
> all? Shouldn't the CBWFQ policy-map be handling that (such as policy
> queues going first, etc)? And how can it possibly do that without full
> flow information?

The shaper needs a mechanism to release packets to the tx_ring accordingly.

Consider the following LLQ configuration:

policy-map blah_child
 class voip
  priority 64
 class class-default
  bandwidth 64

policy-map blah_parent
 class class-default
  shape average 128000
  service-policy blah_child

When the Bc limit is reached for the time interval, and the shape
queue fills up, should the shaper simply release packets to the
tx_ring (FIFO) at the next time interval? Or should the voip traffic
be released first? If the shaper didn't have a "dequeueing strategy",
the desired policy would not be in effect. In CBWFQ, I guess you could
say the shaper uses WFQ to dequeue packets, in HQF I am not sure what
you would call this, but its the same principal.

-Yuri

On Sat, Jul 14, 2012 at 3:07 AM, Keller Giacomarro <keller.g_at_gmail.com> wrote:
> I am trying to wrap my head around how QoS queueing actually functions. If
> you're able, please confirm or debunk my understanding!
>
> Your 'normal' QoS setup involves a CBWFQ policy-map applied outbound on a
> WAN interface. As the tx_ring fills up, packets are queued into the CBWFQ
> policy-map queues (one per class-map), and are dequeued as normal. The
> tx_ring filling up is the trigger for filling queues. Okay, simple so far.
>
> The complication comes when you have an interface with a rate limit higher
> than your CIR (like a home Internet connection via 100Mbps ethernet with a
> CIR of 512Kbps). If CBWFQ is applied directly to the interface, even if
> the bandwidth is set, the tx_ring clears faster than the WAN circuit will
> take the data, and the software queues are bypassed entirely. In this
> situation, applying a CBWFQ policy-map directly to the interface, even
> setting the bandwidth command, does absolutely nothing.
>
> Here's where I get fuzzier. The solution to this is to put something else
> between the CBWFQ policy-map and the tx_ring: a shaper via nested policy
> maps. The shaper is configured to the correct CIR. As the shaper sees
> that the interface is transmitting too fast, it begins to fill up the CBWFQ
> policy-map queues instead of transmitting. In this way, the physical
> interface is faster than the CIR but we still create the necessary
> 'backpressure' to fill up the software queues.
>
> Two things muck with my understanding:
> In https://supportforums.cisco.com/thread/2132501 , a Cisco employee says
> that the shaper uses WFQ (or HQF in the newest releases) to de-queue the
> CBWFQ queues. Why is the shaper implementing any dequeueing strategy at
> all? Shouldn't the CBWFQ policy-map be handling that (such as policy
> queues going first, etc)? And how can it possibly do that without full
> flow information?
>
> The other issue is that the show commands on my router support my
> understanding...almost. If I'm moving a lot of ssh data upstream (via
> scp), I can see the shaper queue fill and the CBWFQ queue fill, makes
> sense. Most of the time their values are the same. However, they do
> on occasion differ by a number or two. Show command artifact, or an
> indication that I have no idea what I'm talking about?
>
> gateway#show policy-map int f0/1
> FastEthernet0/1
>
> Service-policy output: pm-wan-out-shaper
>
> Class-map: class-default (match-any)
> 600317 packets, 143960388 bytes
> 30 second offered rate 631000 bps, drop rate 14000 bps
> Match: any
> Traffic Shaping
> Target/Average Byte Sustain Excess Interval Increment
> Rate Limit bits/int bits/int (ms) (bytes)
> 600000/600000 937 3750 3750 6 468
>
> Adapt *Queue* Packets Bytes Packets Bytes Shaping
> Active *Depth* Delayed Delayed Active
> - *3* 598394 141284492 90698 94225802 yes
>
> Class-map: cm-ssh (match-all)
> 70238 packets, 105192011 bytes
> 30 second offered rate 621000 bps, drop rate 14000 bps
> Match: protocol ssh
> Queueing
> Output Queue: Conversation 74
> Bandwidth 5 (%)
> Bandwidth 30 (kbps)
> (pkts matched/bytes matched) 62464/93671468
> *(depth/total drops/no-buffer drops) 2*/1816/3
> exponential weight: 9
> mean queue depth: 1
>
> Appreciate your input -- hopefully this helps someone else too, as none of
> the standard study resources I've read have adequately explained how this
> works!
>
> Keller Giacomarro
> keller.g_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat Jul 14 2012 - 14:06:23 ART