ionary

Voice over IP -- inevitable or impractical?

Fred Goldstein,  December 2002












ions  





Using the Internet to carry voice, or even just using its protocol, thus seemed a perfect fit for the times.  It was like putting "dot com" on the end of your phone number!...














...data traffic is bursty and unpredictable, while voice traffic is steady and predictable...












vis
.











... Voice and other streaming applications thus do not slow down when the network is congested -- the sender doesn't receive the network's only slow-down signal, which is a dropped packet....












...VoIP networks have to be engineered for very low loss... it raises the cost, compared to a loss-tolerant pure data network. This is supposed to save money?...





Voice
G.729/G.723
RTP
UDP
IP
PPP or Ethernet
Physical link
Typical VoIP protocol Stack (complex)





Voice
PCM
Physical link TDM
Circuit-mode telephony protocol stack (simpler!)





...Circuit-switching technology has improved as fast as VoIP has.  Modern circuit switches are cheap, compact, and flexible, just like VoIP "softswitches"....  

Ever since VocalTec hit the market with its Sound Blaster-based phone package in 1995, Conventional Wisdom has held that Voice over IP will inevitably eclipse circuit switching and render it obsolete.  Certainly there has been big money bet on it. Lucent and Nortel both invested heavily in it, starving investment in circuit-switched products, while dozens of startups have been created to exploit the technology.  Cisco and 3Com have bet fortunes on it, and a significant minority of corporations have even adopted IP-based PBX systems for their internal use. Consultants such a pulver.com have made it the focus of their business.  The press loves it too; Network World Fusion, a respectable trade paper, sometimes seems to give it more space than it does to its traditional data networking focus.  So it must be inevitable, right?  Only dinosaurs and Luddites still think that older "legacy" technologies like ATM or, heaven forbid, circuit switching, are worthy of further investment.

Count me as a friend of Ned Ludd and Fred Flintstone.  I don't think VoIP will replace circuit switching.  Indeed I dare say that its star is already beginning to lose some of its luster.

VoIP had lots of friends

I can understand why so many people wanted VoIP to succeed.  For one thing, it hit the market at a great time.  While the Internet Protocol took over the ARPAnet in the early 1980s and was widespread in corporate and educational networks within a few years, the Internet itself only "went public" in 1994.  It met with incredible pent-up demand, catching the public eye. This, combined with cheap capital looking for the Next Big Thing to invest in, led to the dotcom boom. Internet Service Providers in that era didn't have to make money; there was plenty of equity available to cover losses. So they didn't have to worry about whether or not their pricing models were long-term viable.

And businesses everywhere were attempting to cash in on the Internet boom by giving themselves names that ended in ".com".  This was supposed to have a sort of middlebrow "cool", as it were, or perhaps "k3w1", as the net's "31337" (elite) might have spelled it. Compare that to the stodgy old telephone business, with its suits, its boring old SONET gear and, at least for established players, profits.  How uncool!

Using the Internet to carry voice, or even just using its protocol, thus seemed a perfect fit for the times.  It was almost like putting "dot com" on the end of your phone number!  Lucent, interestingly enough, summed this up on the web site for its (now-defunct) PathStar VoIP system.  The features/benefit table gave two benefits for using Voice over IP:  "Access to capital" and "Wall Street image"!

Early VoIP products were largely purchased with one key end-user benefit in mind.  It was a way to bypass long-distance charges.  Telephone companies have, for decades, overpriced long distance calls as a way to subsidize underpriced local service.  VoIP provided a path around this, and thus attracted the same kind of audience that selected MCI's pioneering Execunet service in the 1970s.  So VoIP was marketed in two ways. Corporations and computer users bought VoIP systems and gateways which could be used for private communications, while a number of long-distance carriers sprang up who used VoIP as their technology.  

For corporate users, VoIP could actually save money, compared to switched long distance.  So could conventional tie lines, time-division multiplexors, Voice over Frame Relay or Voice over ATM. But with most data traffic using IP, there was a certain obviousness about using spare bandwidth for voice.

For carriers, it was much less compelling.  The telecom boom of the 1990s resulted in a worldwide glut of long-haul fiber optics.  So the wholesale cost of bandwidth fell. New circuit switching technology and startup vendors, and a glut of capacity, have also lowered the cost of circuit switching.  If domestic circuit-switched long distance can be had wholesale for under two cents a minute, how much could be saved by using IP?  VoIP carriers charged lower price for their lower-tier service, but not necessarily because their costs were lower. The discount VoIP carriers have thus been among the first to fall.

An impedance mismatch

Lots of 1990s-era companies have failed in the bursting of the bubble economy.  But VoIP's core problems are technical, not financial.  The key point to remember is that packet switching, especially connectionless packet switching as embodied in IP, was invented with a goal of being unlike the telephone network.  Data and voice are different; the telephone network is pretty lousy at carrying data, so IP was invented to do the job instead. Trying to run data on a voice network is inefficient, like an electrical impedance mismatch; so's the converse.

The key difference, of course, is that data traffic is bursty and unpredictable, while voice traffic is steady and predictable (at least for the duration of a call).  But it's even worse than that.  IP itself has no traffic management capabilities whatsoever!  It's called a "best effort" service, but that's a euphemism for "no particular guarantees at all". Packets go into the network and some of them come out. Some don't. It's absolutely acceptable for an IP switch (a router) to throw packets on the floor, and it must be done silently (no error messages returned). All of this follows from IP's connectionless nature. Connectionless means that every packet is self-contained, with its own source and destination addresses in the header, so no connection has to be established before a packet is forwarded.  Since there's no connection, there's no context, in the router, for each packet.  Thus there is no way to assure any kind of quality of service within IP per se.

For data, this is not a bad thing!  That's where TCP (Transmission Control Protocol) comes in. TCP only runs in the end systems, the computers at either end of the connection.  TCP keeps track of individual data packets, and retransmits packets that aren't acknowledged on time.  So the application gets all the data.  Eventually.  But what's a second or two of delay to a web page, email message or file transfer?

But note TCP's other purpose, congestion control. What happens when the data flowing in to a router is faster than the path going out?  Think of an Ethernet port leading to a DSL or modem, or a LAN gateway leading to a T1 line.  If the Ethernet-equipped device kept blasting away, the slower circuit would be overwhelmed.  In the early days of LANs, a curious phenomenon was noted.  A number of high-speed computers would send packets, not get acknowledged on time, and resend.  The network would discard packets, causing more retransmission, causing more discard, causing more retansmission... leading to congestion collapse.  This was not pretty!

A solution was found and adopted in TCP in the mid-1980s.  It's called the slow start algorithm. When a packet is lost, the sending side assumes that the network is congested, and thus at least one router in the path had zero room to store additional packets.  So the sender retransmits only one packet.  If it is acknowledged on time, then it may send two packets before getting an acknowledgment (a window).  Then the window grows until another packet is lost and the cycle repeats itself.  This leads to a stable Internet, provided that everyone plays by the same rules.

Voice over IP doesn't use TCP. It can't, because it can't tolerate the delays in retransmission. A lost voice packet results in a gap in the received audio.  Voice and other streaming applications thus do not slow down when the network is congested -- the sender doesn't receive the network's only slow-down signal, which is a dropped packet.  So too much voice traffic can literally push data off the net!

Nowadays the problem is usually viewed the other way around, as if the Internet needed to improve itself to better support voice.  Lost data packets are retransmitted, and the end user doesn't know about it unless the loss rate gets very high.  Lost voice packets detract from the quality of the call.  So VoIP networks have to be engineered for very low loss. This is possible, of course, but it raises the cost, compared to a loss-tolerant pure data network. This is supposed to save money?  Or is the tail wagging the dog?

Adding QoS is a workaround

A commonly proposed solution is to add "QoS" (quality of service) options to the data stream. One method is to assign voice a  higher priority (such as a Type of Service bit).  This is okay so long as there's not too much of it; for instance, on a corporate network.  It doesn't work on most public ISPs, or between ISPs.

Another option is to use a QoS layer such as MPLS.  This works, because it puts a connection-oriented layer beneath IP, and then separates voice and data into different flows.  But then it's not IP doing the work, it's a lower-layer protocol.  MPLS is really another form of Frame Relay.  And when you're using Frame Relay or MPLS, VoIP's packet overhead is wasted; VoFR works well by itself.  So does VoATM. These connection-oriented protocols are capable of metering and controlling traffic flows better than IP.

Finally there's the overhead issue.  IP, being connectionless, has rather long headers. (IP version 6, which has some big money backing too, has much longer headers, and does nothing to help QoS or VoIP performance. Or security for that matter. Don't believe articles that say otherwise.)  So when voice is encapsulated in IP, there's a lot of overhead.  The percentage of the packet that is overhead depends on the length of the packet payload.  Longer payloads are more efficient, but require more packetization delay, which impacts the conversation quality.  So a 64 kbps voice conversation, when routed over IP, can consume up to around 100 kbps of bandwidth. (This is what some full-quality long-distance carriers, with ample dedicated fiber bandwidth, do, because VoIP capacity on  some newer switches is  cheaper than circuit switching.) Many (though far from all) VoIP systems, such as Vonage and VocalTec, use low-bit-rate compression to shrink the payload.  This tends to worsen voice quality, and is incompatible with fax and modems.  Some clever systems use header compression, sometimes reducing the complex VoIP headers (including the UDP and RTP layers) down to as little as two bytes. That's efficient, and handy for access links such as dialup or ADSL, but by that point, with the IP header removed, it's not really VoIP, and it doesn't work on Internet backbone links.

Niche technology

VoIP supporters tend to confuse the putative benefits of their technology with the benefits of a newer business model.  The old-line telephone companies were certainly not masters of rapid technological progress, nor of flexible business practices.  But is VoIP the only alternative?  

For some purposes, it is a good idea.  There are niche applications for which VoIP is quite suitable, such as remote PBX extensions and call center agents, and international calling into places where conventional bandwidth is overpriced.  But for many purposes, such as ordinary home telephone lines and even most PBX systems and domestic long distance, it's a forced fit. Even VoIP evangelist Jeff Pulver now concedes that it's best for specialized applications, which he calls "purple minutes", while circuit-mode POTS (plain old telephone service) will remain viable.  Circuit-switching technology has improved as fast as VoIP has.  Modern circuit switches are cheap, compact, and flexible, just like VoIP "softswitches".  While VoIP systems are indeed more flexible than, say, a 5ESS, that's a result of their modernity, and their newer control structures, not the use of IP to carry the actual call traffic. Circuit and ATM-based switches such as Taqua, Metaswitch, and Convergent (not to mention Sonus, if you use it in circuit or ATM mode, though it's usually marketed for its VoIP capabilities) allow carriers to provide full-quality circuit-based telephony without the overhead of minicomputer-era legacy switching systems from Lucent and Nortel.  They also provide "softswitch" control capabilities. And for corporate use, circuit-mode PBXs today are dirt cheap.

So I suggest that readers take the trade press' obsession with VoIP with a boulder-sized grain of salt.  Weigh all of the alternatives, and don't assume that IP is the answer to all questions.  The dotcom era is over; today, business and technical realities are more important.  End user demand for telephone service remains steady. In a cutthroat market, a lower-quality service is hardly the formula for competitive advantage. Remember that "legacy" today all too often means "technology that actualy works".

ionary