[c-nsp] service-policy on virtual interface

[Tony]

--- On Wed, 9/9/09, Pete Templin <petelists at templin.org> wrote:


> Tony wrote:
> 
> >> From the card above you can see that unclassified
> traffic (COS 0)
> >> will start getting discarded at 40% and as the
> queue gets fuller it
> >> will progressively discard more. If the queue gets
> to 70% then ALL
> >> COS0 traffic will be discarded. In queue 1 this
> 30% at the top of
> >> the queue is for COS 2 & 3 packets in
> threshold 2.
> > 
> > This theoretically means that the maximum throughput
> you would see on
> > the above card with just enabling QOS and not
> configuring anything is
> > around 700Mbps (70% of 1Gbps). in reality it would
> probably be a bit
> > less, but that would be absolute maximum
> 
> Can you clarify this for me?  If 999Mbps of traffic is
> arriving on an 'ingress' port and is the only traffic
> leaving on an 'egress' port, there shouldn't be much if any
> queueing, right?  Queueing should only be occurring
> when the (instantaneous) packet arrival rate exceeds the
> rate at which the device can dispatch the packets, and as
> those queues get to various thresholds of %-full, they'll
> execute WRR to manage the queue depth, correct?
> 
> pt
>

I can see what you're getting at and it sounds correct.

It might hold true in a test environment where you only had two interfaces and you pushed traffic in one and out the other. If I had access to the gear to test this I would like to and see what happens with and without QoS enabled. In most normal environments you would probably have bursty traffic and over subscription somewhere even if it the egress interface wasn't being over-utilised (ie average egress <1000Mbps).


There are also buffer limits that are applied to the queues. The below is from the output of "show queueing int gigx/y":

    queue-limit ratios:     70[queue 1]  15[queue 2]  15[Pri Queue]

The above output says that queue 1 (ie. default class, COS 0) is only allowed 70% of the buffers. I'm not sure whether the "queue-limit" is a hard limit though (ie. it can't ever be exceeded). I'm not totally convinced of this part of my argument myself. It a 1:1 situation, do the queues fill at all or can the egress interface transmit as fast an ingress packets so that there is no queueing at all (as you questioned above) ?


You then have the ratio of how the queues are serviced, which is:

    WRR bandwidth ratios:  100[queue 1] 255[queue 2]

So queue 1 gets 100/(100+255) = 28% of the WRR scheduler and queue 2 gets 72%. Even though queue 2 is smaller, because it gets serviced with a higher weighting it will empty quicker than queue 1.

There is also the previous thread from the OP who stated that with default QoS enabled he was only getting ~400Mbps out of his Gbps port.

http://puck.nether.net/pipermail/cisco-nsp/2009-July/062100.html

This suggests that stuff is being dropped to make sure the queue buffers aren't filled so that there is room for any stuff with higher COS settings perhaps ? If the queue was filled with COS 0 traffic and some higher COS traffic comes along you would have to drop the higher COS traffic due to lack of space in buffers which kind of defeats the purpose of QoS (give/reserve priority to higher preferenced traffic). 

I would point to the below reference on not enabling QOS globally without looking at your traffic because you may get less performance than with QoS disabled:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html#wp1750716

This next link also has some examples of how changing some of the queue values affects what happens to the traffic in the queues.
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bf98.shtml


If someone else wants to correct me then please do. This is how I understand it works, but I'm happy for it to be otherwise. I'm aware that this stuff gets archived and people will be looking at it in the future, I don't want someting that is incorrect to be left around for people to be looking at thinking it is correct (peer reviewed == good).

Anyone more knowledgable on the subject wish to chime in ?


regards,
Tony.




      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/