QoS applied on Windows Workstation for VOIP in addition to switch interface

[romanroma]

My company is rolling out a hosted VOIP solution, and I am learning about the DSCP levels. However, when QoS is applied at the switch interface, does not the workstation, Windows in my case need also to know about the DSCP levels when operating with a soft phone? I have found some references to Group Policy and QoS settings; however, what do folks do in the real world for QoS for VOIP phones?

[Stephanie Knoop]

I have implemented Cisco VoIP for several customers as well as for my own organization. In almost every case, customers were interested in ensuring that quality of service markings were in place and honored throughout their Network.

The group policy QoS settings are the way this is most easily done for Windows PCs. The reason for this is that Windows does not honor application markings. Mac computers do.

With so much traffic being generated from Internet best workstations and/or traversing the Internet, I have begun to question how important this is. The Opus codec that is used by the WebEx app and Jabber is much more resilient than older codecs. As the internet does not honor quality of service markings, just note that the only place they will really be relevant is on the corporate Network, or potentially within a VPN tunnel (which is itself subject to the variance of the Internet path it traverses).

One other thing to consider is that in my current experience CPU and RAM utilization of the PC cause more quality issues than most people's internet connections.

All this being said, I would still apply the GPO for the windows machines.

[romanroma]

@Stephanie Knoop 

Hi Stephanie,

It is very exciting to hear from someone who has implemented Cisco VoIP on such scale. Unfortunately, it is not Cisco VoIP (I wish), but a cloud vendor.

---

@Stephanie Knoop wrote:

The group policy QoS settings are the way this is most easily done for Windows PCs. The reason for this is that Windows does not honor application markings. Mac computers do.

---

I am not sure I understand - Does the group policy fix this behavior in Windows or is the Group policy just statically setting the type of traffic and what DSCP values should be used? I do have about 400 users that use Mac, but I will address them later when I address my Linux workstation, but thank you for warning me about the caveats of the different systems.

---

@Stephanie Knoop wrote:
With so much traffic being generated from Internet best workstations and/or traversing the Internet, I have begun to question how important this is. The Opus codec that is used by the WebEx app and Jabber is much more resilient than older codecs. As the internet does not honor quality of service markings, just note that the only place they will really be relevant is on the corporate Network, or potentially within a VPN tunnel (which is itself subject to the variance of the Internet path it traverses).

---

I am not sure what codec the vendor is using; however, they did send an implementation paper, which had all sorts of DSCP value settings and marking the traffic. I have no experience with VoIP; however, I would expect the protocol/codecs become more resilient with computer softphones, but I am not sure how hardware phones does it. It will be exciting to see! Yet, I totally understand what you are describing about on-prem vs off-prem quality control. I guess the idea is to make all efforts to have have on-prem path the BEST solution possible, but know that once it goes off site via Internet - is anyone's guess.

Do you see Internet provides being used more often that offer lower latency to be a driving factor when selection an ISP when voice/VoIP being used?

Thank you

---

---

[Stephanie Knoop]

@romanroma , sorry I missed a reply here.  

To this:

---

---

I am not sure I understand - Does the group policy fix this behavior in Windows or is the Group policy just statically setting the type of traffic and what DSCP values should be used? I do have about 400 users that use Mac, but I will address them later when I address my Linux workstation, but thank you for warning me about the caveats of the different systems.

The group policy does not "fix" the behavior, but does what you go on to do what you suggest.  It matches a profile of "policy conditions" and then sets the DSCP value accordingly.

On other matters, @Joseph W. Doherty  is explaining better than I could   Hope all this is helpful.

Example for a Cisco implementation a couple years ago:

Computer Configuration > Policies > Windows Settings > Policy-based QoS > QoS Policies

GPO: Softphone QoS Marking
Policy Name	DSCP Value	Throttle Rate	Policy Conditions
CIPC Signaling	24	Not Specified	Protocol	TCP
			Application	communicatork9.exe
			Source IP	Any
			Destination IP	Any
			Source Port	Any
			Destination Port	2000
CIPC Voice	46	Not Specified	Protocol	UDP
			Application	communicatork9.exe
			Source IP	Any
			Destination IP	Any
			Source Port	16384:32767
			Destination Port	Any
Jabber Signaling	24	Not Specified	Protocol	TCP and UDP
			Application	CiscoJabber.exe
			Source IP	Any
			Destination IP	Any
			Source Port	Any
			Destination Port	5060:5061
Jabber Voice	46	Not Specified	Protocol	UDP
			Application	CiscoJabber.exe
			Source IP	Any
			Destination IP	Any
			Source Port	16384:24575
			Destination Port	Any
Jabber Video	0	Not Specified	Protocol	UDP
			Application	CiscoJabber.exe
			Source IP	Any
			Destination IP	Any
			Source Port	24576:32767
			Destination Port	Any

[Joseph W. Doherty · Accepted solution]

Ideally, the source of the traffic would mark ToS, as desired, but if not, network devices, that support QoS, often can analyze traffic and change a packet's ToS, again, as desired.

Further, even when the end device marks ToS, it's often good practice for the network, ASAP, validate the marking and, if not as desired, change it.

Dedicated "hard" VoIP phones, generally, mark their packets' ToS.  Often you can configure them to mark ToS as desired.

To your later posting's question:

"Do you see Internet provides being used more often that offer lower latency to be a driving factor when selection an ISP when voice/VoIP being used?"

Internet providers, almost always, don't offer service guarantees.  So, in theory, they are not the best choice for supporting VoIP.  That said, they often cost much, much less then private cloud providers and, often, you can run VoIP on them, successfully.

BTW, latency, alone, often isn't as critical to VoIP quality as low jitter and/or low drops.

When using the Internet, to support VoIP, something that can be done to insure much better VoIP performance is to use a separate (dedicated) Internet link for just the VoIP traffic.  Since VoIP often doesn't use much bandwidth per flow (even G.711 doesn't exceed about 100 Kbps), having a dedicated link is often not a big expense.

[romanroma]

@Joseph W. Doherty 

HI Joseph, Thank you for such insight and details. I have a few more questions now, since you got me thinking.

If I turn QoS on and enable all the MLS features - does that mean frame/packets coming will be processed according to the QoS MLS feature set, even if the frames/packets are not matches - but examine by the DSCP value already in the frame/packet? I am a little confused, as to how an AF23 (example) will be processed (a) before and  (b) after MLS feature set is turned on. I am worried that if I turn on/add the MLS configuration features, that traffic will start to be processed/examined differently - even if no policy matches. AF23 has a high drop probability - so if an application is marking the frames/packets with AF23, do I have to create a policy to remark AF32 to something AF21(example) so it does not get dropped as easily? I might be confusing myself, but the network currently does NOT have QoS/MLS enabled at any level.

I did some packet captures, and it does appear that Windows is marking everything as BF, or so I saw in my packet capture.

---

@Joseph W. Doherty wrote:

BTW, latency, alone, often isn't as critical to VoIP quality as low jitter and/or low drops.

---

I thought jitter was caused by packets/frame getting queued up, or by latency in the circuit. So even if I have GREAT bandwidth, 10Gbps ISP, I could still get jitter due to the ISP and how the handle the packets.

Thank you.

[Joseph W. Doherty]

Generally, when QoS is activate, all frames and/or packets are processed by it.  What varies is whether the default treatment is different from when QoS is inactivate or whether for frames/packets marked differently, whether they receive different treatment due to their markings.

Jitter is generally caused by intermixing different traffic flows going to the same egress interface.  So, yes, that's due to queuing.

Additional latency is also cause by queuing, but its also caused by the time takes to send the transmission across copper or fiber.