While the IC’s research organization looks into adding security to cloud environments, in the here and now, intelligence agencies are sharing more data.
Your agency’s network may have been designed to support only best-effort data applications, but your users want you to run voice and video traffic over it as well. They’re expecting you to provide a reliable transport for time-sensitive multimedia services such as video conferencing, video distribution and Voice over Internet Protocol.
For multimedia packets to travel seamlessly on the network, voice and video packets must be given priority over other, less-time-sensitive traffic, such as e-mail or web browsing. If only it were that simple. The truth is, implementing and managing quality of service leads to a number of complex and often thorny issues that must be considered and resolved before QoS becomes a stalwart protocol on the network.
There’s a smorgasbord of QoS protocols to choose from — among them, Differentiated Services (DiffServ), Integrated Services (IntServ), Resource reSerVation Protocol (RSVP), IP Precedence and IEEE 802.1p/q, to name just a few.
This networking Tower of Babel makes it seem as if each QoS protocol was developed in a vacuum. That’s because the various protocols are oblivious to one another. DiffServ knows nothing of IP Precedence or RSVP. RSVP is ignorant of 802.1p/q — and so on. Unless your network relies on one consistent underlying protocol, you’re going to have a difficult time deploying QoS on your campus. Factor in vendors’ various implementations of these protocols and it’s possible to have a total lack of interoperability between QoS services running on the same network.
QoS is a networkwide issue, not for just a single network box. To work its magic, QoS must be consistently applied throughout the network — that is, deployed end to end. This means that every router and all the Layer 3 devices that handle packets within the network must be QoS aware. If one router or device in the chain doesn’t support QoS, or supports it differently than the other devices in the network, it becomes difficult, if not impossible, to establish QoS from end to end.
Not only does the core network need to understand and implement QoS, but the edge devices and end-user applications must be uniformly involved in the process as well. This can be a tough assignment, particularly when different protocols are used to support QoS in the same network.
Finally, network hardware has to be not only QoS aware, but also QoS capable. This requires network devices to have multiple internal queues — typically no fewer than four. It does little good for QoS to be implemented in a device unless there are sufficient queues to hold the packets. Some network devices have only one or two queues, causing time-critical packets to sit idle, awaiting their turn on the network.
Clearly, for effective deployment you need a consistently managed central QoS policy. And this is not necessarily an easy task — in fact, it can become quite political. QoS administration can require the techniques of a polished negotiator, the firmness of a boot-camp sergeant and the resolve of Abraham Lincoln.
Policies have never been easy things to develop and implement on networks. QoS policies are certainly no exception. There are a number of difficult issues that must be resolved, such as how to handle the many intricacies of QoS and how QoS policies will be administered. QoS policies have to be agreed upon, adopted and then enforced.
Once you have established a unified, enterprise QoS standard and have the policies in place to support QoS across the organization’s network, you’re almost there. Now you need a way to manage QoS policies.
Centralized management of QoS entails policy creation, validation, deployment and monitoring. This helps assure a fair and equitable environment for time-sensitive applications to traverse the network. Policy management tools, or tools that prioritize QoS by applications or groups, ease the administrative burden associated with centralized QoS management. They can form the basis for enterprisewide QoS policy administration through the use of technologies such as the Common Open Policy Service protocol.
You’ll need an effective policy management tool, such as Cisco Systems’ Quality of Service Policy Manager. QPM, or a tool like it, not only provides centralized management of QoS, but also provides comprehensive QoS provisioning and monitoring capabilities. This is important not just to assure that every application is playing fairly on the network, but also to assure that network administrators can actually manage the network.
Network staff need the ability to fine-tune network delays, adjust the delay variation (jitter), allocate bandwidth appropriately and control packet loss. All of these parameters are required for successful QoS deployment and optimal utilization of network resources. The use of a policy management tool integrates the management of these parameters into a single application, thus adding clarity to the QoS picture.
Speaking of network resources, there is a running debate among some network managers as to whether it is better to have large bandwidth capability in the network or well-deployed QoS. In truth, you need both. True, a network that has unlimited bandwidth will allow all packets to get through immediately, even if they are associated with low-priority traffic, such as e-mail. On the other hand, with effective QoS policy implementation when networks become congested, critical traffic can get through. Therefore, decent bandwidth and effectively implemented QoS make a winning combination.
Delivering QoS guarantees for high-priority voice and video also means that some applications will be riding in a coach-class seat. QoS is more about who rides in the back than it is about who gets into first class. Most would agree that the middle seat in the rear of an aircraft isn’t the most desirous seat assignment. But if the flight is full, someone has to sit there. This can be another contentious issue when it comes to administering QoS.
Depending on the impact this has on users and their applications, the network staff can expect to bear the brunt of some political heat. All the policies and agreements in the world cannot prevent the firestorms that result when someone gets poorer quality than they expect or feel they deserve.
The good news is that many data applications are quite happy to reside in the back of the aircraft. E-mail systems, for example, don’t particularly care if a packet is delayed for a few milliseconds as a video packet flies past it. The message still gets through in a timely manner. The same is true of web browsing and instant messaging, as long as it is text-based and not using high-bandwidth streaming audio or video. There’s even better news, in that modern network equipment tends to do a better job of supporting QoS.
By using QoS policy management, network managers can apply a mix of QoS policies to protect mission-critical application performance across the network. It does carry several challenges, risks and liabilities. This shouldn’t deter your implementation plans, but you do have to implement QoS thoughtfully and in a consistent manner. Doing so requires the support of your user community.
QoS is important to users today and will be even more so tomorrow. The key is to realize that QoS, like the protocols that support it, is still an emerging technology. Much of it is here today, but more of it will be available tomorrow. Given today’s hunger for bandwidth and the proliferation of multimedia services, when fully implemented QoS finally arrives on the network, it will not be a moment too soon.