LAN QoS

[visitor68]

Hi...why with L2 QoS does one have to map CoS values to the specific queues that are available on the Catalyst switch, yet that is not necessary with L3 QoS on an IOS router? With a router, one can configure CBWFQ with LLC, for example, without knowing or caring how many queues are available on the output or input interface...we just configure the policy through MQC, apply it to an interface and that's that. 

[Philip D'Ath]

The switch does it in hardware, and can do it at full line rate.

The router does it using CPU, so does not have the same restraints.

[visitor68]

Hi... I'm not sure I understand that answer... can you or someone else elaborate more? The answer creates more questions than it answers...

[Joseph W. Doherty]

As Philip mentioned, switches generally have dedicated hardware (often built around ASICs) to provide multi-port wire rate frame/packet forwarding.  Such dedicated hardware also often includes, when provided, support for QoS.

The capabilities of hardware QoS is also often reflected in the configuration command syntax.  For example on the 3560/3750 series of switches, the hardware supports four egress queues per port unlike a small software based router that supports CBWFQ, using MQC, which often also support many more than four queues per interface.  A switch's limited support of QoS features wouldn't benefit as much from using MQC syntax, as does a software based router, although the later Catalyst switches, like the 3650 and 3850, with their expanded QoS features, I believe, now use MQC syntax unlike earlier switches which did not.

[visitor68]

Thanks, folks...so allow a follow-up question, please. 

What exactly is a hardware queue and how does it differ from a software queue? In the end, a queue is an abstraction that is implemented using memory buffers. Hardware queue or software queue, what we are talking about are "cells" of memory that are carved out the system's overall memory - perhaps DRAM. So what differentiates the hardware queue from the so-called software queue?

Moreover, yes, a switch has hardware queues that are provided by the ASIC and a router has a FIFO hardware queue (Tx Ring) that is the last stage before serialization on the outbound wire. So, what is the difference between those hardware queues, if any?

My thoughts are the following: what is actually meant by "hardware queue" is the fact that the buffer (memory cell) is permanently assigned to the interface and is not configurable - it's just there and it is static.

Moreover, the buffer is an addressable memory construct that the queue points to.On the other hand, a so-called "software queue" is also implemented or created by the assignment of addressable buffer memory (memory cells) but it is done dynamically through CLI configuration via the administrator. BUT, IN THE END, HARDWARE OR SOFTWARE QUEUEING, WHAT WE ARE TALKING ABOUT ARE MEMORY BUFFERS that are either permanently carved out, as in the case of the former, or dynamically assigned to an interface, as in the case of the latter. 

Thoughts?

[Joseph W. Doherty]

Switch hardware queues just mean that (some of the) logic for managing the queues is by embedded ASICs, while software based queues are managed by the IOS.

You mention the tx-ring, which is also managed by hardware, while something like CBWFQ queue(s) are managed by the IOS.

[visitor68]

OK, that may be the case and you have thus differentiated the two from a management perspective. But what are your thoughts insofar as the differentiation I made? I was specifically addressing the constructs themselves - as in, what are they...

[EDIT] So, in a SoC scenario, all the buffers are on the hardware ASIC and are provided by the ASIC - so all the buffers are "hardware buffers," per se. But the so-called "hardware queue" is statically assigned and part of the design of the interface circuitry on the chip itself and, as you put it (and I think I agree because it sounds right), managed by the embedded code on the ASIC. On the other hand. the so-called "software queues" are implemented (read: assigned) and managed by the IOS (in the case of Cisco, of course)...

would you agree with this description?[EDIT]

[Joseph W. Doherty · Accepted solution]

In principal/concept I agree, but in practice only the vendor can tell you exactly how they support their queues between IOS and dedicated hardware (although much of what/how they manage features they likely consider proprietary information).  I'm sure there can be overlap between the two, too.

Although we've been discussing queue management, similar issues, on switches, concern frame/packet forwarding.  Such can be done with the IOS or it can also be done with dedicated hardware.

[Ganesh Hariharan]

Hi...why with L2 QoS does one have to map CoS values to the specific queues that are available on the Catalyst switch, yet that is not necessary with L3 QoS on an IOS router? With a router, one can configure CBWFQ with LLC, for example, without knowing or caring how many queues are available on the output or input interface...we just configure the policy through MQC, apply it to an interface and that's that. 

Hi,

Generally, router QoS offers many more QoS configuration options compare to switch level and QoS features vary between platforms, especially between routers and switches.

Traffic will be prioritized by QoS policy on interface traversal.Two most commonly used QoS process is  classification and queuing along with policing and shaping.

Classification identifies and marks traffic to ensure network devices know how to identify and prioritize data as it traverses a network. Queues are buffers in devices that hold data to be processed.

Queues provide bandwidth reservation and prioritization of traffic as it enters or leaves a network device. If the queues are not emptied, they overflow and drop traffic.

Hope it Helps..

-GI

[lpassmore]

With L2 QoS, one does not HAVE to map CoS values to specific queues, but if you don't explicitly do it then a default allocation will be applied.  Each interface type has a slightly different allocation of which hardware queue gets which CoS value by default.  But generally the CoS values have to be applied to a physical queue because that is how the switch knows where to put the packets for physical transmission.  Any frames in the Priority hardware queue are sent and then the others get a share of the transmit bandwidth.

With L3 QoS, the queuing is done using software buffers.  The frames are then picked from the buffers using the CBWFQ algorithm (or whatever) and put into the appropriate hardware queue (based on the CoS value) ready for transmitting.

If the answers are raising other questions, please ask them.