Forum

Hey guys, I have a question I could not answer for myself.

It is well known that VoIP applications use UDP because it's useless to retransmit voice packets. To quote Coleman and Westcott, it's "better never than late" when it comes to VoIP. In a Wi-Fi network, there is no difference between voice or data. Both are considered data frames, because they have payload. So both would have to be retransmitted if there is a L1-2 problem. That kinda goes against the VoIP mentality if these data frames are actually voice packets.

So, what really happens in VoWiFi deployments? Are there proprietary solutions to this? Or are these packets acknowledged/retransmitted in layer 2, but not at layer 4+?

L2 retransmissions are much faster than L4 retransmissions, and not retrying voice frames has the possibility of actually degrading call quality in some scenarios. Admittedly, it is not ideal to retry some frames, and retries are the source of many performance problems on Wi-Fi. But some percentage of retries is almost inevitable, and voice quality won't suffer if the retries aren't excessive.

Some APs allow you to configure the number of retries, which could help reduce latency and jitter. However, this could cause breaks in the voice stream on a busy medium.

Thanks for the info, @@ron!! Sorry I didn't answer before, that was rude.

So basically there is no way to avoid it, the retries will happen at L2, but hopefully they will not add too much delay to the data flow.

I'd like to thank Leomezza too for helping me understand it through chat.

No worries, glad it's making more sense for you! :-)

There is a way to avoid Re-transmission of any access category (BE,BK,Vo,VI) in the QOS settings on the STA or AP in WLAN. You have to disable the Ack policy for the access category you need.
If you do so, there would be no ack send for the data frames received on those access categories.

I have done this in Ralink Chipset (STA) with the Ralink supplicant in XP.

I think you mean disabling the retrasmission and not the ACK correct?

Disabling the ACK will disable the re-transmissions, rite ?

If there is no ACK, then the device will keep transmitting the data packets like everything is UDP. This might be useful with Voice/Video traffic over WLAN.

Makes sense, since ACKs (actually, the lack thereof) drive retransmissions.

I don't think I can agree with you.
Let's use two examples:
1) AP with re-transmissions disabled
Data flow from AP to STA (client)
UDP packets (voice packets) are sent and even if the STA does not send an ACK the packets are never retransmitted. Packets not retrasmitted are lost since UDP does not care about packet loss.
TCP packets are sent and even if the STA does not send an ACK the packets are never retransmitted by the AP. Packets not retrasmitted by the AP are retrasmitted by the sender device according to TCP lack of acknowledgment.

2) STA with ACK disabled
Data flow from AP to STA
TCP or UDP packets are sent continuously until the AP gives up according to the vendor retrasmission behaviour since there is no way for the AP to know if the packets were actually received (no ACKs). Never heard about disabling ACK but it will sure causes a lot of airtime consumption.

If ACKs are blindly disabled, then scenario 2) holds true. However, QoS stations can set the service class to QoSNoAck to disable layer 2 acknowledgements. See 802.11-2012 5.1.1.1 (it's also referenced throughout the standard where appropriate).