QoS Problems With VoIP Over Wireless

Posted by: Eric Siegel

A fascinating article, "Coexistence of VoIP and TCP in Wireless Multihop Networks," was just published in the June 2009 edition of IEEE Communications Magazine (vol 47, issue 6, pp 75-81; the authors are Kyungtae Kim and Dragos Niculescu [NEC Laboratories America] and Sangjin Hong [Stony Brook University - SUNY]).

Burton Group has been warning that using VoIP over wireless LAN (VoWLAN) is tricky because "QoS alone cannot completely regulate the bandwidth provided to flows on a wireless network... a single wireless station on a shared wireless channel can degrade performance for all other stations on the channel...." We've been saying that: "A reasonable alternative is to avoid voice over WLAN altogether, substituting cellular voice, possibly with femtocell or in-building repeater technology." (See the Burton Group reports "Quality of Service (QoS) Alternatives Demystifying Radio Management;along with the Technical Position "Quality of Service".)

This new article shows that the problems created by VoIP over wireless LAN are even worse than I'd thought. The authors did some experiments, and they found that TCP and VoIP do not coexist well on a wireless LAN. TCP's large frame sizes, large receive windows (RWIN), bursty traffic, and retransmission when a frame is lost make it interfere with short, evenly-spaced VoIP frames. The TCP frames will dominate radio transmissions because of the frame lengths and frequency during a burst. (Frames can't be interrupted after they start to transmit; therefore, long, frequent TCP frames will dominate over infrequent, short VoIP frames.)

Worse, the self-interference and half-duplex characteristics of a wireless LAN system increase the probability that the long TCP data bursts will need retransmission, further increasing their burstiness and their domination of the channel when compared to short VoIP frames. (Self-interference occurs when a single flow interferes with itself as it travels over the wireless system. When transmission and reception share the same half-duplex radio channel, a stream may compete with its own acknowledgements for radio time, delaying or destroying some data and acknowledgement packets. If transmission hops over a couple of radio links in sequence, then each hop's transmission may interfere with transmissions on other hops that are within reception range; a flow may interfere with itself.)

The authors of the new article show that no standard type of queuing algorithm in routers adjacent to the wireless network, even Priority Queuing (PQ), can handle these problems. And they also show that five standard TCP variants used in end stations (TCP Reno, TCP Vegas, TCP Westwood, TCP CUBIC [used in Linux], and C-TCP [used in Windows Vista and Server 2008]) do not handle these problems. In all cases, the TCP flows dominate and degrade the VoIP flows.

What should be done? Well, Burton Group has recommended that cellular should be considered instead of VoWLAN. The authors of the study make additional suggestions that sound interesting, but they also warn that none of them is a panacea - they all are only partial solutions, at best. The authors warn that "the methods examined here have straight-forward application only when the wireless capacity is fixed. In reality, the capacity is highly variable." They also warn that P2P, uploading traffic, and interactive streaming, such as Skype, that use TCP for voice will complicate the situation even more.

The paper's most interesting recommendations are:

• Use unusually-small TCP receive windows and eliminate TCP bursts on the wireless LAN. This may need to be done by gateways at the wired:wireless interface. The gateway would use smaller TCP packets and a small receive window; it would also use a buffer to ensure that any bursts were smoothed out and that TCP packets were spaced out to reduce self-interference and interference with VoIP frames.
• Use a traffic shaping system. The article says, "After a packet of size pkt_size goes out over the air, the next packet is scheduled no earlier than pkt_size/R. The gateway chooses R based on the network status to determine how much to send as well as when to send."

Other papers have recommended different methods, such as doing priority queuing at all intermediate wireless nodes and combining that with traffic shaping.

At this time, it seems to me that avoiding sharing the same channel between TCP and voice is still the best solution.