trust-cos or trust-dscp

[romanroma]

I am not sure if my VOIP vendor steered me in the right direction. I am not using Cisco phones, but a workstation is connected downstream of the phone; however, the vendor told us to use the following settings on interfaces

!global
mls qos map cos-dscp 0 8 16 24 32 40 46 56
mls qos

#sh mls qos maps cos-dscp
   Cos-dscp map:
        cos:   0  1  2  3  4  5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 40 46 56

#sh mls qos maps cos-output-q
   Cos-outputq-threshold map:
              cos:  0   1   2   3   4   5   6   7
              ------------------------------------
  queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

!interface
mls qos trust cos
priority-queue out

From what I understand 'trust cos' is going to trust the items from the phone; however, NOT trust the traffic from the workstation. So I suspect workstation traffic will get flagged as 0. 

I have noticed the voip phones work great; however, end users and customers are saying that Microsoft Teams is having issues with video and some call quality. I have also noticed that I am getting some drops on Q1.

In this day in age, would it not be better to trust DSCP since I have 16 levels over 8, since this is what the switch actually uses on the backplane?

Also, if I do change the COS<>DSCP values with a map and modify the que they go to, does that effect how the switch will process the frames ? I found this linke, https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/qos/configuration/guide/nexus1000v_qos/qos_6dscp_val.pdf

However, I am using Catalyst 2960x switches and not Nexus, yet I suspect this is a good place to start.

In my example with my config snippet - If I understand correctly, the following happens

(inbound) -> cos values > [map to dscp vaules] ---> queue placement #

So in my case a CoS value of 5 is getting translated to DSCP 40, and also getting placed into queue 1-1.

Due to the latter, are the decimal levels always processed in the order from the link I provided? I think in my case I should change the traffic I want to control into a different queue; however, that means I would re-map some traffic to use 4-1 by changing the CoS>DSCP values. Will doing this change how the switch processes the traffic global then?

The reason I am doing this, I am getting outbound drops in Queue 1-1 to workstation and phone. Should I remove the

priority-queue out

I have read that only Queue 1-1 is always used and I am only seeing drops on queue 1-1, and due to the CoS<>DSCP mapping all my traffic for video and control are going into Queue 1-1.

I noticed that queue 4-1 is NEVER being used. So my thinking is, if i move all video traffic to Queue 4-1 by changing the DSCP values then I should be ok. However, that does mean I change how the switch will global process traffic and the likely hood of drop packets according to

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/qos/configuration/guide/nexus1000v_qos/qos_6dscp_val.pdf

What happens to traffic coming that has a DSCP value that is not mapped to CoS? This is another question that makes me think I should trust DSCP over CoS.

[M02@rt37]

Hello @romanroma,

Trusting DSCP might be more beneficial as it provides finer-grained control with 64 levels compared to COS's 8 levels. Given the variety of traffic types in modern applications like Microsoft Teams, DSCP might be more suitable for QoS settings.

Modifying the COS-DSCP mapping can indeed affect how the switch processes frames. Changing the mappings will influence how different types of traffic are prioritized and handled within the network.

Traffic with DSCP values not mapped to COS will likely be treated based on the default handling for unmapped DSCP values in the network devices, which might not prioritize them effectively.

If you're experiencing drops in queue 1-1 and it's being heavily utilized, considering redistributing video traffic to another queue like 4-1 (by changing DSCP values) might indeed alleviate congestion and reduce drops.

[Joseph W. Doherty]

"Trusting DSCP might be more beneficial as it provides finer-grained control with 64 levels compared to COS's 8 levels. Given the variety of traffic types in modern applications like Microsoft Teams, DSCP might be more suitable for QoS settings."

M02@rt37 is 100% correct that you can have finer-grain control.

However and BTW, DSCP 64 level support is often never used, as the many of the possible markings are either set aside for private usage and/or never used, this is (somewhat) noted in the Wiki article's:

In theory, a network could have up to 64 different traffic classes using the 64 available DSCP values. The DiffServ RFCs recommend, but do not require, certain encodings. This gives a network operator great flexibility in defining traffic classes. In practice, however, most networks use the following commonly defined per-hop behaviors:

• Default Forwarding (DF) PHB — which is typically best-effort traffic
• Expedited Forwarding (EF) PHB — dedicated to low-loss, low-latency traffic
• Assured Forwarding (AF) PHB — gives assurance of delivery under prescribed conditions
• Class Selector PHBs — which maintain backward compatibility with the IP precedence field.

NB: DSCP usually (if not always) leaves IPPrec 6 and 7 alone (for backward compatibility - also Class Selectors for IPPrec backward compatibility - is "sort of", it's somewhat involved to understand their relationship).

Often some network devices, especially switches, do not have the capability to actually support that many different QoS treatments.  (For example, a 2960 only supports 4 egress queues, each supporting 3 drop thresholds.)

However, often more beneficial, I think, is the ToS is part of the IP packet, can be carried end-to-end, while the L2 CoS requires VLAN tagging and needs to be recreated at every L3 hop.

(BTW, one reasonable argument for still using L2 CoS, is for pure L2 switches, which support QoS only using L2 CoS. That would be a good exception although also most modern L2 switches that support QoS, are likely to be "smart" or "enhanced" and can work with IP's ToS.)

Unless your QoS can only be done via L2 CoS, always use L3 ToS.

[Joseph W. Doherty]

"However, I am using Catalyst 2960x switches and not Nexus, yet I suspect this is a good place to start."

Often, with switches, it's not, as switch QoS capabilities often vary much.  I.e. you want to review the QoS capabilities of your actual hardware.

Do you know whether your phone tag the packet's ToS?  If so, I would recommend ignoring L2 CoS.

"From what I understand 'trust cos' is going to trust the items from the phone; however, NOT trust the traffic from the workstation. So I suspect workstation traffic will get flagged as 0."

Not usually how they work.  For starters, L2 CoS requires a VLAN tag (which can, in theory, have a VLAN ID of zero so it might be used just for CoS).  Second, the ingress port doesn't, per se, know whether the VoIP phone or PC generated the CoS, and often doesn't care.  But, as just describes, as a L2 CoS requires a VLAN tag, and PCs don't often VLAN tag, effectively CoS is considered as being zero.

Queue drops are the results of insufficient buffer space (which can be very easily encountered on a 2960 due to both its lack of hardware buffer resources and [often it default] buffer allocations.

Mitigation of queue drops, might be accomplished by moving some traffic from that queue to another queue, as you're thinking, but the other queue now will contend for buffer resources of its own (including from a common pool), and possibly change the mix of prioritization of the two other non-PQ queues.  I.e. potentially, such a traffic migration might make things, overall worse.  Ideally, you want to use a QoS policy suitable (as much as possible on any specific platform) to accomplish your QoS goals.

[romanroma]

Hi Joseph Doherty - you have helped me out in the past and it is good seeing you.

I am not very strong with QoS yet; however, learning quickly.

Currently I have my workstation traffic vlan tagged and my phone traffic vlan tagged. I am unsure if I should trust the CoS values or just Trust DSCP. Both the VOIP phone traffic and (example) Soft-phone and Team traffic need to route through my network, I figured I should trust DSCP more.

I was the link as a starting place for the levels of tagging and understanding, Cos 8 levels vs DSCP 16 levels - still looking for the hardware notes for my 2960x and QoS documentation. But from the sounds of it, the 2960x are lacking in hardware.

Trying to keep things a little simple as a pilot-project - and figured since I see no packet incremented on the queue counter for Q4 I could get away with moving specific tagged traffic to that queue.

[Joseph W. Doherty]

"I am not very strong with QoS yet; however, learning quickly."

That's not uncommon.  Learning QoS, to actually do it well, can be difficult.  IMO, it's not actually difficult to learn, but how it's taught leaves much to be desired, again, IMO.

"Currently I have my workstation traffic vlan tagged and my phone traffic vlan tagged"

You're sure?  I ask because that's unusual.

"I am unsure if I should trust the CoS values or just Trust DSCP."

My prior reply, might overlay with your reply, but in short, given a choice, always go with L3's ToS/DSCP.

"DSCP 16 levels"

How did you get 16 and "levels"?  As M02@rt37 correctly described, there are 64 possible DSCP values.  The "recommended" named values are BE, CSx (where x=1..7) AFxy (where x=1..4 and y=1..3), and EF.  "Levels", though?

"2960x and QoS documentation"

If you cannot find that, look for 3750 series QoS documentation, more-or-less, same QoS features.

"But from the sounds of it, the 2960x are lacking in hardware."

Compared to more expensive switches, that's true.

" and figured since I see no packet incremented on the queue counter for Q4 I could get away with moving specific tagged traffic to that queue."

I understand your logic, and it may work, but better, I think, to work out a QoS policy for your traffic, and they try to support it, as best as possible, on different network devices based on their QoS feature support.

Here's my generic QoS CBWFQ policy (which, unfortunately, almost no switch will directly support):

policy-map CBWFQ-model
 class real-time
  priority percent 33
  fair-queue
 class better-than-BE
  bandwidth remaining percent 81
  fair-queue
 class less-than-BE
  bandwidth remaining percent 1
  fair-queue
 class BE
  bandwidth remaining percent 9
  fair-queue

In the above, you need to be careful about to which class you direct certain traffic flows.
The above model is likely cannot be directly implemented on any Cisco device, but it's an ideal.

[romanroma]

Thank you for your support and suggestions.

"

"Currently I have my workstation traffic vlan tagged and my phone traffic vlan tagged"

You're sure?  I ask because that's unusual."

Here is what I have on my config

interface GigabitEthernet1/0/34
 switchport access vlan 1001
 switchport mode access
 switchport voice vlan 200
 priority-queue out
 ipv6 dhcp guard attach-policy dhcp6_client
 no snmp trap link-status
 mls qos trust cos
 spanning-tree portfast edge

Since it was detailed to me, that they wanted the workstation inline, downstream of the phone, I did the following with the 'voice' vlan tag, so I did not have to worry about the 802.1q negotiation. Not to mention the IP Provision Team and the Firewall Team wanted the phones to isolated in their own network.

Why is it unsual to have phones in a different vlan, when I read so much good things about the 'voice vlan' tag.

swvoip.pdf (cisco.com)

Can you recommend any good Basic 101 QoS resources? I am just reading random items, and putting it all together; however, if there was like a Day-One QoS write up that showed the Basic would be very helpful.

Thank you again.

[Joseph W. Doherty]

"Why is it unsual to have phones in a different vlan, when I read so much good things about the 'voice vlan' tag."

That's not at all uncommon, but also I didn't question that.

What I thought was uncommon is you noting "Currently I have my workstation traffic vlan tagged and my phone traffic vlan tagged."  Your edge port configuration is common for untagged data packets.  That said, I understand some Cisco switches might accept tagged data packets.

What you described might be explicitly done if the interface is defined as a trunk, allowing the two VLANs, 1001 and 200, with 1001 also being defined as the native VLAN.  Implicitly, your common data/voice edge port configuration might support that.

Again, though, I've never seen user workstations VLAN tag frames, not saying they cannot, just I consider it unusual.  (For QoS purposes, they often will use L3 ToS/DSCP.)

Often VoIP phones do both VLAN tagging, with CoS, and also do ToS/DSCP L3 tagging, with the latter used for QoS treatment, while the former is generally totally ignored.

"Why is it unsual to have phones in a different vlan, when I read so much good things about the 'voice vlan' tag."

Again, I agree using voice VLANs is NOT unusual and generally is a "good thing", although not a necessary thing, but then again, having VoIP phones being the only device on the edge port is even a "better thing", although also not a necessary thing.  (In fact, one 3rd party VoIP vendor suggests you can have twice as many of their VoIP phones in a voice VLAN if they don't share the physical port with a workstation host.)

"Can you recommend any good Basic 101 QoS resources?"

Nothing that I can endorse as being especially "good".

As an aside, my approach to QoS has "plagiarized" what's been developed, over decades, for managing contention for CPU and disk drives resources.  Initially, they too used FIFO for much resource management, but FIFO was lacking in many respects, but for the past 4 decades or so, such systems moved on to more sophisticated management approaches.  Network bandwidth management, has been much avoided except for really critical app requirements (e.g. VoIP) and by constantly increasing bandwidth capacity (increasing capacity, of course, also has been on-going with computer system CPU and storage management too, just their not as much stuck with using increased capacity, for improved perceived performance, alone).

[romanroma]

Hi Jospeh,

I see the confusion, and it was on my part when I said "tagged" since I said tagged. I thought the port is automatically placed in a truck state and frames are tagged when they leave the interface with there is two vlans assign but one marked with "voice", since the traffic going to the phone is tagged, but the workstation is untagged. ++laugh++ I think we are saying the same thing, but due to my lack of skills, it is confusing. So I do appreciate your help and patience with me.

So many things to learn, so little time. My head is swimming right now and will need to regroup over the weekend and will have more questions.

Thank you again

[Joseph W. Doherty]

Yup, believe we're on the same page now.

Data/voice access ports do have two VLANs, but generally only one of them (the voice VLAN) actually sends tagged frames.

Tagging VLAN frames usually implies adding the 802.1Q tag (4 bytes) to the frame.

[romanroma]

I do have one question - I did a packet capture and noticed the voip phone is tagging traffic with AF41, which is a decimal value of 34. However, since I have the following

!global
mls qos map cos-dscp 0 8 16 24 32 40 46 56
mls qos

#sh mls qos maps cos-dscp
   Cos-dscp map:
        cos:   0  1  2  3  4  5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 40 46 56

#sh mls qos maps cos-output-q
   Cos-outputq-threshold map:
              cos:  0   1   2   3   4   5   6   7
              ------------------------------------
  queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

!interface
mls qos trust cos
priority-queue out

the DSCP value is not going to get tursted since I have "mls qos trust cos", and the traffic is getting marked down to Best Effort. This is why I suspect my VOIP lead me wrong with the configuration, or the wrong configuration was applied to the voip phones.

If I change the config to trust dscp, and remove the dscp <> mapping, then the switch should automatically assign the AF41 traffic to the correct queue found in the "show mls qos maps dscp-output-q" ?

[Joseph W. Doherty]

"I did a packet capture and noticed the voip phone is tagging traffic with AF41"

That's curious as AF41 is a recommended marking for video.

VoIP phones often allow you to configure how you want VoIP bearer and/or VoIP signaling frames/packets marked.  (NB: it's recommended to treat bearer and signaling differently.)

When it comes to trusting COS vs. DSCP, I recall (?) there are "rules" about how they interact when both present.  Likely the "trusted" one is the one use for QoS processing.

"If I change the config to trust dscp, and remove the dscp <> mapping, then the switch should automatically assign the AF41 traffic to the correct queue found in the "show mls qos maps dscp-output-q" ?"

Well it depends on what you consider the "correct" queue.  The device has it's own default settings, which may not be optimal for you.

If I haven't already, I recommend you first "design" you ideal QoS policy (which can "evolve", if you want).

For example, we have VoIP traffic that needs to meet typical VoIP service requirements which will help insure by giving VoIP bearer frames/packets first priority, enough buffer space to preclude frame/packet drops, etc.

For VoIP signaling, we will . . .

Everything else is BE.

Example of evolution:

Microsoft Teams traffic will . . .

Etc.

[MHM Cisco World]

What is your SW platform model?

What is port you use ?

[romanroma]

2960x

1Gbps ports