Re: Interface Congestion Definition and interaction with WFQ

Matt,

In short, an egress interface is assumed to be congested, when the
receive interrupt process routine cannot put the received packet
directly to the interface TX-Ring due to the lack of buffer space.
Insted of that, the packet is queued to the software queue assigned to
the interface.

If you are using hierarchical queueing, i.e. you have shaper applied
to an interface, the receive interrupt calls for the shaper metering
process to see if the packet exceeds or conforms to the configured
rate. Exceeding packets are queued under the shaper's queue,
conforming packets are assigned to the interface TX-Ring. Notice that
a properly configured shaper rate should be *lower* than interface's
physical rate and under this condition the TX-Ring never overflows, as
the interface could serialize all packets in timely manner.

However, if you have multiple VCs on the interface (e.g. FR), all
shaped to their PIRs, you may have (deliberate) oversubscription
situation where the total sum of all shaper PIRs exceeds the interface
physical rate. Under some conditions, will create functional
congestion and engage interface software queue. Normally, there should
be a back-pressure mechanism to signal the VC shapers they should
throttle down. For example, FR traffic-shaping may adapt to the
interface congestion. If the shapers dont adapt, traffic would be
handled by the interface software queue, whatever is configured (e.g.
PIPQ for FRTS).

This overview does not cover fragmentation and interleaving
procedures, as they make the queueing process a little bit different.

HTH,

-- 
Petr Lapukhov, petr_at_INE.com
CCIE #16379 (R&S/Security/SP/Voice)
Internetwork Expert, Inc.
http://www.INE.com
2010/3/17 Matt Bentley <mattdbentley_at_gmail.com>:
> Hi Team:
>
> Have a question regarding QoS.  I know that the built in policer for CBWFQ
> LLQ takes effect only during congestion.
>
> I also know that the "bandwidth" command only guarantees traffic during
> congestion.
>
> For example, if you have a GigE NNI interface to a carrier who provides a
> 10Mb ethernet service, and you have QoS configured as follows.
>
> int Gi0/1
> bandwidth 10000
> ip add x.x.x.x
> service-policy output TEST
>
> policy-map HQoSTEST
> class class-default
> shape average 10000000
> service-policy TEST
>
> policy-map TEST
> class EF
> priority percent 10
>  police 1000000
>  conform transmit
>  exceed set-dscp-default transmit
> class AF31
>  bandwidth percent 30
> class class-default
> bandwidth percent 30
> random-detect dscp-based
>
> My question is how does the router determine that "congestion" has occurred.
>  Does it look strictly at the interface buffers - does the full Gig have to
> be being sent before CWFQ is notified of congestion?
>
> Is the HQoS really necessary, or does it just go off of the bandwidth
> CONFIGURED on the interface.
>
> I would think that before traffic is passed to the WFQ scheduler, it has to
> pass through the shaper.  Does the shaper just blindly take the first 10Mbps
> that comes to it - regardless of priority - and pass to WFQ.  In this case,
> if the shaper fills up with 10Mbps of BE traffic, and then an EF packet
> comes along, will it be buffered before it is passed to WFQ scheduler?
>
> So is it preferred NEVER to use a hierarchical shaper - when we can avoid
> it?
>
> Thanks,
>
>
> 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