How are DSCP values set?

[a1111]

Hello,

It's possible to identify QoS traffic based on DSCP values. For example, for the EF class, by using the command "match ip dscp ef". But, how is the correct DSCP value set for specific traffic?

I know that with some applications, the user can have the application mark the packet with QoS markings:

https://answers.microsoft.com/en-us/skype/forum/all/quality-of-service-marking-packet/c81491d7-cafc-419b-91ad-e0093455100c

However, because of the trust boundary configuration, anything marked by the end user is not trusted. Which means typically, it's the networking devices that do the marking -- ideally, the closer to the source/sender, the better. In other words, it's the switch that marks the CoS field in the VLAN tag.

How does the switch know that I make a Skype/Microsoft Teams/etc call? Just by looking at the frame, how does the switch know what CoS value to set? The switch doesn't do deep packet analysis.

Thanks.

[Peter Paluch]

Hello,

An awesome question - and a very tough one!

The hard truth is: This is always a compromise, and there is no perfect solution. Precisely as you mentioned, a switch does not perform deep packet inspection and so cannot be 100% sure that a packet marked with EF comes from an application that produces expedited-forwarding-alike traffic such as Skype. And anyway, since so many applications today use encryption, even deep packet inspection isn't an all-saving mechanism.

In times of hardware IP phones, a port on the switch could be configured to conditionally trust the incoming DSCP marking if a phone was detected through CDP. Without the phone, the port would remark all incoming traffic to BE or some other pre-set value; if a phone was up and running, the DSCP (or CoS - the duality was a horror) markings would be trusted.

As it is no longer that popular to use hardware IP phones, and plus, many applications running on a computer may themselves need a different treatment from best effort, we seldom have other option aside from simply trusting what comes from the computer.

There are two approaches I can see, although I'm not sure how viable they are.

The first approach would be to use the capabilities of the operating system on the computer itself to prevent a user from misbehaving. For example, in Windows, use the QoS Policy to define which applications can use non-zero DSCP marking: https://learn.microsoft.com/en-us/windows-server/networking/technologies/qos/qos-policy-manage

The second approach would be to accept the DSCP markings from the hosts on the switches, and verify them at the nearest box that can afford to do deep packet inspection - whether it's the default gateway, or a firewall in the DMZ...

Like the whole QoS, even the trust boundary shows itself to be a nice concept in theory, but certain compromises must be drawn when implementing it in practice - depending on the capabilities of your network nodes, and your workstations' operating systems.

@Joseph W. Doherty will certainly have more wisdom to share!

Best regards,
Peter

[Joseph W. Doherty]

@Peter Paluch so good to see one of your replies.

Or course, you're a hard act to follow.  ; )

"But, how is the correct DSCP value set for specific traffic?"

Ah, but what is the correct DSCP value that should be set?

Often the host can set the DSCP value, as can any DSCP processing capable network transit device.  If fact, every network device has the option to change a DSCP value.

Since all these devices can set a DSCP value, any can set an incorrect value.  Even if there's a "correct" DSCP value, again define correct, such a value may not obtain the "correct" QoS treatment.

"However, because of the trust boundary configuration, anything marked by the end user is not trusted."

Not necessarily.  But, host DSCP marking verification or immediate limitations, as near to the host source, as possible, are often good practice.

"Which means typically, it's the networking devices that do the marking -- ideally, the closer to the source/sender, the better. In other words, it's the switch that marks the CoS field in the VLAN tag."

Like Peter, CoS, yuk (very much avoid), again, network device, even the first possible network device, might not mark.

Much depends on your QoS policy, including whether you both using ToS (or CoS).  (BTW, Cisco routers, then and now [still I believe], by default, ignore ToS.  Cisco switches, then, by default, also ignore ToS, but if QoS enabled, by default, they would set it to zero.  Now, Cisco switches, usually have QoS enabled by default, and have a very basic QoS policy driven by ToS/CoS markings.)

If a host uses .1Q tagging, it too can set CoS (again yuk), or it can set the ToS (or both, if desired).

"How does the switch know that I make a Skype/Microsoft Teams/etc call? Just by looking at the frame, how does the switch know what CoS value to set? The switch doesn't do deep packet analysis."

Much depends on how "enhanced" or "smart" the switch is.

Generally, even the better switches cannot do deep packet inspection, but the "enhanced" ones can often examine L3 and L4 fields.  That's sometimes enough to indicate what the traffic might be.  For example:

Skype Port Number Details
Skype uses several ports for communication, and the specific port numbers may vary depending on the scenario. Here are some key port numbers associated with Skype:

TCP port 3478: This is the primary port used by Skype for peer-to-peer (P2P) connections, file transfers, and voice/video calls.
TCP port 50010: This port is used for Skype’s Web SDK (Software Development Kit) and is involved in Web-based interactions, such as instant messaging and file sharing.
UDP port 3478: Skype also uses UDP (User Datagram Protocol) port 3478 for some peer-to-peer connections, particularly for voice and video calls.

Unfortunately, I suspect the above won't help you much because I further suspect you have limited QoS understanding.  BTW, that's not a critique of you as it is not uncommon, as, IMO, QoS isn't well explained beyond often it's said we need it for real-time traffic like VoIP, Skype, video, etc., which often we do, but how it should be done is often explained superficially, and fundamental concepts glossed over.  Compounding understanding and/or appreciating QoS, is muddled, (in my not so humble opinion) by "cookbook" QoS approaches.

If I can further clarify anything about QoS, please feel free to post additional questions.

[a1111]

Hello Peter,

Thank you very much for the thorough response.

If end-to-end encryption is so common, then what's the use of NBAR2? Isn't the main benefit of NBAR2 that it's the only thing that can do analysis of L5-L7 information? But if that's encrypted, then how can it do that?

You mention that using both DSCP and CoS is "a horror." Is that because of the administrative overhead?

Without CoS, how can we apply QoS policies with L2-only switches?

To anyone else reading: Peter gave an interesting list of good use cases for CoS here:
https://community.cisco.com/t5/routing/when-to-use-cos-instead-of-dscp/td-p/2071708

"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."

Thank you. Have a nice week
Attila

[Joseph W. Doherty]

Hopefully Peter won't mind if I address a couple of your questions.

"If end-to-end encryption is so common, then what's the use of NBAR2?"

None, except for NBAR protocol matching which is just a "pretty face" for an ACL.

However, end-to-end tunnel like encryption, I believe, isn't yet all that common.  I.e. lots of end-to-end encryption might be just payload encryption (e.g. https) or network device encryption, used for site-to-site traffic across the Internet, where the network device can "see" the traffic before it's encrypted (and where pre-encrypted packets ToS is copied to network device encrypted packets).

Now, don't misunderstand, end-to-end encryption can be problematic for a transit network device.  Good example, I've stubbed my QoS toe on SSH (console) traffic vs. SCP traffic, between end hosts.  (When I want to distinguish between them, for QoS purposes, I now use bandwidth rate as a hint to which is which, and either being misclassified isn't much of a problem, because it's behaving like the other kind of traffic.)

"Without CoS, how can we apply QoS policies with L2-only switches?"

As I mentioned in my replies, some L2 switches support L3 ACLs and L3 QoS.  If they don't you either do without, or you do need L2 CoS.  (BTW, go ahead and provide common real-world examples, especially as L2 congestion is often also managed by just increasing L2 bandwidth.)

"To anyone else reading: Peter gave an interesting list of good use cases for CoS here:"

More theoretical than actual.  Using much IPX or NetBEUI (not over IP) now a days? CDP/LLDP from host to its directly connected edge switch, how does prioritization get used?  STP or VTP (IS-IS?) we're sure switch doesn't do something like PAK priority?

Certainly if you have a compelling need for QoS, and only L2 CoS is available, then you use it.  But is the need really compelling and you have no alternatives?

[Kasun Bandara]

Hi, this is one of fundamental question where everyone get hammered on process of understanding QoS. QoS helped lot to optimize the use of bandwidth by prioritizing the essential vs non essential  traffic. when technology improves and widened with encryption, dynamic requirements, availability of high bandwidth connections. 

as per explanation by @Peter Paluch and @Joseph W. Doherty , there is many other methods to detect different applications other than QoS parameters. these methods can use to optimize the traffic flow, but is it really required to do at L2 level is a debatable question. i propose to do application separation at firewall level which helps to manage traffic by application, service types and more. this is my personal suggestion.

[a1111]

Hello, 

Thank you for the response. Please see my second response, where I show the configuration of a learning material. It shows that traffic is matched using DSCP values. This setup has triggered my question. Although the wider context of QoS is very interesting and important, what interests me the most in this thread is how the correct DSCP values are set in the first place.

Thank you.

Attila

[Joseph W. Doherty]

Another try for:

"But, how is the correct DSCP value set for specific traffic?"

Simply, whatever is setting the DSCP value does it correctly.

Above may seem to be a circular answer, but it's actually the correct answer.

You mention trust boundaries, but all they are, are just a boundary where DSCP (ToS) markings are verified to be "correct" as the are passed along to subsequent devices in the trust domain.  If, markings are considered incorrect, an action is taken, usually to remark the traffic, but possibly such traffic is dropped.

Basically a trust policy (hopefully) insures all packets are tagged relevant to that traffic kind and that trust or QoS policy domain.

Keep in mind traffic may transit multiple trust or QoS policy domains.

Also keep in mind the ToS marking is but just a performance shortcut to identify traffic for different QoS processing.

OP also mentions L2 CoS, but pure L2 switches, that support CoS, mostly depend on upstream device to correctly set its value.  Their trust boundaries have almost no discrimination as they cannot "see" other than L2 information.

In my prior reply, I mentioned what are "correct" DSCP markings.  Well, one company I worked at, the network manager told me to treat the regional CEO's traffic "better".  Also, at the same company (which was a fairly large international company), I recall my (somewhat) extensive QoS policy made little use, if any, of a packet's ToS marking (at the time much contemporary Cisco devices didn't yet support DSCP, they did support IPPrec and sometimes the other ToS bits).

Lastly, also keep in mind, if you believe a trust boundary guarantees QoS will not be abused, that depends on your boundary policy and how clever the abuser is.

[a1111]

Hello Joseph,

Thank you very much for the thorough response.

"Ah, but what is the correct DSCP value that should be set?"

EF = voice, CS = call signaling, etc. In other words, the DiffServ suggested marking values, as shown in this table:

https://www.patrickdenis.biz/blog/ip-precedence-dscp-tos-lookup-table/

By the way, the table says IPP=CS, and CoS=IPP. The former is correct, as per the CCNA OCG:

...but how can the latter be? CoS is for dot1q, but IPP is in the L3 header.

Or do I misunderstand something?

Can you please elaborate why the CoS marking method should be avoided?

As for the "Skype Port Number Details" info: Skype has no registered port. If you go to IANA's website and download the list as a CSV, it becomes searchable. It doesn't mention Skype.

50010 is a dynamic port. 3478 is used by STUN, and it can partly (but not exclusively, if I'm not mistaken) be used in cases where voice and video applications are used, which is useful of course:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=66

My main confusion is caused by some learning material that showed QoS configurations. Specifically, the following two:

Config 1: 

Config 2: 

As you can see, this config doesn't use an ACL to match traffic, but DSPC values. Hence my question: where do those originate from? Which networking device? 

I'd be very happy to read any further thoughts you might have on this.

Thank you. Have a nice week
Attila

[Joseph W. Doherty]

"EF = voice, CS = call signaling, etc. In other words, the DiffServ suggested marking values, as shown in this table:"

"Suggested" is a critical word, but I had more in mind whatever values you choose to use to support your QoS policy.  If you want to use the RFC recommendations, or Cisco's recommendations (almost the same, but not the same), you can do so, but EF really represents a "class" of QoS treatment, not just VoIP.  If you had some other traffic, that needed EF like treatment, unknown to any RFC or Cisco recommendation, marking such traffic with EF would be fine, if that's the treatment you believe it should obtain.

BTW, there is some benefit to using RFC or Cisco recommendations, but the RFC actual sets aside more than half of the DSCP markings for private usage.

"By the way, the table says IPP=CS, and CoS=IPP. The former is correct, as per the CCNA OCG:"

Easy to get confused.  IPP uses the same 3 bits as CS, but they don't have the same meaning, although another recommendation is to try to use CS in a way that more or less conforms with IPP for backward compatibility.

Further, CoS for class of service might be use generically, such that a CS is a CoS, or might be used specifically when referring to Ethernet's .1Q priority code point.  Which, generally, would be used much as was an IP packet using IPP.

". . . but how can the latter be? CoS is for dot1q, but IPP is in the L3 header."

Again, CoS is really a generic term often also used specifically for .1Q PCP.

If this is still confusing, you might review:

https://en.wikipedia.org/wiki/Class_of_service

https://en.wikipedia.org/wiki/IEEE_802.1Q

https://en.wikipedia.org/wiki/IEEE_P802.1p

You will see much conceptional overlap.

"Can you please elaborate why the CoS marking method should be avoided?"

Two major reasons: first, it's often a PIA, and modern switches that support QoS, even "L2 switches" usually also support working with IP's ToS.  If you have the latter, why bother with the former?

"As for the "Skype Port Number Details" info: Skype has no registered port. If you go to IANA's website and download the list as a CSV, it becomes searchable. It doesn't mention Skype."

Ah, well the info I provided was from my browser's AI, summarizing search results.  Just as traffic with well known ports might not use them, conversely, other apps might also use ports "assigned" to another app.  The AI summary is likely noted common port usage for Skype, but for real Skype, you should be able to identify what it looks like.

"As you can see, this config doesn't use an ACL to match traffic, but DSPC values. Hence my question: where do those originate from? Which networking device?"

With just the information provided, no way to tell.  We might assume something upstream of this device's interface egress policy is marking the packets, but there's no guarantee of that.  I.e. packets hitting that egress policy might not be marked at all "correctly" or even all just having a default BE value.

BTW, the upstream marking might even be done on the device with the interface egress policy, using an interface ingress policy.  Or the host (non network device) sourcing the traffic might be doing the marking.

So, since we don't know whether the DSCP marking are correct, we need to try to insure they are (the point of a trust boundary/domain) or, in fact, use other IP packet attributes instead (e.g. ACLs, NBAR).