Is QoS Becoming Irrelevant?
Changes in applications and their locations are conspiring to make it increasingly difficult to implement QoS.
Evolving UC communications requires increasingly complex quality-of-service strategies. Have we reached the point where QoS is too complex for normal use? Do cloud services over the Internet mean that QoS is irrelevant?
The differentiated services (DiffServ) model of QoS prioritizes different types of traffic so that time-critical applications like voice, video, and interactive business applications receive priority over traffic flows that aren't as time critical. In the DiffServ model, a Differentiated Services Code Point (DSCP) value is set within the IP packet header. While up to 64 different per-hop behaviors can be specified with DSCP, most QoS designs use only six to 12 of them. (Note: An Integrated Services QoS model is also available, but it hasn't gained widespread acceptance.) IETF standards documents describe each of the per-hop behaviors, one of them being a priority queue that's typically reserved for time-critical protocols like voice. Some QoS designs may also prioritize critical device communications, such as from bedside monitors in healthcare or process control alerts in manufacturing plants.
The DSCP version of QoS consists of three basic functions: classification, marking, and queueing. Classification, which is typically performed at the ingress edge of the network, identifies different classes of traffic. Once a packet has been classified, its headers are marked by adding a QoS tag. Performing classification and marking at the network's edge allows successive network equipment in the forwarding path to make forwarding decisions efficiently -- meaning, they don't have to repeat the classification function. Packets are then queued according to the applied classification and marking, with higher-priority packets selected for transmission over congested links before lower-priority packets.
It's important to note that QoS only applies during congestion, when more packets need to be sent over a link than the link can handle. The network equipment only needs to make a queueing decision when multiple packets need to be sent on a link. Ideally, the highest-priority packets get selected to go first, followed by lower-priority packets. The 64 traffic classes defined by DSCP provides a lot of flexibility.
Endpoints can add marking to packets that they originate, but the lack of a good security model forces most organizations to implement classification and marking at the point where endpoints connect to the network (the ingress access layer). Unfortunately, classification is becoming more and more difficult to implement.
Desktops, laptops, tablets, and phones are now sources of low-priority data traffic, higher-priority business data, and high-priority voice and video. At one point, network designers could assign phones to separate address ranges and use the packet addresses for classification. But with the lines between data and UC&C blurring, building reliable classification rules is becoming more and more of a challenge. A possible answer is to use network-based application recognition. But with integrated applications becoming prevalent, even that solution may not be appropriate in all circumstances.
Recall that QoS is used only when congestion occurs. This, along with the complexity of QoS configuration, leads many organizations to consider increasing link speeds to the point that congestion never occurs. However, this line of thinking ignores the presence of microbursts. A microburst is a brief period in which multiple packets arrive in a burst. A good example is when a workstation downloads a picture or a large document. Or it can be a graphic-intensive Web page where the browser opens multiple TCP connections to speed the population of the page.
A typical enterprise-based application environment may have 10-Gbps links out to the access layer and 1-Gbps links to the desktop. TCP performs its initial handshake and a few packets are sent. The window size doubles on each round-trip time. A burst of 64 packets is possible after only seven round-trip times. A 10G server infrastructure can easily deliver a big burst that can overwhelm the queues on a downstream 1G interface, causing undesirable packet loss and higher jitter than normal. TCP will handle the resulting packet loss by adjusting its transmission rate, but UDP will continue to blast away since it has no congestion feedback mechanism. QoS will need to be used if the packet loss due to microbursts grows too large.
Continue to Page 2: Where QoS works, where it doesn't work, and more