UDP broadcast / multicast with respect to unicast behavior (dropped packets)

Question

I have a built-in device (source) that sends a stream of (audio) data in pieces of 20 ms (= about 330 bytes) using UDP packets. Thus, the network volume is quite low - about 16 Kbps (almost a bit due to the overhead of UDP / IP). The device launches the lwIP stack (v1.3.2) and connects to the WiFi network using the Wi-Fi solution from H & D Wireless (HDG104, WiFi G-mode). The destination (receiver) is a Windows Vista PC that is also connected to the Wi-Fi network using a USB-WiFi dongle (WiFi G-mode). A program is running on the PC that allows me to track the number of dropped packets. I also run Wireshark to directly analyze network traffic. Currently, no other clients are actively sending data over the network.

When I send data using broadcast or multicast, many packets are discarded, sometimes up to 15%. However, when I switch to using UDP unicast, the number of dropped packets is negligible (<2%).

Using UDP, I expect the packets to be removed (which is normal in my audio application), but why do I see such a big difference in performance between broadcast / multicast and unicast?

My router is WRT54GS (FW v7.50.2), and the PC (receiver) uses the TEW-648UB network adapter with a trend network operating in G-WiFi mode.

Answer 1

This seems to be a well-known WiFi issue:

Quote from http://www.wi-fiplanet.com/tutorials/article.php/3433451

802.11 (Wi-Fi) standards define multicast support as part of asynchronous services. An 802.11 client station, such as a wireless laptop or PDA (not an access point), starts multicast delivery by sending multicast packets in unicast 802.11 data frames directed only to the access point. The access point responds with an 802.11 acknowledgment frame sent to the source station if no errors were detected in the data frame.

If the client sending the frame does not receive confirmation, the client will retransmit the frame. In multicast, the leg of the data path from the wireless client to the access point includes the recovery of transmission errors. The 802.11 protocols provide reliability between stations both in the infrastructure and in special configurations using unicast data frame transmissions.

After receiving the unicast click click frame from the client, the access point transmits the data (which the initiating client wants for multicast) as a multicast frame that contains the group address as the destination for the intended recipients. Each of the destination stations may receive a frame; however, they do not respond with signs. As a result, multicast does not provide a complete, reliable data stream .

The lack of confirmation when multicasting means that some data sent by your application may not reach all destinations, and there are no indications of a successful reception. This may be good, however, for some applications, especially those where everything is in order to have data gaps. For example, continuous telemetry streaming from a control valve monitor may occasionally skip status updates.

This article has more information: http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf

One very interesting side effect of multicast implementation (at the WiFi MAC network level) is that as long as your receivers are connected, you will not experience any problems (due to confirmation on the receiver side that the connection is truly unicast) . However, with WiFi receivers (as in my case), packet loss is enormous and completely unacceptable for audio.

Answer 2

There are no ack packets in multicast and therefore no retransmission of lost packets. This makes perfect sense, as there are many receivers, and this is not how they can respond at the same time (air is shared like coaxial Ethernet). If they were all sent sequentially using some snooze scheme, it would consume all your bandwidth.

Packet loss UDP streaming is a well-known task and is usually solved using some direct error correction. Recently, a class known as fountain codes such as Raptor-Q promises the problem of packet loss, in particular when there are several untrusted sources for data at the same time. (example: multiple Wi-Fi access points covering an area)