The first technology in the Zielie Deep Dive Series discusses Quality of Service (QoS). QoS is a funny thing, often it’s kind of like a fuse. If everything is running correctly you don’t need it and it doesn’t do anything. This means that you can’t be sure if it's right until something happens, and you do need it (and it better be right). This allows a lot of AV over IP integrations to work just fine when the QoS isn’t right. This lulls people into a false sense of complacency, similar to putting pennies in place of a fuse and saying it’s OK because you have been doing it a long time and your house has never burned down before (don’t try this at home).
Often, I get asked to help adjust integrations that don’t work as they are expected to. I have recently been brought into situations where fixing QoS fixed integrations which just didn’t work right. When I looked into why the systems were configured as they were, I found that the integrator “followed the directions”, but the directions did not consider that there would be multiple types of traffic on the network. As I looked further into it, I could not find a single “how to QoS” in the AV industry that accounts for a complex network (by complex I mean Audio and Video on a network). This stems from the fact that it is very rare for a manufacturer to document or produce training that considers a network with any other traffic than its own, unfortunately, that is not the world I live in.
The QoS series follows the sequence, outlined above, over five parts. I believe it covers the subject as it applies to AV carried on IT infrastructure, although if I receive feedback that there are use cases that I didn’t consider, there could be more.
QoS Part 1
Ethernet traffic is often visualized as water flowing through pipes, where each stream is consistent flow of traffic which can characterized by the bandwidth. Using this model, as long as the sum of the bandwidths is less than the size of the pipe, everything is fine. In reality, bandwidth values are averages over time, real network traffic is bursty. Rather than a smooth-running hose as the source for each data flow, it might be better to think of it as a randomly set pulsating shower massage with a toddler running the spigot.
Network equipment is designed to deal with this issue by forming a queue, holding onto packets, and forwarding them when there is available bandwidth. During a burst, excess traffic builds up and the queue gets longer. During lulls, the queue gets shorter. Over time the average is achieved.
Ethernet network protocols are best effort, they do not make guarantees if or when the traffic will arrive at the destination. For normal IT applications, this is not a problem, no one will notice if their email shows up 100ms later. But networked media, real-time audio and video distribution over ethernet, is deterministic, it needs to display a new video frame every 33ms or play out a new audio sample 48,000 times per second. If the data is not there in time it is the same as not getting there at all. Networked media needs to jump to the head of the queue, skipping the line, when the line gets too long.
Quality of Service (QoS) comprises a set of tools and techniques which allow network devices to be configured to identify traffic that needs to be prioritized and to forward traffic based on the needs and priorities of the organization configuring the network. Ethernet traffic is serial, packets traverse the network one at a time. There is nothing you can do about the order of the packets coming into a network device, but QoS allows a network device to forward the packets in a different order than received. This wouldn’t really make a difference if you only had one input, but if there is a queue of lower-priority packets from another input already in the queue, the ability for high-priority packets to “skip the line” is valuable.
In general, the benefits of QoS increase with scale and criticality. A network with lots of switch hops, or high bandwidth traffic benefits more from QoS. Applications with strict low latency or jitter requirements like PTP timing and audio traffic between DSPs also benefit from using QoS.
To receive the benefits Quality of Service benefits you need a few things.
1: Network equipment that supports QoS.
2: A decision (in order) of which network flows (traffic types) should be prioritized.
3: A method to identify the network flows to be prioritized.
4: A method to allow high-priority packets to be placed at the front of the queue.
Most QoS used In AV networked media distribution is performed at the network switch. To take advantage of QoS features you will need a managed switch. The QoS features available vary greatly between manufacturers and models and should be considered when choosing a switch for AV installations.
The term ‘managed switch’ was originally a technical term indicating if the switch could be configured as opposed to an unmanaged switch which can only have a single (preset) configuration. This was sufficient when the primary use case for switch management was creating VLANs and perhaps IGMP snooping.
As technology advanced, creating more potential features to be managed, and features from “high-end” network equipment became feasible in more cost-effective devices, the managed switch segment fractured. The industry seems to have settled on the term “Smart Switch” to denote a switch that allows some level of management (lower than their “managed switches”) Often the smart switches may be subdivided into multiple levels with increasing feature sets. The same is often true with the higher-end switches where market differentiating terms like ‘Lite’, ‘managed’ and ‘fully managed’ indicate various feature levels. The actual features included at each level vary by manufacturer and often between models of the same manufacturer.
It is no longer safe to assume that specifying a ‘managed switch’ will provide the features required for your integration. Best practice dictates that the specific requirements that a switch must support are outlined and matched against prospective solutions. The practice of just buying the “top of the line” switch may negate this due-diligence requirement but may come with a hefty price tag.
The decision of which traffic types should be prioritized is administrative and depends on the mix of applications and organizational priorities. In a converged network the traffic types and markings must be agreed upon by any network stakeholders to ensure that there are no conflicts or resource limitations.
Identification of the chosen traffic is performed using one or both of two methods, classification and marking.
Classification identifies the traffic to be prioritized using a special type of Access Control List (ACL) called a class map. The class map consists of a set of rules to match a combination of values from the network headers which combine to perform a unique “fingerprint” of the traffic. These rules, which define the class are called the class attributes.
The ACL is applied at the network ingress, the port at which the traffic first enters the network.
Marking involves setting values in the headers of the packets to be prioritized so the switches can recognize which packets should receive priority treatment. By convention, higher marked values indicate higher priorities, but any marking could be mapped to any priority. The advantages of marking are that identifying traffic using markings uses significantly less processing than classification, and that marking only needs to occur once and then every device in the network path can use the markings to identify the prioritized traffic. For this reason, traffic is usually marked after it is classified. Technically all traffic is marked, un-marked traffic just has a marked value of zero.
Markings could also be pre-applied by the source device. This feature is common in AV gear which benefits from QoS. By default, network devices do not trust the markings coming into a port because anyone could make their data highest priority. For a switch to use externally marked packets, the ingress port must be configured to trust marked packets this includes ports connected to trusted source devices and ports connected to other switches which have already classified and marked or trusted the marked traffic as it enters the network.
High priority traffic “jumps the line” using a system of multiple queues.
Each marked values is mapped to one of multiple egress queues at the switch level (a common configuration for all ports). Higher queue numbers designate higher priorities. The number of available egress queues varies from device to device but is generally between four and eight. Classified and/or marked packets of similar priority level may need to be assigned to the same queue.
A process called Scheduling, configured at the port level, dictates the number of packets to be forwarded from each queue, with higher queues allowing higher numbers. Each queue is accessed in turn until the number has been reached or the queue is empty. This allows the higher priority traffic (in higher queues) to jump ahead and also makes it more likely that low priority packets will be discarded if there is too much congestion.
Most AV integrators first find that they need to implement QoS in installations that have networked audio like Dante, Q-Sys, Ravena or AES67 to pass audio between Digital Signal Processors (DSPs) and/or edge devices. These protocols all synchronize the playback of audio across multiple devices using Precision Time Protocol (PTP) to a defined latency. If congestion causes too much delay in either the PTP or audio packets, the result can be that the audio will not be played. The simplest way to implement QoS is to have the source devices mark the packets. Fortunately most audio transport protocols support QoS marking in the source devices.
QoS Markings
There are two places in the network headers where QoS markings can be applied.
1: The 802.1Q tag in the Ethernet header, used to identify VLAN membership, has a 3 bit field (0-7) known as Class of Service (CoS) specified under IEEE 802.1p.
2: The IP header has an 8 bit field called Type of Service in IPv4 and Traffic Class in IPv6 for QoS Values. This field is used by several types of QoS including Differentiated Services Code Point (DSCP), IP Precedence (IPP), Type of Service (TOS), and Explicit Congestion Notification (ECN). There is no indication within the field to indicate the type of marking, so each device using this field must be configured to interpret it correctly.
Differentiated Services Code Point (DSCP) also called DiffServ, is the most common method of marking for QoS today and its use is considered best practice. Differentiated means to recognize a difference. In DSCP Data flows are marked for prioritization with values from 0-64 using the first 6 bits of the IPv4, Type of Service field or the IPv6, Traffic Class field so the network can recognize the packets that need special handling.
Note: In QoS, a data flow is comprised of the packets of a single protocol all sharing the same source and destination address at layers and 3 and 4 (IP address and port). While many data sessions are bi-directional, data flows are unidirectional and may be characterized as inbound or outbound data flows. The data flow is the smallest possible unit of differentiation in DSCP. It is not at all unusual for an application to have several data flows, for example a device receiving Dante may have multiple inbound audio data flows from different devices It will have two Precision Time Protocol (PTP) data flows (or more if it’s the leader) and multiple control data flows.
Traffic Flows are the combination of all data flows of a single type. They are typically defined by a higher layer protocol, for example Dante audio, but sometimes generalized to lower protocols like UDP.
DSCP values have no inherent meaning, however common practice dictates that higher priority traffic is assigned higher values. IETF RFC 2597, Assured Forwarding (AF), is a common DSCP traffic marking scheme, used primarily for routing.
Assured Forwarding designates the first three DSCP bits as the Class Selector, giving eight values from CS0 – CS7, typically assigning each class to a queue ignoring the last three bits. Classes 1-4 have three additional Assured Forwarding Values set by the next two bits. Packets marked with AF values are assigned to the same queues as their class value, but are designated are designated as traffic to be dropped as congestion rises and their queues are filled. The drop probability value is an exception to the “higher values have higher priorities”, drop probability rises with DSCP value within a class.
Note: Switches do generally not support the Assured Forwarding priority scheme, but it is important to recognize the markings because often DSCP values are specified by their AF name rather than the DSCP value. Some switches only mark the 21 named values
Conclusion
At this point you should understand the concepts and some of the vocabulary of QoS, as Illustrated above. Maybe enough to get you through a meeting without looking stupid while understanding enough so you know what to Google. In the next installment, QoS part two, we will start to discuss how QoS is configured in the real world.
