Implementing DSCP (The Versatile Way)
In QoS part two, we went through setting up QoS, trusting the incoming DSCP markings. If you trust incoming markings, all packets are assigned to queues as marked. For this method to be effective, two conditions must be met at each incoming switch port with traffic to be prioritized:
1. The packets are correctly marked. This happens in one of two ways.
o The source device marks the packets with the DSCP values the way you want.
o The packets come from another switch that has marked the packets with the DSCP values the way you want.
2. No other packets entering the port have DSCP markings that conflict with any desired DSCP markings.
In this installation of the QoS series, we will go through the information to be gathered and the decisions to be made when one or both of these two conditions are not true. This information will be required whether you are configuring the switch yourself or handing it off to the IT team. We will cover the actual switch configuration process in the next installment.
Everything Works Until it Doesn’t
Differentiated services code point (DSCP) values, often referred to as marks, are set in the first 6 bits of the IPv4 header Type of Service (TOS) field. They are intended to stay with the packet through the entire network journey, allowing each piece of networking gear to identify which traffic needs special handling. When a packet first reaches the QoS managed portion of the network, you can either trust the DSCP values that the packet arrived with, or you can change the values, re-marking the packets with values that fit your QoS management scheme.
In simple, one protocol, well segmented AV networks, you will generally not have to manipulate DSCP marks in the switch configuration. (You could, and it would work just fine. I probably wouldn’t, but you could)
Eventually you will come across a scenario where the source device cannot or does not apply the DSCP markings you need (more common with video than audio) or that there is a conflict in the chosen DSCP markings of two different products that can’t be addressed in the product configuration.
There is a third scenario where re-marking the traffic becomes necessary. It is when the administrator of the network you are trying to use, refuses to trust inbound markings to their network and requires that any DSCP markings are applied by the network. This is not just the admin being stubborn, they are doing their job according to best industry practices. The admins of a large network cannot predict or audit all the various devices or configurations that are being plugged into their networks. By not trusting the inbound markings and applying them based on the traffic parameters, they are ensuring that QoS will work properly in all cases. It is unreasonable to expect that the IT admins understand the subtleties of AV traffic on a network, They will need guidance for you to get the QoS results you need.
The Scenario
To illustrate and explain the process of the information gathering and QoS decision making I have created an example of a small AV installation. The TMUBPS (Totally Made Up but Plausible Scenario) network consists of two switches, each with two VLANs, one IT VLAN connecting normal PC traffic and an AV VLAN with audio, video and control. Both VLANs are connected to a router providing more connectivity to other networks.
This example includes multiple AV traffic types that might benefit from QoS; synchronized audio and real time video, both of which will have some type of session control, and AV device control. We also have computers that are on the IT network that could bring their own QoS requirements.
In the real world, this integration probably wouldn’t generate enough congestion to make QoS important, but let’s assume we are just illustrating a subset of a large network that justifies QoS. The only difference is that the configurations will be applied in many places rather than one or two.
When implementing QoS from scratch, it is usually much easier when you gather all the required information in advance, so that you can anticipate where any tradeoffs need to be made. The required information for the TMUBPS QoS implementation is as follows.
The synchronized audio is Dante, running on the Spurious Audio platform
o There is a DSP with Dante TX and RX ports
o There are small Dante devices with either send or receive only
o There is a computer running Dante Controller on the AV VLAN
The real-time video is the latest product from Pretendtron the Vapor3000
o The Vapor3000 distributes the video using RTP multicast addressed to UDP port 1776.
o The Vapor3000 can also send (non-Dante) streaming audio sourced through the HDMI input to a separate RTP multicast addressed to UDP port 1778. This audio can be received by the DSP as a raw audio stream.
The Pretendtron Controller controls the Vapor3000 using TCP port 3000.
The switches support four QoS queues.
We don’t have conferencing, as in dedicated VoIP or videoconferencing codecs, in this example, but that application could be running on the PCs. They may be candidates for QoS, but that configuration is out of the scope of this article.
A quick search on the internet came up with several detailed discussions of QoS for various cloud conferencing platforms, for example:
In these systems, QoS could be marked in the computer by configuring policy objects, or in the switch using the methods we are discussing in this article. In most organizations, these types of decisions and configurations are not made by the AV people, but without your guidance, they may not be made at all.
Planning and Strategy
Two days of troubleshooting can save you two hours of planning.
The first step in planning the QoS configuration is to list the data types that will be carried on the network and decide which traffic types need to be prioritized and what the priority order is. Remember, in a converged network, AV is probably not the only traffic type that needs to be prioritized. There may be other stakeholders who must be involved in the decision.
The table below shows some common network traffic types used in Pro AV along with attributes that we will use to set the priorities.
Priorities are situational and you may make other choices depending on the mix of technologies and the importance of the content carried.
Notice I have listed three kinds of audio. In my priority list, I put Synchronized Audio, protocols where the playback on different devices is synchronized, like Dante or AES67, highest because they have a very low tolerance to delay. Conferencing (VoIP or the audio portion video conferencing) is second, also due to the need for low delay, in this case on echo canceled audio. Third, I listed Real Time Audio (audio that is immediately distributed, often as the audio channel of a video source), because the delay tolerance typically is higher. On my list, Audio on demand (like a webinar or YouTube) falls under everything else, because it is generally TCP and highly buffered so it generally does not need help.
In general, these are the tie-breakers:
Later 2 Timing (PTP) is highest
Network management is higher than content
Audio is higher than video
Content is higher than control
Session control is higher than device control
UDP is higher than TCP
The outcome of this step is a prioritized list of DiffServ classes.
A class is a group of things with common properties that can be differentiated (recognized as different from one another) from other classes. In this case the classes are differentiated by traffic type. DiffServ classes are assigned names to identify them in the configuration. It is best practice to make those names descriptive. The table above shows my preliminary list of DiffServ classes.
The second step of planning the QoS configuration is to decide what DSCP value will be assigned to each traffic class. When doing this we take into consideration the number of queues available to us. There will often be more traffic classes than there are queues. Queues, not DSCP values define priority. When setting DSCP values with the end intent of QoS prioritization, the following realities can guide your decision.
Multiple classes can be marked with the same DSCP value
o A class can only be assigned one DSCP value on an inbound interface
o A class could be assigned different DSCP values on different interfaces
Multiple DSCP values can be assigned to the same queue
o DSCP queue assignments are global across the switch
The table below shows the DSCP value assignments for each class and the associated queue assignments. It is organized in a format that will aid in the configuration, showing which devices are the source of the traffic flows to be assigned to the class and indicating (green / red ) whether or not the traffic flow is marked before coming into the switch.
Looking at my decisions you will see that I chose to put Dante audio and program audio (audio from the video encoders) in the same queue. I could have set the program audio the same DSCP value EF(46) as the Dante audio which would save me a Queue assignment, but I chose to set it to a different value AF(31). I did this because it makes my configuration management easier. If I want to use a different queue assignment in another switch, further along in the network, the two traffic flows are already differentiated. I also chose to put device control in Queue 1 along with video. In the real world, I probably would have left it at CS(0) and kept it in Queue 0, but in this case it illustrates a point I will make later really well, so I did it this way.
Assigning DSCP values is somewhat arbitrary. Numbers have the meaning you give them. The general convention of higher DSCP values having higher priority can be easily overridden in the DSCP to Queue assignment. When assigning DSCP values to traffic flows, best practice still dictates you follow the accepted conventions.
In QoS Part 1 I discussed the IETF RFC 2597 (Assured Forwarding) standard, which assigns a standardized meaning to certain DSCP values. That standard is really designed for routers and is most useful in applications where all of the traffic between sites is aggregated to a link, like building-to-building or campus-to-campus links.
Even though Assured Forwarding rules generally don’t apply at switch level QoS we are using in Pro AV, being aware of and using the IETF RFC 2597 is important for the following reasons.
The Assured Forwarding naming convention is often used instead of the DSCP value
o Example: indicating CS1 instead of 8
It is commonly used alongside the DSCP value in the format AF_name(DSCP_value)
o Example:CS1(8)
Some switches only offer the ability to map the 21 Assured Forwarding values to queues
o Some others make it easier in the UI to map the 21 Assured Forwarding values to queues.
o Others don’t care, but they still list the AF values in the configuration.
DSCP assignments are persistent through the network, even if RFC 2597 compliant assignment doesn’t matter at your device, it may matter further downstream. By using the 21 AF values, you ensure interoperability.
Differentiate the Classes
The final piece of information to gather are the Class Differentiators. The switch needs to be able to sort out which packets coming into the switch need to be marked. The switch looks at the packet headers and compares the values in the incoming packet headers to a configured set of values looking for a match. When a matching packet is found, the new DSCP value can be marked on the packet.
We need to identify which combination of header attributes (values) can uniquely differentiate (identify) each packet flow we want to mark. Each packet flow we identify is called a class combination of values are called class attributes. The actual header fields which can be used, may vary slightly between switches, but the table shown to the left contains a good representative sample of the fields we have to choose from.
We decided above that we need to mark three types of traffic flows, program_audio, video, and device control. Each identified set Using the information from the TMUBPS we can identify the class attributes for the prog_audio and video classes.
The Vapor3000 distributes video using RTP multicast addressed to UDP port 1776.
The Vapor3000 distributes prog_audio using RTP multicast addressed to UDP port 1778
We only need to differentiate the class from the other traffic coming into the port. We could probably get away with matching just the protocol and destination port, but for this exercise, I also matched against the range of multicast addresses (224.0.0.0 – 239.255.255.255) in case some other application uses UDP port 1776 or 1778.
Next, using the information from the TMUBPS we will identify the class attributes for the control class. This will be applied both to the controller and to the video encoders and decoders under the assumption that the video devices talk back to the controllers. (It’s my TMUBPS, I can assume what I want, besides I already told you I was including this to make a point)
The Pretendtron Controller controls the Vapor3000 using TCP port 3000.
At first glance it seems pretty straight forward, match on TCP and destination port 3000 and move on, but there is a twist. In TCP, when the Vapor3000 sends it’s reply to the Pretendtron Controller the source port will be 3000 and the destination port will be whatever random port the Pretendtron Controller chose to use as a source port. We don’t know what that will be, so we need to identify two sets of class attributes. In this case, I chose TCP port 3000 as my matching criteria.
How this is configured, varies from switch to switch and will be covered in QoS Part 4.
In this case, I chose TCP port 3000 as my matching criteria.
IPv6 Note > IPv6 traffic is classified the same way as IPv4 traffic, but because of the different header fields the values to match are different. Generally, IPv4 and IPv6 ACLs are created and applied separately. If you needed to have a traffic flow that works with either, you will probably need to create a class for each.
You may ask…
“I know you made up the products and ports, but how do I get that information in the real world?” That was a really good question. Manufacturers should have a document called something like “Ports and Protocols” which describes all this.
Conclusion
The things we covered in this article apply whether or not you are ever touching a switch for configuration. You can think of it as a needs analysis.
In the next installment of QoS we will go over the concepts, vocabulary and sequence of getting the configuration for DHCP marking into the switch, using the information gathered here.
