[c-nsp] WRR Confusion on 6748 blades

[Tim Stevenson]

Hi John, please see inline below:

At 10:05 AM 6/27/2012, John Neiberger pronounced:
<...snip...>
> > What this should be doing is just causing us to service the queue more
> > frequently. That could certainly reduce/eliminate drops in the event of
> > congestion, but only if there is traffic in the other queues that is also
> > contending for the bandwidth.
> >
> > In other words, if there is only one active queue (ie only one queue has
> > traffic in it), then it can & should get full unrestricted access to the
> > entire link bandwidth. Can you confirm whether there's traffic in the other
> > queues?
> >
>
>I'm not certain whether or not we have traffic in the other queues. In
>nearly all cases, the output drops are all in one queue with zero in
>the other queues. That seems to indicate that either all of our
>traffic is one queue or there just isn't a lot of traffic in the other
>queues.


Unfortunately, there are no 'absolute' per queue counters, only per 
queue drop counters. So no easy way to determine if other queues are 
being utilized unless you just 'know' (based on your classification 
policies and known application mix) or those queues overflow & drop.


> >
> >
><...snip...>


> > This suggests to me that there is traffic in other queues 
> contending for the
> > available bandwidth, and that there's periodically instantaneous 
> congestion.
> > Alternatively you could try sizing this queue bigger and using the original
> > bandwidth ratio. Or a combination of those two (tweaking both bandwidth &
> > queue-limit).
> >
> > Is there some issue with changing the bandwidth ratio on this 
> queue (ie, are
> > you seeing collateral damage)? Else, seems like you've solved the problem
> > already ;)
>
>Nope, we don't have a problem with it. That's what we've been doing.
>We haven't really been adjusting the queue limit ratios, though. In
>most cases, we were just changing the bandwidth ratio weights. I'm
>looking at an interface right now where the 30-second weighted traffic
>rate has never gone above around 150 Mbps but I'm still seeing OQDs in
>one of the queues only. How do you think we should be interpreting
>that?



In my opinion, it indicates that:
1. there is traffic in the other queues contending for the link bandwidth
2. there is instantaneous oversubscription that causes the problem 
queue to fill as it's not being serviced frequently enough and/or is 
inadequately sized
3. the other queues are sized/weighted appropriately to handle the 
amount of traffic that maps to them (ie, even under congestion 
scenarios, there is adequate buffer to hold enough packets to avoid drops)

If #1 was not true, then I don't see how changing the bandwidth ratio 
would make any difference at all - if there is no traffic in the 
other queues, then the single remaining active queue would get full 
unrestricted access to the full bandwidth of the link and no queuing 
would be necessary in the first place.

Supposing there is no traffic in the other queues - in that case, you 
could certainly still have oversubscription of the single queue and 
drops, but changing the weight should have no effect on that scenario 
at all (while changing the q-limit certainly could).


2 cents,
Tim





> >
> > Hope that helps,
> > Tim
>
>It helps a lot! thanks!
>
>John




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.