QoS confusion...

[Aileron88]

Hi all,

I'm reading through the course notes from the QoS course, and i'm a little confused about a few points.

1. Are the CDT and hold queue out values only used in WFQ, not CBWFQ?

2. When will the TxRing send? I understand that having too large a TxRing can cause delay & too small a TxRing can cause unnecesary CPU usage. My question is, when exactly will the packets be sent? Does the device wait for the TxRing to be full before sending or is there a time or are packets in the TxRing literally sent as they are sent to the interface?

3. In CBWFQ you can use WRED in classes to 'intelligently' drop rather than using tail drop. On the default class, if you just use WFQ by issueing the fair-queue command I'll assume you're now using WFQ on that class and that each 'conversation' will have its own queue (up to a point unless there's too much traffic when queues will be shared). Now if you apply the random-detect command on this class-default how is this class now operating? I thought that with the initial fair-queue command the flows would be managed by the CDT and eventually tail dropped by the hold queue out limit. But when the fair-queue command is added does this overide this behaviour and then drop per queue/conversation using the WRED values instead?

Thanks for your time,

Adam

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

#1 CDT is?

#2 Not 100% positive, but believe interface will draw from TxRing when it's able to transmit other frame/packet.  I.e., I don't believe the interface waits for TxRing to fill (if for no other reason, depending on size of ring and actual traffic, that could be a very long wait.)

#3 My understanding, if you enable WRED with FQ, both operate.  I.e. you might have both WRED and FQ flow drops.  The WRED operates against all packets in the class regardless where the packets are queued.

[Aileron88]

Hi Joseph,

Thanks for the reply.

1. CDT is Congestive Discard Threshold, or how full the queue is in WFQ before packets are dropped.

2. So if the interface is free packets will be trasmitted as they are recieved in to the TxRing?

3. This makes sense. So whereas the WFQ drops are 'per flow' the WRED drops are per class and should ultimately kick in before the FQ drops.

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

#2 Only Cisco could answer when exactly interface will draw from the TxRing.  I presume if it can transmit, it will check the TxRing.  What happens when the TxRing is empty and the interface is ready to transmit and a packet/frame arrives, I don't know.  It may first queue into the TxRing and then transmit it, or it might bypass the TxRing for the first packet. I think it more likely to always work from the TxRing, but even it if didn't, it would make little difference.

#3 Yes, WFQ drops are "per flow" (queue) and WRED drops per class, but they might not kick in first.  Much would depend on how both WFQ and WRED are configured and actual offered traffic.  Remember WRED works with a moving average queue limit, WFQ works with instantaneous queue limits.

[Marwan ALshawi]

output queuing there are two of them by default and this can be changed for interfaces that support
virtual circutes such as ATM, Frame relay when per-VC enabled

this first output Queue is a software queue where it defuanse per interface logical queues
this can be simple queue FIFO or complicated one using WFQ or CBWFQ

the second output Queue conmes directly after the software queue and it is hardware or trnsmit ring (Tx-ring)
the interface driver work with this memory space directly when looking for packet to send it is always FIFO and smaller than the software Queue

The Software queue start fill up only wen the tx-ring is full and thats why traffic dos enot need ot be queued in the software unless the hardware queue is busy

so the tx-ring length shows how fast the systm siwthces to logical queuing for interface scheduling

by the way it is not so easy to change vlause of both especially with real time sensitve traffic liek VOIP

as it might effect the router performance

HTH