Strangely, SSL VPNs can help VoIP call quality
by Matthew Gast
Last summer, I wrote that reliability should not always be a goal in network design, especially with applications like VoIP. "Better late than never" is true for a stream of bits you need to reproduce perfectly, but it's not the case for a stream of bits you're trying to deliver in less than 200 milliseconds. If something is late, it's better to forget it and move on.
Well, as the saying goes, the difference between theory and practice is greater in practice than in theory. The always-interesting Joel Snyder recently tested VoIP call quality through a variety of VPNs for Network World. From the pure theoretical perspective, going through a VPN technology that ensures in-order delivery should offer no help to call quality, and would be expected to cause some problems, especially on low-reliability networks that have frequent loss and retransmission.
That's not what he found. After finding that call quality improved when using SSL, he used a network analyzer to find out what was going on:
In every case, adding an SSL VPN to a VoIP call over a good broadband network improved call quality. So in effect, wrapping a VoIP call in SSL gives it more structure, kind of like the rind of good Brie. What we had not counted on was the huge difference between what VoIP requires (64Kbps) and a typical broadband connection of 500Kbps or more. Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality.
(I'll disagree with Joel on the cheese analogy, because I hate Brie. Rind or not, I find it disgusting.)
To see the improvements, check out the pop-up graph about half-way through the article. It's a graph that compares the mean opinion score (MOS), a measure of call quality, to an unencrypted reference for four test scenarios. Data points farther to the right are better.
The biggest surprise came from the test on the "bad" network (the orange data points in the picture). SSL VPNs delivered a signifcant performance improvement. On the graph, you can see that the orange data points are far to the right of the unencrypted reference line, and offer the widest gap between the reference line and the measured SSL-protected quality.
The best news of all our testing came when we set up the bad network, representing the lower end of quality of the broadband services. In this test, TCP and a high-speed network again came to the rescue. All but three of our SSL VPN vendors also improved the unacceptable call but took call quality up enough for the call to be considered acceptable. In these tests, we saw as much as a 45% to 50% improvement in call quality.
Interestingly, the call improvement is specific to SSL. Juniper's product offers two operational modes, SSL (which is based on TCP, and therefore does re-order packets) and IPsec ESP (which is an IP datagram service, and does not). The SSL mode resulted in significantly better call quality as long as the network was providing decent service. In the last test, with a very poor quality network, the datagram services provided the best call quality, but it was still so bad as to be unusable.
I only have one minor technical nit to pick with the article. It states that a phone call requires 64 kbps. It requires 64 kbps of data payload throughput, but adding on the encapsulation headers for UDP and RTP pushes the required throughput to 80 kbps. (See Table 1 at the bottom of the first page in my VoIP capacity analysis for more codec details.) As the test shows, 100 kbps is not enough to sustain an 80 kbps stream with any kind of quality because it has no headroom.
The moral of the story is that quality of service through overprovisioning is not such a bad idea after all. The key appears to be having enough burst headroom to recover from the impairment and fill in the gap. When an error occurs, you need to be able to detect it and retransmit enough data quickly to fill in the gap and move on. At six times the required data rate (500 kbps), that's easy. At 25% higher than the required data rate (100 kbps), it just isn't possible.
To confirm that the headroom capacity is what matters, a great follow-up test would replace the 80 kbps G.711 codec with, say G.729, which only requires 24 kbps. At that point, the network would have four times the necessary capacity to transmit a voice call, so there is significant excess capacity that can be used to retransmit error recovery packets.
|Never trust anyone who hates Brie. ;-)|
It seems to me that a protocol that tries harder than UDP to guarantee delivery but doesn't impose all of the strictness of TCP would offer the best quality...
TCP will always deliver your packets, no matter how late (or sever the connection). In addition, it will always hold up later packets until previous ones are successfully delivered. It would be slick if we had a protocol that allowed out-of-order delivery and would negotiate retransmissions within a certain timeframe.