By John Bartlett I consult from my home office, and so my wife often overhears my phone conversations. She can repeat my lines about packet loss and jitter and how they affect your real-time traffic, even though her background is in biology and art. She asked me the other day why people still don't know this story, since she knows it so well. Great question. And the answer is that voice and video streams are really different from those data transaction streams we have managed for years, and they really do need special treatment.
By John Bartlett I consult from my home office, and so my wife often overhears my phone conversations. She can repeat my lines about packet loss and jitter and how they affect your real-time traffic, even though her background is in biology and art. She asked me the other day why people still don't know this story, since she knows it so well. Great question. And the answer is that voice and video streams are really different from those data transaction streams we have managed for years, and they really do need special treatment.Let's start with packet loss. I talk to a customer at least twice a week who says: My links are not heavily utilized, so I don't need QoS. Shouldn't be a problem. Voice is just a stream of packets, we know how to handle packets.
Unfortunately, not so.
TCP-based networks have packet loss. TCP is designed to overcome packet loss easily, and so as long as the loss is not excessive, TCP works well. In fact, TCP often creates packet loss as a way of finding out how much bandwidth is available. Remember that TCP is an end-to-end protocol, being executed by the sending and receiving computers. The network speed at either end of the link may be very high (100 Mbps or 1Gbps), but there may also be a slow-speed link somewhere in between. TCP starts off slowly, and increases its speed until packet loss occurs. Then it backs down to half that speed and starts to creep up again. This is how it figures out what is the available bandwidth, and it's how a TCP flow dynamically shares that bandwidth with other TCP flows.
Voice and Video streams don't use TCP, they use UDP instead. UDP does not recover from packet loss. It is what we call a 'send and pray' protocol, like the post office. We put those packets (or letters) into the network and just hope they get there. So the UDP stream doesn't know anything about the available bandwidth, and makes no adjustment if there is insufficient bandwidth available. When a bandwidth constraint occurs, packets are lost. Because UDP does not recover those packets, the receiver does not get all the data, and the voice or video quality is compromised.
But back to the customer with a low link utilization. Why should there be any packet loss if utilization is only 30%? Because the measurement of utilization is always an average over some period of time, often multiple minutes. The peak utilization occurs in bursts that can be very short, such as during the loading of a web page. During those bursts, TCP will try to use all the available bandwidth, and cause packet loss. I have seen packet loss on 10Gig backbone links that were 3% utilized, due to these TCP peaks.
So we use QoS to make sure the voice and video streams get through, even during those peak burst moments. Ya gotta have it!
