When to use COS instead of DSCP?

[mitchell helton]

Hey folks... i've searched google and the Cisco forums for an hour or better and haven't found exactly what I'm looking for.  I'm hoping you guys can help.

Is there a good reason to use COS instead of DSCP?  If all of my devices support DSCP, why would I want to use COS?

And if I am using DSCP only, is there any reason to have a DSCP to COS (or vice versa) map?

Thanks guys... I appreciate it.

[Peter Paluch · Accepted solution]

Hello Mitch,

This is a very good question.

The DSCP is superior to CoS in most ways - it is retained end-to-end, has a finer granularity, can be easily used both by end hosts and intermediary devices, and is an integral part of

IP header

That makes it the preferred place of QoS marking.

However, there are protocols other than IP. Should you use, say, IPX, CLNP, NetBEUI, or even more typical VTP, CDP, LLDP, STP, IS-IS or many, many more - they do not have their own DSCP or DSCP-alike field. If these datagrams are to be given a different treatment than others, your only way is to use the Ethernet-based CoS marking.

Another reason to use CoS marking is the fact that the Ethernet switches themselves may support Ethernet-based CoS marking but they do not look into the frame contents and do not recognize/respect the DSCP marking. Again, the only QoS marking that such a switch would observe is the CoS. Cisco Catalysts do not belong into this category - they recognize both DSCP and CoS, and in fact, this is the reason why you have to choose which one do you trust, either DSCP or CoS, as they may be set differently, even in a conflicting way, and you need to trust only one of them and subsequently "normalize", or rewrite, the other.

Ideally, both markings should be utilized to allow both routers (that are DSCP-based) and switches (which are, at least in theory, CoS-based) to properly treat the frames/packets. However, using CoS is in fact quite difficult. I have not yet seen a Windows-based program that would be capable of sending CoS-marked frames from a PC. This would require the PC to send 802.1Q-tagged frames which is not technically impossible, just mostly unsupported in Windows drivers and application software. However, another issue is that 802.1Q frames are not readily accepted on Catalyst switchports in access mode - they must meet certain requirements, and furthermore, even if 802.1Q-tagged frames were accepted by the switch, the 802.1Q tag including the CoS field would be stripped if the frame was about to be switched out another access port in its access VLAN. This makes the CoS marking on Catalyst switches extremely short-lived, as it is maintained only if the frame is sent out trunks (beware of native VLANs here) or on voice VLAN.

To sum it up - specifically with Cisco Catalyst-based switched networks, it is ideal to use DSCP whenever possible. However, because an incoming frame may be both DSCP and CoS marked, you always have to decide which one you trust more, and that is why you still need the DSCP-to-CoS or CoS-to-DSCP maps.

Please feel welcome to ask further!

Best regards,

Peter

[Joseph W. Doherty · Accepted solution]

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

When to use CoS is when DSCP can't be used, for the many reasons and usages Peter has noted.

I do want to further emphasis what Peter also described, DSCP is part of the

IP header

the ToS field/byte/octet.  As such, the field is available end-to-end (for IP).  (Note: transit devices can change the value.)

CoS is part of a VLAN tag, and as such is not available if VLAN tagging isn't on the frame and is lost at the first L3

gateway

(although it might be generated again).

Lastly, as also noted by Peter, DSCP offers more granularity, 6 bits vs. CoS's 3 bits.  Common convention, though, is to correspond CoS with the 1st 3 bits of DSCP (much like the earlier

IP Precedence

).

PS:

In the Cisco world, some Cisco switches use an internal "CoS" for QoS processing, and although also 8 values, it's not the L2 VLAN tagged CoS (although might be set by it or used to set it).

[mitchell helton]

Thanks very much for the feedback and insight folks.  I'll leave the mappings in place, and use DSCP whenever I can.  All of our infrastructure support DSCP fortunately.

Thanks again - God bless.

[haji_akhundov]

Hey there,

I recently started working and figuring out the QoS stuff and had pretty much the same question.

I'll give you an example from what I encountered:

I have to separate networks:

NetworkA--- switch --- router -----2Mbit/s---- router --- switch --- NetworkB

The link between the two routers fairly gets distributed among all the different hosts. What I wanted to do is to be able to have certain hosts (I called them 'dedicated' hosts) on both networks to have priority and allow them to use almost the entire bandwidth if needed while the rest could wait. So here what I did:

1. Dedicated certain physical Ethernet ports on the switch for the ‘dedicated’ hosts and configure the switch to mark all the packets with a certain CoS value.This would allow us to further classify the traffic on the router. (I used CoS marking here because I couldn't do DSCP marking on my switch)

2. The router’s Ethernet interface that is connected to the switch acts as the

gateway

for all the traffic on the network. Modular quality of service (MQS) then was used to match all the traffic on the

gateway

with the CoS value that was used in Step 1 and SET (mark) the packet with a certain DSCP value that would aid in later steps.

So basically I mark all the packets from 'dedicated' ports at the OSI Layer 2 with CoS, and then re-mark those same packets at the OSI Layer 3 with a DSCP.

As you can see I had to use both CoS marking and DSCP marking in my case.

Hope my experience with this helped you.

[Boo]

Thanks for the simplest and easy to understand explanation. I now completely understand that DSCP tagging are end-to-end and COS tagging are short-lived and they are best suited to be switched through trunks ports. Does COS being short-lived only apply to cisco based L2 devices ?