Reliability is not always desirable (or, the problems of encrypting VoIP)

by Matthew Gast

Related link: http://www.educatedguesswork.org/movabletype/archives/2005/07/why_voip_over_s.ht…



Many network engineers know that having multiple reliable layers is a waste of effort. (One classic essay is Why TCP over TCP is Bad Idea.) Eric Rescorla, one of the leading experts on SSL and a general all-around security guy, recently analyzed the problem of transmitting VoIP over an SSL VPN, which can be generalized into a set of problems faced when layering a streaming protocol on top of a reliable transmission protocol.

This is one of the rare cases in computing where reliability is an undesirable attribute. Reliable protocols retransmit data so that you can get all of the bits in the same order they were transmitted. The implict assumption is that it is better to wait a bit to get the data correctly and in order. In most cases, that assumption is true. I'd rather have the bits making up what I read or the pictures I see in the order they were transmitted, even if I have to wait slightly longer. For most types of data, you might as well give up if you can't get the bits in the right order.

Streaming transmissions are a bit of a different animal. The stream must go on. The value of any particlar bit diminishes very quickly with age. If bits don't arrive on time, you may as well just forget about them and move on. Retransmissions gum up the works by holding up the bits you want right now in favor of the lost bits you probably don't care about any more. In the meantime, you still have to do something to keep the stream chugging along. In streaming protocols, the old adage "better late than never" does not apply. Instead, it becomes "better never than late."

The quickly diminishing value of late bits is one of the big reasons that many voice packages use UDP. Lost data stays lost. The endpoints don't use valuable network capacity trying to find it by retransmitting the lost data. Keeping lost data out of the picture is one of the advantages that IPsec has as a VPN technology for voice. IPsec is an unreliable (meaning no automatic retransmissions) protocol. If IPsec packets are lost, a higher layer protocol has to make the decision to retransmit, but IPsec will not throw sand in its own wheels.

I don't know how much, if any, trouble the additional reliability causes. Most of the people I know using VoIP are either subscribers to a service (my provider uses UDP), or are encrypting the call with IPsec (which also refrains from retransmitting). I don't have any direct expereiencewith VoIP over a reliable protocol. (For that matter, I don't have any good indirect experience, either.) TCP is good at providing high average utilization, but it might deliver that capacity in bursts. TCP is not well suited to delivering small bits of capacity at frequent intervals. My guess is that the reliability causes more severe problems in the case of network congestion because it causes TCP to slow down and retransmit more often.


Do you send your voice over TCP, SSL, TLS, or any other reliable protocol?