I identified four parts of a QoS implementation in my blog on January 15th. Number four on my list is testing and monitoring. Lets take a look at why testing for real-time traffic is not only different, but so crucial to a successful QoS implementation.
I identified four parts of a QoS implementation in my blog on January 15th. Number four on my list is testing and monitoring. Lets take a look at why testing for real-time traffic is not only different, but so crucial to a successful QoS implementation.When I say real-time traffic, I am referring to traffic streams that are used to recreate a real-world ongoing event, such as a video image or an audio sound. These events don't just happen and go away, they are continuous, and need continuous updating. Interactive real-time, where there is someone at each end of a conversation, makes the timing of reproducing those signals very important. Both voice conversations (VoIP) and video conferencing are interactive real-time applications. For these applications we need to deliver the data necessary to reconstruct the voice or video, and we need to deliver it quickly and consistently, to maintain the sense that we are both in the same room and our communications are instantaneous. This isn't about voice-mail, this is about talking!
OK here is the problem. These real-time streams are carried by UDP, not by TCP. This means that if the network has packet loss it will directly affect the quality of voice and video streams. UDP does not recover lost packets like TCP does. With TCP-based applications, a little packet loss means a little slow-down in the responsiveness of the application. Many times we don't even know this is happening. But with voice and video, packet loss means poor quality.
Traditional data networking test tools are not designed to find the problems that can cause packet loss on real-time streams. The only way to really know if a network path is losing packets is to test the actual stream, or to simulate that stream with equivalent data. The measurements must take into account the whole network from end to end.
This is where the indignant network engineer usually raises his hand and says "My tools are monitoring packet loss so I am all set." Let's take a closer look.
Usually what this engineer means is that he has a tool which is checking packet drops on key routers in the network. The tool is probably looking for output queue drops on critical links, like where large numbers of links come together, or at boundaries where traffic flows from a high speed link (LAN) to a lower speed link (WAN). This is good information, but may be insufficient.
Packet loss can occur anywhere along the line from one endpoint to another. A very common cause of loss is a half/full duplex mismatch. The mismatch causes a layer 2 error which is not detected by the Ethernet collision mechanism due to the mismatch. The packet is dropped because it is incomplete or its checksum is bad. No router queue ever sees this packet. The router reports that of all packets it received, it dropped none, but this packet never got there!
The same can be true for a noisy copper line, bad Ethernet cables (Cat 3 where Cat 5 is required) or even for a router interface that is not being monitored. But the application is still missing data and the voice or video quality still degrades.
So a new type of testing tool is required. I'll talk more about these tools, how they work, who makes them, and how to use them in my next blog.
